Vitalik: Sự chuyển đổi cần thiết của Ethereum—mở rộng quy mô L2, bảo mật và quyền riêng tư của ví

Tiêu đề gốc: "Ba giao dịch"

Tác giả gốc: Vitalik Buterin

Biên soạn gốc: MarsBit

Khi Ethereum chuyển đổi từ một công nghệ thử nghiệm non trẻ sang một nhóm 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 cấp phép cho người dùng thông thường, nhóm công nghệ này cần phải trải qua ba giai đoạn thay đổi công nghệ chính. gần như cùng lúc:

Sự thay đổi quy mô L2 - mọi người đều chuyển sang mô hình cuộn

Bảo mật Ví Thay đổi - Mọi người đang chuyển sang ví hợp đồng thông minh

Thay đổi quyền riêng tư - Đảm bảo việc chuyển tiền được bảo vệ quyền riêng tư và đảm bảo rằng chúng đang được phát triển Tất cả các công cụ khác (khôi phục xã hội, nhận dạng , danh tiếng) bảo vệ quyền riêng tư

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

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

Vì những lý do trên, ba thay đổi này rất quan trọng. Nhưng chúng cũng đầy thách thức vì việc giải quyết chúng đòi hỏi sự phối hợp chặt chẽ. Không chỉ chức năng của giao thức cần được cải thiện mà trong một số trường hợp còn cần những thay đổi cơ bản trong 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ẽ thay đổi hoàn toàn mối quan hệ giữa người dùng và địa chỉ

Trong bản mở rộng L2 Trong trên thế giới, người dùng sẽ tồn tại ở nhiều L2. Bạn có phải là thành viên của exampleDAO, một tổ chức lạc quan không? Vậy là bạn đã có tài khoản trên Optimism! Bạn có giữ CDP trong hệ thống stablecoin của ZkSync không? Vậy là bạn đã có tài khoản trên ZkSync! Bạn đã bao giờ thử một số ứng dụng có trên Kakarot chưa? Vậy là bạn đã có 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 quan điểm của Brave Wallet. Đúng, 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!

Ví hợp đồng thông minh ngày càng phức tạp hơn, 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. 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ù 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ột mã băm tương đương trên các mạng, đặc biệt là các nhà máy đơn lẻ CREATE 2 và ERC-2470, nhưng rất khó đạt được đ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 và thường sử dụng Solidity hoặc cụm trung gian thay thế, do đó ngăn cả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, khả năng ví 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 loại địa chỉ mà chúng tôi xử lý. Nếu đề xuất địa chỉ bảo mật đượ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ỉ trên mỗi L2, thì có thể có một địa chỉ trên 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: nhiều người dùng lưu trữ tiền của họ trong cùng một hợp đồng thông minh (và do đó có cùng địa chỉ). Để gửi tiền cho một người dùng cụ thể, người dùng sẽ 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 có thể thấy, ba sự thay đổi này làm suy yếu mô hình tinh thần về "một người dùng ~= một địa chỉ" theo nhiều cách khác nhau và một số tác động này phản hồi lại thực hiện trong sự phức tạp của chuyển đổi. Hai vấn đề phức tạp cụ thể là:

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

2. 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, họ thực hiện việc thay thế khóa và khôi phục xã hội như thế nào?

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

Tôi có trên Scroll Coins, tôi muốn trả tiền cà phê (nếu "tôi" theo nghĩa đen, ám chỉ tác giả bài viết của tôi, thì "cà phê" tất nhiên là một ẩn dụ của "trà xanh"). Bạn đang bán cà phê cho tôi nhưng bạn chỉ sẵn sàng nhận xu trên Taiko. tôi làm gì?

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

1. Nhận ví (có thể là người bán, hoặc chỉ là Người bình thường cá nhân) cố gắng hỗ trợ mỗi L2 với một số chức năng tự động để hợp nhất tiền một cách không đồng bộ.

2. 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 chuyển tiền đến L2 đích thông qua một số loại 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, điều này có thể liên quan đến gửi trực tiếp (nếu họ may mắn) hoặc qua đường cầu ngang L2.

Nhưng đây chỉ là một ví dụ về thách thức chính do ca thứ ba đưa ra: Những 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 là chỉ một địa chỉ 20 byte . nhiều.

May mắn thay, việc chuyển sang ví hợp đồng thông minh không gây ảnh hưởng đến 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 hệ thống. 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 phần cuối nhận thanh toán của ví không chỉ theo dõi chuyển ETH từ EOA mà còn theo dõi ETH được gửi bởi mã hợp đồng thông minh . Các ứng dụng dựa trên giả định về quyền sở hữu địa chỉ bất biến (ví dụ: NFT cấm hợp đồng thông minh để thực thi 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 - cụ thể, nếu ai đó chỉ nhận được mã thông báo không phải ETH ERC 20, họ sẽ có thể sử dụng người thanh toán ERC-4337 để thanh toán phí 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 thách thức lớn mà chúng tôi vẫn 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 từ hệ thống. Sau 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ế, "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 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ể cách giải mã để giúp người nhận khám phá các khoản thanh toán.

Giao thức Địa chỉ Bảo mật dựa trên khái niệm siêu địa chỉ và cách thức hoạt động của nó là một phần của địa chỉ meta là phiên bản mù của địa chỉ meta. 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ể đặt cả hai khóa giống nhau).

