Đặc biệt cảm ơn Dan Finlay, Karl Floersch, David Hoffman và nhóm Scroll và SoulWallet vì những phản hồi, đánh giá và đề xuất.

Khi Ethereum chuyển đổi từ một công nghệ thử nghiệm non trẻ thành 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 bình thường, có ba quá trình chuyển đổi kỹ thuật chính mà nhóm công nghệ đó cần phải trải qua, gần như đồng thời:

• Quá trình chuyển đổi quy mô L2 - mọi người chuyển sang bản tổng hợp
• Quá trình chuyển đổi bảo mật ví - mọi người chuyển sang ví hợp đồng thông minh
• Quá trình chuyển đổi quyền riêng tư - đảm bảo khả năng chuyển tiền bảo vệ quyền riêng tư và đảm bảo 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 được bảo vệ quyền riêng tư

Tam giác chuyển tiếp hệ sinh thái. Bạn chỉ có thể chọn 3 trong số 3.

Nếu không có giao dịch đầ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 mất chuỗi và áp dụng các giải pháp tập trung cho mọi thứ.

Nếu không có cái thứ hai, Ethereum sẽ thất bại vì người dùng không thoải mái khi lưu trữ tiền của họ (và tài sản phi tài chính) và mọi người đều chuyển sang các sàn giao dịch tập trung.

Nếu không có cái thứ ba, Ethereum sẽ thất bại vì việc cung cấp tất cả các giao dịch (và POAP, v.v.) một cách công khai cho bất kỳ ai có thể nhìn thấy theo đúng nghĩa đen là sự hy sinh quyền riêng tư quá cao đối với nhiều người dùng và mọi người đều chuyển sang các giải pháp tập trung ít nhất là che giấu phần nào dữ liệu của bạn.

Ba sự chuyển đổi này rất quan trọng vì những lý do trên. Nhưng chúng cũng đầy thách thức vì có sự phối hợp chặt chẽ để giải quyết chúng một cách hợp lý. Không chỉ các tính 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 khá cơ bản, đòi hỏi những thay đổi sâu sắc từ các ứng dụng và ví.

Ba lần chuyển đổi sẽ định hình lại hoàn toàn 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 rất nhiều L2. Bạn có phải là thành viên của exampleDAO, sống dựa trên Chủ nghĩa lạc quan không? Vậy là bạn đã có tài khoản trên Optimism! Bạn có đang nắm giữ CDP trong hệ thống stablecoin trên ZkSync không? Vậy là bạn đã có tài khoản trên ZkSync! Bạn đã từng thử dùng thử một ứng dụng nào đó tình cờ có trên Kakarot chưa? Vậy là bạn đã có tài khoản trên Kakarot! Những ngày người dùng chỉ có một địa chỉ sẽ không còn nữa.

Tôi có ETH ở bốn nơi, theo quan điểm Ví Brave của tôi. Và vâng, Arbitrum và Arbitrum Nova khác nhau. Đừng lo lắng, nó sẽ trở nên khó hiểu hơn theo thời gian!

