Khi Ethereum chuyển đổi từ một công nghệ thử nghiệm non trẻ thành một công nghệ trưởng thành có thể thực sự mang lại trải nghiệm cởi mở, toàn cầu và không cần cấp phép cho người dùng thông thường, thì ngăn xếp cần trải qua ba chuyển đổi công nghệ lớn, gần như đồng thời:
Thay đổi tỷ lệ L2 - mọi người chuyển sang tổng số
Thay đổ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ư 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, danh tính, danh tiếng) đều bảo vệ quyền riêng tư
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)
Đây là tam giác chuyển đổi hệ sinh thái. Bạn chỉ được chọn 3 trong 3.
Nếu không có lần đầu tiên, Ethereum sẽ thất bại vì mỗi giao dịch sẽ có giá 3,75 đô la (82,48 đô la nếu chúng tôi có một đợt tăng giá khác) và mọi sản phẩm thị trường đại chúng cuối cùng sẽ quên đi chuỗi và sử dụng giải pháp tập trung cho mọi thứ.
Nếu không có thứ hai, Ethereum sẽ thất bại vì người dùng sẽ miễn cưỡng lưu trữ tiền của họ (và tài sản phi tài chính) và tất cả sẽ chuyển sang các sàn giao dịch 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.) sẽ được công khai cho mọi người xem, đây sẽ là sự hy sinh quá mức về quyền riêng tư đối với nhiều người dùng và mọi người sẽ chuyển sang tập trung ít nhất một số dữ liệu ẩn. giải pháp.
Vì những lý do đã đề cập ở 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 vì cần có sự phối hợp chặt chẽ để giải quyết chúng. Không chỉ cần cải thiện chức năng của giao thức, có những trường hợp cần thực hiện những thay đổi khá cơ bản đối với cách chúng ta tương tác với Ethereum, đòi hỏi những thay đổi sâu sắc đối với ứng dụng và ví.
Ba thay đổi này sẽ cách mạng hóa mối quan hệ giữa người dùng và địa chỉ
Trong một thế giới mở rộng L2, người dùng sẽ tồn tại trong nhiều L2. Bạn có phải là thành viên của ExampleDAO, thuộc về Chủ nghĩa lạc quan không? Sau đó, bạn có một tài khoản trên Optimism! Bạn có giữ CDP trong hệ thống stablecoin của 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 tình cờ có 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ỉ.
Tôi có ETH ở bốn nơi, theo chế độ xem Brave Wallet của tôi. Có, Arbitrum và Arbitrum Nova khác nhau. Đừng lo lắng, điều này sẽ trở nên phức tạp hơn theo thời gian!
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)
Ví hợp đồng thông minh phức tạp hơn, khiến việc có cùng địa chỉ trên 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à hàm băm của khóa chung đượ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 duy trì đị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 để cố gắng biến các địa chỉ thành mã băm tương đương trên mạng, đặc biệt là các nhà máy đơn lẻ CREATE2 và ERC-2470, nhưng rất khó để thực hiện điều này một cách 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 sử dụng Solidity hoặc một tổ hợp trung gian để thay thế, ngăn chặn sự tương đương của 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 chính 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 xử lý. Nếu đề xuất địa chỉ riêng đượ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, thì 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 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 đó trong cùng một địa chỉ). Để gửi tiền cho một người dùng cụ thể, người dùng cần dựa vào hệ thống địa chỉ nội bộ của chương trình quyền riêng tư.
Như chúng ta đã thấy, ba ca làm việc đã 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à một số tác động này dẫn đến sự phức tạp của việc triển khai các ca làm việc. Hai biến chứng cụ thể là:
Nếu bạn muốn thanh toán cho ai đó thì làm cách nào để lấy thông tin để thanh toán cho họ?
Nếu người dùng lưu trữ nhiều tài sản ở những nơi khác nhau trên các chuỗi khác nhau, làm thế nào để họ thực hiện thay thế khóa và phục hồi xã hội?
Ba lần chuyển đổi có liên quan đến 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 sẽ chỉ nhận được tiền trên Taiko. tô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 chỉ là một cá nhân thông thường) cố gắng hỗ trợ từng L2, với một số chức năng tự động để tích hợp tiền một cách không đồng bộ.
Người nhậ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 mục tiêu thông qua một số loại 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 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 (nếu họ may mắn) hoặc thông qua đường dẫn bắc cầu qua L2.
Nhưng đó chỉ là một ví dụ về thách thức chính do ba ca làm việc đưa ra: một việc đơn giản như trả tiề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 sang ví hợp đồng thông minh không gây gánh nặng cho 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 chúng không chỉ gửi 21000 gas trong các giao dịch, mà quan trọng hơn là để đảm bảo rằng bên nhận thanh toán của ví không chỉ theo dõi chuyển ETH từ EOA mà còn cả ETH được gửi bằng 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 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 trả tiền ERC-4337 để thanh toán xăng bằng mã thông báo đó.
Mặt khác, quyền riêng tư một lần nữa đặt ra những 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 gây 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 tiền vào hệ thống và rút tiền. Khi bạn có thể thực hiện chuyển khoản nội bộ, người dùng 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 công khai chi tiêu", một lời hứa về một bí mật mà người nhận có thể sử dụng để chi tiêu và (ii) người gửi gửi một tin nhắn được mã hóa mà chỉ người nhận mới có thể sử dụng. người nhận có thể giải mã cách để giúp người nhận khám phá các khoản thanh toán.
Giao thức địa chỉ riêng tư dựa trên khái niệm siêu địa chỉ, hoạt động theo cách sau: một phần của siêu địa chỉ 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ù triển khai tối thiểu có thể đặt cả hai phím này đều giống nhau).
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)
Bài học quan trọng ở đây là trong một hệ sinh thái tập trung vào 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 và "thông tin thanh toán" của người dùng sẽ phải chứa cả hai khóa. Bên cạnh việc trả tiền, còn có những lý do chính đáng khác để mở rộng theo hướng này. Ví dụ: nếu chúng tôi muốn email được mã hóa trên Ethereum, người dùng sẽ cần cung cấp công khai một số dạng khóa mã hóa. Trong "thế giới EOA", chúng ta có thể sử dụng lại các khóa tài khoản để đạt được điều này, nhưng trong thế giới ví hợp đồng thông minh an toàn, có lẽ chúng ta nên có chức năng rõ ràng hơn để đạt được điều này. Điều này cũng sẽ 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, ví dụ nổi bật nhất là các khóa PGP.
Ba lần chuyển đổi và khôi phục khóa
Trong thế giới mà người dùng có thể 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à yêu cầu người dùng thực hiện các 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 bằng một cú nhấp chuột: ví có thể chứa phần mềm để thực hiện quy trình khôi phục đồng thời trên tất cả địa chỉ của người dùng. Tuy nhiên, ngay cả với việc đơn giản hóa UX như vậy, vẫn có ba vấn đề với khả năng khôi phục đa địa chỉ ngây thơ:
Hóa đơn xăng không thực tế: Cái này tự nó nói lên.
Địa chỉ phản thực: một địa chỉ có hợp đồng thông minh chưa được công bố (thực ra, đây có nghĩa là một tài khoản mà bạn chưa gửi tiền từ đó). Với tư cách là người dùng, bạn có khả năng 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 hoàn toàn khác các địa chỉ phản thực vô hạn, bắt nguồn từ sơ đồ địa chỉ ẩn bả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, 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 khá tinh tế 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.
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)
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 minh 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 sẽ yêu cầu bằng chứng trong 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 để cung cấp cho họ cách đọc trạng thái của L1 một cách trực tiếp. 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 minh 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 minh các phần của trạng thái 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, mặc dù điều này sẽ giảm xuống dưới 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ác kỹ thuật tổng hợp ngoài chuỗi (ví dụ: dựa trên EIP-4337) có thể được xây dựng để 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.
Cam kết KZG. L2, hoặc các sơ đồ được xây dựng trên nó, 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 bên trong hệ thống này chỉ dài 48 byte. Giống như ZK-SNARK, 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.
![Vitalik: Để triển khai quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)
Nếu chúng tôi muốn tránh thực hiện bằng chứng cho mỗi giao dịch, chúng tôi có thể triển khai giải pháp nhẹ hơn, chỉ cần thực hiện bằng chứng chéo L2 khi 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 địa chỉ phản thực vẫn an toàn ngay cả khi khóa cũ của bạn không an toàn: "kích hoạt" địa chỉ phản thực, biến nó thành hợp đồng làm việc sẽ yêu cầu thực hiện bằng chứng chéo L2 để sao chép khóa công khai chi tiêu hiện tại. Chủ đề này trên các diễn đàn An toàn mô tả cách một kiến trúc tương tự có thể hoạt động.
Để thêm quyền riêng tư cho sơ đồ như vậy, chúng tôi chỉ cần mã hóa con trỏ, sau đó thực hiện tất cả các bằng chứng trong ZK-SNARK:
![Vitalik: Để triển khai quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)
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. Tuy nhiên, có nhiều hiệp lực tiềm năng giữa các chương trình này. Ví dụ: khái niệm về "hợp đồng kho khóa" cũng có thể là một giải pháp cho 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ỉ liên tục không thay đổi khi người dùng cập nhật khóa của họ, chúng tôi sẽ có thể đặt địa chỉ meta bí mật, khóa mã hóa và thông tin khác vào hợp đồng kho khóa và sử dụng địa chỉ của hợp đồng kho khóa làm "địa chỉ" của người dùng.
Rất nhiều cơ sở hạ tầng phụ cần được cập nhật
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, mặc dù cao, 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 trả lại phí gas thành 200 gwei sẽ làm tăng phí giao dịch đăng ký 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í (phí tên miền ENS không phải là vấn đề vì các nền tảng này cung cấp tên miền phụ cho người dùng của họ), chúng tôi cần Chạy ENS trên L2 .
May mắn thay, nhóm ENS đã bắt đầu hoạt động và ENS trên L2 đang thực sự diễn ra! ERC-3668 (còn được gọi là "tiêu chuẩn CCIP"), cùng với ENSIP-10, cung cấp phương pháp tự động xác thực tên miền phụ ENS trên bất kỳ L2 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 về dữ liệu L2 và 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 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 trạng thái L2 của bằng chứng (ví dụ: nhánh Merkle) thực sự lưu trữ tên miền phụ cụ thể đó.
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)
Trên thực tế, việc thu thập bằng chứng liên quan đến việc truy cập vào một loạt URL được lưu trữ trong hợp đồng, điều này phải thừa nhận là giống như sự tập trung hóa, mặc dù tôi cho rằng 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ệ sẽ bị CCIP chặn Việc xác minh logic trong chức năng gọi lại của hợp đồng nắm bắt được điều đó, miễn là có một URL trả về bằng chứng hợp lệ thì không có vấn đề gì). Danh sách URL này có thể chứa hàng chục URL.
Công việc của ENS CCIP 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 loại cải cách triệt để mà chúng ta cần là có thể thực hiện được. Nhưng cần có nhiều cải cách ở cấp độ ứng dụng hơn. Một số ví dụ bao gồm:
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 thuộc 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ọ cần hỗ trợ nó.
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ẽ bị phá vỡ. 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; câu hỏi tìm hiểu xem liệu một hoạt động chuyển quyền kiểm soát mật mã cụ thể có phải là một hoạt động chuyển quyền lợi có lợi hay không là một câu hỏi khó có thể không được giải quyết nếu không nhờ đến một số cộng đồng ngoài chuỗi- cơ chế điều khiển.Tiếp theo giải quyết. Nhiều khả năng, các ứng dụng sẽ ít phải phụ thuộc vào việc chặn chuyển giao và phụ thuộc nhiều hơn vào các kỹ thuật như thuế Harberger.
Cách ví tương tác với chi tiêu 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: một nonce tiêu chuẩn (ví dụ: hàm băm của tên ứng dụng) được ký bằng khóa riêng của EOA, tạo ra một nonce không thể tạo nếu không có khóa riêng. of , vì vậy 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 cần được ví xử lý rõ ràng hơn.
Các máy khách nhẹ (ví dụ: Helios) sẽ phải xác minh L2, 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 tiêu đề L1 (sử dụng giao thức đồng bộ hóa ứng dụng khách nhẹ) và xác thực trạng thái L1 và các nhánh Merkle của các giao dịch bắt nguồn từ tiêu đề L1. Ngày mai, họ cũng 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 (phiên bản nâng cao hơn này thực sự xem xét xác nhận trước của L2).
Ví cần bảo vệ tài sản và dữ liệu
Giờ đây, công việc kinh doanh của chiếc ví là 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 hiện đang bảo vệ những tài sản đó. Nếu bạn thay đổi khóa, bạn có thể xuất bản khóa riêng trước đó của mình một cách an toàn trên Internet vào ngày hôm sau. Tuy nhiên, trong một thế giới không có bằng chứng về 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 bảo vệ 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 tại Zuzalu. Người dùng có một khóa riêng mà họ sử dụng để xác thực hệ thống, có thể được sử dụng để thực hiện các bằng chứng cơ bản như "chứng minh rằng tôi là cư dân của Zuzalu, nhưng không tiết lộ khóa nào". Tuy nhiên, hệ thống Zupass cũng bắt đầu có các ứng dụng khác được xây dựng trên nó, đáng chú ý nhất là Tem (phiên bản POAP của Zupass).
Một trong nhiều con tem Zupass của tôi chứng tỏ 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 trên POAP là tem là riêng tư: bạn giữ dữ liệu cục bộ và bạn chỉ chứng minh tem (hoặc một số tính toán trên đó) cho họ nếu bạn muốn họ có thông tin này về bạn. Nhưng điều này làm tăng rủi ro: nếu bạn làm mất thông tin này, bạn sẽ mất tem của mình.
Tất nhiên, vấn đề giữ dữ liệu bắt nguồn từ vấn đề giữ khóa mật mã: bên thứ ba (hoặc thậm chí chuỗi) có thể giữ 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ả. Ngược lại, 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 thực tế 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ị (ví dụ: máy tính xách tay và điện thoại), vì khả năng họ bị mất tất cả chúng cùng một lúc là rất nhỏ. 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, chia khóa cho nhiều người giám hộ.
Việc 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 đó 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, vi phạm quyền riêng tư thường ít rủi ro hơn so với mất hoàn toàn tài sản và nếu ai đó yêu cầu trường hợp sử dụng bảo vệ quyền riêng tư cao, anh ta có thể chấp nhận rủi ro mất mát cao hơn bằng cách không sao lưu các khóa liên quan yêu cầu quyền riêng tư- các hành động bảo tồn.
Để tránh làm người dùng choáng ngợp với một hệ thống phức tạp gồm 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 câu hỏi nhận dạng
Chủ đề chung của những thay đổi này là khái niệm về "địa chỉ" mà bạn sử dụng trên chuỗi làm mã định danh mã hóa đại diện cho "bạn" phải thay đổi hoàn toàn. "Hướng dẫn về cách tương tác với tôi" không còn chỉ là một địa chỉ ETH; chúng phải chứa một số tổ hợp nhiều địa chỉ trên nhiều L2, địa chỉ meta bí mật, khóa mã hóa và dữ liệu khác ở một số dạng.
Một cách để làm điều này là tạo cho ENS 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 này và nếu bạn gửi cho ai đó bob.eth (hoặc bob.ecc.eth, hoặc...), họ có thể tìm hiểu và tìm hiểu về tất cả những thứ trả tiền và tương tác với bạn, kể cả theo những cách phức tạp hơn và 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 thứ với tên của bạn. Tên của bạn không phải là bạn, tên của bạn chỉ là một trong nhiều thuộc tính của bạn. Bạn sẽ có thể thay đổi tên của mình mà không cần di chuyển toàn bộ hồ sơ nhận dạng và cập nhật một loạt hồ sơ trong nhiều ứng dụng.
Bạn không thể có tên phản thực 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. Nếu không có chức năng như vậy, có một vấn đề về con gà và quả trứng: tương tác với chuỗi yêu cầu trả phí giao dịch và trả phí yêu cầu ... đã sở hữu tiền. Địa chỉ ETH, bao gồm địa chỉ hợp đồng thông minh với CREATE2, có tính năng này. Tên ENS thì 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 cái nào có tên đó.
Một giải pháp khả thi là đưa nhiều nội dung hơn vào hợp đồng kho khóa được đề cập trong kiến trúc trước đó trong bài đăng 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ách bạn tương tác với nó (thông qua CCIP, một số trong số đó có thể nằm ngoài chuỗi) và người dùng có thể sử dụng hợp đồng kho khóa của họ làm số nhận dạng 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 bị ràng buộc về tên, chúng thân thiện với thực tế: bạn có thể tạo một địa chỉ chỉ có thể đượ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 liên quan đến việc từ bỏ khái niệm địa chỉ hướng đến người dùng, tương tự như tinh thần của giao thức thanh toán 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 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 Chấp nhận thanh toán theo cách họ muốn.
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)
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í để trực tiếp tạo thông tin thanh toán cập nhật trong thời gian thực giúp giảm ma sát. Phải 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) và trên thực tế, giả định 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 khó, vì vậy chúng tôi có thể xem xét 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, điều quan trọng là giữ cho mọi thứ vừa phi tập trung vừa 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 nhất về tài sản hiện tại của họ, cũng như thông tin được xuất bản dành cho 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 không trở thành một "tháp trừu tượng" không rõ ràng để các nhà phát triển hiểu điều gì đang diễn ra và 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 truy cập thực tế cho người dùng bình thường. Chúng ta cần phải đáp ứng thách thức này.
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ọ.
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: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư
Bản gốc: "Ba lần chuyển tiếp"
Được viết bởi: Vitalik Buterin
Biên dịch: MarsBit, MK
Khi Ethereum chuyển đổi từ một công nghệ thử nghiệm non trẻ thành một công nghệ trưởng thành có thể thực sự mang lại trải nghiệm cởi mở, toàn cầu và không cần cấp phép cho người dùng thông thường, thì ngăn xếp cần trải qua ba chuyển đổi công nghệ lớn, gần như đồng thời:
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-898e667808-dd1a6f-62a40f)
Đây là tam giác chuyển đổi hệ sinh thái. Bạn chỉ được chọn 3 trong 3.
Nếu không có lần đầu tiên, Ethereum sẽ thất bại vì mỗi giao dịch sẽ có giá 3,75 đô la (82,48 đô la nếu chúng tôi có một đợt tăng giá khác) và mọi sản phẩm thị trường đại chúng cuối cùng sẽ quên đi chuỗi và sử dụng giải pháp tập trung cho mọi thứ.
Nếu không có thứ hai, Ethereum sẽ thất bại vì người dùng sẽ miễn cưỡng lưu trữ tiền của họ (và tài sản phi tài chính) và tất cả sẽ chuyển sang các sàn giao dịch 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.) sẽ được công khai cho mọi người xem, đây sẽ là sự hy sinh quá mức về quyền riêng tư đối với nhiều người dùng và mọi người sẽ chuyển sang tập trung ít nhất một số dữ liệu ẩn. giải pháp.
Vì những lý do đã đề cập ở 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 vì cần có sự phối hợp chặt chẽ để giải quyết chúng. Không chỉ cần cải thiện chức năng của giao thức, có những trường hợp cần thực hiện những thay đổi khá cơ bản đối với cách chúng ta tương tác với Ethereum, đòi hỏi những thay đổi sâu sắc đối với ứng dụng và ví.
Ba thay đổi này sẽ cách mạng hóa mối quan hệ giữa người dùng và địa chỉ
Trong một thế giới mở rộng L2, người dùng sẽ tồn tại trong nhiều L2. Bạn có phải là thành viên của ExampleDAO, thuộc về Chủ nghĩa lạc quan không? Sau đó, bạn có một tài khoản trên Optimism! Bạn có giữ CDP trong hệ thống stablecoin của 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 tình cờ có 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ỉ.
Tôi có ETH ở bốn nơi, theo chế độ xem Brave Wallet của tôi. Có, Arbitrum và Arbitrum Nova khác nhau. Đừng lo lắng, điều này sẽ trở nên phức tạp hơn theo thời gian!
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-a9bb8e17d9-dd1a6f-62a40f)
Ví hợp đồng thông minh phức tạp hơn, khiến việc có cùng địa chỉ trên 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à hàm băm của khóa chung đượ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 duy trì đị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 để cố gắng biến các địa chỉ thành mã băm tương đương trên mạng, đặc biệt là các nhà máy đơn lẻ CREATE2 và ERC-2470, nhưng rất khó để thực hiện điều này một cách 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 sử dụng Solidity hoặc một tổ hợp trung gian để thay thế, ngăn chặn sự tương đương của 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 chính 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 xử lý. Nếu đề xuất địa chỉ riêng đượ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, thì 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 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 đó trong cùng một địa chỉ). Để gửi tiền cho một người dùng cụ thể, người dùng cần dựa vào hệ thống địa chỉ nội bộ của chương trình quyền riêng tư.
Như chúng ta đã thấy, ba ca làm việc đã 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à một số tác động này dẫn đến sự phức tạp của việc triển khai các ca làm việc. Hai biến chứng cụ thể là:
Nếu bạn muốn thanh toán cho ai đó thì làm cách nào để lấy thông tin để thanh toán cho họ?
Nếu người dùng lưu trữ nhiều tài sản ở những nơi khác nhau trên các chuỗi khác nhau, làm thế nào để họ thực hiện thay thế khóa và phục hồi xã hội?
Ba lần chuyển đổi có liên quan đến 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 sẽ chỉ nhận được tiền trên Taiko. tô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 chỉ là một cá nhân thông thường) cố gắng hỗ trợ từng L2, với một số chức năng tự động để tích hợp tiền một cách không đồng bộ.
Người nhậ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 mục tiêu thông qua một số loại 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 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 (nếu họ may mắn) hoặc thông qua đường dẫn bắc cầu qua L2.
Nhưng đó chỉ là một ví dụ về thách thức chính do ba ca làm việc đưa ra: một việc đơn giản như trả tiề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 sang ví hợp đồng thông minh không gây gánh nặng cho 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 chúng không chỉ gửi 21000 gas trong các giao dịch, mà quan trọng hơn là để đảm bảo rằng bên nhận thanh toán của ví không chỉ theo dõi chuyển ETH từ EOA mà còn cả ETH được gửi bằng 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 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 trả tiền ERC-4337 để thanh toán xăng bằng mã thông báo đó.
Mặt khác, quyền riêng tư một lần nữa đặt ra những 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 gây 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 tiền vào hệ thống và rút tiền. Khi bạn có thể thực hiện chuyển khoản nội bộ, người dùng 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 công khai chi tiêu", một lời hứa về một bí mật mà người nhận có thể sử dụng để chi tiêu và (ii) người gửi gửi một tin nhắn được mã hóa mà chỉ người nhận mới có thể sử dụng. người nhận có thể giải mã cách để giúp người nhận khám phá các khoản thanh toán.
Giao thức địa chỉ riêng tư dựa trên khái niệm siêu địa chỉ, hoạt động theo cách sau: một phần của siêu địa chỉ 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ù triển khai tối thiểu có thể đặt cả hai phím này đều giống nhau).
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-39bca9184c-dd1a6f-62a40f)
Bài học quan trọng ở đây là trong một hệ sinh thái tập trung vào 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 và "thông tin thanh toán" của người dùng sẽ phải chứa cả hai khóa. Bên cạnh việc trả tiền, còn có những lý do chính đáng khác để mở rộng theo hướng này. Ví dụ: nếu chúng tôi muốn email được mã hóa trên Ethereum, người dùng sẽ cần cung cấp công khai một số dạng khóa mã hóa. Trong "thế giới EOA", chúng ta có thể sử dụng lại các khóa tài khoản để đạt được điều này, nhưng trong thế giới ví hợp đồng thông minh an toàn, có lẽ chúng ta nên có chức năng rõ ràng hơn để đạt được điều này. Điều này cũng sẽ 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, ví dụ nổi bật nhất là các khóa PGP.
Ba lần chuyển đổi và khôi phục khóa
Trong thế giới mà người dùng có thể 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à yêu cầu người dùng thực hiện các 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 bằng một cú nhấp chuột: ví có thể chứa phần mềm để thực hiện quy trình khôi phục đồng thời trên tất cả địa chỉ của người dùng. Tuy nhiên, ngay cả với việc đơn giản hóa UX như vậy, vẫn có ba vấn đề với khả năng khôi phục đa địa chỉ ngây thơ:
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: một kiến trúc tách logic xác thực khỏi việc nắm giữ tài sản.
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-25b93e2117-dd1a6f-62a40f)
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 minh 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 sẽ yêu cầu bằng chứng trong 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 để cung cấp cho họ cách đọc trạng thái của L1 một cách trực tiếp. 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 minh 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 minh các phần của trạng thái 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, mặc dù điều này sẽ giảm xuống dưới 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ác kỹ thuật tổng hợp ngoài chuỗi (ví dụ: dựa trên EIP-4337) có thể được xây dựng để 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.
Cam kết KZG. L2, hoặc các sơ đồ được xây dựng trên nó, 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 bên trong hệ thống này chỉ dài 48 byte. Giống như ZK-SNARK, 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.
![Vitalik: Để triển khai quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-a50b6aa1e3-dd1a6f-62a40f)
Nếu chúng tôi muốn tránh thực hiện bằng chứng cho mỗi giao dịch, chúng tôi có thể triển khai giải pháp nhẹ hơn, chỉ cần thực hiện bằng chứng chéo L2 khi 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 địa chỉ phản thực vẫn an toàn ngay cả khi khóa cũ của bạn không an toàn: "kích hoạt" địa chỉ phản thực, biến nó thành hợp đồng làm việc sẽ yêu cầu thực hiện bằng chứng chéo L2 để sao chép khóa công khai chi tiêu hiện tại. Chủ đề này trên các diễn đàn An toàn mô tả cách một kiến trúc tương tự có thể hoạt động.
Để thêm quyền riêng tư cho sơ đồ như vậy, chúng tôi chỉ cần mã hóa con trỏ, sau đó thực hiện tất cả các bằng chứng trong ZK-SNARK:
![Vitalik: Để triển khai quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-137a30a3c1-dd1a6f-62a40f)
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. Tuy nhiên, có nhiều hiệp lực tiềm năng giữa các chương trình này. Ví dụ: khái niệm về "hợp đồng kho khóa" cũng có thể là một giải pháp cho 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ỉ liên tục không thay đổi khi người dùng cập nhật khóa của họ, chúng tôi sẽ có thể đặt địa chỉ meta bí mật, khóa mã hóa và thông tin khác vào hợp đồng kho khóa và sử dụng địa chỉ của hợp đồng kho khóa làm "địa chỉ" của người dùng.
Rất nhiều cơ sở hạ tầng phụ cần được cập nhật
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, mặc dù cao, 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 trả lại phí gas thành 200 gwei sẽ làm tăng phí giao dịch đăng ký 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í (phí tên miền ENS không phải là vấn đề vì các nền tảng này cung cấp tên miền phụ cho người dùng của họ), chúng tôi cần Chạy ENS trên L2 .
May mắn thay, nhóm ENS đã bắt đầu hoạt động và ENS trên L2 đang thực sự diễn ra! ERC-3668 (còn được gọi là "tiêu chuẩn CCIP"), cùng với ENSIP-10, cung cấp phương pháp tự động xác thực tên miền phụ ENS trên bất kỳ L2 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 về dữ liệu L2 và 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 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 trạng thái L2 của bằng chứng (ví dụ: nhánh Merkle) thực sự lưu trữ tên miền phụ cụ thể đó.
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-b1a43ef2c1-dd1a6f-62a40f)
Trên thực tế, việc thu thập bằng chứng liên quan đến việc truy cập vào một loạt URL được lưu trữ trong hợp đồng, điều này phải thừa nhận là giống như sự tập trung hóa, mặc dù tôi cho rằng 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ệ sẽ bị CCIP chặn Việc xác minh logic trong chức năng gọi lại của hợp đồng nắm bắt được điều đó, miễn là có một URL trả về bằng chứng hợp lệ thì không có vấn đề gì). Danh sách URL này có thể chứa hàng chục URL.
Công việc của ENS CCIP 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 loại cải cách triệt để mà chúng ta cần là có thể thực hiện được. Nhưng cần có nhiều cải cách ở cấp độ ứng dụng hơn. Một số ví dụ bao gồm:
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 thuộc 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ọ cần hỗ trợ nó.
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ẽ bị phá vỡ. 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; câu hỏi tìm hiểu xem liệu một hoạt động chuyển quyền kiểm soát mật mã cụ thể có phải là một hoạt động chuyển quyền lợi có lợi hay không là một câu hỏi khó có thể không được giải quyết nếu không nhờ đến một số cộng đồng ngoài chuỗi- cơ chế điều khiển.Tiếp theo giải quyết. Nhiều khả năng, các ứng dụng sẽ ít phải phụ thuộc vào việc chặn chuyển giao và phụ thuộc nhiều hơn vào các kỹ thuật như thuế Harberger.
Cách ví tương tác với chi tiêu 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: một nonce tiêu chuẩn (ví dụ: hàm băm của tên ứng dụng) được ký bằng khóa riêng của EOA, tạo ra một nonce không thể tạo nếu không có khóa riêng. of , vì vậy 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 cần được ví xử lý rõ ràng hơn.
Các máy khách nhẹ (ví dụ: Helios) sẽ phải xác minh L2, 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 tiêu đề L1 (sử dụng giao thức đồng bộ hóa ứng dụng khách nhẹ) và xác thực trạng thái L1 và các nhánh Merkle của các giao dịch bắt nguồn từ tiêu đề L1. Ngày mai, họ cũng 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 (phiên bản nâng cao hơn này thực sự xem xét xác nhận trước của L2).
Ví cần bảo vệ tài sản và dữ liệu
Giờ đây, công việc kinh doanh của chiếc ví là 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 hiện đang bảo vệ những tài sản đó. Nếu bạn thay đổi khóa, bạn có thể xuất bản khóa riêng trước đó của mình một cách an toàn trên Internet vào ngày hôm sau. Tuy nhiên, trong một thế giới không có bằng chứng về 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 bảo vệ 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 tại Zuzalu. Người dùng có một khóa riêng mà họ sử dụng để xác thực hệ thống, có thể được sử dụng để thực hiện các bằng chứng cơ bản như "chứng minh rằng tôi là cư dân của Zuzalu, nhưng không tiết lộ khóa nào". Tuy nhiên, hệ thống Zupass cũng bắt đầu có các ứng dụng khác được xây dựng trên nó, đáng chú ý nhất là Tem (phiên bản POAP của Zupass).
Một trong nhiều con tem Zupass của tôi chứng tỏ 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 trên POAP là tem là riêng tư: bạn giữ dữ liệu cục bộ và bạn chỉ chứng minh tem (hoặc một số tính toán trên đó) cho họ nếu bạn muốn họ có thông tin này về bạn. Nhưng điều này làm tăng rủi ro: nếu bạn làm mất thông tin này, bạn sẽ mất tem của mình.
Tất nhiên, vấn đề giữ dữ liệu bắt nguồn từ vấn đề giữ khóa mật mã: bên thứ ba (hoặc thậm chí chuỗi) có thể giữ 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ả. Ngược lại, 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 thực tế 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ị (ví dụ: máy tính xách tay và điện thoại), vì khả năng họ bị mất tất cả chúng cùng một lúc là rất nhỏ. 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, chia khóa cho nhiều người giám hộ.
Việc 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 đó 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, vi phạm quyền riêng tư thường ít rủi ro hơn so với mất hoàn toàn tài sản và nếu ai đó yêu cầu trường hợp sử dụng bảo vệ quyền riêng tư cao, anh ta có thể chấp nhận rủi ro mất mát cao hơn bằng cách không sao lưu các khóa liên quan yêu cầu quyền riêng tư- các hành động bảo tồn.
Để tránh làm người dùng choáng ngợp với một hệ thống phức tạp gồm 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 câu hỏi nhận dạng
Chủ đề chung của những thay đổi này là khái niệm về "địa chỉ" mà bạn sử dụng trên chuỗi làm mã định danh mã hóa đại diện cho "bạn" phải thay đổi hoàn toàn. "Hướng dẫn về cách tương tác với tôi" không còn chỉ là một địa chỉ ETH; chúng phải chứa một số tổ hợp nhiều địa chỉ trên nhiều L2, địa chỉ meta bí mật, khóa mã hóa và dữ liệu khác ở một số dạng.
Một cách để làm điều này là tạo cho ENS 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 này và nếu bạn gửi cho ai đó bob.eth (hoặc bob.ecc.eth, hoặc...), họ có thể tìm hiểu và tìm hiểu về tất cả những thứ trả tiền và tương tác với bạn, kể cả theo những cách phức tạp hơn và 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 nhiều nội dung hơn vào hợp đồng kho khóa được đề cập trong kiến trúc trước đó trong bài đăng 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ách bạn tương tác với nó (thông qua CCIP, một số trong số đó có thể nằm ngoài chuỗi) và người dùng có thể sử dụng hợp đồng kho khóa của họ làm số nhận dạng 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 bị ràng buộc về tên, chúng thân thiện với thực tế: bạn có thể tạo một địa chỉ chỉ có thể đượ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 liên quan đến việc từ bỏ khái niệm địa chỉ hướng đến người dùng, tương tự như tinh thần của giao thức thanh toán 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 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 Chấp nhận thanh toán theo cách họ muốn.
![Vitalik: Để triển khai trên quy mô lớn, Ethereum phải trải qua ba lần chuyển đổi: L2, ví và quyền riêng tư] (https://img.gateio.im/social/moments-69a80767fe-f7c28b44ae-dd1a6f-62a40f)
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í để trực tiếp tạo thông tin thanh toán cập nhật trong thời gian thực giúp giảm ma sát. Phải 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) và trên thực tế, giả định 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 khó, vì vậy chúng tôi có thể xem xét 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, điều quan trọng là giữ cho mọi thứ vừa phi tập trung vừa 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 nhất về tài sản hiện tại của họ, cũng như thông tin được xuất bản dành cho 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 không trở thành một "tháp trừu tượng" không rõ ràng để các nhà phát triển hiểu điều gì đang diễn ra và 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 truy cập thực tế cho người dùng bình thường. Chúng ta cần phải đáp ứng thách thức này.
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ọ.