Bài học quan trọng ở đây là trong hệ sinh thái tập trung vào quyền riêng tư, người dùng sẽ có cả khóa công khai chi tiêu và khóa công khai mã hóa, đồng thời "Thông tin thanh toán" của người dùng sẽ phải chứa cả hai khóa. Bên cạnh thanh toán, còn có một số 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 dự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 tôi có thể sử dụng lại 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 tôi 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 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à khóa PGP.

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

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

Chi phí gas không thực tế: Vấn đề này có thể tự giải thích được.

Địa chỉ giả: Địa chỉ có 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ó vô số địa chỉ giả thực: 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à một tập hợp vô hạn các địa chỉ giả thực hoàn toàn khác bắt nguồn từ sơ đồ địa chỉ ẩn.

Quyền riêng tư: Nếu người dùng cố tình có nhiều địa chỉ để tránh liên kết chúng với nhau, họ chắc chắn không muốn công khai liên kết bằng cách khôi phục chúng cùng một lúc hoặc cùng thời điểm Tất cả các địa chỉ!

Giải quyết những vấn đề này rất 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 thực 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 cho mỗi địa chỉ là một con trỏ tới hợp đồng kho khóa. Việc chi tiêu từ các địa chỉ này sẽ yêu cầu bằng chứng nhập 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à gần đây nhất).

Có thể đạt được bằng chứng bằng nhiều cách:

1. 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ực tiếp trạng thái L1. Nếu hợp đồng kho khóa nằm trên L1, điều này có nghĩa là các hợp đồng trong L2 có thể truy cập kho khóa "miễn phí".

2. 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 của bằng chứng: 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 do cây Verkle.

3. 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ác kỹ thuật tổng hợp ngoài chuỗi có thể được xây dựng (ví dụ: dựa 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.

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

Nếu muốn tránh phải tạo bằng chứng cho mọi giao dịch, chúng tôi có thể triển khai một giải pháp nhẹ nhàng hơn chỉ yêu cầu bằng chứng liê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 khóa chi tiêu có khóa chung 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 sẽ an toàn ngay cả khi khóa cũ của bạn không: "Kích hoạt" địa chỉ phản thực và 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 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 ta chỉ cần mã hóa con trỏ và sau đó thực hiện tất cả các bằng chứng trong ZK-SNARK:

Thông qua 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 ta cũng có thể loại bỏ phần lớn sự phức tạp của ZK-SNARK và tạo một sơ đồ dựa trên KZG đơn giản hơn.

Những tình huống này có thể trở nên phức tạp. Tuy nhiên, có rất nhiều sự phối hợp tiềm năng giữa các lựa chọn này. 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 "địa chỉ" được đề cập ở 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 có thể đưa đị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.

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. Hôm nay, tháng 6 năm 2023, tình hình không quá tệ: phí giao dịch tuy cao nhưng vẫn có thể so sánh với phí miền ENS. Việc đăng ký zuzalu.eth khiến tôi mất khoảng $ 27 , trong đó $ 11 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í giao dịch đăng ký tên miền lên 104 USD. 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 ENS Runs trên L2.

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

Việc lấy bằng chứng thực tế liên quan đến việc truy cập vào một loạt URL được lưu trữ trong hợp đồng, phải thừa nhận là có vẻ 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 trong N (bằng chứng không hợp lệ. Nó sẽ được logic xác minh nắm bắt trong chức năng gọi lại của hợp đồng CCIP. Miễn là có 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 ví dụ thành công và 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à 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), việc này rất đơn giản. ERC-1271 cung cấp một cách tiêu chuẩn hóa cho ví hợp đồng thông minh để đạt được điều này. Tuy nhiên, nhiều dapp vẫn không hỗ trợ ERC-1271 và họ cần được hỗ trợ.

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 việc chuyển tiền hoặc thực thi tiền bản quyền) sẽ bị hỏng. 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 chuyển giao quyền kiểm soát mật mã cụ thể có phải là một chuyển giao có lợi hay không là một vấn đề khó có thể giải quyết được nếu không sử dụng một số cơ chế do cộng đồng điều khiển ngoài chuỗi. Giải quyết dưới đây. Rất có thể, các ứng dụng sẽ phải ít phụ thuộc hơn vào việc chặn chuyển khoản mà 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ẽ cần 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: việc ký một nonce tiêu chuẩn (ví dụ: hàm băm của tên ứng dụng) bằng cách sử dụng khóa riêng của EOA sẽ tạo ra một khóa không thể được tạo nếu không có giá trị xác định, do đó, nó. là an toàn về mặt kỹ thuật. Tuy nhiên, những công nghệ này "không rõ ràng" đối với ví, ngăn cả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 xử lý rõ ràng hơn bằng ví.