Ví hợp đồng thông minh sẽ phức tạp hơn nhiều, bằng cách khiến việc có cùng một địa chỉ trên L1 và các L2 khác nhau trở nên khó khăn hơn nhiều. 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ỉ theo nghĩa đen 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 giữ một địa chỉ trở nên khó khăn hơn. Mặc dù rất nhiều công việc đã được thực hiện để cố gắng biến các địa chỉ thành các mã băm có thể tương đương trên các mạng, đáng chú ý nhất là CREATE2 và nhà máy đơn lẻ ERC-2470, thật khó để làm cho điều này hoạt động hoàn hảo. Một số L2 (ví dụ. “ 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 cụm trung gian để thay thế, ngăn chặn sự tương đương của hàm băm. Và ngay cả khi bạn có thể có giá trị băm tương đương, khả năng ví thay đổi quyền sở hữu thông qua những thay đổi chính sẽ tạo ra những hậu quả không trực quan khác.

Quyền riêng tư yêu cầu mỗi người dùng phải có nhiều địa chỉ hơn nữa và thậm chí có thể thay đổi 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ì mỗi người dùng chỉ có một vài địa chỉ hoặc một địa chỉ cho mỗi L2, thì người dùng có thể có một địa chỉ cho mỗi giao dịch. Các chương trình bảo mật khác, ngay cả những chương trình hiện có như Tornado Cash, thay đổi cách lưu trữ tài sản theo một 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 đó ở 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 phải dựa vào hệ thống địa chỉ nội bộ của chính chương trình bảo mật.

Như chúng ta đã thấy, mỗi lần chuyển đổi trong số ba lần chuyển đổi 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ố hiệu ứng này phản ánh sự phức tạp của việc thực hiện các chuyển đổi. Hai điểm đặc biệt phức tạp là:

1. Nếu bạn muốn trả tiền cho ai đó, bạn sẽ lấy thông tin về cách trả tiền cho họ bằng cách nào?
2. Nếu người dùng có nhiều tài sản được lưu trữ ở những nơi khác nhau trên các chuỗi khác nhau, họ sẽ thực hiện những thay đổi quan trọng và phục hồi xã hội như thế nào?

Ba lần chuyển đổi và thanh toán trên chuỗi (và danh tính)

Tôi có tiền trên Scroll và tôi muốn trả tiền cho cà phê (nếu “tôi” theo đúng nghĩa đen là tôi, người viết bài này, thì “cà phê” tất nhiên là một từ hoán dụ cho “trà xanh”). Bạn đang bán cà phê cho tôi, nhưng bạn chỉ được thiết lập để nhận xu trên Taiko. Làm gì thế?

Về cơ bản có hai giải pháp:

1. Ví nhận (có thể là người bán nhưng cũng có thể chỉ là cá nhân bình thường) cố gắng hết sức để hỗ trợ mọi L2 và có một số chức năng tự động để tổng hợp tiền không đồng bộ.
2. Người nhận cung cấp L2 cùng với địa chỉ của họ và ví của người gửi sẽ tự động chuyển tiền đến L2 đích thông qua một số hệ thống bắc cầu chéo L2.

Tất nhiên, những 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 sẽ 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 nói cách khác là gửi L2 chéo con đường bắc cầu.

Nhưng đây chỉ là một ví dụ về thách thức chính mà ba quá trình chuyển đổi đưa ra: các hành động đơn giản như trả tiền cho ai đó bắt đầu yêu cầu nhiều thông tin hơn chỉ là một địa chỉ 20 byte.

May mắn thay, việc chuyển đổi 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 đánh địa chỉ, nhưng vẫn còn một số vấn đề kỹ thuật trong các phần khác của ngăn xếp ứng dụng cần được giải quyết. Các ví sẽ cần phải được cập nhật để đảm bảo rằng chúng không chỉ gửi 21000 gas cùng với một giao dịch và điều quan trọng hơn nữa 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 rằng quyền sở hữu địa chỉ là không thay đổi (ví dụ: Các NFT cấm hợp đồng thông minh để thực thi tiền bản quyền) sẽ phải tìm những 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 - đá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 công cụ thanh toán ERC-4337 để thanh toán gas 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 đưa 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 ra khỏi hệ thống. Tuy nhiên, khi bạn có thể thực hiện chuyển khoả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. Trong thực tế, “thông tin thanh toán” của người dùng sẽ cần phải chứa cả (i) một số loại “khóa chi tiêu”, cam kết 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 gửi mã hóa. thông tin mà chỉ người nhận mới có thể giải mã để giúp người nhận khám phá khoản thanh toán.

Các giao thức địa chỉ ẩn dựa trên khái niệm về đị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 mù của khóa chi tiêu của người gửi và một phần khác 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ể đặt hai khóa đó giống nhau).

Sơ đồ 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.

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 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ẽ phải bao gồm cả hai khóa. Ngoài ra còn có những lý do chính đáng khác ngoài việc thanh toán để 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 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 có chức năng rõ ràng hơn cho việc này. Điều này cũng sẽ giúp làm cho danh tính dựa trên Ethereum tương thích hơn với các hệ sinh thái quyền riêng 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 để thực hiện các thay đổi quan trọng và khôi phục mạng xã hội trong thế giới nhiều địa chỉ cho mỗi người dùng 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ỉ riêng biệt. Điều này có thể được thực hiện chỉ bằng một cú nhấp chuột: ví có thể bao gồm phần mềm để thực hiện quy trình khôi phục trên tất cả các địa chỉ của người dùng cùng một lúc. Tuy nhiên, ngay cả với việc đơn giản hóa UX như vậy, việc khôi phục đa địa chỉ đơn giản vẫn có ba vấn đề:

