Vitalik bài viết kỹ thuật mới: Tầm nhìn về ví lý tưởng - Nâng cấp toàn diện từ trải nghiệm xuyên chuỗi đến bảo vệ quyền riêng tư
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik bài viết kỹ thuật mới: Tầm nhìn về ví lý tưởng - Nâng cấp toàn diện từ trải nghiệm xuyên chuỗi đến bảo vệ quyền riêng tư
Ví tiền là cửa sổ kết nối người dùng với thế giới Ethereum, và tôi cho rằng việc tập trung vào các thuộc tính bảo mật và quyền riêng tư là có giá trị nhất.
Chuyên sâu báo cáo Web3Xin chân thành cảm ơn phản hồi và đánh giá từ Liraz Siri, Yoav Weiss cùng các nhà phát triển ImToken, Metamask và OKX.
Một lớp then chốt trong ngăn xếp cơ sở hạ tầng Ethereum là ví tiền, nhưng thường bị các nhà nghiên cứu và phát triển L1 cốt lõi đánh giá thấp. Ví chính là cửa sổ giữa người dùng và thế giới Ethereum; người dùng chỉ có thể hưởng lợi từ bất kỳ thuộc tính phi tập trung, chống kiểm duyệt, an toàn, riêng tư hay thuộc tính nào khác mà Ethereum và các ứng dụng của nó cung cấp nếu bản thân ví cũng sở hữu những thuộc tính này.
Gần đây, chúng ta đã chứng kiến sự tiến bộ đáng kể về trải nghiệm người dùng, bảo mật và chức năng của ví Ethereum. Mục đích bài viết này là trình bày quan điểm cá nhân tôi về một số đặc tính mà một ví Ethereum lý tưởng nên có. Đây không phải danh sách đầy đủ; nó phản ánh xu hướng "mật mã phe cánh" (cypherpunk) của tôi, tập trung vào an toàn và riêng tư, và gần như chắc chắn chưa đầy đủ về mặt trải nghiệm người dùng. Tuy nhiên, tôi cho rằng danh sách mong ước ít hiệu quả hơn so với việc đơn giản là triển khai và lặp lại dựa trên phản hồi khi tối ưu hóa trải nghiệm người dùng, do đó tôi cho rằng tập trung vào các thuộc tính an toàn và riêng tư là có giá trị nhất.
Trải nghiệm người dùng giao dịch xuyên L2
Hiện nay đã có lộ trình ngày càng chi tiết nhằm cải thiện trải nghiệm người dùng xuyên L2, bao gồm phần ngắn hạn và dài hạn. Ở đây tôi sẽ nói về phần ngắn hạn: những ý tưởng có thể triển khai ngay cả về mặt lý thuyết hôm nay.
Ý tưởng cốt lõi là (i) gửi tiền xuyên L2 được tích hợp sẵn, và (ii) địa chỉ riêng theo chuỗi và yêu cầu thanh toán. Ví của bạn nên có thể cung cấp cho bạn một địa chỉ (theo phong cách của bản thảo ERC này), như sau:
Khi ai đó (hoặc một ứng dụng nào đó) cung cấp cho bạn địa chỉ theo định dạng này, bạn nên có thể dán nó vào trường "người nhận" trong ví rồi nhấn "gửi". Ví nên tự động xử lý việc gửi dữ liệu bằng mọi cách có thể:
-
Nếu bạn đã có đủ loại token cần thiết trên chuỗi đích, hãy gửi trực tiếp token
-
Nếu bạn có loại token cần thiết trên một chuỗi khác (hoặc nhiều chuỗi khác), hãy sử dụng các giao thức như ERC-7683 (thực tế là một DEX xuyên chuỗi) để gửi token
-
Nếu bạn có loại token khác trên cùng hoặc các chuỗi khác, sử dụng sàn giao dịch phi tập trung để chuyển đổi thành đúng loại tiền tệ trên đúng chuỗi và gửi đi. Việc này cần sự cho phép rõ ràng của người dùng: người dùng sẽ thấy họ đã trả bao nhiêu phí và người nhận nhận được bao nhiêu.
Mô hình giao diện ví khả thi với hỗ trợ địa chỉ xuyên chuỗi
Phần trên áp dụng cho trường hợp "bạn sao chép-dán địa chỉ (hoặc ENS, ví dụ vitalik.eth@optimism.eth) để ai đó gửi tiền cho bạn". Nếu một dapp yêu cầu đặt cọc (ví dụ, xem ví dụ Polymarket này) thì quy trình lý tưởng là mở rộng web3 API và cho phép dapp đưa ra yêu cầu thanh toán riêng theo chuỗi. Sau đó, ví của bạn sẽ có thể đáp ứng yêu cầu đó theo bất kỳ cách nào cần thiết. Để trải nghiệm người dùng tốt, cũng cần chuẩn hóa yêu cầu getAvailableBalance và ví cần nghiêm túc cân nhắc mặc định lưu trữ tài sản người dùng trên chuỗi nào để tối đa hóa độ an toàn và thuận tiện khi chuyển tiền.
Yêu cầu thanh toán riêng theo chuỗi cũng có thể được đưa vào mã QR, ví di động có thể quét. Trong các tình huống thanh toán tiêu dùng trực tiếp (hoặc trực tuyến), người nhận sẽ phát hành mã QR hoặc gọi web3 API, biểu thị “tôi muốn X đơn vị token Y trên chuỗi Z, kèm ID tham chiếu hoặc callback W”, ví có thể tự do đáp ứng yêu cầu đó theo bất kỳ cách nào. Một lựa chọn khác là giao thức liên kết nhận tiền (claim link), nơi ví người dùng tạo mã QR hoặc URL chứa ủy quyền nhận tiền từ hợp đồng trên chuỗi của họ một lượng tiền nhất định, nhiệm vụ của người nhận là tìm cách chuyển khoản tiền đó vào ví của mình.
Một chủ đề liên quan khác là thanh toán gas. Nếu bạn nhận được tài sản trên một L2 chưa có ETH và cần thực hiện giao dịch trên L2 đó, ví nên có thể tự động sử dụng các giao thức (ví dụ RIP-7755) để thanh toán gas trên chuỗi nơi bạn có ETH. Nếu ví muốn bạn thực hiện thêm nhiều giao dịch trên L2 trong tương lai, nó cũng nên chỉ sử dụng DEX để gửi một lượng ETH nhỏ (ví dụ vài triệu gas) để các giao dịch tương lai có thể trực tiếp chi tiêu gas tại đó (vì như vậy rẻ hơn).
Bảo mật tài khoản
Một cách tôi hình dung thử thách bảo mật tài khoản là một ví tốt nên hoạt động hiệu quả trên hai phương diện: (i) Bảo vệ người dùng khỏi tin tặc hoặc hành vi ác ý từ chính nhà phát triển ví, và (ii) Bảo vệ người dùng khỏi những sai lầm của chính họ.
Từ "lỗi" ở bên trái mang nghĩa vô tình. Tuy nhiên, khi tôi nhìn thấy nó, tôi nhận ra nó rất phù hợp với ngữ cảnh, nên quyết định giữ lại.
Giải pháp ưa thích của tôi cho vấn đề này, trong hơnmột thập kỷ, luôn là ví khôi phục xã hội và ví đa chữ ký với kiểm soát truy cập phân cấp. Tài khoản người dùng có hai lớp khóa: khóa chính và N người giám hộ (ví dụ N = 5). Khóa chính có thể thực hiện các thao tác giá trị thấp và phi tài chính. Hầu hết các người giám hộ cần thực hiện (i) thao tác giá trị cao, ví dụ gửi toàn bộ giá trị trong tài khoản, hoặc (ii) thay đổi khóa chính hoặc bất kỳ người giám hộ nào. Nếu cần, có thể cho phép khóa chính thực hiện thao tác giá trị cao thông qua khóa thời gian.
Trên đây là thiết kế cơ bản, có thể mở rộng. Các khóa phiên và cơ chế quyền như ERC-7715 có thể giúp hỗ trợ sự cân bằng khác nhau giữa tiện lợi và bảo mật cho các ứng dụng khác nhau. Kiến trúc người giám hộ phức tạp hơn, ví dụ với nhiều khoảng thời gian khóa thời gian ở các ngưỡng khác nhau, có thể giúp tối đa hóa khả năng khôi phục tài khoản hợp pháp thành công đồng thời giảm thiểu rủi ro bị đánh cắp.
Trên đây là thiết kế cơ bản, có thể mở rộng. Các khóa phiên và cơ chế quyền như ERC-7715 có thể giúp hỗ trợ sự cân bằng khác nhau giữa tiện lợi và bảo mật cho các ứng dụng khác nhau. Kiến trúc người giám hộ phức tạp hơn, ví dụ với nhiều khoảng thời gian khóa thời gian ở các ngưỡng khác nhau, có thể giúp tối đa hóa khả năng khôi phục tài khoản hợp pháp thành công đồng thời giảm thiểu rủi ro bị đánh cắp.
Người giám hộ nên là ai hoặc cái gì?
Đối với người dùng tiền mã hóa giàu kinh nghiệm trong cộng đồng người dùng tiền mã hóa giàu kinh nghiệm, một lựa chọn khả thi là khóa của bạn bè và gia đình. Nếu bạn yêu cầu mỗi người cung cấp cho bạn một địa chỉ mới, thì không ai cần biết họ là ai — thực tế, các người giám hộ của bạn thậm chí không cần biết lẫn nhau. Nếu họ không thông báo trước cho bạn, khả năng họ cấu kết với nhau là rất nhỏ. Tuy nhiên, đối với hầu hết người dùng mới, tùy chọn này không khả dụng.
Lựa chọn thứ hai là người giám hộ tổ chức: các công ty chuyên cung cấp dịch vụ chỉ ký giao dịch khi nhận được xác nhận bổ sung từ bạn: ví dụ. mã xác nhận, hoặc cuộc gọi video dành cho người dùng giá trị cao. Người ta đã cố gắng tạo ra các dịch vụ này từ lâu, ví dụ. tôi từng giới thiệu về CryptoCorp năm 2013. Tuy nhiên, đến nay, các công ty này vẫn chưa thành công lắm.
Lựa chọn thứ ba là nhiều thiết bị cá nhân (ví dụ điện thoại, máy tính để bàn, ví phần cứng). Điều này có thể hoạt động, nhưng cũng khó thiết lập và quản lý đối với người dùng chưa có kinh nghiệm. Ngoài ra còn tồn tại rủi ro mất hoặc bị đánh cắp đồng thời các thiết bị, đặc biệt khi chúng nằm cùng vị trí.
Gần đây, chúng ta bắt đầu thấy nhiều giải pháp dựa trên chìa khóa phổ quát (passkey). Khóa này chỉ có thể sao lưu trên thiết bị của bạn, biến nó thành một giải pháp thiết bị cá nhân, hoặc cũng có thể sao lưu trên đám mây, khiến độ an toàn phụ thuộc vào phức tạphỗn hợp giả định về mật khẩu, tổ chức và phần cứng đáng tin cậy. Trên thực tế, passkey là một bước tăng cường bảo mật quý giá đối với người dùng thông thường, nhưng riêng chúng chưa đủ để bảo vệ toàn bộ tài sản tích lũy của người dùng.
May mắn thay, với ZK-SNARK, chúng ta có lựa chọn thứ tư: ID tập trung được gói bằng ZK. Loại này bao gồm zk-email, Anon Aadhaar, Myna Wallet v.v. Về cơ bản, bạn có thể lấy dạng ID tập trung (công ty hoặc chính phủ) dưới nhiều hình thức và chuyển đổi nó thành địa chỉ Ethereum, nơi bạn chỉ có thể gửi giao dịch bằng cách tạo chứng minh ZK-SNARK rằng bạn sở hữu ID tập trung đó.
Với bổ sung này, giờ đây chúng ta có một loạt lựa chọn rộng rãi, và ID tập trung được gói bằng ZK có tính "thân thiện với người mới" độc đáo.
Để đạt được điều này, nó cần được thực hiện thông qua giao diện người dùng đơn giản và tích hợp: bạn nên có thể chỉ định bạn muốn "example@gmail.com" làm người giám hộ, và hệ thống sẽ tự động tạo địa chỉ Ethereum zk-email tương ứng bên dưới. Người dùng nâng cao nên có thể nhập email của họ (và có thể muối riêng tư được lưu trong email đó) vào ứng dụng bên thứ ba nguồn mở và xác nhận địa chỉ được tạo là chính xác. Điều này cũng nên đúng với bất kỳ loại người giám hộ được hỗ trợ nào khác.
Lưu ý rằng một thách thức thực tế hiện nay với zk-email là nó phụ thuộc vào chữ ký DKIM, sử dụng các khóa luân chuyển vài tháng một lần và các khóa này bản thân chúng không được ký bởi bất kỳ tổ chức nào khác. Điều này có nghĩa là zk-email hiện nay có yêu cầu tin cậy vượt ra ngoài chính nhà cung cấp; điều này có thể giảm nếu zk-email sử dụng TLSNotary bên trong phần cứng đáng tin cậy để xác minh các khóa cập nhật, nhưng điều này không lý tưởng. Mong rằng các nhà cung cấp email sẽ bắt đầu ký trực tiếp các khóa DKIM của họ. Hôm nay, tôi khuyên nên dùng zk-email làm một người giám hộ, nhưng không khuyến nghị dùng cho đa số người giám hộ: đừng lưu trữ tài sản trong thiết lập mà nếu zk-email hỏng thì bạn không thể truy cập được tiền.
Người dùng mới và ví tích hợp trong ứng dụng
Người dùng mới thực tế không muốn nhập một lượng lớn người giám hộ khi đăng ký lần đầu tiên. Do đó, ví nên cung cấp cho họ một lựa chọn rất đơn giản. Một con đường tự nhiên là sử dụng zk-email trên địa chỉ email của họ, khóa được lưu cục bộ trên thiết bị người dùng (có thể là passkey) và khóa sao lưu do nhà cung cấp nắm giữ, theo cấu hình 2-trên-3. Khi người dùng trở nên giàu kinh nghiệm hơn hoặc tích lũy thêm tài sản, nên nhắc họ thêm nhiều người giám hộ hơn vào một thời điểm nào đó.
Ví tích hợp vào ứng dụng là điều tất yếu, vì các ứng dụng cố gắng thu hút người dùng phi mã hóa không muốn người dùng đồng thời tải xuống hai ứng dụng mới (ứng dụng chính và ví Ethereum), gây rối trải nghiệm người dùng. Tuy nhiên, người dùng ví ứng dụng nên có thể liên kết tất cả ví của họ, để họ chỉ cần lo lắng về một "vấn đề kiểm soát truy cập". Cách đơn giản nhất là áp dụng sơ đồ phân cấp, nơi có một quy trình "liên kết" nhanh, cho phép người dùng đặt ví chính của họ làm người giám hộ cho tất cả ví tích hợp trong ứng dụng. Khách hàng Farcaster Warpcast đã hỗ trợ điều này:
Theo mặc định, việc khôi phục tài khoản Warpcast của bạn do đội ngũ Warpcast kiểm soát. Tuy nhiên, bạn có thể "tiếp quản" tài khoản Farcaster của mình và thay đổi việc khôi phục sang địa chỉ riêng của bạn.
Bảo vệ người dùng khỏi lừa đảo và các mối đe dọa bên ngoài khác
Ngoài bảo mật tài khoản, ví ngày nay còn làm rất nhiều việc để nhận diện địa chỉ giả, lừa đảo qua mạng, gian lận và các mối đe dọa bên ngoài khác, cố gắng hết sức để bảo vệ người dùng khỏi những mối đe dọa này. Đồng thời, nhiều biện pháp đối phó vẫn khá sơ sài: ví dụ, yêu cầu nhấp chuột để gửi ETH hoặc token khác đến bất kỳ địa chỉ mới nào, dù bạn gửi 100 đô la hay 100.000 đô la. Ở đây không có giải pháp thần kỳ duy nhất. Đây là một loạt sửa chữa và cải tiến liên tục, chậm rãi cho các loại mối đe dọa khác nhau. Tuy nhiên, tiếp tục nỗ lực cải thiện ở đây mang lại nhiều giá trị.
Riêng tư
Đã đến lúc bắt đầu coi trọng hơn về riêng tư trên Ethereum. Công nghệ ZK-SNARK hiện nay đã rất tiên tiến, các công nghệ riêng tư không phụ thuộc vào cửa hậu để giảm rủi ro quản lý (ví dụ Private Pools) ngày càng trưởng thành, và các cơ sở hạ tầng cấp hai như Waku và mempool ERC-4337 cũng dần ổn định hơn. Tuy nhiên, cho đến nay, việc chuyển tiền riêng tư trên Ethereum đòi hỏi người dùng phải chủ động tải xuống và sử dụng "ví riêng tư", ví dụ Railway (hoặc Umbra cho địa chỉ ẩn). Điều này gây bất tiện lớn và làm giảm số lượng người sẵn sàng thực hiện giao dịch riêng tư. Giải pháp là việc chuyển tiền riêng tư cần được tích hợp trực tiếp vào ví.
Một cách triển khai đơn giản như sau. Ví có thể lưu trữ một phần tài sản người dùng như "số dư riêng tư" trong Private Pool. Khi người dùng thực hiện chuyển tiền, hệ thống sẽ tự động rút khỏi Private Pool. Nếu người dùng cần nhận tiền, ví có thể tự động tạo một địa chỉ ẩn.
Ngoài ra, ví có thể tự động tạo một địa chỉ mới cho mỗi ứng dụng mà người dùng tham gia (ví dụ giao thức defi). Tiền gửi sẽ đến từ Private Pool, tiền rút sẽ đi thẳng vào Private Pool. Điều này cho phép hoạt động của người dùng trong một ứng dụng cụ thể không bị liên kết với hoạt động của họ trong các ứng dụng khác.
Một ưu điểm của công nghệ này là nó không chỉ là con đường tự nhiên để chuyển tài sản riêng tư, mà còn là con đường tự nhiên để có danh tính riêng tư. Danh tính đã xảy ra trên chuỗi: bất kỳ ứng dụng nào sử dụng cổng xác minh danh tính (ví dụ Gitcoin Grants), bất kỳ cuộc trò chuyện có cổng token, Ethereum Follow Protocol v.v. đều là danh tính trên chuỗi. Chúng ta muốn hệ sinh thái này cũng bảo vệ riêng tư. Điều này có nghĩa là hoạt động trên chuỗi của người dùng không nên được tập hợp tại một nơi: mỗi dự án nên lưu trữ riêng biệt, và ví người dùng nên là thứ duy nhất có "cái nhìn toàn cục", có thể nhìn thấy tất cả các chứng minh của bạn cùng lúc. Hệ sinh thái bản địa với mỗi người dùng sở hữu nhiều tài khoản giúp đạt được mục tiêu này, cũng như các giao thức chứng minh ngoài chuỗi như EAS và Zupass.
Điều này đại diện cho tầm nhìn thực tế về riêng tư Ethereum trong trung hạn. Mặc dù có thể giới thiệu một số chức năng ở L1 và L2 để làm cho việc chuyển tiền bảo vệ riêng tư hiệu quả và đáng tin cậy hơn, nhưng điều này hiện đã có thể thực hiện. Một số người ủng hộ riêng tư cho rằng điều duy nhất chấp nhận được là riêng tư hoàn toàn cho mọi thứ: mã hóa toàn bộ EVM. Tôi cho rằng đây có thể là kết quả lý tưởng dài hạn, nhưng nó đòi hỏi suy nghĩ lại cơ bản hơn về mô hình lập trình, và hiện chưa đạt đến mức độ trưởng thành sẵn sàng triển khai trên Ethereum. Chúng ta thực sự cần riêng tư mặc định để có tập hợp ẩn danh đủ lớn. Tuy nhiên, bước đầu tiên thực tế là tập trung vào (i) chuyển tiền giữa các tài khoản, và (ii) danh tính và các trường hợp sử dụng liên quan đến danh tính (ví dụ chứng minh riêng tư), dễ thực hiện hơn và ví hiện đã có thể bắt đầu sử dụng.
Ví Ethereum cũng cần trở thành ví dữ liệu
Một hệ quả của bất kỳ giải pháp riêng tư hiệu quả nào là, dù dùng cho thanh toán, danh tính hay các trường hợp sử dụng khác, nó đều tạo ra nhu cầu người dùng lưu trữ dữ liệu ngoài chuỗi. Điều này rõ ràng trong Tornado Cash, nơi yêu cầu người dùng lưu giữ mỗi "vé" đại diện cho khoản gửi 0,1-100 ETH. Các giao thức riêng tư hiện đại hơn đôi khi lưu dữ liệu đã mã hóa trên chuỗi và sử dụng một khóa riêng duy nhất để giải mã. Điều này có rủi ro, vì nếu khóa bị rò rỉ, hoặc máy tính lượng tử trở nên khả thi, dữ liệu sẽ bị phơi bày hoàn toàn. Nhu cầu lưu trữ dữ liệu ngoài chuỗi của các giao thức như EAS và Zupass còn rõ ràng hơn.
Ví không chỉ cần là phần mềm lưu trữ quyền truy cập trên chuỗi, mà còn cần là phần mềm lưu trữ dữ liệu riêng tư của bạn. Thế giới phi mã hóa cũng ngày càng nhận ra điều này, ví dụ. xem công trình gần đây của Tim Berners-Lee về lưu trữ dữ liệu cá nhân. Tất cả các vấn đề chúng ta cần giải quyết xung quanh đảm bảo vững chắc quyền kiểm soát truy cập, chúng ta cũng cần giải quyết xung quanh đảm bảo vững chắc khả năng truy cập dữ liệu và không rò rỉ. Có lẽ các giải pháp này có thể chồng lên nhau: nếu bạn có N người giám hộ, hãy dùng chia sẻ bí mật M-trên-N giữa N người giám hộ đó để lưu trữ dữ liệu của bạn. Dữ liệu về bản chất khó bảo vệ hơn, vì bạn không thể thu hồi phần dữ liệu đã chia cho ai đó, nhưng chúng ta nên đưa ra các giải pháp lưu ký phi tập trung an toàn nhất có thể.
Truy cập chuỗi an toàn
Ngày nay, ví tin tưởng nhà cung cấp RPC của họ sẽ nói với họ mọi thông tin về chuỗi. Đây là một lỗ hổng, có hai khía cạnh:
-
Nhà cung cấp RPC có thể cố gắng ăn cắp tiền bằng cách cung cấp thông tin sai lệch cho họ, ví dụ. về giá thị trường.
-
Nhà cung cấp RPC có thể thu thập thông tin riêng tư về các ứng dụng và tài khoản khác mà người dùng đang tương tác.
Lý tưởng nhất, chúng ta muốn bịt cả hai lỗ hổng này. Để giải quyết vấn đề đầu tiên, chúng ta cần khách hàng nhẹ chuẩn hóa cho L1 và L2, có thể trực tiếp xác minh đồng thuận blockchain. Helios đã làm điều này với L1 và đang thực hiện các công việc tiền kỳ để hỗ trợ một số L2 cụ thể. Để bao phủ đúng tất cả L2, chúng ta cần một tiêu chuẩn, theo đó hợp đồng cấu hình đại diện cho L2 (cũng dùng cho địa chỉ riêng theo chuỗi) có thể khai báo một hàm, có thể theo cách tương tự ERC-3668, chứa logic để lấy gốc trạng thái gần nhất và xác minh bằng chứng về trạng thái và biên lai đối với các gốc trạng thái đó. Như vậy, chúng ta có thể có một khách hàng nhẹ phổ quát, cho phép ví xác minh an toàn bất kỳ trạng thái hoặc sự kiện nào trên L1 và L2.
Về riêng tư, cách duy nhất thực tế ngày nay là chạy nút đầy đủ riêng của bạn. Tuy nhiên, bây giờ L2 đang nổi lên, việc chạy nút đầy đủ cho mọi thứ ngày càng khó khăn. Cái tương đương với khách hàng nhẹ ở đây là Truy vấn Thông tin Riêng tư (PIR). PIR liên quan đến máy chủ lưu bản sao tất cả dữ liệu và khách hàng gửi yêu cầu mã hóa tới máy chủ. Máy chủ thực hiện tính toán trên tất cả dữ liệu, trả lại dữ liệu mà khách hàng cần, được mã hóa theo khóa của khách hàng, mà không tiết lộ với máy chủ khách hàng đã truy cập dữ liệu nào.
Để giữ cho máy chủ trung thực, từng dự án cơ sở dữ liệu bản thân là các nhánh Merkle, do đó khách hàng có thể dùng khách hàng nhẹ để xác minh chúng.
PIR (TechFlow chú thích: thường đề cập đến "Truy vấn Thông tin Riêng tư" (Private Information Retrieval), là một giao thức hoặc công nghệ cho phép người dùng truy xuất thông tin từ cơ sở dữ liệu mà không tiết lộ thông tin nào đã được truy xuất.) có khối lượng tính toán rất lớn. Có một số cách giải quyết vấn đề này:
-
Dùng sức mạnh thô: Cải tiến thuật toán hoặc phần cứng chuyên dụng có thể làm cho PIR chạy đủ nhanh. Các kỹ thuật này có thể phụ thuộc vào tiền xử lý: máy chủ có thể lưu dữ liệu đã mã hóa và xáo trộn cho từng khách hàng, và khách hàng có thể truy vấn dữ liệu đó. Thách thức chính trong môi trường Ethereum là thích nghi các kỹ thuật này với tập dữ liệu thay đổi nhanh chóng (giống như trạng thái). Điều này làm giảm chi phí tính toán thời gian thực, nhưng có thể làm tăng tổng chi phí tính toán và lưu trữ.
-
Làm yếu yêu cầu riêng tư: Ví dụ, mỗi lần tra cứu chỉ có 1 triệu "mixins", do đó máy chủ sẽ biết khách hàng có thể truy cập một trong một triệu giá trị khả dĩ, nhưng không biết chi tiết hơn.
-
PIR đa máy chủ: Nếu bạn dùng nhiều máy chủ, và giả định trung thực giữa các máy chủ là 1-trong-N, thì các thuật toán PIR thường nhanh hơn.
-
Ẩn danh thay vì bí mật: Có thể gửi yêu cầu qua mạng hỗn hợp để ẩn người gửi yêu cầu, thay vì ẩn nội dung yêu cầu. Tuy nhiên, làm hiệu quả điều này không tránh khỏi làm tăng độ trễ, làm xấu trải nghiệm người dùng.
Tìm ra tổ hợp kỹ thuật phù hợp trong môi trường Ethereum để tối đa hóa riêng tư đồng thời duy trì tính thực dụng là một câu hỏi nghiên cứu mở, tôi hoan nghênh các nhà mật mã học thử làm điều này.
Ví kho khóa lý tưởng
Ngoài chuyển tiền và truy cập trạng thái, một quy trình làm việc quan trọng khác cần hoạt động trơn tru trong bối cảnh xuyên L2 là thay đổi cấu hình xác thực tài khoản: dù là thay đổi khóa (ví dụ khôi phục), hay thay đổi sâu hơn về logic toàn bộ tài khoản. Có ba lớp giải pháp ở đây, sắp xếp theo độ khó tăng dần:
-
Phát lại cập nhật: Khi người dùng thay đổi cấu hình của họ, tin nhắn ủy quyền thay đổi này sẽ được phát lại trên mỗi chuỗi mà ví phát hiện người dùng có tài sản. Có thể, định dạng tin nhắn và quy tắc xác minh có thể độc lập với chuỗi, do đó có thể tự động phát lại trên càng nhiều chuỗi càng tốt.
-
Kho khóa trên L1: Thông tin cấu hình nằm trên L1, ví trên L2 dùng L1SLOAD để đọc nó hoặc gọi tĩnh từ xa. Như vậy, chỉ cần cập nhật cấu hình trên L1, cấu hình sẽ tự động có hiệu lực.
-
Kho khóa trên L2: Thông tin cấu hình tồn tại trên L2, ví trên L2 dùng ZK-SNARK để đọc nó. Điều này giống (2), ngoại trừ việc cập nhật kho khóa có thể rẻ hơn, nhưng ngược lại việc đọc thì đắt hơn.
Giải pháp (3) đặc biệt mạnh mẽ, vì nó kết hợp tốt với riêng tư. Trong "giải pháp riêng tư" bình thường, người dùng có bí mật s, đăng "giá trị lá" L lên chuỗi, người dùng chứng minh L = hash(s, 1) và N = hash(s, 2) cho một số bí mật (chưa bao giờ tiết lộ) mà họ kiểm soát. Mã vô hiệu N được đăng để đảm bảo việc chi tiêu trong tương lai từ cùng lá sẽ thất bại, mà không tiết lộ L này phụ thuộc vào s an toàn của người dùng. Một giải pháp riêng tư thân thiện với khôi phục sẽ nói: s là một vị trí (ví dụ địa chỉ và khe lưu trữ) trên chuỗi, người dùng phải chứng minh truy vấn trạng thái: L = hash(sload(s), 1).
Bảo mật dapp
Khâu yếu nhất trong bảo mật người dùng thường là dapp. Hầu hết thời gian, người dùng tương tác với ứng dụng bằng cách truy cập trang web, nơi giao diện mã nguồn được máy chủ tải xuống thời gian thực một cách ngầm định, rồi thực thi trong trình duyệt. Nếu máy chủ bị tấn công, hoặc DNS bị tấn công, người dùng sẽ nhận được bản sao giao diện giả, có thể lừa người dùng thực hiện bất kỳ thao tác nào. Các chức năng ví như mô phỏng giao dịch rất hữu ích để giảm rủi ro, nhưng chúng vẫn còn xa mới hoàn hảo.
Lý tưởng nhất, chúng ta sẽ chuyển hệ sinh thái sang kiểm soát phiên bản nội dung trên chuỗi: người dùng sẽ truy cập dapp qua tên ENS của nó, tên này sẽ chứa giá trị băm IPFS của giao diện. Cập nhật giao diện cần giao dịch trên chuỗi từ đa chữ ký hoặc DAO. Ví sẽ hiển thị cho người dùng liệu họ đang tương tác với giao diện trên chuỗi an toàn hơn hay giao diện Web2 kém an toàn hơn. Ví cũng có thể hiển thị cho người dùng liệu họ đang tương tác với chuỗi an toàn (ví dụ giai đoạn 1+, nhiều đánh giá bảo mật).
Đối với người dùng chú trọng riêng tư, ví cũng có thể thêm chế độ ám ảnh (paranoid mode), yêu cầu người dùng nhấp để chấp nhận yêu cầu HTTP, chứ không chỉ thao tác web3:
Mô hình giao diện có thể cho chế độ ám ảnh
Các phương pháp tiên tiến hơn là vượt ra ngoài HTML + Javascript, và viết logic nghiệp vụ của dapp bằng ngôn ngữ chuyên dụng (có thể là lớp phủ tương đối mỏng trên Solidity hoặc Vyper). Sau đó, trình duyệt có thể tự động tạo giao diện người dùng cho mọi chức năng cần thiết. OKContract đã đang làm điều này.
Một hướng khác là phòng thủ thông tin kinh tế mã hóa: các nhà phát triển dapp, công ty bảo mật, người triển khai chuỗi và những người khác có thể đặt một khoản ký quỹ, nếu dapp bị tấn công hoặc gây hại cho người dùng theo cách rất gây hiểu lầm, khoản ký quỹ sẽ được trả cho người dùng bị ảnh hưởng (được xác định bởi một DAO tài phán trên chuỗi). Ví có thể hiển thị cho người dùng một điểm số dựa trên kích thước ký quỹ.
Tương lai xa hơn
Tất cả những điều trên đều diễn ra trong bối cảnh giao diện truyền thống, liên quan đến việc trỏ và nhấp vào các thứ và nhập dữ liệu vào các trường văn bản. Tuy nhiên, chúng ta cũng đang ở ngưỡng cửa của một sự thay đổi sâu sắc hơn về mô hình:
-
Trí tuệ nhân tạo, có thể dẫn chúng ta từ mô hình nhấp và gõ sang mô hình "nói điều bạn muốn làm, robot sẽ tự hiểu"
-
Giao diện não - máy tính, cả các phương pháp "nhẹ nhàng" như theo dõi chuyển động mắt, và các công nghệ trực tiếp hơn hoặc thậm chí xâm lấn (xem: bệnh nhân Neuralink đầu tiên năm nay)
-
Phòng thủ chủ động phía khách hàng: Trình duyệt Brave chủ động bảo vệ người dùng khỏi quảng cáo, công cụ theo dõi và nhiều đối tượng xấu khác. Nhiều trình duyệt, tiện ích mở rộng và ví mã hóa có cả đội ngũ tích cực nỗ lực bảo vệ người dùng khỏi các mối đe dọa an toàn và riêng tư khác nhau. Những "người bảo vệ chủ động" này sẽ chỉ ngày càng mạnh mẽ hơn trong thập kỷ tới.
Ba xu hướng này cùng nhau sẽ dẫn đến việc suy nghĩ lại sâu sắc hơn về cách thức hoạt động của giao diện. Với đầu vào ngôn ngữ tự nhiên, theo dõi chuyển động mắt hoặc cuối cùng là giao diện não - máy tính trực tiếp hơn, cộng với lịch sử của bạn (có thể bao gồm tin nhắn, miễn là mọi dữ liệu được xử lý cục bộ), "ví" có thể hiểu rõ và trực quan về điều bạn muốn làm. Sau đó, trí tuệ nhân tạo có thể chuyển đổi trực giác này thành một "kế hoạch hành động" cụ thể: một chuỗi tương tác trên và ngoài chuỗi để hoàn thành điều bạn muốn. Điều này có thể giảm đáng kể nhu cầu về giao diện người dùng bên thứ ba. Nếu người dùng thực sự tương tác với ứng dụng bên thứ ba (hoặc người dùng khác), trí tuệ nhân tạo nên đại diện cho người dùng suy nghĩ đối kháng, nhận diện mọi mối đe dọa và đề xuất kế hoạch hành động tránh mối đe dọa. Lý tưởng nhất, các trí tuệ nhân tạo này nên có hệ sinh thái mở, được tạo ra bởi các nhóm khác nhau với các định kiến và cấu trúc khuyến khích khác nhau.
Những ý tưởng triệt để hơn này phụ thuộc vào công nghệ hiện nay còn rất non nớt, vì vậy tôi sẽ không đặt tài sản của mình vào các ví phụ thuộc vào chúng hôm nay. Tuy nhiên, điều gì đó tương tự rõ ràng dường như là xu hướng tương lai, do đó đáng để bắt đầu khám phá tích cực hơn theo hướng này.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
