Tác giả gốc: Người sáng lập Ethereum Vitalik Buterin
Xin đặc biệt cảm ơn Dan Finlay, Karl Floersch, David Hoffman và các nhóm Scroll và SoulWallet vì phản hồi, đánh giá và đề xuất của họ.
Khi Ethereum chuyển đổi từ một công nghệ non trẻ, thử nghiệm sang một nhóm công nghệ trưởng thành có khả năng thực sự mang lại trải nghiệm mở, toàn cầu và không cần cấp phép cho người dùng thông thường, thì nhóm sẽ cần trải qua ba quá trình chuyển đổi công nghệ chính gần như đồng thời:
Quá trình chuyển đổi mở rộng L2 - mọi người chuyển sang bản tổng hợp
Chuyển đổi bảo mật ví - mọi người chuyển sang ví hợp đồng thông minh
Chuyển đổi quyền riêng tư - Đảm bảo chuyển tiền bảo vệ quyền riêng tư có sẵn và đảm bảo rằng tất cả các tiện ích khác đang được phát triển (khôi phục xã hội, danh tính, danh tiếng) đều bảo vệ quyền riêng tư
Tam giác chuyển tiếp hệ sinh thái.
Nếu không có lần đầu tiên, Ethereum sẽ thất bại, vì mỗi giao dịch có giá 3,75 đô la (82,48 đô la nếu chúng ta có một đợt tăng giá khác) và mọi sản phẩm nhắm đến thị trường đại chúng chắc chắn sẽ quên đi chuỗi và áp dụng một giải pháp thay thế tập trung cho mọi thứ.
Nếu không có điều thứ hai, Ethereum sẽ thất bại vì người dùng không muốn lưu trữ tiền của họ (và tài sản phi tài chính) và mọi người chuyển sang trao đổi tập trung.
Nếu không có phần ba, Ethereum sẽ thất bại vì tất cả các giao dịch (và POAP, v.v.) Một giải pháp tập trung giúp ẩn dữ liệu của bạn ở mức độ lớn nhất.
Ba quá trình chuyển đổi này rất quan trọng vì những lý do đã nêu ở trên. Nhưng chúng cũng đầy thách thức, vì giải quyết chúng đúng cách đòi hỏi sự phối hợp chặt chẽ. Nó không chỉ là chức năng của giao thức cần được cải thiện; trong một số trường hợp, cách chúng ta tương tác với Ethereum cần phải thay đổi về cơ bản, đòi hỏi những thay đổi sâu sắc đối với các ứng dụng và ví.
Ba chuyển đổi này về cơ bản sẽ định hình lại mối quan hệ giữa người dùng và địa chỉ
Trong thế giới mở rộng L2, người dùng sẽ tồn tại trên nhiều L2. Bạn có phải là thành viên của ExampleDAO dựa trên sự lạc quan không? Sau đó, bạn có một tài khoản Lạc quan! Bạn có giữ CDP trong hệ thống stablecoin trên ZkSync không? Sau đó, bạn có một tài khoản trên ZkSync! Bạn đã thử một số ứng dụng trên kakarot chưa? Sau đó, bạn có một tài khoản trên Kakarot! Đã qua rồi cái thời mà người dùng chỉ có một địa chỉ.
*Theo quan điểm của Brave Wallet, tôi có ETH ở bốn vị trí. Có, Arbitrum và Arbitrum Nova khác nhau. Đừng lo lắng, nó sẽ trở nên lộn xộn hơn theo thời gian! *
Ví hợp đồng thông minh làm tăng thêm độ phức tạp và khiến việc có cùng một địa chỉ trong L1 và các L2 khác nhau trở nên khó khăn hơn. Ngày nay, hầu hết người dùng đang sử dụng các tài khoản thuộc sở hữu bên ngoài có địa chỉ thực sự là mã băm của các khóa công khai được sử dụng để xác minh chữ ký - vì vậy không có gì thay đổi giữa L1 và L2. Tuy nhiên, với ví hợp đồng thông minh, việc đặt địa chỉ trở nên khó khăn hơn. Mặc dù đã có rất nhiều công việc được thực hiện để thử và biến các địa chỉ thành một mã băm tương đương trên các mạng, đáng chú ý nhất là các nhà máy đơn lẻ CREATE2 và ERC-2470, thật khó để làm cho điều này hoạt động hoàn hảo. Một số L2 (chẳng hạn như "ZK-EVM loại 4") không hoàn toàn tương đương với EVM, thường thì Solidity hoặc các tổ hợp trung gian được sử dụng thay thế để ngăn tương đương hàm băm. Ngay cả khi bạn có thể có giá trị băm tương đương, thì khả năng ví tiền thay đổi quyền sở hữu thông qua các thay đổi quan trọng sẽ gây ra những hậu quả không trực quan khác.
Quyền riêng tư yêu cầu nhiều địa chỉ hơn cho mỗi người dùng và thậm chí có thể thay đổi các loại địa chỉ mà chúng tôi đang xử lý. Nếu đề xuất địa chỉ ẩn được sử dụng rộng rãi, thay vì chỉ một vài địa chỉ cho mỗi người dùng hoặc một địa chỉ cho mỗi L2, người dùng có thể có một địa chỉ cho mỗi giao dịch. Các kế hoạch bảo mật khác, ngay cả những kế hoạch hiện có như Tornado Cash, thay đổi cách lưu trữ tài sản theo cách khác: tiền của nhiều người dùng được lưu trữ trong cùng một hợp đồng thông minh (và do đó tại cùng một địa chỉ). Để gửi tiền cho một người dùng cụ thể, người dùng sẽ cần dựa vào hệ thống địa chỉ nội bộ riêng của chương trình quyền riêng tư.
Như chúng ta đã thấy, mỗi trong số ba quá trình chuyển đổi này làm suy yếu mô hình tinh thần "một người dùng ~= một địa chỉ" theo những cách khác nhau, với một số tác động này phản ánh sự phức tạp của việc triển khai quá trình chuyển đổi. Hai điểm phức tạp đặc biệt là:
Nếu bạn muốn trả tiền cho ai đó, làm thế nào bạn có được thông tin về cách trả tiền cho họ?
Nếu người dùng có nhiều tài sản trên các chuỗi được lưu trữ ở những nơi khác nhau, làm cách nào để họ thực hiện các thay đổi chính và phục hồi xã hội?
Ba lần chuyển đổi và thanh toán trên chuỗi (và danh tính)
Tôi có xu trên Scroll và tôi muốn trả tiền cho cà phê (nếu "tôi" ám chỉ tôi với tư cách là tác giả của bài viết này, thì "cà phê" tất nhiên là một ẩn dụ của "trà xanh"). Bạn đang bán cà phê cho tôi, nhưng bạn chỉ có thể nhận được tiền trên Taiko. phải làm gì
Về cơ bản có hai giải pháp:
Ví nhận (có thể là người bán hoặc cá nhân thông thường) hoạt động rất chăm chỉ để hỗ trợ từng L2, với một số tự động hóa để tích hợp tiền không đồng bộ.
Người nhận thanh toán cung cấp L2 và địa chỉ của họ, đồng thời ví của người gửi sẽ tự động định tuyến tiền đến L2 đích thông qua một số hệ thống cầu nối giữa các L2.
Tất nhiên, các giải pháp này có thể được kết hợp: người nhận cung cấp danh sách các L2 mà họ sẵn sàng chấp nhận và ví của người gửi tính toán khoản thanh toán, có thể liên quan đến việc gửi trực tiếp hoặc đường dẫn bắc cầu qua L2 nếu họ may mắn.
Nhưng đây chỉ là một ví dụ về thách thức chính mà ba quá trình chuyển đổi này đưa ra: các hoạt động đơn giản như thanh toán cho ai đó bắt đầu yêu cầu nhiều thông tin hơn là chỉ một địa chỉ 20 byte.
May mắn thay, việc chuyển đổi sang ví hợp đồng thông minh sẽ không làm quá tải hệ thống địa chỉ, nhưng vẫn còn một số vấn đề kỹ thuật cần được giải quyết trong các phần khác của ngăn xếp ứng dụng. Các ví sẽ cần được cập nhật để đảm bảo rằng chúng không chỉ gửi 21000 gas cùng với giao dịch và điều quan trọng hơn là đảm bảo phần cuối nhận thanh toán của ví không chỉ theo dõi việc chuyển ETH từ EOA mà còn theo dõi cả ETH được gửi bởi mã hợp đồng thông minh. Các ứng dụng dựa trên giả định về quyền sở hữu địa chỉ bất biến (ví dụ: NFT cấm hợp đồng thông minh thực thi phí bản quyền) sẽ phải tìm các cách khác để đạt được mục tiêu của mình. Ví hợp đồng thông minh cũng sẽ giúp mọi thứ trở nên dễ dàng hơn - đáng chú ý là nếu ai đó chỉ nhận được mã thông báo ERC20 không phải ETH, họ sẽ có thể sử dụng mã thông báo đó để thanh toán xăng bằng cách sử dụng trình quản lý thanh toán ERC-4337.
Mặt khác, quyền riêng tư lại đặt ra một thách thức lớn mà chúng tôi chưa thực sự giải quyết được. Tornado Cash ban đầu không gây ra bất kỳ vấn đề nào trong số này vì nó không hỗ trợ chuyển khoản nội bộ: người dùng chỉ có thể gửi tiền vào hệ thống và rút tiền từ hệ thống. Tuy nhiên, khi có thể chuyển nội bộ, người dùng sẽ cần sử dụng sơ đồ địa chỉ nội bộ của hệ thống bảo mật. Trên thực tế, "tin nhắn thanh toán" của người dùng cần chứa (i) một số loại "khóa chi tiêu", một lời hứa về bí mật mà người nhận có thể sử dụng để chi tiêu và (ii) một số cách để người gửi chỉ gửi tiền điện tử Thông tin mà người được trả tiền có thể giải mã để giúp người được trả tiền khám phá khoản thanh toán.
Giao thức địa chỉ ẩn dựa trên khái niệm địa chỉ meta, hoạt động theo cách này: một phần của địa chỉ meta là phiên bản ẩn của khóa chi tiêu của người gửi và phần còn lại là khóa mã hóa của người gửi (mặc dù việc triển khai tối thiểu có thể thiết lập cả hai phím giống nhau).
Sơ đồ của sơ đồ địa chỉ tàng hình trừu tượng dựa trên mã hóa và ZK-SNARK.
Một bài học quan trọng ở đây là trong một hệ sinh thái thân thiện với quyền riêng tư, người dùng sẽ có cả khóa công khai tiêu thụ và khóa công khai mã hóa và "thông tin thanh toán" của người dùng phải bao gồm cả hai khóa. Ngoài các khoản thanh toán, có nhiều lý do chính đáng để mở rộng theo hướng này. Ví dụ: nếu chúng tôi muốn email được mã hóa dựa trên Ethereum, người dùng sẽ cần cung cấp công khai một số loại khóa mã hóa. Trong "thế giới EOA", chúng tôi có thể sử dụng lại các khóa tài khoản cho việc này, nhưng trong thế giới ví hợp đồng thông minh an toàn, có lẽ chúng tôi nên cung cấp một chức năng rõ ràng hơn cho việc này. Điều này cũng giúp làm cho các danh tính dựa trên Ethereum tương thích hơn với các hệ sinh thái bảo mật phi tập trung không phải Ethereum, đặc biệt là các khóa PGP.
Ba lần chuyển đổi và khôi phục khóa
Cách mặc định để triển khai các thay đổi quan trọng và khôi phục mạng xã hội trong một thế giới mà mỗi người dùng có nhiều địa chỉ là chỉ cần yêu cầu người dùng chạy quy trình khôi phục trên từng địa chỉ một cách riêng biệt. Điều này có thể được thực hiện bằng một cú nhấp chuột: ví có thể chứa phần mềm có thể thực hiện các quy trình khôi phục đồng thời trên tất cả các địa chỉ của người dùng. Tuy nhiên, ngay cả với việc đơn giản hóa trải nghiệm người dùng này, vẫn có ba vấn đề với khôi phục đa địa chỉ đơn giản:
Chi phí gas là không thực tế: Điều này là tự giải thích.
Địa chỉ phản thực: Địa chỉ mà hợp đồng thông minh chưa phát hành (thực tế, điều này có nghĩa là các tài khoản mà bạn chưa gửi tiền từ đó). Là người dùng, bạn có thể có vô số địa chỉ phản thực: một hoặc nhiều địa chỉ trên mỗi L2, bao gồm các L2 chưa tồn tại và một tập hợp vô hạn các địa chỉ phản thực khác do sơ đồ địa chỉ ẩn.
Quyền riêng tư: Nếu người dùng cố tình có nhiều địa chỉ để tránh liên kết chúng với nhau, thì chắc chắn họ không muốn công khai liên kết tất cả chúng bằng cách khôi phục chúng vào cùng một thời điểm!
Giải quyết những vấn đề này là khó khăn. May mắn thay, có một giải pháp tao nhã hoạt động khá tốt: một kiến trúc tách logic xác thực khỏi việc nắm giữ tài sản.
Mỗi người dùng có một hợp đồng kho khóa tồn tại ở một vị trí (có thể là mạng chính hoặc L2 cụ thể). Sau đó, người dùng có địa chỉ trên các L2 khác nhau, trong đó logic xác thực cho từng địa chỉ là một con trỏ tới hợp đồng kho khóa. Chi tiêu từ các địa chỉ này yêu cầu bằng chứng về việc tham gia vào hợp đồng kho khóa thể hiện khóa công khai chi tiêu hiện tại (hoặc thực tế hơn là gần đây nhất).
Bằng chứng có thể đạt được theo nhiều cách:
Truy cập L1 chỉ đọc trực tiếp trong L2. L2 có thể được sửa đổi để đọc trực tiếp trạng thái L1. Nếu hợp đồng kho khóa nằm trên L1, điều này có nghĩa là các hợp đồng trong L2 có quyền truy cập "miễn phí" vào kho khóa
Nhánh Méc-ken. Các nhánh Merkle có thể chứng thực trạng thái L1 thành L2 hoặc trạng thái L2 thành L1 hoặc bạn có thể kết hợp cả hai để chứng thực trạng thái một phần của L2 này với L2 khác. Điểm yếu chính của bằng chứng Merkle là chi phí gas cao do độ dài bằng chứng: một bằng chứng có thể yêu cầu 5 kB, nhưng điều này sẽ giảm xuống < 1 kB trong tương lai nhờ cây Verkle.
ZK-SNARK. Bạn có thể giảm chi phí dữ liệu bằng cách sử dụng ZK-SNARK của các nhánh Merkle thay vì chính các nhánh đó. Có thể xây dựng các kỹ thuật tổng hợp ngoài chuỗi (ví dụ: trên EIP-4337) để ZK-SNARK xác minh tất cả các bằng chứng trạng thái chuỗi chéo trong một khối.
Lời hứa của KZG. L2, hoặc các sơ đồ được xây dựng trên chúng, có thể giới thiệu một hệ thống đánh địa chỉ tuần tự, cho phép các bằng chứng trạng thái trong hệ thống đó chỉ dài 48 byte. Giống như ZK-SNARK, nhiều sơ đồ bằng chứng có thể kết hợp tất cả các bằng chứng này thành một bằng chứng duy nhất cho mỗi khối.
Nếu chúng tôi muốn tránh tạo bằng chứng cho mọi giao dịch, chúng tôi có thể triển khai sơ đồ nhẹ hơn chỉ yêu cầu một bằng chứng L2 chéo để khôi phục. Chi tiêu từ một tài khoản sẽ phụ thuộc vào khóa chi tiêu có khóa công khai tương ứng được lưu trữ trong tài khoản, nhưng việc khôi phục sẽ yêu cầu một giao dịch sao chép khóa công khai chi tiêu hiện tại trong kho khóa. Tiền trong các địa chỉ phản thực vẫn an toàn ngay cả khi các khóa cũ của bạn không an toàn: "kích hoạt" địa chỉ phản thực để biến địa chỉ đó thành hợp đồng làm việc yêu cầu bằng chứng L2 chéo để sao chép chi tiêu hiện tại_pubkey. Chủ đề này trên các diễn đàn An toàn mô tả cách thức hoạt động của một kiến trúc tương tự.
Để thêm quyền riêng tư cho sơ đồ như vậy, chúng tôi chỉ cần mã hóa con trỏ này và sau đó chúng tôi thực hiện tất cả các bằng chứng trong ZK-SNARK:
Với nhiều công việc hơn (ví dụ: sử dụng công việc này làm điểm bắt đầu), chúng tôi cũng có thể loại bỏ hầu hết sự phức tạp của ZK-SNARK và tạo sơ đồ dựa trên KZG đơn giản hơn.
Những kịch bản này có thể trở nên phức tạp. Về mặt tích cực, có nhiều sự phối hợp tiềm năng giữa chúng. Ví dụ: khái niệm "hợp đồng kho khóa" cũng có thể giải quyết thách thức "địa chỉ" được đề cập trong phần trước: nếu chúng tôi muốn người dùng có địa chỉ cố định không thay đổi mỗi khi người dùng nhập lại khóa, chúng tôi có thể đặt Địa chỉ meta ẩn , các khóa mã hóa và thông tin khác được đưa vào hợp đồng kho khóa và địa chỉ của hợp đồng kho khóa được sử dụng làm "địa chỉ" của người dùng.
Nhiều hạ tầng thứ cấp cần được nâng cấp
Sử dụng ENS rất tốn kém. Hôm nay, tháng 6 năm 2023, mọi thứ không quá tệ: phí giao dịch cao nhưng vẫn tương đương với phí miền ENS. Đăng ký với zuzalu.eth tiêu tốn của tôi khoảng 27 đô la, trong đó 11 đô la là phí giao dịch. Nhưng nếu chúng ta có một thị trường tăng giá khác, phí sẽ tăng vọt. Ngay cả khi không có sự tăng giá của ETH, việc chuyển phí gas trở lại 200 gwei sẽ tăng phí giao dịch đăng ký tên miền lên 104 đô la. Vì vậy, nếu chúng tôi muốn mọi người thực sự sử dụng ENS, đặc biệt đối với các trường hợp sử dụng như phương tiện truyền thông xã hội phi tập trung, nơi người dùng yêu cầu đăng ký gần như miễn phí (và phí miền ENS không phải là vấn đề vì các nền tảng này cung cấp cho người dùng tên miền phụ của họ), chúng tôi cần ENS ở L2 để hoạt động .
May mắn thay, nhóm ENS đã tăng cường và ENS trên L2 đang diễn ra! ERC-3668 (hay còn gọi là "tiêu chuẩn CCIP"), cùng với ENSIP-10, cung cấp một cách để làm cho các miền con ENS trên bất kỳ L2 nào có thể tự động xác minh được. Tiêu chuẩn CCIP yêu cầu tạo hợp đồng thông minh mô tả phương pháp xác minh bằng chứng về dữ liệu L2 và các miền đó (ví dụ: Optinames sử dụng ecc.eth) có thể được đặt dưới sự kiểm soát của hợp đồng đó. Sau khi hợp đồng CCIP nắm quyền kiểm soát ecc.eth trên L1, việc truy cập một số tên miền phụ.ecc.eth sẽ tự động liên quan đến việc tìm và xác minh bằng chứng trạng thái (ví dụ: nhánh Merkle) trong L2 nơi tên miền phụ cụ thể đó thực sự được lưu trữ.
Trên thực tế, việc lấy bằng chứng liên quan đến một danh sách các URL được lưu trữ trong hợp đồng, chắc chắn có cảm giác giống như tập trung, nhưng tôi nghĩ thực tế không phải vậy: đó là mô hình tin cậy 1/N (bằng chứng không hợp lệ được bắt bởi logic xác minh trong chức năng gọi lại hợp đồng CCIP, miễn là một trong các URL trả về bằng chứng hợp lệ thì không sao). Danh sách các URL có thể chứa hàng tá.
Nỗ lực CCIP của ENS là một câu chuyện thành công và nó nên được coi là một dấu hiệu cho thấy loại cải cách triệt để mà chúng ta cần thực sự có thể thực hiện được. Nhưng vẫn còn nhiều cải cách tầng ứng dụng cần được thực hiện. Một vài ví dụ:
Nhiều dapp dựa vào người dùng để cung cấp chữ ký ngoài chuỗi. Với Tài khoản Sở hữu Bên ngoài (EOA), thật dễ dàng. ERC-1271 cung cấp một cách chuẩn hóa cho các ví hợp đồng thông minh để thực hiện việc này. Tuy nhiên, nhiều dapp vẫn không hỗ trợ ERC-1271; họ sẽ cần phải hỗ trợ.
Các Dapp sử dụng "Đây có phải là EOA không?" để phân biệt người dùng và hợp đồng (ví dụ: ngăn chuyển khoản hoặc thực thi phí bản quyền) sẽ bị phá vỡ. Nói chung, tôi khuyên bạn không nên tìm kiếm các giải pháp kỹ thuật thuần túy ở đây; tìm hiểu xem liệu việc chuyển quyền kiểm soát mật mã cụ thể có phải là chuyển quyền sở hữu có lợi hay không là một vấn đề khó có thể không giải quyết được nếu không giải quyết một số cơ chế do cộng đồng điều khiển ngoài chuỗi. Nhiều khả năng, các ứng dụng sẽ ít phụ thuộc vào ngăn chặn chuyển hướng hơn và phụ thuộc nhiều hơn vào các kỹ thuật như thuế Harberger.
Phải cải thiện cách ví tương tác với chi tiêu và khóa mã hóa. Hiện tại, các ví thường sử dụng chữ ký xác định để tạo khóa dành riêng cho ứng dụng: ký một nonce tiêu chuẩn (chẳng hạn như hàm băm của tên ứng dụng) bằng khóa riêng của EOA sẽ tạo ra một giá trị xác định không thể tạo được nếu không có khóa riêng. theo nghĩa thuần túy kỹ thuật. Tuy nhiên, các kỹ thuật này "không rõ ràng" đối với ví, ngăn không cho ví thực hiện kiểm tra bảo mật cấp giao diện người dùng. Trong các hệ sinh thái trưởng thành hơn, việc ký, mã hóa và các chức năng liên quan sẽ phải được ví xử lý rõ ràng hơn.
Các ứng dụng khách nhẹ (chẳng hạn như Helios) sẽ phải xác thực L2 chứ không chỉ L1. Ngày nay, các ứng dụng khách nhẹ tập trung vào việc kiểm tra tính hợp lệ của các tiêu đề L1 (sử dụng giao thức đồng bộ hóa ứng dụng khách nhẹ) và xác minh các nhánh Merkle của trạng thái L1 và các giao dịch bắt nguồn từ các tiêu đề L1. Ngày mai, họ cũng cần xác minh bằng chứng về trạng thái L2, vốn bắt nguồn từ gốc trạng thái được lưu trữ trong L1 (phiên bản cao cấp hơn thực sự nhìn vào xác nhận trước L2).
Ví sẽ cần bảo vệ tài sản và dữ liệu
Ngày nay, ví đang được sử dụng để bảo vệ tài sản. Mọi thứ đều trực tuyến và thứ duy nhất mà chiếc ví cần bảo vệ là các khóa riêng tư hiện đang bảo mật các tài sản này. Nếu bạn thay đổi khóa của mình, bạn có thể xuất bản khóa riêng tư trước đó của mình trên Internet một cách an toàn vào ngày hôm sau. Tuy nhiên, trong thế giới ZK, điều này không còn đúng nữa: ví không chỉ bảo vệ thông tin xác thực mà còn chứa dữ liệu của bạn.
Chúng tôi đã thấy những dấu hiệu đầu tiên của một thế giới như vậy với Zupass, hệ thống nhận dạng dựa trên ZK-SNARK được sử dụng bởi Zuzalu. Người dùng có một khóa riêng để xác thực hệ thống, khóa này có thể được sử dụng để tạo các bằng chứng cơ bản, chẳng hạn như "chứng minh rằng tôi là cư dân của Zuzalu mà không tiết lộ địa chỉ nào". Nhưng hệ thống Zupass cũng bắt đầu xây dựng các ứng dụng khác trên đó, đáng chú ý nhất là tem (phiên bản POAP của Zupass).
Một trong nhiều con dấu Zupass của tôi xác nhận rằng tôi là một thành viên đáng tự hào của Team Cat.
Tính năng chính mà tem cung cấp so với POAP là tem là riêng tư: bạn lưu dữ liệu cục bộ và nếu bạn muốn ai đó có thông tin về mình, bạn chỉ cần chứng minh tem (hoặc một số tính toán trên tem) cho ai đó . Nhưng điều đó làm tăng thêm rủi ro: nếu bạn mất thông tin đó, bạn sẽ mất tem.
Tất nhiên, vấn đề lưu trữ dữ liệu có thể được giảm xuống thành vấn đề lưu giữ một khóa mã hóa duy nhất: một số bên thứ ba (hoặc thậm chí chuỗi) có thể lưu giữ một bản sao dữ liệu được mã hóa. Điều này có lợi thế thuận tiện là hành động bạn thực hiện không làm thay đổi khóa mã hóa, vì vậy không cần tương tác với hệ thống giữ an toàn cho khóa mã hóa của bạn. Nhưng ngay cả khi đó, nếu bạn đánh mất khóa mã hóa, bạn sẽ mất tất cả. Mặt khác, nếu ai đó nhìn thấy khóa mã hóa của bạn, họ có thể thấy mọi thứ được mã hóa bằng khóa đó.
Giải pháp thiết thực của Zupass là khuyến khích mọi người lưu trữ khóa của họ trên nhiều thiết bị (chẳng hạn như máy tính xách tay và điện thoại), vì khả năng họ mất quyền truy cập vào tất cả các thiết bị đó cùng một lúc là rất thấp. Chúng ta có thể tiến thêm một bước và sử dụng chia sẻ bí mật để lưu trữ khóa, được phân phối giữa nhiều người giám hộ.
Sự phục hồi xã hội thông qua MPC này không phải là một giải pháp thích hợp cho ví, vì điều đó có nghĩa là không chỉ những người giám hộ hiện tại mà cả những người giám hộ trước đây cũng có thể thông đồng để đánh cắp tài sản của bạn, đây là một rủi ro cao không thể chấp nhận được. Tuy nhiên, rủi ro vi phạm quyền riêng tư thường thấp hơn rủi ro mất toàn bộ tài sản và những người có các trường hợp sử dụng quyền riêng tư cao luôn có thể chấp nhận rủi ro mất mát cao hơn do không sao lưu các khóa liên quan đến các hoạt động đòi hỏi quyền riêng tư này.
Để tránh người dùng bị choáng ngợp bởi hệ thống Byzantine với nhiều đường dẫn khôi phục, các ví hỗ trợ khôi phục xã hội có thể cần quản lý cả khôi phục tài sản và khôi phục khóa mã hóa.
Quay lại danh tính
Một trong những điểm chung của những thay đổi này là khái niệm về "địa chỉ", mã định danh mật mã mà bạn sử dụng để đại diện cho "bạn" trên chuỗi, về cơ bản phải thay đổi. "Hướng dẫn cách tương tác với tôi" sẽ không còn chỉ là một địa chỉ ETH; chúng phải là sự kết hợp của nhiều địa chỉ trên nhiều L2, địa chỉ meta ẩn, khóa mã hóa và dữ liệu khác ở một số dạng.
Một cách là biến ENS thành danh tính của bạn: bản ghi ENS của bạn chỉ có thể chứa tất cả thông tin này và nếu bạn gửi cho ai đó bob.eth (hoặc bob.ecc.eth, hoặc...), họ có thể tra cứu và xem mọi thứ về cách thức nó trả tiền và tương tác với bạn, bao gồm các phương pháp bảo vệ quyền riêng tư và tên miền chéo phức tạp hơn.
Nhưng cách tiếp cận lấy ENS làm trung tâm này có hai điểm yếu:
Nó liên kết quá nhiều thứ với tên miền của bạn. Tên miền của bạn không phải là bạn, tên miền của bạn là một trong nhiều thuộc tính của bạn. Có thể thay đổi tên miền của bạn mà không cần di chuyển toàn bộ hồ sơ nhận dạng và cập nhật toàn bộ hồ sơ trong nhiều ứng dụng.
Bạn không thể có ngô phản thực tế không đáng tin cậy. Một tính năng UX quan trọng của bất kỳ chuỗi khối nào là khả năng gửi tiền cho những người chưa tương tác với chuỗi. Không có chức năng như vậy, có một nhược điểm- 22: tương tác với chuỗi yêu cầu thanh toán phí giao dịch, yêu cầu... đã có tiền. Địa chỉ ETH, bao gồm địa chỉ hợp đồng thông minh với CREATE2, có chức năng này. Tên ENS sẽ không, bởi vì nếu cả hai Bob đều quyết định rằng họ là bob.ecc.eth ngoài chuỗi, thì không có cách nào để chọn ai trong số họ nhận được tên.
Một giải pháp khả thi là đưa thêm nội dung vào hợp đồng kho khóa được đề cập trong kiến trúc ở phần đầu của bài viết này. Hợp đồng kho khóa có thể chứa tất cả các loại thông tin về bạn và cách bạn tương tác với nó (đối với CCIP, một số thông tin này có thể nằm ngoài chuỗi) và người dùng sẽ sử dụng hợp đồng kho khóa của họ làm định danh chính. Nhưng tài sản thực tế mà họ nhận được sẽ được cất giữ ở nhiều nơi khác nhau. Hợp đồng kho khóa không xác định tên và chúng rất thân thiện với thực tế: bạn có thể tạo một địa chỉ có thể được chứng minh là chỉ được khởi tạo bởi hợp đồng kho khóa với một số tham số ban đầu cố định.
Một loại giải pháp khác tương tự như giao thức thanh toán Bitcoin, từ bỏ hoàn toàn khái niệm địa chỉ hướng đến người dùng. Một ý tưởng là dựa nhiều hơn vào các kênh giao tiếp trực tiếp giữa người gửi và người nhận; ví dụ: người gửi có thể gửi liên kết khiếu nại (dưới dạng URL hoặc mã QR rõ ràng) mà người nhận có thể sử dụng để tuân theo mức độ sẵn sàng chấp nhận thanh toán của họ.
Bất kể người gửi hay người nhận di chuyển trước, việc dựa nhiều hơn vào ví để trực tiếp tạo thông tin thanh toán cập nhật theo thời gian thực sẽ giúp giảm ma sát. Điều đó nói rằng, số nhận dạng liên tục rất tiện lợi (đặc biệt là với ENS), trong khi giả định giao tiếp trực tiếp giữa người gửi và người nhận là một điều rất phức tạp trong thực tế, vì vậy cuối cùng chúng ta có thể thấy sự kết hợp của các công nghệ khác nhau.
Trong tất cả các thiết kế này, làm cho mọi thứ trở nên rời rạc và dễ hiểu đối với người dùng là điều quan trọng nhất. Chúng tôi cần đảm bảo người dùng có quyền truy cập dễ dàng vào chế độ xem mới nhất về tài sản hiện tại của họ là gì và tin tức nào được xuất bản cho họ. Những quan điểm này nên dựa trên các công cụ mở, không phải các giải pháp độc quyền. Giữ cho cơ sở hạ tầng thanh toán phức tạp hơn không trở thành một "tháp trừu tượng" mờ đục, nơi các nhà phát triển gặp khó khăn trong việc hiểu những gì đang diễn ra và thích ứng với môi trường mới sẽ rất khó khăn. Bất chấp những thách thức, việc đạt được khả năng mở rộng, bảo mật ví và quyền riêng tư cho người dùng thông thường là rất quan trọng đối với tương lai của Ethereum. Đó không chỉ là tính khả thi về mặt kỹ thuật, mà còn là khả năng truy cập thực tế cho người dùng bình thường. Chúng ta cần phải vượt qua thử thách này.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Vitalik Buterin: Ba bước chuyển đổi kỹ thuật của Ethereum
Tác giả gốc: Người sáng lập Ethereum Vitalik Buterin
Xin đặc biệt cảm ơn Dan Finlay, Karl Floersch, David Hoffman và các nhóm Scroll và SoulWallet vì phản hồi, đánh giá và đề xuất của họ.
Khi Ethereum chuyển đổi từ một công nghệ non trẻ, thử nghiệm sang một nhóm công nghệ trưởng thành có khả năng thực sự mang lại trải nghiệm mở, toàn cầu và không cần cấp phép cho người dùng thông thường, thì nhóm sẽ cần trải qua ba quá trình chuyển đổi công nghệ chính gần như đồng thời:
Nếu không có lần đầu tiên, Ethereum sẽ thất bại, vì mỗi giao dịch có giá 3,75 đô la (82,48 đô la nếu chúng ta có một đợt tăng giá khác) và mọi sản phẩm nhắm đến thị trường đại chúng chắc chắn sẽ quên đi chuỗi và áp dụng một giải pháp thay thế tập trung cho mọi thứ.
Nếu không có điều thứ hai, Ethereum sẽ thất bại vì người dùng không muốn lưu trữ tiền của họ (và tài sản phi tài chính) và mọi người chuyển sang trao đổi tập trung.
Nếu không có phần ba, Ethereum sẽ thất bại vì tất cả các giao dịch (và POAP, v.v.) Một giải pháp tập trung giúp ẩn dữ liệu của bạn ở mức độ lớn nhất.
Ba quá trình chuyển đổi này rất quan trọng vì những lý do đã nêu ở trên. Nhưng chúng cũng đầy thách thức, vì giải quyết chúng đúng cách đòi hỏi sự phối hợp chặt chẽ. Nó không chỉ là chức năng của giao thức cần được cải thiện; trong một số trường hợp, cách chúng ta tương tác với Ethereum cần phải thay đổi về cơ bản, đòi hỏi những thay đổi sâu sắc đối với các ứng dụng và ví.
Ba chuyển đổi này về cơ bản sẽ định hình lại mối quan hệ giữa người dùng và địa chỉ
Trong thế giới mở rộng L2, người dùng sẽ tồn tại trên nhiều L2. Bạn có phải là thành viên của ExampleDAO dựa trên sự lạc quan không? Sau đó, bạn có một tài khoản Lạc quan! Bạn có giữ CDP trong hệ thống stablecoin trên ZkSync không? Sau đó, bạn có một tài khoản trên ZkSync! Bạn đã thử một số ứng dụng trên kakarot chưa? Sau đó, bạn có một tài khoản trên Kakarot! Đã qua rồi cái thời mà người dùng chỉ có một địa chỉ.
Ví hợp đồng thông minh làm tăng thêm độ phức tạp và khiến việc có cùng một địa chỉ trong L1 và các L2 khác nhau trở nên khó khăn hơn. Ngày nay, hầu hết người dùng đang sử dụng các tài khoản thuộc sở hữu bên ngoài có địa chỉ thực sự là mã băm của các khóa công khai được sử dụng để xác minh chữ ký - vì vậy không có gì thay đổi giữa L1 và L2. Tuy nhiên, với ví hợp đồng thông minh, việc đặt địa chỉ trở nên khó khăn hơn. Mặc dù đã có rất nhiều công việc được thực hiện để thử và biến các địa chỉ thành một mã băm tương đương trên các mạng, đáng chú ý nhất là các nhà máy đơn lẻ CREATE2 và ERC-2470, thật khó để làm cho điều này hoạt động hoàn hảo. Một số L2 (chẳng hạn như "ZK-EVM loại 4") không hoàn toàn tương đương với EVM, thường thì Solidity hoặc các tổ hợp trung gian được sử dụng thay thế để ngăn tương đương hàm băm. Ngay cả khi bạn có thể có giá trị băm tương đương, thì khả năng ví tiền thay đổi quyền sở hữu thông qua các thay đổi quan trọng sẽ gây ra những hậu quả không trực quan khác.
Quyền riêng tư yêu cầu nhiều địa chỉ hơn cho mỗi người dùng và thậm chí có thể thay đổi các loại địa chỉ mà chúng tôi đang xử lý. Nếu đề xuất địa chỉ ẩn được sử dụng rộng rãi, thay vì chỉ một vài địa chỉ cho mỗi người dùng hoặc một địa chỉ cho mỗi L2, người dùng có thể có một địa chỉ cho mỗi giao dịch. Các kế hoạch bảo mật khác, ngay cả những kế hoạch hiện có như Tornado Cash, thay đổi cách lưu trữ tài sản theo cách khác: tiền của nhiều người dùng được lưu trữ trong cùng một hợp đồng thông minh (và do đó tại cùng một địa chỉ). Để gửi tiền cho một người dùng cụ thể, người dùng sẽ cần dựa vào hệ thống địa chỉ nội bộ riêng của chương trình quyền riêng tư.
Như chúng ta đã thấy, mỗi trong số ba quá trình chuyển đổi này làm suy yếu mô hình tinh thần "một người dùng ~= một địa chỉ" theo những cách khác nhau, với một số tác động này phản ánh sự phức tạp của việc triển khai quá trình chuyển đổi. Hai điểm phức tạp đặc biệt là:
Nếu bạn muốn trả tiền cho ai đó, làm thế nào bạn có được thông tin về cách trả tiền cho họ?
Nếu người dùng có nhiều tài sản trên các chuỗi được lưu trữ ở những nơi khác nhau, làm cách nào để họ thực hiện các thay đổi chính và phục hồi xã hội?
Ba lần chuyển đổi và thanh toán trên chuỗi (và danh tính)
Tôi có xu trên Scroll và tôi muốn trả tiền cho cà phê (nếu "tôi" ám chỉ tôi với tư cách là tác giả của bài viết này, thì "cà phê" tất nhiên là một ẩn dụ của "trà xanh"). Bạn đang bán cà phê cho tôi, nhưng bạn chỉ có thể nhận được tiền trên Taiko. phải làm gì
Về cơ bản có hai giải pháp:
Tất nhiên, các giải pháp này có thể được kết hợp: người nhận cung cấp danh sách các L2 mà họ sẵn sàng chấp nhận và ví của người gửi tính toán khoản thanh toán, có thể liên quan đến việc gửi trực tiếp hoặc đường dẫn bắc cầu qua L2 nếu họ may mắn.
Nhưng đây chỉ là một ví dụ về thách thức chính mà ba quá trình chuyển đổi này đưa ra: các hoạt động đơn giản như thanh toán cho ai đó bắt đầu yêu cầu nhiều thông tin hơn là chỉ một địa chỉ 20 byte.
May mắn thay, việc chuyển đổi sang ví hợp đồng thông minh sẽ không làm quá tải hệ thống địa chỉ, nhưng vẫn còn một số vấn đề kỹ thuật cần được giải quyết trong các phần khác của ngăn xếp ứng dụng. Các ví sẽ cần được cập nhật để đảm bảo rằng chúng không chỉ gửi 21000 gas cùng với giao dịch và điều quan trọng hơn là đảm bảo phần cuối nhận thanh toán của ví không chỉ theo dõi việc chuyển ETH từ EOA mà còn theo dõi cả ETH được gửi bởi mã hợp đồng thông minh. Các ứng dụng dựa trên giả định về quyền sở hữu địa chỉ bất biến (ví dụ: NFT cấm hợp đồng thông minh thực thi phí bản quyền) sẽ phải tìm các cách khác để đạt được mục tiêu của mình. Ví hợp đồng thông minh cũng sẽ giúp mọi thứ trở nên dễ dàng hơn - đáng chú ý là nếu ai đó chỉ nhận được mã thông báo ERC20 không phải ETH, họ sẽ có thể sử dụng mã thông báo đó để thanh toán xăng bằng cách sử dụng trình quản lý thanh toán ERC-4337.
Mặt khác, quyền riêng tư lại đặt ra một thách thức lớn mà chúng tôi chưa thực sự giải quyết được. Tornado Cash ban đầu không gây ra bất kỳ vấn đề nào trong số này vì nó không hỗ trợ chuyển khoản nội bộ: người dùng chỉ có thể gửi tiền vào hệ thống và rút tiền từ hệ thống. Tuy nhiên, khi có thể chuyển nội bộ, người dùng sẽ cần sử dụng sơ đồ địa chỉ nội bộ của hệ thống bảo mật. Trên thực tế, "tin nhắn thanh toán" của người dùng cần chứa (i) một số loại "khóa chi tiêu", một lời hứa về bí mật mà người nhận có thể sử dụng để chi tiêu và (ii) một số cách để người gửi chỉ gửi tiền điện tử Thông tin mà người được trả tiền có thể giải mã để giúp người được trả tiền khám phá khoản thanh toán.
Giao thức địa chỉ ẩn dựa trên khái niệm địa chỉ meta, hoạt động theo cách này: một phần của địa chỉ meta là phiên bản ẩn của khóa chi tiêu của người gửi và phần còn lại là khóa mã hóa của người gửi (mặc dù việc triển khai tối thiểu có thể thiết lập cả hai phím giống nhau).
Một bài học quan trọng ở đây là trong một hệ sinh thái thân thiện với quyền riêng tư, người dùng sẽ có cả khóa công khai tiêu thụ và khóa công khai mã hóa và "thông tin thanh toán" của người dùng phải bao gồm cả hai khóa. Ngoài các khoản thanh toán, có nhiều lý do chính đáng để mở rộng theo hướng này. Ví dụ: nếu chúng tôi muốn email được mã hóa dựa trên Ethereum, người dùng sẽ cần cung cấp công khai một số loại khóa mã hóa. Trong "thế giới EOA", chúng tôi có thể sử dụng lại các khóa tài khoản cho việc này, nhưng trong thế giới ví hợp đồng thông minh an toàn, có lẽ chúng tôi nên cung cấp một chức năng rõ ràng hơn cho việc này. Điều này cũng giúp làm cho các danh tính dựa trên Ethereum tương thích hơn với các hệ sinh thái bảo mật phi tập trung không phải Ethereum, đặc biệt là các khóa PGP.
Ba lần chuyển đổi và khôi phục khóa
Cách mặc định để triển khai các thay đổi quan trọng và khôi phục mạng xã hội trong một thế giới mà mỗi người dùng có nhiều địa chỉ là chỉ cần yêu cầu người dùng chạy quy trình khôi phục trên từng địa chỉ một cách riêng biệt. Điều này có thể được thực hiện bằng một cú nhấp chuột: ví có thể chứa phần mềm có thể thực hiện các quy trình khôi phục đồng thời trên tất cả các địa chỉ của người dùng. Tuy nhiên, ngay cả với việc đơn giản hóa trải nghiệm người dùng này, vẫn có ba vấn đề với khôi phục đa địa chỉ đơn giản:
Giải quyết những vấn đề này là khó khăn. May mắn thay, có một giải pháp tao nhã hoạt động khá tốt: một kiến trúc tách logic xác thực khỏi việc nắm giữ tài sản.
Bằng chứng có thể đạt được theo nhiều cách:
Để thêm quyền riêng tư cho sơ đồ như vậy, chúng tôi chỉ cần mã hóa con trỏ này và sau đó chúng tôi thực hiện tất cả các bằng chứng trong ZK-SNARK:
Những kịch bản này có thể trở nên phức tạp. Về mặt tích cực, có nhiều sự phối hợp tiềm năng giữa chúng. Ví dụ: khái niệm "hợp đồng kho khóa" cũng có thể giải quyết thách thức "địa chỉ" được đề cập trong phần trước: nếu chúng tôi muốn người dùng có địa chỉ cố định không thay đổi mỗi khi người dùng nhập lại khóa, chúng tôi có thể đặt Địa chỉ meta ẩn , các khóa mã hóa và thông tin khác được đưa vào hợp đồng kho khóa và địa chỉ của hợp đồng kho khóa được sử dụng làm "địa chỉ" của người dùng.
Nhiều hạ tầng thứ cấp cần được nâng cấp
Sử dụng ENS rất tốn kém. Hôm nay, tháng 6 năm 2023, mọi thứ không quá tệ: phí giao dịch cao nhưng vẫn tương đương với phí miền ENS. Đăng ký với zuzalu.eth tiêu tốn của tôi khoảng 27 đô la, trong đó 11 đô la là phí giao dịch. Nhưng nếu chúng ta có một thị trường tăng giá khác, phí sẽ tăng vọt. Ngay cả khi không có sự tăng giá của ETH, việc chuyển phí gas trở lại 200 gwei sẽ tăng phí giao dịch đăng ký tên miền lên 104 đô la. Vì vậy, nếu chúng tôi muốn mọi người thực sự sử dụng ENS, đặc biệt đối với các trường hợp sử dụng như phương tiện truyền thông xã hội phi tập trung, nơi người dùng yêu cầu đăng ký gần như miễn phí (và phí miền ENS không phải là vấn đề vì các nền tảng này cung cấp cho người dùng tên miền phụ của họ), chúng tôi cần ENS ở L2 để hoạt động .
May mắn thay, nhóm ENS đã tăng cường và ENS trên L2 đang diễn ra! ERC-3668 (hay còn gọi là "tiêu chuẩn CCIP"), cùng với ENSIP-10, cung cấp một cách để làm cho các miền con ENS trên bất kỳ L2 nào có thể tự động xác minh được. Tiêu chuẩn CCIP yêu cầu tạo hợp đồng thông minh mô tả phương pháp xác minh bằng chứng về dữ liệu L2 và các miền đó (ví dụ: Optinames sử dụng ecc.eth) có thể được đặt dưới sự kiểm soát của hợp đồng đó. Sau khi hợp đồng CCIP nắm quyền kiểm soát ecc.eth trên L1, việc truy cập một số tên miền phụ.ecc.eth sẽ tự động liên quan đến việc tìm và xác minh bằng chứng trạng thái (ví dụ: nhánh Merkle) trong L2 nơi tên miền phụ cụ thể đó thực sự được lưu trữ.
Nỗ lực CCIP của ENS là một câu chuyện thành công và nó nên được coi là một dấu hiệu cho thấy loại cải cách triệt để mà chúng ta cần thực sự có thể thực hiện được. Nhưng vẫn còn nhiều cải cách tầng ứng dụng cần được thực hiện. Một vài ví dụ:
Ví sẽ cần bảo vệ tài sản và dữ liệu
Ngày nay, ví đang được sử dụng để bảo vệ tài sản. Mọi thứ đều trực tuyến và thứ duy nhất mà chiếc ví cần bảo vệ là các khóa riêng tư hiện đang bảo mật các tài sản này. Nếu bạn thay đổi khóa của mình, bạn có thể xuất bản khóa riêng tư trước đó của mình trên Internet một cách an toàn vào ngày hôm sau. Tuy nhiên, trong thế giới ZK, điều này không còn đúng nữa: ví không chỉ bảo vệ thông tin xác thực mà còn chứa dữ liệu của bạn.
Chúng tôi đã thấy những dấu hiệu đầu tiên của một thế giới như vậy với Zupass, hệ thống nhận dạng dựa trên ZK-SNARK được sử dụng bởi Zuzalu. Người dùng có một khóa riêng để xác thực hệ thống, khóa này có thể được sử dụng để tạo các bằng chứng cơ bản, chẳng hạn như "chứng minh rằng tôi là cư dân của Zuzalu mà không tiết lộ địa chỉ nào". Nhưng hệ thống Zupass cũng bắt đầu xây dựng các ứng dụng khác trên đó, đáng chú ý nhất là tem (phiên bản POAP của Zupass).
Tính năng chính mà tem cung cấp so với POAP là tem là riêng tư: bạn lưu dữ liệu cục bộ và nếu bạn muốn ai đó có thông tin về mình, bạn chỉ cần chứng minh tem (hoặc một số tính toán trên tem) cho ai đó . Nhưng điều đó làm tăng thêm rủi ro: nếu bạn mất thông tin đó, bạn sẽ mất tem.
Tất nhiên, vấn đề lưu trữ dữ liệu có thể được giảm xuống thành vấn đề lưu giữ một khóa mã hóa duy nhất: một số bên thứ ba (hoặc thậm chí chuỗi) có thể lưu giữ một bản sao dữ liệu được mã hóa. Điều này có lợi thế thuận tiện là hành động bạn thực hiện không làm thay đổi khóa mã hóa, vì vậy không cần tương tác với hệ thống giữ an toàn cho khóa mã hóa của bạn. Nhưng ngay cả khi đó, nếu bạn đánh mất khóa mã hóa, bạn sẽ mất tất cả. Mặt khác, nếu ai đó nhìn thấy khóa mã hóa của bạn, họ có thể thấy mọi thứ được mã hóa bằng khóa đó.
Giải pháp thiết thực của Zupass là khuyến khích mọi người lưu trữ khóa của họ trên nhiều thiết bị (chẳng hạn như máy tính xách tay và điện thoại), vì khả năng họ mất quyền truy cập vào tất cả các thiết bị đó cùng một lúc là rất thấp. Chúng ta có thể tiến thêm một bước và sử dụng chia sẻ bí mật để lưu trữ khóa, được phân phối giữa nhiều người giám hộ.
Sự phục hồi xã hội thông qua MPC này không phải là một giải pháp thích hợp cho ví, vì điều đó có nghĩa là không chỉ những người giám hộ hiện tại mà cả những người giám hộ trước đây cũng có thể thông đồng để đánh cắp tài sản của bạn, đây là một rủi ro cao không thể chấp nhận được. Tuy nhiên, rủi ro vi phạm quyền riêng tư thường thấp hơn rủi ro mất toàn bộ tài sản và những người có các trường hợp sử dụng quyền riêng tư cao luôn có thể chấp nhận rủi ro mất mát cao hơn do không sao lưu các khóa liên quan đến các hoạt động đòi hỏi quyền riêng tư này.
Để tránh người dùng bị choáng ngợp bởi hệ thống Byzantine với nhiều đường dẫn khôi phục, các ví hỗ trợ khôi phục xã hội có thể cần quản lý cả khôi phục tài sản và khôi phục khóa mã hóa.
Quay lại danh tính
Một trong những điểm chung của những thay đổi này là khái niệm về "địa chỉ", mã định danh mật mã mà bạn sử dụng để đại diện cho "bạn" trên chuỗi, về cơ bản phải thay đổi. "Hướng dẫn cách tương tác với tôi" sẽ không còn chỉ là một địa chỉ ETH; chúng phải là sự kết hợp của nhiều địa chỉ trên nhiều L2, địa chỉ meta ẩn, khóa mã hóa và dữ liệu khác ở một số dạng.
Một cách là biến ENS thành danh tính của bạn: bản ghi ENS của bạn chỉ có thể chứa tất cả thông tin này và nếu bạn gửi cho ai đó bob.eth (hoặc bob.ecc.eth, hoặc...), họ có thể tra cứu và xem mọi thứ về cách thức nó trả tiền và tương tác với bạn, bao gồm các phương pháp bảo vệ quyền riêng tư và tên miền chéo phức tạp hơn.
Nhưng cách tiếp cận lấy ENS làm trung tâm này có hai điểm yếu:
Một giải pháp khả thi là đưa thêm nội dung vào hợp đồng kho khóa được đề cập trong kiến trúc ở phần đầu của bài viết này. Hợp đồng kho khóa có thể chứa tất cả các loại thông tin về bạn và cách bạn tương tác với nó (đối với CCIP, một số thông tin này có thể nằm ngoài chuỗi) và người dùng sẽ sử dụng hợp đồng kho khóa của họ làm định danh chính. Nhưng tài sản thực tế mà họ nhận được sẽ được cất giữ ở nhiều nơi khác nhau. Hợp đồng kho khóa không xác định tên và chúng rất thân thiện với thực tế: bạn có thể tạo một địa chỉ có thể được chứng minh là chỉ được khởi tạo bởi hợp đồng kho khóa với một số tham số ban đầu cố định.
Một loại giải pháp khác tương tự như giao thức thanh toán Bitcoin, từ bỏ hoàn toàn khái niệm địa chỉ hướng đến người dùng. Một ý tưởng là dựa nhiều hơn vào các kênh giao tiếp trực tiếp giữa người gửi và người nhận; ví dụ: người gửi có thể gửi liên kết khiếu nại (dưới dạng URL hoặc mã QR rõ ràng) mà người nhận có thể sử dụng để tuân theo mức độ sẵn sàng chấp nhận thanh toán của họ.
Trong tất cả các thiết kế này, làm cho mọi thứ trở nên rời rạc và dễ hiểu đối với người dùng là điều quan trọng nhất. Chúng tôi cần đảm bảo người dùng có quyền truy cập dễ dàng vào chế độ xem mới nhất về tài sản hiện tại của họ là gì và tin tức nào được xuất bản cho họ. Những quan điểm này nên dựa trên các công cụ mở, không phải các giải pháp độc quyền. Giữ cho cơ sở hạ tầng thanh toán phức tạp hơn không trở thành một "tháp trừu tượng" mờ đục, nơi các nhà phát triển gặp khó khăn trong việc hiểu những gì đang diễn ra và thích ứng với môi trường mới sẽ rất khó khăn. Bất chấp những thách thức, việc đạt được khả năng mở rộng, bảo mật ví và quyền riêng tư cho người dùng thông thường là rất quan trọng đối với tương lai của Ethereum. Đó không chỉ là tính khả thi về mặt kỹ thuật, mà còn là khả năng truy cập thực tế cho người dùng bình thường. Chúng ta cần phải vượt qua thử thách này.