1. Tính không thực tế của chi phí gas: điều này là dễ hiểu.
2. Địa chỉ phản thực: địa chỉ mà hợp đồng thông minh chưa được công bố (trong thực tế, điều này có nghĩa là 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ó thể có số lượng địa chỉ phản thực không giới hạn: một hoặc nhiều trên mỗi L2, bao gồm cả các L2 chưa tồn tại và toàn bộ tập hợp vô hạn các địa chỉ phản thực khác phát sinh từ sơ đồ địa chỉ ẩn.
3. 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, họ chắc chắn không muốn liên kết công khai tất cả chúng bằng cách khôi phục chúng 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á hay và hoạt động khá tốt: một kiến trúc tách biệt logic xác minh và 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ó các địa chỉ trên các L2 khác nhau, trong đó logic xác minh của từng địa chỉ đó là một con trỏ tới hợp đồng kho khóa. Việc chi tiêu từ những địa chỉ đó sẽ yêu cầu bằng chứng đi vào hợp đồng kho khóa hiển thị 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).

Bằng chứng có thể được thực hiện theo một số cách:

• Truy cập L1 chỉ đọc trực tiếp bên trong L2. Có thể sửa đổi L2 để cung cấp cho chúng cách đọ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 bên trong L2 có thể truy cập kho khóa “miễn phí”
• Nhá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 bạn có thể kết hợp cả hai để chứng minh các phần trạng thái 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ể là 5 kB cho một bằng chứng, mặc dù điều này sẽ giảm xuống <1 kB trong tương lai do 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 nhánh Merkle thay vì chính 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) để có 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 của KZG. L2 hoặc các sơ đồ được xây dựng dựa 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 về trạng thái bên trong hệ thống này chỉ dài 48 byte. Giống như ZK-SNARK, sơ đồ đa chứng minh có thể hợp nhất 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 thực hiện một 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 bằng chứng chéo L2 để khôi phục. Việ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 chi tiêu_pubkey hiện tại trong kho khóa. Tiền trong địa chỉ phản thực được an toàn ngay cả khi khóa cũ của bạn không: “kích hoạt” một địa chỉ phản thực để biến nó thành hợp đồng làm việc sẽ yêu cầu tạo bằng chứng L2 chéo để sao chép chi tiêu_pubkey hiện tại. Chủ đề này trên diễn đàn An toàn mô tả cách hoạt động của một kiến trúc tương tự.

Để 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ỏ và thực hiện tất cả việc chứng minh bên trong ZK-SNARK:

Với nhiều công việc hơn (ví dụ. sử dụng<a href="https://notes.ethereum.org/ @vbuterin /non_index_revealing_proof">cái này hoạt động như một điểm khởi đầ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 ra một sơ đồ dựa trên KZG cơ bản hơn.

Những kế hoạch này có thể trở nên phức tạp. Về mặt tích cực, có rất 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ể là một giải pháp cho thách thức về “đị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, địa chỉ đó không thay đổi mỗi khi người dùng cập nhật khóa, chúng tôi có thể đưa các địa chỉ meta ẩn, 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 thứ cấp cần cập nhật

Sử dụng ENS rất tốn kém. Ngày nay, vào tháng 6 năm 2023, tình hình không quá tệ: phí giao dịch rất đáng kể nhưng vẫn có thể so sánh với phí miền ENS. Đăng ký zuzalu.eth tốn khoảng 27 USD, trong đó 11 USD là phí giao dịch. Nhưng nếu chúng ta có một thị trường giá lên khác, phí sẽ tăng vọt. Ngay cả khi giá ETH không tăng, phí gas quay trở lại 200 gwei sẽ tăng phí đăng ký tên miền lên 104 USD. Và 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í tên 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ụ), chúng tôi cần ENS làm việc trên L2.

May mắn thay, nhóm ENS đã vào cuộc và ENS trên L2 đang thực sự diễn ra! ERC-3668 (còn gọi là “tiêu chuẩn CCIP”), cùng với ENSIP-10, cung cấp một cách để tự động xác minh cá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 dữ liệu trên L2 và tên 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 đó. 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 bằng chứng (ví dụ: Nhánh Merkle) của trạng thái trong L2 thực sự lưu trữ tên miền phụ cụ thể đó.

Trên thực tế, việc tìm nạp bằng chứng liên quan đến việc truy cập danh sách các URL được lưu trữ trong hợp đồng, phải thừa nhận là có cảm giác như 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 trong N (bằng chứng không hợp lệ sẽ bị logic xác minh phát hiện trong chức năng gọi lại của hợp đồng CCIP và miễn là ngay cả một trong các URL cũng trả về bằng chứng hợp lệ thì bạn vẫn ổn). Danh sách các URL có thể chứa hàng chục URL như vậy.

Nỗ lực của ENS CCIP là một câu chuyện thành công và nó nên được xem như 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 còn rất nhiều cải cách về lớp ứng dụng cần được thực hiện. Một vài ví dụ:

• Rất nhiều dapp phụ thuộc vào việc người dùng cung cấp chữ ký ngoài chuỗi. Với các tài khoản thuộc sở hữu bên ngoài (EOA), việc này thật dễ dàng. ERC-1271 cung cấp một cách tiêu 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; họ sẽ cần phải làm vậy.
• Các Dapp sử dụng “đây có phải là EOA không?” phân biệt đối xử giữa người dùng và hợp đồng (ví dụ: ngăn chặn việc chuyển nhượng hoặc thực thi tiền bản quyền) sẽ bị vi phạm. 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 liệu một hoạt động 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ó khăn và có thể không thể 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. Rất có thể, các ứng dụng sẽ phải phụ thuộc ít hơn vào việc ngăn chặn chuyển giao và dựa 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ẽ phải được cải thiện. 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 (ví dụ: hàm băm của tên ứng dụng) bằng khóa riêng của EOA tạo ra một giá trị xác định không thể được tạo nếu không có khóa riêng và do đó, nó an toàn theo nghĩa thuần túy kỹ thuật. Tuy nhiên, những 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 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ẽ phải được ví xử lý rõ ràng hơn.
• Khách hàng nhẹ (ví dụ. Helios) sẽ phải xác minh L2 chứ không chỉ L1. Ngày nay, các máy khách hạng 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 máy khách hạng nhẹ) và xác minh các nhánh Merkle của trạng thái L1 cũng như các giao dịch bắt nguồn từ tiêu đề L1. Ngày mai, 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 (phiên bản nâng cao hơn của điều này thực sự sẽ xem xét các xác nhận trước L2).

Ví sẽ cần bảo mật cả tài sản và dữ liệu

Ngày nay, ví có nhiệm vụ đảm bảo tài sản. Mọi thứ đều tồn tại trên chuỗi và điều duy nhất mà ví cần bảo vệ là 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 lê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 lưu giữ dữ liệu của bạn.

Chúng tôi đã nhìn 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, khóa này có thể được sử dụng để đưa ra các bằng chứng cơ bản như “chứng minh tôi là cư dân Zuzalu mà không tiết lộ đó là ai”. Nhưng hệ thống Zupass cũng bắt đầu có các ứng dụng khác được xây dựng bên trên, đáng chú ý nhất là tem (phiên bản POAP của Zupass).

Một trong rất nhiều tem Zupass của tôi, xác nhận rằng tôi là thành viên đáng tự hào của Team Cat.

Tính năng chính mà tem cung cấp qua POAP là tem có tính riêng tư: bạn giữ dữ liệu cục bộ và bạn chỉ chứng minh ZK về tem (hoặc một số tính toán trên tem) cho ai đó nếu bạn muốn họ có thông tin đó về bạn. Nhưng điều này tạo ra rủi ro gia tăng: nếu bạn làm mất thông tin đó, bạn sẽ mất tem.

Tất nhiên, vấn đề lưu giữ dữ liệu có thể được giảm xuống thành vấn đề 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ể 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à các hành động bạn thực hiện không làm thay đổi khóa mã hóa và do đó không yêu cầu bất kỳ tương tác nào với hệ thống đang giữ khóa mã hóa của bạn an toàn. Tuy nhiên, nếu bạn mất khóa mã hóa, bạn sẽ mất tất cả. Và mặt khác, nếu ai đó nhìn thấy khóa mã hóa của bạn, họ sẽ 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ữ 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ọ mất quyền truy cập vào tất cả các thiết bị cùng lúc là rất nhỏ. Chúng tôi có thể tiến xa hơn và sử dụng tính năng chia sẻ bí mật để lưu trữ khóa, phân chia giữa nhiều người giám hộ.

Kiểu phục hồi xã hội thông qua MPC này không phải là giải pháp đủ cho ví, vì nó 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ò rỉ quyền riêng tư thường có rủi ro thấp hơn so với việc mất tổng tài sản và người nào đó có trường hợp sử dụng yêu cầu cao về quyền riêng tư luôn 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 khóa liên quan đến các hành động đòi hỏi quyền riêng tư đó.

Để tránh làm choáng ngợp người dùng bằng 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ể sẽ cần quản lý cả việc khôi phục tài sản và khôi phục khóa mã hóa.

Trở lại danh tính

Một trong những chủ đề chung của những thay đổi này là khái niệm về “địa chỉ”, mã định danh bằng mật mã mà bạn sử dụng để đại diện cho “bạn” trên chuỗi, sẽ phải thay đổi hoàn toàn. “Hướng dẫn cách tương tác với tôi” sẽ không còn chỉ là địa chỉ ETH nữa; Ở một dạng nào đó, chúng sẽ 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 cách để làm điều này là đặt ENS 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 thanh toán và tương tác với bạn, bao gồm cả những cách 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ó gắ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 là một trong nhiều đặc tính của bạn. Bạn 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 của mình và cập nhật toàn bộ hồ sơ trên nhiều ứng dụng.
• Bạn không thể có những cái tên phản thực tế không đáng tin cậy. Một tính năng UX chính của bất kỳ blockchain 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, sẽ có một nhược điểm: tương tác với chuỗi yêu cầu phải trả phí giao dịch, yêu cầu… phải có 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 ngoài chuỗi rằng chúng là bob.ecc.eth, không có cách nào để chọn ai trong số họ có tên.

Một giải pháp khả thi là đưa nhiều thứ 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 tất cả thông tin khác nhau về bạn và cách tương tác với bạn (và với CCIP, một số thông tin đó 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 mã định danh chính. Nhưng tài sản thực tế mà họ nhận được sẽ được lưu trữ ở nhiều nơi khác nhau. Hợp đồng kho khóa không bị ràng buộc với tên và chúng thân thiện với thực tế: bạn có thể tạo một địa chỉ có thể chỉ được khởi tạo bằng hợp đồng kho khóa có 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 về địa chỉ hướng tới người dùng, theo tinh thần tương tự như giao thức thanh toán Bitcoin. Một ý tưởng là dựa nhiều hơn vào các kênh liên lạc 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 xác nhận quyền sở hữu (dưới dạng URL rõ ràng hoặc mã QR) mà người nhận có thể sử dụng để chấp nhận khoản thanh toán theo cách họ muốn.

Bất kể người gửi hay người nhận hành động trước, việc phụ thuộc nhiều hơn vào ví trực tiếp tạo ra thông tin thanh toán cập nhật theo thời gian thực có thể làm giảm xung đột. Điều đó cho thấy, số nhận dạng liên tục rất thuận tiện (đặc biệt là với ENS) và việc giả định liên lạc trực tiếp giữa người gửi và người nhận là một điều thực sự phức tạp trong thực tế và vì vậy cuối cùng chúng ta 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, việc giữ mọi thứ vừa phi tập trung vừa dễ hiểu đối với người dùng là điều tối quan trọng. Chúng tôi cần đảm bảo rằng người dùng có thể dễ dàng truy cập vào chế độ xem cập nhật về nội dung hiện tại của họ và những thông báo đã được xuất bản dành cho họ. Những quan điểm này phải phụ thuộc vào các công cụ mở chứ không phải các giải pháp độc quyền. Sẽ phải làm việc chăm chỉ để tránh sự phức tạp lớn hơn của cơ sở hạ tầng thanh toán biến 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à điều chỉnh nó cho phù hợp với bối cảnh mới. 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. Nó 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 thông thường. Chúng ta cần phải vươn lên để đáp ứng thách thức này.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Vitalik], Mọi bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Sanv Nurlae , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Sanv Nurlae. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.