Vitalik Buterin: Ethereum cần hoàn thành ba chuyển đổi L2, ví, quyền riêng tư

Tiêu đề gốc: 《The Three Transitions》

Tác giả: Vitalik Buterin

Biên dịch: MK, MarsBit

Khi Ethereum chuyển từ một công nghệ thử nghiệm trẻ thành một công nghệ trưởng thành có thể thực sự mang lại trải nghiệm mở, toàn cầu và không cần giấy phép cho người dùng thông thường, công nghệ này cần trải qua ba chuyển đổi chính, diễn ra gần như đồng thời:

1. Chuyển đổi mở rộng L2 - Tất cả mọi người đều chuyển sang rollups
2. Chuyển đổi an toàn ví - Tất cả mọi người đều chuyển sang ví hợp đồng thông minh
3. Chuyển đổi quyền riêng tư - Đảm bảo việc 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, uy tín) đều có thể bảo vệ quyền riêng tư

Đây là mối quan hệ tam giác của sự chuyển đổi hệ sinh thái. Bạn chỉ có thể chọn 3 trong số 3.

Nếu không có cái đầu tiên, Ethereum sẽ thất bại, vì mỗi giao dịch sẽ tốn 3,75 đô la (nếu chúng ta có một đợt tăng giá khác, thì giá sẽ là 82,48 đô la), và mỗi sản phẩm hướng tới thị trường đại chúng cuối cùng sẽ quên 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 muốn lưu trữ tiền của họ (và tài sản phi tài chính), mọi người sẽ 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ì tất cả các giao dịch (và POAPs, v.v.) đều công khai cho bất kỳ ai xem, điều này là một sự hy sinh quá lớn về quyền riêng tư đối với nhiều người dùng, mọi người sẽ chuyển sang ít nhất có một số dữ liệu ẩn trong các giải pháp tập trung.

Vì những lý do trên, ba chuyển đổi này là rất quan trọng. Nhưng vì việc giải quyết những vấn đề này cần có sự phối hợp mạnh mẽ, nên chúng cũng rất thách thức. Không chỉ cần cải thiện chức năng của giao thức, trong một số trường hợp, cách chúng ta tương tác với Ethereum cần có những thay đổi khá cơ bản, cần có những thay đổi sâu sắc trong ứng dụng và ví.

Ba chuyển đổi này sẽ thay đổ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 trong nhiều L2. Bạn có phải là thành viên của ExampleDAO, nó nằm trên Optimism không? Vậy thì 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? Vậy thì bạn có một tài khoản trên ZkSync! Bạn đã từng thử một số ứng dụng nằm trên Kakarot chưa? Vậy thì bạn có một tài khoản trên Kakarot! Thời kỳ mà 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 cái nhìn của ví Brave của tôi. Đúng vậy, Arbitrum và Arbitrum Nova là khác nhau. Đừng lo, theo thời gian, điều này sẽ trở nên phức tạp hơn!

Ví hợp đồng thông minh đã làm tăng thêm sự phức tạp, khiến việc sở hữu cùng một địa chỉ trên L1 và nhiều L2 trở nên khó khăn hơn. Ngày nay, hầu hết người dùng đang sử dụng tài khoản thuộc sở hữu bên ngoài, địa chỉ của họ thực sự là băm của khóa công khai được sử dụng để xác thực chữ ký - vì vậy không có sự thay đổi nào giữa L1 và L2. Tuy nhiên, đối với ví hợp đồng thông minh, việc duy trì một địa chỉ trở nên khó khăn hơn. Mặc dù đã có rất nhiều công việc được thực hiện để cố gắng làm cho địa chỉ trở thành băm tương đương giữa các mạng, đặc biệt là CREATE2 và nhà máy đơn thể ERC-2470, nhưng việc thực hiện điều này một cách hoàn hảo là rất khó. Một số L2 (chẳng hạn như "type 4 ZK-EVMs") không hoàn toàn tương đương với EVM, thường sử dụng Solidity hoặc lắp ráp trung gian thay thế, do đó ngăn chặn sự tương đương băm. Ngay cả khi bạn có thể có sự tương đương băm, khả năng ví thay đổi quyền sở hữu thông qua sự thay đổi khóa cũng 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 có nhiều địa chỉ hơn, thậm chí có thể thay đổi loại địa chỉ mà chúng ta xử lý. Nếu đề xuất địa chỉ quyền riêng tư được sử dụng rộng rãi, mỗi người dùng sẽ không còn chỉ có một vài địa chỉ, hoặc một địa chỉ trên mỗi L2, mà có thể có một địa chỉ trong mỗi giao dịch. Các giải pháp quyền riêng tư khác, thậm chí là các giải pháp hiện có như Tornado Cash, sẽ thay đổi cách lưu trữ tài sản theo những cách khác nhau: 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 (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 giải pháp quyền riêng tư.

Như chúng ta thấy, ba chuyển đổi này đã làm suy yếu mô hình tâm lý "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 trong số đó phản hồi vào độ phức tạp của việc thực hiện các chuyển đổi. Hai điểm phức tạp đặc biệt là:

1. Nếu bạn muốn thanh toán cho ai đó, bạn làm thế nào để có được thông tin thanh toán cho họ?

2. Nếu người dùng lưu trữ nhiều tài sản ở nhiều nơi khác nhau trên các chuỗi khác nhau, họ sẽ làm thế nào để thay đổi khóa và khôi phục xã hội?

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

Tôi có tiền xu trên Scroll, tôi muốn thanh toán cho cà phê (nếu "tôi" là nghĩa đen, chỉ về tác giả của bài viết này, thì "cà phê" chắc chắn là phép ẩn dụ cho "trà xanh"). Bạn đang bán cho tôi cà phê, nhưng bạn chỉ chuẩn bị nhận tiền xu trên Taiko. Tôi phải làm gì?

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

1. Ví nhận (có thể là thương nhân hoặc chỉ là cá nhân bình thường) cố gắng hỗ trợ mỗi L2 và có một số chức năng tự động tích hợp quỹ bất đồng bộ.

2. Người nhận cung cấp L2 của họ và địa chỉ của họ, ví của người gửi tự động định tuyến quỹ đến L2 mục tiêu thông qua một hệ thống cầu nối giữa các L2.

Tất nhiên, những giải pháp này có thể kết hợp: người nhận cung cấp danh sách các L2 mà họ sẵn sàng nhận, ví của người gửi tính toán thanh toán, điều này 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 một lộ trình cầu nối giữa các L2.

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

Chuyển đổi ví hợp đồng thông minh may mắn không tạo ra gánh nặng lớn cho hệ thống địa chỉ, nhưng vẫn còn một số vấn đề kỹ thuật cần giải quyết ở các phần khác của ngăn xếp ứng dụng. Ví cần được cập nhật để đảm bảo rằng chúng không chỉ gửi 21000 gas trong giao dịch, mà quan trọng hơn là đảm bảo rằng đầu vào thanh toán của ví không chỉ theo dõi việc chuyển ETH từ EOAs mà còn theo dõi ETH được gửi bởi mã hợp đồng thông minh. Các ứng dụng phụ thuộc vào giả định rằng quyền sở hữu địa chỉ không thay đổi (ví dụ, cấm hợp đồng thông minh để thực thi bản quyền NFT) sẽ phải tìm cách khác để đạt được mục tiêu của họ. Ví hợp đồng thông minh cũng sẽ làm cho một số điều trở nên dễ dàng hơn - đặc biệt là nếu ai đó chỉ nhận các token ERC20 không phải ETH, họ sẽ có thể sử dụng người thanh toán ERC-4337 để thanh toán phí gas bằng token đó.

Mặt khác, quyền riêng tư lại đặt ra thách thức chính mà chúng ta vẫn chưa thực sự giải quyết. 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ào hệ thống và rút ra. 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 hệ thống địa chỉ nội bộ của giải pháp quyền riêng tư. Trong thực tế, "thông tin thanh toán" của người dùng cần bao gồm (i) một loại "khóa công khai chi tiêu", tức là một cam kết bí mật mà người nhận có thể sử dụng để chi tiêu, và (ii) cách mà người gửi gửi thông tin được mã hóa mà chỉ người nhận có thể giải mã, để giúp người nhận phát hiện thanh toán.

Giao thức địa chỉ quyền riêng tư phụ thuộc vào khái niệm địa chỉ meta, hoạt động theo cách: một phần của địa chỉ meta là một phiên bản mờ của khóa chi tiêu của người gửi, phần còn lại là khóa mã hóa của người gửi (mặc dù việc triển khai tối thiểu có thể thiết lập rằng hai khóa này là giống nhau).

Bài học chính ở đây là, trong một hệ sinh thái chú trọng quyền riêng tư, người dùng sẽ có khóa công khai chi tiêu và khóa mã hóa, "thông tin thanh toán" của người dùng sẽ phải bao gồm cả hai loại khóa này. Ngoài thanh toán, còn có một số lý do tốt khác để mở rộng theo hướng này. Ví dụ, nếu chúng ta muốn có email mã hóa dựa trên Ethereum, người dùng sẽ cần cung cấp công khai một hình thức khóa mã hóa nào đó. Trong "thế giới EOA", chúng ta có thể tái sử dụng khóa tài khoản để đạt được mục tiêu này, nhưng trong một thế giới ví hợp đồng thông minh an toàn, chúng ta có thể nên có những chức năng rõ ràng hơn để đạt được mục tiêu 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 hệ sinh thái quyền riêng tư phân tán không phải Ethereum, ví dụ nổi bật nhất là khóa PGP.

Ba chuyển đổi và khôi phục khóa

Trong một thế giới mà người dùng có thể có nhiều địa chỉ, cách mặc định để thực hiện thay đổi khóa và khôi phục xã hội là để người dùng thực hiện quy trình khôi phục cho mỗi địa chỉ một cách riêng biệt. Điều này có thể được thực hiện chỉ với một nút bấm: 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 trải nghiệm người dùng như vậy, khôi phục nhiều địa chỉ một cách ngây thơ cũng có ba vấn đề:

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

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

1. Đọc quyền truy cập chỉ đọc L1 trực tiếp trong L2. L2 có thể được sửa đổi để cung cấp cho họ một phương pháp đọc trực tiếp trạng thái L1. Nếu hợp đồng kho khóa ở L1, điều này có nghĩa là hợp đồng trong L2 có thể "miễn phí" truy cập vào kho khóa.

2. Nhánh Merkle. Nhánh Merkle có thể chứng minh trạng thái L1 đến L2, hoặc trạng thái L2 đến L1, hoặc bạn có thể kết hợp cả hai để chứng minh một phần trạng thái của L2 cho một L2 khác. Điểm yếu chính của chứng minh Merkle là chi phí gas cao do độ dài chứng minh: một chứng minh có thể cần 5 kB, mặc dù do cây Verkle, điều này sẽ giảm xuống dưới 1 kB trong tương lai.

3. ZK-SNARKs. 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ì nhánh chính nó. Có thể xây dựng các kỹ thuật tổng hợp ngoài chuỗi (ví dụ, dựa trên EIP-4337), cho phép một ZK-SNARK duy nhất xác thực tất cả các chứng minh trạng thái xuyên chuỗi trong một khối.

4. Cam kết KZG. Các L2 hoặc các giải pháp xây dựng trên nó có thể giới thiệu một hệ thống địa chỉ tuần tự, cho phép chứng minh trạng thái bên trong hệ thống này chỉ dài 48 byte. Giống như ZK-SNARKs, một giải pháp nhiều chứng minh có thể hợp nhất tất cả các chứng minh này thành một chứng minh duy nhất cho mỗi khối.

Nếu chúng ta muốn tránh việc thực hiện một chứng minh cho mỗi giao dịch, chúng ta có thể thực hiện một giải pháp nhẹ hơn, chỉ cần thực hiện một chứng minh xuyên L2 khi khôi phục. Việc chi tiêu từ một tài khoản sẽ phụ thuộc vào một khóa chi tiêu, 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ẽ cần một giao dịch, sao chép khóa công khai chi tiêu hiện tại trong kho khóa. Tài sản trong địa chỉ phản thực tế vẫn an toàn ngay cả khi khóa cũ của bạn không an toàn: "kích hoạt" một địa chỉ phản thực tế, biến nó thành một hợp đồng hoạt động sẽ cần thực hiện một chứng minh xuyên L2, sao chép khóa công khai chi tiêu hiện tại. Chủ đề này trên diễn đàn Safe mô tả cách một kiến trúc tương tự có thể hoạt động.

Để tăng cường quyền riêng tư cho một giải pháp như vậy, chúng ta chỉ cần mã hóa các con trỏ, sau đó thực hiện tất cả các chứng minh trong ZK-SNARKs:

Thông qua nhiều công việc hơn (ví dụ, lấy công việc này làm điểm khởi đầu), chúng ta cũng có thể tách biệt hầu hết độ phức tạp của ZK-SNARKs, tạo ra một giải pháp đơn giản hơn dựa trên KZG.

Những giải pháp này có thể trở nên phức tạp. Tuy nhiên, giữa những giải pháp này có nhiều hiệu ứng hợp tác tiềm năng. Ví dụ, khái niệm "hợp đồng kho khóa" cũng có thể là giải pháp cho thách thức "địa chỉ" được đề cập trong phần trước: nếu chúng ta muốn người dùng có địa chỉ bền vững, những địa chỉ này sẽ không thay đổi khi người dùng cập nhật khóa, chúng ta có thể đưa đị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.

Nhiều cơ sở hạ tầng cấp hai cần được cập nhật

Việc sử dụng ENS là tốn kém. Hôm nay, tháng 6 năm 2023, tình hình không quá tệ: phí giao dịch mặc dù cao nhưng vẫn có thể so sánh với phí tên miền ENS. Đăng ký zuzalu.eth tốn khoảng 27 đô la, trong đó 11 đô la là phí giao dịch. Nhưng nếu chúng ta có một đợt tăng giá khác, phí sẽ tăng vọt. Ngay cả khi không có giá ETH tăng, phí gas trở lại 200 gwei sẽ làm tăng phí giao dịch đăng ký tên miền lên 104 đô la. Do đó, nếu chúng ta muốn mọi người thực sự sử dụng ENS, đặc biệt là trong các trường hợp ứng dụng như mạng xã hội phi tập trung, 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 các miền con cho người dùng của họ), chúng ta cần ENS hoạt động trên L2.