Các khách hàng hạng nhẹ (chẳng hạn như Helios) sẽ phải xác minh L2, 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 thực các trạng thái L1 cũng như các nhánh Merkle của các giao dịch bắt nguồn từ các 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 có nguồn gốc từ gốc trạng thái được lưu trữ trong L1 (phiên bản nâng cao hơn này sẽ thực sự xem xét các xác nhận trước L2).

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

Bây giờ, hoạt động kinh doanh 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 đang bảo vệ những tài sản đó. Nếu bạn thay đổi khóa của mình, 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 không có bằng chứng kiến thức nào, đ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 bảo vệ 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 ở 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ó 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 để thực hiện các bằng chứng cơ bản như "chứng minh tôi là cư dân của Zuzalu, nhưng không tiết lộ cái 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à Stamps (phiên bản POAP của Zupass).

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

Tính năng chính mà Tem cung cấp qua POAP là Tem có tính riêng tư: bạn giữ dữ liệu cục bộ và chỉ có dữ liệu đó khi bạn muốn, bạn sẽ chứng minh được. con tem (hoặc một số phép tính trên con tem) đối với họ. Nhưng điều này đặt ra nguy cơ: nếu bạn làm mất thông tin này, bạn sẽ mất tem.

Tất nhiên, vấn đề lưu giữ dữ liệu chủ yếu là vấn đề giữ khóa mã hóa: bên thứ ba (thậm chí một chuỗi) có thể giữ bản sao được mã hóa của dữ liệu . Đ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, do đó không cần bất kỳ tương tác nào với hệ thống giữ an toàn cho khóa mã hóa của bạn. Nhưng ngay cả như vậy, nếu bạn 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) khi họ bị mất chúng đồng thời. Tỷ lệ rất nhỏ đối với tất cả các thiết bị . Chúng ta có thể tiến thêm một bước nữa và sử dụng tính năng chia sẻ bí mật để lưu trữ khóa, chia chúng cho nhiều người giữ.

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

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

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

Chủ đề chung trong số những thay đổi này là bạn đang ở trên chuỗi Khái niệm về một "địa chỉ" được sử dụng để đại diện cho mã định danh mật mã của "bạn" phải trải qua một sự thay đổi căn bản. "Hướng dẫn cách tương tác với tôi" không còn chỉ là địa chỉ ETH nữa; chúng phải là sự kết hợp của nhiều địa chỉ trên nhiều L2, địa chỉ meta ẩn, khóa mã hóa và dữ liệu khác ở một số dạng.

Một cách để thực hiện việc này là đặt ENS làm danh tính của bạn: bản ghi ENS của bạn có thể chứa tất cả thông tin 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à hiểu 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.

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ó 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 chỉ là một trong nhiều thuộ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 nhiều bản ghi trong nhiều ứng dụng.

Bạn không thể có những cái tên phản thực nếu không có sự tin tưởng. 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 vấn đề nan giải: tương tác với chuỗi yêu cầu phải trả phí giao dịch và việc trả phí đòi hỏi...đã 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 hai Bob quyết định ngoài chuỗi rằng họ là bob.ecc.eth thì không có cách nào để chọn ai nhận được tên đó.

Một giải pháp khả thi là đưa thêm nội dung vào hợp đồng kho khóa được đề cập trong kiến trúc trước đó trong bài viết này. Hợp đồng kho khóa có thể chứa tất cả các loại thông tin về bạn và cách tương tác với bạn (thông qua CCIP, một số thông tin này 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 mã định danh chính. Nhưng tài sản thực tế 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 thực tế: bạn có thể tạo một địa chỉ chỉ có thể được khởi tạo bằng hợp đồng kho khóa với một số 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ỏ khái niệm địa chỉ hướng đến người dùng, có 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 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.

Dựa nhiều hơn vào việc các 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ể giảm bớt xung đột, cho dù người gửi hay người nhận thực hiện hành động trước. Phải nói rằng, số nhận dạng liên tục rất thuận tiện (đặc biệt với ENS) và trong thực tế, giả định liên lạc trực tiếp giữa người gửi và người nhận là một vấn đề rất phức tạp, vì vậy chúng ta 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à phải đảm bảo mọi thứ vừa được phân quyền 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 về tài sản hiện tại của họ cũng như thông tin đã được xuất bản 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. Việc tránh cơ sở hạ tầng thanh toán phức tạp hơn trở thành một "tháp trừu tượng" mờ đục khiến các nhà phát triển khó hiểu những gì đang diễn ra và thích ứng với môi trường mới sẽ đòi hỏi phải làm việc chăm chỉ. 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ư của Ethereum cho người dùng bình thường là rất quan trọng. Đó không chỉ là tính khả thi về mặt kỹ thuật mà còn là khả năng tiếp cận thực tế cho người dùng bình thường. Chúng ta cần phải đáp ứng thách thức này.

Đặ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 của họ.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia