Tác giả: Vitalik, người sáng lập Ethereum; Bản dịch: Jinse Finance tiền điện tử
Khi Ethereum phát triển từ một công nghệ non trẻ, thử nghiệm thành một kho công nghệ trưởng thành có khả năng 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, có ba quá trình chuyển đổi công nghệ chính cần diễn ra đồng thời:
Đầu tiên là chuyển đổi mở rộng dung lượng L2 - mọi người chuyển sang công nghệ Rollup;
Thứ hai là Chuyển đổi bảo mật ví - Mọi người bắt đầu sử dụng ví hợp đồng thông minh;
Thứ ba là chuyển đổi quyền riêng tư - đảm bảo có sẵn chức năng chuyển tiền bảo vệ quyền riêng tư và đảm bảo rằng tất cả các công cụ khác đang được phát triển (khôi phục xã hội, xác minh danh tính, danh tiếng, v.v.) đều có các tính năng bảo vệ quyền riêng tư.
Tam giác chuyển đổi hệ sinh thái Ethereum. Bạn chỉ có thể chọn cả ba. *
Nếu không có mục đầ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 trải qua một đợt tăng giá khác) và mọi sản phẩm thị trường đại chúng chắc chắn sẽ bỏ Giao dịch trên chuỗi và áp dụng giải pháp tập trung.
Nếu không có mục thứ hai, Ethereum sẽ thất bại vì người dùng sẽ 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 sẽ chuyển sang trao đổi tập trung.
Nếu không có mục thứ ba, Ethereum sẽ thất bại vì đối với nhiều người dùng, tất cả các giao dịch (và POAP, v.v.) sẽ được hiển thị công khai, sự hy sinh quyền riêng tư sẽ quá lớn và mọi người sẽ chuyển sang ít nhất một số cấp độ dữ liệu ẩn của giải pháp tập trung.
Vì những lý do nêu trên, ba quá trình chuyển đổi này là rất quan trọng. Nhưng chúng cũng đầy thách thức do sự phức tạp của sự phối hợp liên quan. 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 một cách cơ bản và sâu sắc, đòi hỏi những thay đổi lớn trong ứ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 quy mô L2, người dùng sẽ tồn tại trên nhiều mạng L2. Bạn có phải là thành viên của ExampleDAO không? Ví dụDAO là về chủ nghĩa lạc quan. Sau đó, bạn có một tài khoản với Optimism! Bạn có giữ CDP của hệ thống stablecoin trên ZkSync không? Sau đó, bạn có một tài khoản trên ZkSync! Bạn đã bao giờ thử một số ứng dụng nằm 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 người dùng chỉ có một địa chỉ.
*Chế độ xem ví Brave của tôi, tôi giữ Ethereum ở bốn vị trí. Có, Arbitrum và Arbitrum Nova khác nhau. Đừng lo lắng, mọi thứ sẽ trở nên phức tạp hơn theo thời gian! *
**Ví hợp đồng thông minh phức tạp hơn vì việc có cùng địa chỉ trên các mạng L1 và L2 khác nhau trở nên khó khăn hơn. **Hầu hết người dùng ngày nay 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à hà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, việc duy trì một địa chỉ trở nên khó khăn hơn khi sử dụng ví hợp đồng thông minh. Mặc dù đã có rất nhiều công việc được thực hiện để thử và biến địa chỉ thành mã băm tương đương trên các mạng khác nhau, điều quan trọng nhất là CREATE2 và nhà máy đơn lẻ ERC-2470, rất khó để đạt được điều này một cách hoàn hảo. Một số mạng L2 (ví dụ: "ZK-EVM thuộc loại thứ tư") không hoàn toàn tương đương với EVM, thường sử dụng Solidity hoặc hợp ngữ trung gian thay vì tương đương hàm băm. Ngay cả khi có thể đạt được giá trị băm tương đương, thì khả năng các ví thay đổi quyền sở hữu thông qua những thay đổi quan trọng dẫn đến những hậu quả khác khó dự đoán hơn.
**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 loại địa chỉ mà chúng tôi xử lý. **Nếu đề xuất địa chỉ ẩn được sử dụng rộng rãi, người dùng có thể có một địa chỉ cho mỗi giao dịch 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 mạng L2. 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 những cách khác nhau: nhiều tiền của người dùng được lưu trữ trong cùng một hợp đồng thông minh (và do đó trên 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, ba phép biế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, một số tác động trong số đó lại làm tăng độ phức tạp của việc thực hiện các phép biến đổi này. Hai trong số những vấn đề đặc biệt phức tạp là:
**1. Nếu bạn muốn thanh toán cho ai đó, bạn sẽ lấy thông tin thanh toán như thế nào? **
**2. Nếu người dùng lưu trữ nội dung ở các vị trí khác nhau trên các chuỗi khác nhau, thì 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 quá trình chuyển đổi này và thanh toán trên chuỗi (và danh tính)
Tôi giữ mã thông báo trên Scroll và tôi muốn sử dụng chúng để mua cà phê (nếu chữ "tôi" theo nghĩa đen ám chỉ Vitalik, tác giả của bài viết này, thì "cà phê" tất nhiên có nghĩa là "trà xanh"). Bạn bán cà phê trên Taiko, nhưng bạn chỉ chấp nhận mã thông báo 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 bình thường) cố gắng hỗ trợ từng L2 và có một số chức năng hợp nhất quỹ không đồng bộ.
Người nhận thanh toán cung cấp thông tin L2 của họ bên cạnh địa chỉ và ví của người gửi sẽ tự động định tuyến tiền đến L2 mục tiêu thông qua một số loại hệ thống bắc cầu L2.
Tất nhiên, các giải pháp này có thể được sử dụng kết hợp: người nhận thanh toán cung cấp danh sách L2 mà họ sẵn sàng chấp nhận và ví của người gửi xác định phương thức thanh toán, phương thức này có thể được gửi trực tiếp (nếu may mắn) hoặc thanh toán qua đường dẫn bắc cầu qua L2.
Nhưng đây chỉ là một ví dụ về thách thức chính do ba chuyển đổi đưa ra: Các hành vi thanh toán đơn giản 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 sang ví hợp đồng thông minh không phải là gánh nặng lớn đối vớ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í cần được cập nhật để đảm bảo rằng chúng không chỉ gửi 21000 gas khi gửi giao dịch mà còn cần chú ý nhiều hơn để đảm bảo rằng phần cuối nhận của ví không chỉ theo dõi chuyển ETH từ EOA mà còn chuyển ETH từ EOA. mã hợp đồng thông minh. Các ứng dụng dựa trên 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 tiền 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ột số việc trở nên dễ dàng hơn, đặc biệt nếu ai đó chỉ chấp nhận mã thông báo ERC20 không phải ETH, họ sẽ có thể sử dụng người quản lý thanh toán ERC-4337 để thanh toán xăng bằng mã thông báo đó.
Mặt khác, vấn đề quyền riêng tư lại là một thách thức lớn mà chúng ta chưa thực sự giải quyết được. Tornado Cash ban đầu không đưa ra những vấn đề này vì nó không hỗ trợ chuyển khoản nội bộ: người dùng chỉ có thể gửi và rút tiền vào 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 sẽ cần chứa (i) một số loại "khóa công khai chi tiêu", một cam kết bí mật mà người nhận có thể sử dụng để chi tiêu và (ii) người gửi có thể gửi tin nhắn được mã hóa mà chỉ người nhận có thể giải mã Người nhận trợ giúp phát hiện ra phương thức thanh toán.
Giao thức địa chỉ tàng hình dựa trên khái niệm siêu địa chỉ, hoạt động như sau: một phần của siêu địa chỉ là khóa chi tiêu bị lừa của người gửi và phần còn lại là khóa được 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 khóa là như nhau).
Tổng quan về 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ó khóa công khai chi tiêu và khóa công khai mã hóa, đồng thời "thông tin thanh toán" của người dùng sẽ cần bao gồm cả hai khóa. ** Ngoài việc trả tiền, còn có những lý do chính đáng khác để mở rộng 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 khóa tài khoản, 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 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 quá trình chuyển đổi và khôi phục khóa này
Trong một thế giới mà mỗi người dùng có nhiều địa chỉ, cách mặc định để triển khai các thay đổi chính và khôi phục mạng xã hội là để người dùng chạy quy trình khôi phục trên từng địa chỉ riêng lẻ. Điều này có thể được thực hiện chỉ bằng một cú nhấp chuột: ví có thể cung cấp chức năng phần mềm để thực hiện quá 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ỉ:
1. Chi phí xăng là phi thực tế: Điều này là hiển nhiên.
2. Địa chỉ giả: địa chỉ chưa phát hành hợp đồng thông minh (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ỉ ảo: 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à toàn bộ vô số địa chỉ ảo phát sinh từ sơ đồ địa chỉ ẩn.
3. Quyền riêng tư: Nếu người dùng cố ý sử dụng 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 liên kết công khai tất cả các địa chỉ đó bằng cách khôi phục chúng cùng một lúc hoặc gần như cùng một lúc!
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 khá tinh tế hoạt động khá tốt: Kiến trúc này 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 một L2 cụ thể). Sau đó, người dùng có địa chỉ trên các L2 khác nhau và logic xác minh cho từng địa chỉ là một con trỏ tới hợp đồng kho khóa. Chi tiêu tiền từ các địa chỉ này sẽ yêu cầu cung cấp bằng chứng về khóa công khai chi tiêu hiện tại (hoặc thực tế hơn là rất gần đây) cho số tiền đó.
Bằng chứng này có thể đạt được bằng nhiều cách:
** Quyền truy cập chỉ đọc vào L1 trực tiếp bên trong L2. ** L2 có thể được sửa đổi để cho phép nó đọ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 đó 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.
**Cành Merkle. **Các nhánh Merkle có thể chứng minh trạng thái L1 thành L2 hoặc trạng thái L2 thành L1 hoặc sự kết hợp của cả hai có thể chứng minh 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, có thể yêu cầu độ dài bằng chứng là 5kB, nhưng do sử dụng cây Verkle, điều này sẽ giảm xuống <1kB trong tương lai.
**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ì sử dụng chính các nhánh đó. Các kỹ thuật tổng hợp ngoài chuỗi (ví dụ: trên EIP-4337) có thể được xây dựng để cho phép một ZK-SNARK duy nhất 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. **Cho dù đó là L2 hay sơ đồ được xây dựng trên nó, một hệ thống định địa chỉ tuần tự có thể được giới thiệu, cho phép bằng chứng trạng thái bên trong hệ thống chỉ có 48 byte. Giống như ZK-SNARK, các sơ đồ đa 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 cần bằng chứng cho mọi giao dịch, chúng tôi có thể triển khai một sơ đồ nhẹ hơn chỉ yêu cầu khôi phục trên các bằng chứng L2. Chi tiêu từ một tài khoản sẽ phụ thuộc vào khóa chi tiêu với khóa công khai tương ứng được lưu trữ bên 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 vào kho khóa. Ngay cả khi các khóa cũ của bạn không an toàn, tiền trong địa chỉ ảo vẫn an toàn: "kích hoạt" địa chỉ ảo để biến địa chỉ đó thành hợp đồng có thể sử dụng sẽ yêu cầu bằng chứng L2 chéo để sao chép khóa công khai chi tiêu hiện tại. Có một chủ đề 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ỏ và thực hiện tất cả các bằng chứng bên trong ZK-SNARK:
Với công việc tiếp theo (ví dụ: sử dụng công việc này làm điểm bắt đầu), chúng ta cũng có thể lột bỏ ZK - Hầu hết sự phức tạp của SNARK, xây dựng 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. Ưu điểm là có nhiều khả năng phối hợp giữa chúng. Ví dụ: khái niệm về "hợp đồng lưu trữ khóa" cũng có thể là một giải pháp cho "địa chỉ" được đề cập trong phần trước: nếu chúng tôi muốn người dùng có một địa chỉ liên tục không thay đổi mỗi khi người dùng cập nhật khóa, chúng tôi có thể đặt ẩn địa chỉ meta, khóa mã hóa và các 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.
Rất nhiều cơ sở hạ tầng thứ cấp cần được cập nhật
Sử dụng ENS rất tốn kém. Mặc dù không còn đắt như trước vào tháng 6 năm 2023, nhưng phí giao dịch đăng ký tên miền vẫn tương đối cao, tương đương với phí của một tên miền ENS. Ví dụ: chi phí khoảng 27 đô la để đăng ký với zuzalu.eth, 11 đô la trong số đó là phí giao dịch. Nhưng nếu thị trường tăng trở lại, phí sẽ tăng cao. Ngay cả khi giá ETH không tăng, nếu phí gas trở lại mức 200 gwei, thì phí giao dịch đăng ký tên miền sẽ lên tới 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í (phí tên miền ENS không phải là vấn đề vì các nền tảng này có thể cung cấp cho người dùng tên miền phụ), thì chúng tôi cần sử dụng ENS trên Lớp 2.
May mắn thay, nhóm ENS đã tăng cường và ENS đang được triển khai trên Lớp 2! ERC-3668 (còn được gọi là "tiêu chuẩn CCIP") và ENSIP-10 cung cấp cách tự động xác minh tên miền phụ ENS trên bất kỳ Lớp 2 nào. Tiêu chuẩn CCIP yêu cầu thiết lập hợp đồng thông minh mô tả phương pháp xác minh bằng chứng dữ liệu trên Lớp 2 và một tên miền (ví dụ: ecc.eth cho Optinames) có thể được đặt dưới sự kiểm soát của hợp đồng đó. Sau khi hợp đồng CCIP kiểm soát ecc.eth trên L1, việc truy cập vào một tên miền phụ.ecc.eth nhất định sẽ tự động tìm và xác minh bằng chứng lưu trữ trạng thái Lớp 2 của tên miền phụ cụ thể đó (ví dụ: nhánh Merkle).
thực sự có được những bằng chứng này liên quan đến việc truy cập danh sách các URL được lưu trữ trong hợp đồng, mặc dù đây là trong Bằng cách nào đó, nó có thể trông giống như tập trung hóa, nhưng tôi muốn nói rằng thực tế không phải vậy: đó là mô hình tin cậy 1-to-N (bằng chứng không hợp lệ được bắt bởi logic xác thực trong chức năng gọi lại hợp đồng CCIP, miễn là một trong các URL A trả về bằng chứng hợp lệ là tốt). Danh sách URL có thể chứa hàng chục URL.
**Nỗ lực CCIP của ENS là một câu chuyện thành công và nên được coi là một dấu hiệu cho thấy những 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 ở cấp độ ứng dụng cần được thực hiện. Dưới đây là một số ví dụ:
**Nhiều DApp dựa vào người dùng để cung cấp chữ ký ngoài chuỗi. **Đối với Tài khoản bên ngoài (EOA), thật dễ dàng. ERC-1271 cung cấp một cách chuẩn hóa để thực hiện việc này cho ví hợp đồng thông minh. Tuy nhiên, nhiều DApp vẫn không hỗ trợ ERC-1271 và chúng cần được điều chỉnh.
** Các DApp sử dụng "đây có phải là EOA không?" để phân biệt giữa người dùng và hợp đồng (ví dụ: để ngăn chặn chuyển nhượng hoặc thực thi tiền bản quyền) sẽ gặp sự cố. **Nói chung, tôi khuyên bạn không nên cố gắng tìm một giải pháp kỹ thuật thuần túy ở đây; việc xác định xem một chuyển giao quyền kiểm soát mật mã cụ thể có phải là chuyển giao quyền sở hữu có lợi hay không là một vấn đề khó có thể không được giải quyết nếu không nhờ đến một số biện pháp hướng đến cộng đồng ngoài chuỗi cơ chế giải quyết. Rất có thể, các ứng dụng sẽ ít dựa vào các phương tiện kỹ thuật để ngăn chặn chuyển giao và dựa nhiều hơn vào các kỹ thuật như thuế Harberger.
**Tương tác ví với các khoản thanh toán và khóa mã hóa sẽ cần được cải thiện. **Hiện tại, 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 (ví dụ: hàm băm của tên ứng dụng) bằng khóa riêng của EOA sẽ tạo ra giá trị xác định trừ khi khóa riêng được sở hữu, nếu không thì giá trị không thể được tạo ra và do đó hoàn toàn an toàn về mặt kỹ thuật. Tuy nhiên, các kỹ thuật này "không rõ ràng" đối với ví, ngăn ví thực hiện kiểm tra bảo mật cấp giao diện người dùng. Trong một 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ẽ cần được ví xử lý rõ ràng hơn.
Các ứng dụng khách nhẹ (chẳng hạn như Helios) sẽ cần xác thực Lớp 2 thay vì chỉ Lớp 1**. **Hiện tại, ứng dụng khách nhẹ đang tập trung vào việc kiểm tra tính hợp lệ của thông tin tiêu đề khối L1 (sử dụng giao thức đồng bộ hóa ứng dụng khách nhẹ) và xác minh nhánh Merkle của trạng thái L1 và các giao dịch dựa trên thông tin tiêu đề khối L1. Trong tương lai, họ cũng sẽ cần xác minh bằng chứng về trạng thái L2 bắt nguồn từ gốc trạng thái được lưu trữ trong L1 (các phiên bản nâng cao hơn sẽ thực sự xem xét xác nhận trước L2).
Ví sẽ cần bảo vệ tài sản và dữ liệu
Hiện tại, nhiệm vụ của ví là bảo vệ tài sản. Mọi thứ được lưu trữ trên chuỗi, tất cả những gì ví cần bảo vệ là các khóa riêng hiện đang bảo vệ các tài sản này. Nếu bạn thay đổi khóa, bạn có thể đăng công khai khóa riêng trước đó trên Internet một cách an toàn vào ngày hôm sau. Tuy nhiên, trong một thế giới không có kiến thức, điều này không còn đúng nữa: ví không chỉ bảo vệ thông tin đăng nhập 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 tại Zuzalu với Zupass, một hệ thống nhận dạng dựa trên ZK-SNARK. Người dùng có một khóa riêng được sử dụng để xác thực vào 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ộ tôi là cư dân nào". Hệ thống Zupass cũng bắt đầu xây dựng các ứng dụng khác trên đó, quan trọng nhất là tem (phiên bản POAP của Zupass).
*Một trong nhiều tem Zupass của tôi xác nhận rằng tôi là thành viên của Team Cat. *
Tính năng chính của tem liên quan đến POAP là chúng ở chế độ riêng tư: bạn lưu dữ liệu cục bộ và chỉ chứng minh tem cho ZK của họ (hoặc thực hiện một số tính toán trên tem) nếu bạn muốn cung cấp thông tin đó cho ai đó. Nhưng điều này cũng đi kèm với một rủi ro bổ sung: nếu bạn làm mất thông tin đó, bạn sẽ mất tem của mình.
Tất nhiên, vấn đề lưu giữ dữ liệu có thể giảm xuống thành vấn đề giữ một khóa mã hóa duy nhất: bên thứ ba (thậm chí trên chuỗi) có thể 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 thay đổi khóa mã hóa, do đó không cần tương tác với hệ thống giữ khóa mã hóa. Nhưng ngay cả khi đó, nếu bạn mất khóa mã hóa, bạn sẽ mất tất cả dữ liệu của mình. Và đổi lại, nếu ai đó thấy khóa mã hóa của bạn, họ sẽ 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ữ chìa 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 lúc là rất thấp. Chúng ta có thể tiến thêm một bước bằng cách sử dụng tính năng chia sẻ khóa để phân chia bộ lưu trữ khóa cho nhiều người bảo vệ.
Phục hồi xã hội thông qua MPC 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ỉ người bảo vệ hiện tại mà cả những người bảo vệ trước đó 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. Mặc dù vi phạm quyền riêng tư thường ít rủi ro hơn so với việc mất hoàn toàn tài sản, nhưng đối với các trường hợp sử dụng có nhu cầu quyền riêng tư cao, bạ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 nhu cầu quyền riêng tư đó.
Để tránh làm người dùng sa lầy trong một hệ thống phức tạp gồm nhiều đường khôi phục, các ví hỗ trợ khôi phục xã hội có thể cần quản lý cả hai khía cạnh 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 chủ đề chung trong số những thay đổi này là khái niệm "địa chỉ" như một đại diện cho danh tính trên chuỗi khối sẽ cần phải thay đổi về cơ bản. ** "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 nữa; express. **
Một trong những cách này là sử dụng ENS làm danh tính của bạn: bản ghi ENS của bạn có thể chứa tất cả thông tin về cách thanh toán và tương tác với bạn, nếu bạn gửi cho ai đó bob.eth (hoặc bob.ecc.eth, v.v.), họ có thể hỏi và tìm hiểu về mọi thứ tương tác với bạn, kể cả theo những cách phức tạp hơn trên các miền và với bảo vệ quyền riêng tư.
Tuy nhiên, 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 nội dung với tên của bạn. **Tên của bạn không có nghĩa là tất cả mọi thứ về bạn, nó chỉ là một trong nhiều thuộc tính về bạn. Có thể thay đổi tên của bạn mà không cần di chuyển toàn bộ hồ sơ nhận dạng của bạn và cập nhật hồ sơ trong nhiều ứng dụng.
**Bạn không thể có tên phản thực mà không yêu cầu sự tin tưởng. **Một tính năng trải nghiệm người dùng chính của bất kỳ chuỗi khối nào là khả năng gửi mã thông báo cho những người chưa tương tác với chuỗi. Nếu không có chức năng như vậy, sẽ có một tình huống khó xử: tương tác với chuỗi yêu cầu trả phí giao dịch và thanh toán phí giao dịch yêu cầu... đã sở hữu mã thông báo. Đị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 thì không, bởi vì nếu cả hai Bob quyết định ngoài chuỗi rằng họ là bob.ecc.eth, thì không có cách nào để chọn Bob lấy tên nào.
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 trước đó trong kiến trúc của bài viết này. Hợp đồng kho khóa có thể chứa nhiều thông tin khác nhau về bạn và các tương tác với bạn (và với CCIP, một số thông tin này có thể nằm ngoài chuỗi), người dùng sẽ sử dụng hợp đồng kho khóa của họ làm định danh chính. Tuy nhiên, tài sản mà họ thực sự nhận được sẽ được cất giữ ở nhiều nơi khác nhau. Hợp đồng kho khóa không phân biệt tên và thân thiện với tên ảo: bạn có thể tạo một địa chỉ chỉ có thể được khởi tạo bằng hợp đồng kho khóa với các tham số ban đầu cố định nhất định.
Một loại giải pháp khác liên quan đến việc từ bỏ hoàn toàn khái niệm địa chỉ hướng tới người dùng, tương tự như giao thức thanh toán của Bitcoin. 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 một liên kết yêu cầu (dưới dạng URL hoặc mã QR rõ ràng), mà người nhận có thể sử dụng để gửi bất kỳ yêu cầu nào họ muốn chấp nhận sự chi trả.
Cho dù đó là người gửi hay người nhận hành động đầu tiên, việc dựa nhiều hơn vào ví để tạo thông tin thanh toán cập nhật trong thời gian thực sẽ giúp giảm ma sát. Tuy nhiên, các định danh liên tục rất thuận tiện (đặc biệt là với ENS), trong khi trên thực tế, việc dựa vào giao tiếp trực tiếp giữa người gửi và người nhận là một vấn đề rất phức tạp, do đó có thể thấy sự kết hợp của các kỹ thuật khác nhau.
Trong tất cả các thiết kế này, điều quan trọng là phải duy trì tính phi tập trung và dễ hiểu đối với người dùng. Chúng tôi cần đảm bảo rằng người dùng có thể dễ dàng truy cập chế độ xem cập nhật về tài sản hiện tại và thông điệp được nhắm mục tiêu đến họ. Những quan điểm này nên dựa vào các công cụ mở hơn là các giải pháp độc quyền. Sẽ mất nhiều công sức để giữ cho cơ sở hạ tầng thanh toán phức tạp hơn trở thành một "tháp trừu tượng" mờ đục, khó hiểu và khó thích nghi với môi trường mới. Bất chấp những thách thức, đạt được khả năng mở rộng của Ethereum, bảo mật ví và quyền riêng tư cho người dùng thông thường là điều tối quan trọng. Đó không chỉ là tính khả thi về mặt kỹ thuật, mà còn là khả năng tiếp cận thực tế đối với người dùng bình thường. Chúng ta cần phải đáp ứng thách thức 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: Hệ sinh thái Ethereum cần ba lần chuyển đổi công nghệ
Tác giả: Vitalik, người sáng lập Ethereum; Bản dịch: Jinse Finance tiền điện tử
Khi Ethereum phát triển từ một công nghệ non trẻ, thử nghiệm thành một kho công nghệ trưởng thành có khả năng 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, có ba quá trình chuyển đổi công nghệ chính cần diễn ra đồng thời:
Nếu không có mục đầ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 trải qua một đợt tăng giá khác) và mọi sản phẩm thị trường đại chúng chắc chắn sẽ bỏ Giao dịch trên chuỗi và áp dụng giải pháp tập trung.
Nếu không có mục thứ hai, Ethereum sẽ thất bại vì người dùng sẽ 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 sẽ chuyển sang trao đổi tập trung.
Nếu không có mục thứ ba, Ethereum sẽ thất bại vì đối với nhiều người dùng, tất cả các giao dịch (và POAP, v.v.) sẽ được hiển thị công khai, sự hy sinh quyền riêng tư sẽ quá lớn và mọi người sẽ chuyển sang ít nhất một số cấp độ dữ liệu ẩn của giải pháp tập trung.
Vì những lý do nêu trên, ba quá trình chuyển đổi này là rất quan trọng. Nhưng chúng cũng đầy thách thức do sự phức tạp của sự phối hợp liên quan. 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 một cách cơ bản và sâu sắc, đòi hỏi những thay đổi lớn trong ứ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 quy mô L2, người dùng sẽ tồn tại trên nhiều mạng L2. Bạn có phải là thành viên của ExampleDAO không? Ví dụDAO là về chủ nghĩa lạc quan. Sau đó, bạn có một tài khoản với Optimism! Bạn có giữ CDP của hệ thống stablecoin trên ZkSync không? Sau đó, bạn có một tài khoản trên ZkSync! Bạn đã bao giờ thử một số ứng dụng nằm 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 người dùng chỉ có một địa chỉ.
**Ví hợp đồng thông minh phức tạp hơn vì việc có cùng địa chỉ trên các mạng L1 và L2 khác nhau trở nên khó khăn hơn. **Hầu hết người dùng ngày nay 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à hà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, việc duy trì một địa chỉ trở nên khó khăn hơn khi sử dụng ví hợp đồng thông minh. Mặc dù đã có rất nhiều công việc được thực hiện để thử và biến địa chỉ thành mã băm tương đương trên các mạng khác nhau, điều quan trọng nhất là CREATE2 và nhà máy đơn lẻ ERC-2470, rất khó để đạt được điều này một cách hoàn hảo. Một số mạng L2 (ví dụ: "ZK-EVM thuộc loại thứ tư") không hoàn toàn tương đương với EVM, thường sử dụng Solidity hoặc hợp ngữ trung gian thay vì tương đương hàm băm. Ngay cả khi có thể đạt được giá trị băm tương đương, thì khả năng các ví thay đổi quyền sở hữu thông qua những thay đổi quan trọng dẫn đến những hậu quả khác khó dự đoán hơn.
**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 loại địa chỉ mà chúng tôi xử lý. **Nếu đề xuất địa chỉ ẩn được sử dụng rộng rãi, người dùng có thể có một địa chỉ cho mỗi giao dịch 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 mạng L2. 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 những cách khác nhau: nhiều tiền của người dùng được lưu trữ trong cùng một hợp đồng thông minh (và do đó trên 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, ba phép biế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, một số tác động trong số đó lại làm tăng độ phức tạp của việc thực hiện các phép biến đổi này. Hai trong số những vấn đề đặc biệt phức tạp là:
**1. Nếu bạn muốn thanh toán cho ai đó, bạn sẽ lấy thông tin thanh toán như thế nào? **
**2. Nếu người dùng lưu trữ nội dung ở các vị trí khác nhau trên các chuỗi khác nhau, thì 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 quá trình chuyển đổi này và thanh toán trên chuỗi (và danh tính)
Tôi giữ mã thông báo trên Scroll và tôi muốn sử dụng chúng để mua cà phê (nếu chữ "tôi" theo nghĩa đen ám chỉ Vitalik, tác giả của bài viết này, thì "cà phê" tất nhiên có nghĩa là "trà xanh"). Bạn bán cà phê trên Taiko, nhưng bạn chỉ chấp nhận mã thông báo 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 bình thường) cố gắng hỗ trợ từng L2 và có một số chức năng hợp nhất quỹ không đồng bộ.
Người nhận thanh toán cung cấp thông tin L2 của họ bên cạnh địa chỉ và ví của người gửi sẽ tự động định tuyến tiền đến L2 mục tiêu thông qua một số loại hệ thống bắc cầu L2.
Tất nhiên, các giải pháp này có thể được sử dụng kết hợp: người nhận thanh toán cung cấp danh sách L2 mà họ sẵn sàng chấp nhận và ví của người gửi xác định phương thức thanh toán, phương thức này có thể được gửi trực tiếp (nếu may mắn) hoặc thanh toán qua đường dẫn bắc cầu qua L2.
Nhưng đây chỉ là một ví dụ về thách thức chính do ba chuyển đổi đưa ra: Các hành vi thanh toán đơn giản 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 sang ví hợp đồng thông minh không phải là gánh nặng lớn đối vớ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í cần được cập nhật để đảm bảo rằng chúng không chỉ gửi 21000 gas khi gửi giao dịch mà còn cần chú ý nhiều hơn để đảm bảo rằng phần cuối nhận của ví không chỉ theo dõi chuyển ETH từ EOA mà còn chuyển ETH từ EOA. mã hợp đồng thông minh. Các ứng dụng dựa trên 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 tiền 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ột số việc trở nên dễ dàng hơn, đặc biệt nếu ai đó chỉ chấp nhận mã thông báo ERC20 không phải ETH, họ sẽ có thể sử dụng người quản lý thanh toán ERC-4337 để thanh toán xăng bằng mã thông báo đó.
Mặt khác, vấn đề quyền riêng tư lại là một thách thức lớn mà chúng ta chưa thực sự giải quyết được. Tornado Cash ban đầu không đưa ra những vấn đề này vì nó không hỗ trợ chuyển khoản nội bộ: người dùng chỉ có thể gửi và rút tiền vào 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 sẽ cần chứa (i) một số loại "khóa công khai chi tiêu", một cam kết bí mật mà người nhận có thể sử dụng để chi tiêu và (ii) người gửi có thể gửi tin nhắn được mã hóa mà chỉ người nhận có thể giải mã Người nhận trợ giúp phát hiện ra phương thức thanh toán.
Giao thức địa chỉ tàng hình dựa trên khái niệm siêu địa chỉ, hoạt động như sau: một phần của siêu địa chỉ là khóa chi tiêu bị lừa của người gửi và phần còn lại là khóa được 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 khóa là như nhau).
Tổng quan về 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ó khóa công khai chi tiêu và khóa công khai mã hóa, đồng thời "thông tin thanh toán" của người dùng sẽ cần bao gồm cả hai khóa. ** Ngoài việc trả tiền, còn có những lý do chính đáng khác để mở rộng 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 khóa tài khoản, 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 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 quá trình chuyển đổi và khôi phục khóa này
Trong một thế giới mà mỗi người dùng có nhiều địa chỉ, cách mặc định để triển khai các thay đổi chính và khôi phục mạng xã hội là để người dùng chạy quy trình khôi phục trên từng địa chỉ riêng lẻ. Điều này có thể được thực hiện chỉ bằng một cú nhấp chuột: ví có thể cung cấp chức năng phần mềm để thực hiện quá 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ỉ:
1. Chi phí xăng là phi thực tế: Điều này là hiển nhiên.
2. Địa chỉ giả: địa chỉ chưa phát hành hợp đồng thông minh (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ỉ ảo: 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à toàn bộ vô số địa chỉ ảo phát sinh từ sơ đồ địa chỉ ẩn.
3. Quyền riêng tư: Nếu người dùng cố ý sử dụng 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 liên kết công khai tất cả các địa chỉ đó bằng cách khôi phục chúng cùng một lúc hoặc gần như cùng một lúc!
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 khá tinh tế hoạt động khá tốt: Kiến trúc này 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 một L2 cụ thể). Sau đó, người dùng có địa chỉ trên các L2 khác nhau và logic xác minh cho từng địa chỉ là một con trỏ tới hợp đồng kho khóa. Chi tiêu tiền từ các địa chỉ này sẽ yêu cầu cung cấp bằng chứng về khóa công khai chi tiêu hiện tại (hoặc thực tế hơn là rất gần đây) cho số tiền đó.
Bằng chứng này có thể đạt được bằng nhiều cách:
Nếu chúng tôi muốn tránh cần bằng chứng cho mọi giao dịch, chúng tôi có thể triển khai một sơ đồ nhẹ hơn chỉ yêu cầu khôi phục trên các bằng chứng L2. Chi tiêu từ một tài khoản sẽ phụ thuộc vào khóa chi tiêu với khóa công khai tương ứng được lưu trữ bên 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 vào kho khóa. Ngay cả khi các khóa cũ của bạn không an toàn, tiền trong địa chỉ ảo vẫn an toàn: "kích hoạt" địa chỉ ảo để biến địa chỉ đó thành hợp đồng có thể sử dụng sẽ yêu cầu bằng chứng L2 chéo để sao chép khóa công khai chi tiêu hiện tại. Có một chủ đề 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ỏ và thực hiện tất cả các bằng chứng bên trong ZK-SNARK:
Những kịch bản này có thể trở nên phức tạp. Ưu điểm là có nhiều khả năng phối hợp giữa chúng. Ví dụ: khái niệm về "hợp đồng lưu trữ khóa" cũng có thể là một giải pháp cho "địa chỉ" được đề cập trong phần trước: nếu chúng tôi muốn người dùng có một địa chỉ liên tục không thay đổi mỗi khi người dùng cập nhật khóa, chúng tôi có thể đặt ẩn địa chỉ meta, khóa mã hóa và các 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.
Rất nhiều cơ sở hạ tầng thứ cấp cần được cập nhật
Sử dụng ENS rất tốn kém. Mặc dù không còn đắt như trước vào tháng 6 năm 2023, nhưng phí giao dịch đăng ký tên miền vẫn tương đối cao, tương đương với phí của một tên miền ENS. Ví dụ: chi phí khoảng 27 đô la để đăng ký với zuzalu.eth, 11 đô la trong số đó là phí giao dịch. Nhưng nếu thị trường tăng trở lại, phí sẽ tăng cao. Ngay cả khi giá ETH không tăng, nếu phí gas trở lại mức 200 gwei, thì phí giao dịch đăng ký tên miền sẽ lên tới 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í (phí tên miền ENS không phải là vấn đề vì các nền tảng này có thể cung cấp cho người dùng tên miền phụ), thì chúng tôi cần sử dụng ENS trên Lớp 2.
May mắn thay, nhóm ENS đã tăng cường và ENS đang được triển khai trên Lớp 2! ERC-3668 (còn được gọi là "tiêu chuẩn CCIP") và ENSIP-10 cung cấp cách tự động xác minh tên miền phụ ENS trên bất kỳ Lớp 2 nào. Tiêu chuẩn CCIP yêu cầu thiết lập hợp đồng thông minh mô tả phương pháp xác minh bằng chứng dữ liệu trên Lớp 2 và một tên miền (ví dụ: ecc.eth cho Optinames) có thể được đặt dưới sự kiểm soát của hợp đồng đó. Sau khi hợp đồng CCIP kiểm soát ecc.eth trên L1, việc truy cập vào một tên miền phụ.ecc.eth nhất định sẽ tự động tìm và xác minh bằng chứng lưu trữ trạng thái Lớp 2 của tên miền phụ cụ thể đó (ví dụ: nhánh Merkle).
**Nỗ lực CCIP của ENS là một câu chuyện thành công và nên được coi là một dấu hiệu cho thấy những 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 ở cấp độ ứng dụng cần được thực hiện. Dưới đây là một số ví dụ:
Ví sẽ cần bảo vệ tài sản và dữ liệu
Hiện tại, nhiệm vụ của ví là bảo vệ tài sản. Mọi thứ được lưu trữ trên chuỗi, tất cả những gì ví cần bảo vệ là các khóa riêng hiện đang bảo vệ các tài sản này. Nếu bạn thay đổi khóa, bạn có thể đăng công khai khóa riêng trước đó trên Internet một cách an toàn vào ngày hôm sau. Tuy nhiên, trong một thế giới không có kiến thức, điều này không còn đúng nữa: ví không chỉ bảo vệ thông tin đăng nhập 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 tại Zuzalu với Zupass, một hệ thống nhận dạng dựa trên ZK-SNARK. Người dùng có một khóa riêng được sử dụng để xác thực vào 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ộ tôi là cư dân nào". Hệ thống Zupass cũng bắt đầu xây dựng các ứng dụng khác trên đó, quan trọng nhất là tem (phiên bản POAP của Zupass).
*Một trong nhiều tem Zupass của tôi xác nhận rằng tôi là thành viên của Team Cat. *
Tính năng chính của tem liên quan đến POAP là chúng ở chế độ riêng tư: bạn lưu dữ liệu cục bộ và chỉ chứng minh tem cho ZK của họ (hoặc thực hiện một số tính toán trên tem) nếu bạn muốn cung cấp thông tin đó cho ai đó. Nhưng điều này cũng đi kèm với một rủi ro bổ sung: nếu bạn làm mất thông tin đó, bạn sẽ mất tem của mình.
Tất nhiên, vấn đề lưu giữ dữ liệu có thể giảm xuống thành vấn đề giữ một khóa mã hóa duy nhất: bên thứ ba (thậm chí trên chuỗi) có thể 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 thay đổi khóa mã hóa, do đó không cần tương tác với hệ thống giữ khóa mã hóa. Nhưng ngay cả khi đó, nếu bạn mất khóa mã hóa, bạn sẽ mất tất cả dữ liệu của mình. Và đổi lại, nếu ai đó thấy khóa mã hóa của bạn, họ sẽ 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ữ chìa 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 lúc là rất thấp. Chúng ta có thể tiến thêm một bước bằng cách sử dụng tính năng chia sẻ khóa để phân chia bộ lưu trữ khóa cho nhiều người bảo vệ.
Phục hồi xã hội thông qua MPC 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ỉ người bảo vệ hiện tại mà cả những người bảo vệ trước đó 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. Mặc dù vi phạm quyền riêng tư thường ít rủi ro hơn so với việc mất hoàn toàn tài sản, nhưng đối với các trường hợp sử dụng có nhu cầu quyền riêng tư cao, bạ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 nhu cầu quyền riêng tư đó.
Để tránh làm người dùng sa lầy trong một hệ thống phức tạp gồm nhiều đường khôi phục, các ví hỗ trợ khôi phục xã hội có thể cần quản lý cả hai khía cạnh 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 chủ đề chung trong số những thay đổi này là khái niệm "địa chỉ" như một đại diện cho danh tính trên chuỗi khối sẽ cần phải thay đổi về cơ bản. ** "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 nữa; express. **
Một trong những cách này là sử dụng ENS làm danh tính của bạn: bản ghi ENS của bạn có thể chứa tất cả thông tin về cách thanh toán và tương tác với bạn, nếu bạn gửi cho ai đó bob.eth (hoặc bob.ecc.eth, v.v.), họ có thể hỏi và tìm hiểu về mọi thứ tương tác với bạn, kể cả theo những cách phức tạp hơn trên các miền và với bảo vệ quyền riêng tư.
Tuy nhiên, 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 trước đó trong kiến trúc của bài viết này. Hợp đồng kho khóa có thể chứa nhiều thông tin khác nhau về bạn và các tương tác với bạn (và với CCIP, một số thông tin này có thể nằm ngoài chuỗi), người dùng sẽ sử dụng hợp đồng kho khóa của họ làm định danh chính. Tuy nhiên, tài sản mà họ thực sự nhận được sẽ được cất giữ ở nhiều nơi khác nhau. Hợp đồng kho khóa không phân biệt tên và thân thiện với tên ảo: bạn có thể tạo một địa chỉ chỉ có thể được khởi tạo bằng hợp đồng kho khóa với các tham số ban đầu cố định nhất định.
Một loại giải pháp khác liên quan đến việc từ bỏ hoàn toàn khái niệm địa chỉ hướng tới người dùng, tương tự như giao thức thanh toán của Bitcoin. 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 một liên kết yêu cầu (dưới dạng URL hoặc mã QR rõ ràng), mà người nhận có thể sử dụng để gửi bất kỳ yêu cầu nào họ muốn chấp nhận sự chi trả.
Cho dù đó là người gửi hay người nhận hành động đầu tiên, việc dựa nhiều hơn vào ví để tạo thông tin thanh toán cập nhật trong thời gian thực sẽ giúp giảm ma sát. Tuy nhiên, các định danh liên tục rất thuận tiện (đặc biệt là với ENS), trong khi trên thực tế, việc dựa vào giao tiếp trực tiếp giữa người gửi và người nhận là một vấn đề rất phức tạp, do đó có thể thấy sự kết hợp của các kỹ thuật khác nhau.
Trong tất cả các thiết kế này, điều quan trọng là phải duy trì tính phi tập trung và dễ hiểu đối với người dùng. Chúng tôi cần đảm bảo rằng người dùng có thể dễ dàng truy cập chế độ xem cập nhật về tài sản hiện tại và thông điệp được nhắm mục tiêu đến họ. Những quan điểm này nên dựa vào các công cụ mở hơn là các giải pháp độc quyền. Sẽ mất nhiều công sức để giữ cho cơ sở hạ tầng thanh toán phức tạp hơn trở thành một "tháp trừu tượng" mờ đục, khó hiểu và khó thích nghi với môi trường mới. Bất chấp những thách thức, đạt được khả năng mở rộng của Ethereum, bảo mật ví và quyền riêng tư cho người dùng thông thường là điều tối quan trọng. Đó không chỉ là tính khả thi về mặt kỹ thuật, mà còn là khả năng tiếp cận thực tế đối với người dùng bình thường. Chúng ta cần phải đáp ứng thách thức này.