May mắn thay, đội ngũ ENS đã bắt đầu hành động, ENS trên L2 thực sự đang 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 một phương pháp tự động xác thực các miền con ENS trên bất kỳ L2 nào. Tiêu chuẩn CCIP yêu cầu thiết lập một hợp đồng thông minh, mô tả phương pháp xác thực chứng minh dữ liệu L2, 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 một hợp đồng như vậy. Khi hợp đồng CCIP kiểm soát ecc.eth trên L1, việc truy cập vào some subdomain.ecc.eth sẽ tự động liên quan đến việc tìm kiếm và xác thực chứng minh (ví dụ, nhánh Merkle) của trạng thái L2, thực sự lưu trữ miền con cụ thể đó.

Việc thực sự lấy chứng minh liên quan đến việc truy cập một loạt URL được lưu trữ trong hợp đồng, điều này thừa nhận cảm giác như là tập trung, mặc dù tôi sẽ lập luận rằng thực tế không phải như vậy: đó là một mô hình tin cậy 1-trong-N (chứng minh không hợp lệ sẽ bị logic xác thực trong hàm gọi lại của hợp đồng CCIP bắt giữ, miễn là có một URL trả về chứng minh hợp lệ, 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 ENS CCIP là một ví dụ thành công, nên được coi là dấu hiệu cho thấy loại cải cách triệt để mà chúng ta cần là khả thi. Nhưng vẫn cần thực hiện nhiều cải cách ở cấp ứng dụng hơn. Một số ví dụ bao gồm:

Nhiều dapp phụ thuộc vào người dùng cung cấp chữ ký ngoài chuỗi. Đối với các tài khoản thuộc sở hữu bên ngoài (EOA), điều này rất đơn giản. ERC-1271 cung cấp một phương pháp tiêu chuẩn hóa cho ví hợp đồng thông minh để thực hiện điều này. Tuy nhiên, nhiều dapp vẫn không hỗ trợ ERC-1271; họ cần phải hỗ trợ.

Những dapp sử dụng "Đây có phải là EOA không?" để phân biệt người dùng và hợp đồng (ví dụ, để ngăn chặn chuyển nhượng hoặc thực hiện bản quyền) sẽ bị phá vỡ. Nói chung, tôi khuyên không nên cố gắng tìm một giải pháp thuần túy kỹ thuật; việc xác định xem việc chuyển nhượng quyền kiểm soát mã hóa cụ thể có phải là một vấn đề chuyển nhượng quyền lợi có lợi hay không là một vấn đề khó khăn, có thể không thể giải quyết mà không cần một số cơ chế cộng đồng ngoài chuỗi. Có khả năng cao là các ứng dụng sẽ phải ít phụ thuộc vào việc ngăn chặn chuyển nhượng, nhiều hơn vào các công nghệ như thuế Harberger.

Cách mà ví tương tác với khóa 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 ra khóa cụ thể cho ứng dụng: sử dụng khóa riêng của EOA để ký một số ngẫu nhiên tiêu chuẩn (ví dụ, băm tên ứng dụng), tạo ra một giá trị xác định không thể tạo ra mà không có khóa riêng, vì vậy về mặt kỹ thuật là an toàn. Tuy nhiên, những kỹ thuật này là "không minh bạch" đối với ví, ngăn cản ví thực hiện các kiểm tra an toàn ở cấp giao diện người dùng. Trong một hệ sinh thái trưởng thành hơn, chữ ký, mã hóa và các chức năng liên quan cần được xử lý rõ ràng hơn bởi ví.

Các khách hàng nhẹ (ví dụ Helios) sẽ phải xác thực L2, không chỉ L1. Ngày nay, các khách hàng 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ộ khách hàng nhẹ) và xác thực nhánh Merkle của trạng thái và giao dịch L1 xuất phát từ tiêu đề L1. Ngày mai, họ cũng sẽ cần xác thực chứng minh trạng thái L2 xuất phát từ gốc trạng thái L1 được lưu trữ (phiên bản tiên tiến hơn này thực sự 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

Hiện tại, công việc của ví là bảo vệ 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 tại bảo vệ những tài sản đó. Nếu bạn thay đổi khóa, bạn có thể an toàn công khai khóa riêng trước đó của mình trên internet vào ngày hôm sau. Tuy nhiên, trong một thế giới chứng minh không biết, tình hình không còn như vậy: ví không chỉ bảo vệ chứng nhận, mà còn bảo vệ dữ liệu của bạn.

Chúng ta đã thấy dấu hiệu đầu tiên của một thế giới như vậy trong Zupass, Zupass là hệ thống danh tính dựa trên ZK-SNARK được sử dụng trong Zuzalu. Người dùng có một khóa riêng, họ sử dụng nó để xác thực hệ thống, có thể được sử dụng để thực hiện các chứng minh cơ bản, chẳng hạn như "chứng minh tôi là một cư dân của Zuzalu, nhưng không tiết lộ là cư dân nào". Tuy nhiên, hệ thống Zupass cũng bắt đầu có các ứng dụng khác xây dựng trên đó, nổi tiếng nhất là tem (phiên bản POAP của Zupass).

Một trong nhiều tem Zupass của tôi, chứng minh tôi là một thành viên tự hào của Team Cat.

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

Tất nhiên, vấn đề giữ dữ liệu có thể được quy về vấn đề giữ một khóa mã hóa: bên thứ ba (thậm chí là chuỗi) có thể giữ bản sao mã hóa của dữ liệu. Điều này có một lợi thế thuận tiện, tức là hành động bạn thực hiện sẽ 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 của bạn an toàn. Nhưng ngay cả như vậy, nếu bạn mất khóa mã hóa của mình, bạn sẽ mất tất cả. Ngược lại, nếu ai đó thấy khóa mã hóa của bạn, họ có thể thấy tất cả những gì đượ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 tất cả các thiết bị cùng một lúc là rất nhỏ. Chúng ta có thể tiến xa hơn, sử dụng chia sẻ bí mật để lưu trữ khóa, chia nhỏ khóa giữa nhiều người bảo vệ.

Hình thức khôi phục xã hội này thông qua MPC không phải là một giải pháp đủ cho ví, vì điều này 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ó thể thông đồng để đánh cắp tài sản của bạn, điều này là một rủi ro không thể chấp nhận được. Tuy nhiên, việc lộ quyền riêng tư thường có rủi ro nhỏ hơn so với việc mất hoàn toàn tài sản, nếu ai đó cần một trường hợp sử dụng yêu cầu bảo vệ quyền riêng tư cao, họ 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 đến hành động cần bảo vệ quyền riêng tư.

Để tránh việc đè bẹp người dùng bằng một hệ thống nhiều đường khôi phục phức tạp, ví hỗ trợ khôi phục xã hội có thể cần quản lý đồng thời cả khôi phục tài sản và khôi phục khóa mã hóa.

Quay lại vấn đề danh tính

Một chủ đề chung của những thay đổi này là khái niệm "địa chỉ" đại diện cho "bạn" bằng các định danh mã hóa trên chuỗi cần phải được thay đổi hoàn toàn. "Hướng dẫn 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 bao gồm một cách nào đó, một 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à các dữ liệu khác.

Một cách để thực hiện điều này là để ENS trở thành 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, nếu bạn gửi cho ai đó bob.eth (hoặc bob.ecc.eth, hoặc…), họ có thể tìm kiếm và hiểu tất cả 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 phức tạp hơn xuyên lĩnh vực và bảo vệ quyền riêng tư.

Tuy nhiên, phương pháp tập trung vào ENS này có hai điểm yếu:

• Nó gắn 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 nên có thể thay đổi tên của mình mà không cần phải di chuyển toàn bộ hồ sơ danh tính của mình và cập nhật một đống bản ghi trong nhiều ứng dụng.
• Bạn không thể có tên thật không tin cậy. Một đặc điểm UX chính 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ương tác với chuỗi. Nếu không có chức năng như vậy, sẽ có một vấn đề gà và trứng: tương tác với chuỗi yêu cầu phải trả phí giao dịch, trong khi việc thanh toán phí yêu cầu… đã sở hữu tiền. Địa chỉ ETH, bao gồm cả địa chỉ hợp đồng thông minh với CREATE2, đều có đặc điểm này. Tên ENS không có, vì nếu hai Bob đều quyết định họ là bob.ecc.eth mà không có cách nào chọn ai sẽ nhận 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 cấu trúc ở đầu bài viết này. Hợp đồng kho khóa có thể chứa thông tin về bạn và cách tương tác với bạn (thông qua CCIP, một số thông tin có thể ở ngoài chuỗi), người dùng có thể sử dụng hợp đồng kho khóa của họ như một đị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, chúng thân thiện với phản 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 nào đó.

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 tới người dùng, điều này tương tự với 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 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 rõ ràng hoặc mã QR), người nhận có thể sử dụng liên kết đó để nhận thanh toán theo cách họ muốn.

Dù người gửi hay người nhận hành động trước, việc dựa nhiều hơn vào ví để tạo ra thông tin thanh toán mới nhất theo thời gian thực có thể giảm thiểu ma sát. Nói như vậy, các định danh bền vững là tiện lợi (đặc biệt là khi kết hợp với ENS), và trong thực tế, giả định về việc có 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ó khăn, vì vậy chúng ta có thể thấy sự kết hợp của các công nghệ khác nhau.

Trong tất cả các thiết kế này, việc giữ cho mọi thứ vừa phi tập trung vừa dễ hiểu đối với người dùng là rất quan trọng. Chúng ta cần đảm bảo rằng người dùng có thể dễ dàng truy cập vào cái nhìn mới nhất về tài sản hiện tại của họ, cũng như thông tin đã được công bố hướng tới họ. Những cái nhìn này nên dựa vào các công cụ mở, thay vì các giải pháp độc quyền. Tránh việc cơ sở hạ tầng thanh toán phức tạp trở thành một "tháp trừu tượng" không minh bạch mà các nhà phát triển khó hiểu những gì đang xảy ra và điều chỉnh nó cho môi trường mới sẽ cần phải làm việc chăm chỉ. Mặc dù đối mặt với những thách thức, nhưng việc đạt được khả năng mở rộng Ethereum, an toàn ví và quyền riêng tư cho người dùng thông thường là rất quan trọng. Đây không chỉ là về khả năng kỹ thuật, mà còn là về khả năng tiếp cận thực tế của người dùng thông thường. Chúng ta cần phải đối mặt với thách thức này.

Cảm ơn đặc biệt đến Dan Finlay, Karl Floersch, David Hoffman và đội ngũ Scroll và SoulWallet vì phản hồi, xem xét và đề xuất của họ.