Trải nghiệm người dùng của giao dịch chéo L2

Bây giờ có một lộ trình ngày càng chi tiết để cải thiện trải nghiệm người dùng chuyển đổi L2, bao gồm một phần ngắn hạn và một phần dài hạn. Ở đây, tôi sẽ nói về phần ngắn hạn: những ý tưởng mà lý thuyết có thể thực hiện ngay hôm nay.

Ý tưởng cốt lõi là (i) gửi chéo L2 tích hợp và (ii) địa chỉ và yêu cầu thanh toán cụ thể theo chuỗi. Ví của bạn sẽ có thể cung cấp cho bạn một địa chỉ (theo kiểu phiên bản thảo luận ERC này) trông như thế này:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

Khi ai đó (hoặc một ứng dụng nào đó) cung cấp cho bạn một địa chỉ với định dạng này, bạn nên có thể dán nó vào trường “đến” của ví và nhấn “gửi”. Ví sẽ tự động xử lý việc gửi đó bằng bất kỳ cách nào mà nó có thể:

• Nếu bạn đã có đủ số lượng đồng xu cần thiết trên chuỗi đích, hãy gửi đồng xu trực tiếp
• Nếu bạn có đồng coin loại cần thiết trên một chuỗi khác (hoặc nhiều chuỗi khác), hãy sử dụng giao thức như ERC-7683(hiệu quả là một sàn giao dịch cross-chain) để gửi các đồng tiền
• Nếu bạn có đồng coin loại khác trên cùng hoặc trên các chuỗi khác, hãy sử dụng các sàn giao dịch phi tập trung để chuyển đổi chúng thành loại coin đúng trên chuỗi đúng và gửi chúng. Điều này yêu cầu sự cho phép rõ ràng từ người dùng: người dùng sẽ thấy mình đang trả bao nhiêu đồng coin và người nhận sẽ nhận được bao nhiêu đồng coin.

Mô phỏng giao diện ví tiềm năng với hỗ trợ địa chỉ xuyên chuỗi

Trên đây là cho “bạn sao chép-dán địa chỉ (hoặc ENS, ví dụ,vitalik.eth@optimism.eth) để ai đó trả tiền cho bạn” trường hợp sử dụng. Nếu một dapp đang yêu cầu một khoản tiền gửi (ví dụ: xem ví dụ Polymarket này) sau đó, quy trình lý tưởng là mở rộng API web3 và cho phép dapp tạo yêu cầu thanh toán cụ thể cho chuỗi. Ví của bạn sau đó sẽ có thể đáp ứng yêu cầu đó bằng bất kỳ cách nào mà nó cần. Để mang lại trải nghiệm người dùng tốt, cũng cần chuẩn hóa yêu cầu getAvailableBalance và ví cần phải suy nghĩ kỹ về chuỗi mà họ lưu trữ tài sản của người dùng mặc định để tối đa hóa bảo mật và dễ dàng chuyển giao.

Yêu cầu thanh toán cụ thể cho mỗi chuỗi cũng có thể được đưa vào mã QR, mà các ví di động có thể quét. Trong kịch bản thanh toán tiêu dùng trực tiếp (hoặc trực tuyến), người nhận sẽ tạo mã QR hoặc gọi API web3 nói rằng “Tôi muốn X đơn vị token Y trên chuỗi Z, với ID tham chiếu hoặc gọi lại W”, và ví sẽ tự do thỏa mãn yêu cầu đó bằng bất kỳ cách nào mà nó có thể. Tùy chọn khác là giao thức liên kết yêu cầu, trong đó ví của người dùng tạo ra mã QR hoặc URL chứa một ủy quyền để yêu cầu một số tiền nhất định từ hợp đồng onchain của họ, và việc của người nhận là phải tìm cách di chuyển các quỹ đó đến ví của họ.

Một chủ đề liên quan khác là thanh toán gas. Nếu bạn nhận được tài sản trên một L2 mà bạn chưa có ETH, và bạn cần gửi một giao dịch trên L2 đó, một ví tiền nên tự động sử dụng một giao thức (ví dụ RIP-7755) để thanh toán phí gas trên một chuỗi nơi bạn có ETH. Nếu ví mong đợi bạn thực hiện nhiều giao dịch hơn trên L2 trong tương lai, nó cũng nên chỉ cần sử dụng một DEX để gửi, ví dụ, một vài triệu gas trị giá ETH, để các giao dịch tương lai có thể tiêu gas trực tiếp tại đó (vì điều này rẻ hơn).

Bảo mật tài khoản

Một cách mà tôi hiểu về thách thức bảo mật tài khoản là một chiếc ví tốt nên đồng thời tốt ở hai lĩnh vực: (i) bảo vệ người dùng khỏi việc nhà phát triển ví bị hack hoặc độc hại, và (ii) bảo vệ người dùng khỏi những sai lầm của chính họ.

Lỗi chính tả “mistakles” bên trái không cố ý. Tuy nhiên, khi nhìn thấy nó, tôi nhận ra rằng nó hoàn toàn phù hợp với ngữ cảnh, vì vậy tôi quyết định giữ lại nó.

Giải pháp ưa thích của tôi cho điều này, choqua mười nămđã được phục hồi xã hội và ví đa chữ ký, với kiểm soát truy cập được xếp hạng. Tài khoản của người dùng có hai lớp khóa: một khóa chính và N người bảo vệ (ví dụ: N = 5). Khóa chính có thể thực hiện các hoạt động có giá trị thấp và không liên quan đến tài chính. Yêu cầu đa số người bảo vệ thực hiện (i) các hoạt động có giá trị cao, như gửi đi toàn bộ giá trị trong tài khoản, hoặc (ii) thay đổi khóa chính hoặc bất kỳ người bảo vệ nào. Nếu muốn, khóa chính có thể được phép thực hiện các hoạt động có giá trị cao với một khóa thời gian.

Trên là một thiết kế cơ bản và có thể được mở rộng. Các khóa phiên và cơ chế quyền nhưERC-7715có thể giúp hỗ trợ các số dư khác nhau giữa tiện lợi và an ninh cho các ứng dụng khác nhau. Kiến trúc bảo vệ phức tạp hơn, chẳng hạn như có nhiều khoảng thời gian khóa thời gian ở ngưỡng khác nhau, có thể giúp tối đa hóa cơ hội phục hồi tài khoản hợp lệ thành công trong khi giảm thiểu rủi ro mất trộm.

Người hoặc vật gì nên là những người bảo vệ?

Đối với người dùng tiền điện tử có kinh nghiệm trong cộng đồng người dùng tiền điện tử có kinh nghiệm, một lựa chọn khả thi là các khóa của bạn bè và gia đình. Nếu bạn yêu cầu mỗi người cung cấp cho bạn một địa chỉ mới, thì không ai cần phải biết họ là ai - thực tế, người bảo vệ của bạn thậm chí không cần phải biết họ là ai. Khả năng họ sẽ xảy ra âm mưu mà không có một người trong số họ tiết lộ cho bạn là rất nhỏ. Tuy nhiên, đối với hầu hết người dùng mới, lựa chọn này không khả dụng.

Lựa chọn thứ hai là người giám hộ tổ chức: các công ty chuyên thực hiện dịch vụ chỉ ký giao dịch nếu họ nhận được một số xác nhận khác rằng yêu cầu đến từ bạn: ví dụ: mã xác nhận hoặc cuộc gọi video đối với người dùng có giá trị cao. Mọi người đã cố gắng để làm cho những điều này trong một thời gian dài, ví dụ:. Tôi đã viết hồ sơ về CryptoCorp vào năm 2013. Tuy nhiên, cho đến nay các công ty như vậy đã không thành công lắm.

Một lựa chọn thứ ba là sử dụng nhiều thiết bị cá nhân (ví dụ: điện thoại, máy tính để bàn, ví cứng). Điều này có thể hoạt động, nhưng cũng khá khó để cài đặt và quản lý đối với người dùng không có kinh nghiệm. Có cũng có nguy cơ thiết bị bị mất hoặc bị đánh cắp cùng một lúc, đặc biệt nếu chúng ở cùng một địa điểm.

Gần đây, chúng tôi đã bắt đầu thấy nhiều ví dựa trên passkey. Passkey có thể được sao lưu trên thiết bị của bạn, tạo thành một loại giải pháp cá nhân hoặc được sao lưu trên đám mây, làm tăng tính bảo mật của chúng phụ thuộc vàophức tạp hybridvề an ninh mật khẩu, giả định phần cứng cơ sở và đáng tin cậy. Một cách thực tế, passkeys là một lợi ích an ninh quý báu đối với người dùng thông thường, nhưng chúng không đủ mạnh mẽ một mình để bảo vệ toàn bộ tiền tiết kiệm của người dùng.

May mắn thay, với ZK-SNARKs, chúng ta có một lựa chọn thứ tư: ZK-wrapped centralized ID. Thể loại này bao gồm zk-email, Anon Aadhaar, Ví Myna, và nhiều hơn nữa. Cơ bản, bạn có thể chuyển đổi nhiều hình thức của ID tập trung (doanh nghiệp hoặc chính phủ) và biến nó thành địa chỉ Ethereum, từ đó bạn chỉ có thể thực hiện giao dịch bằng cách tạo ra một chứng minh ZK-SNARK về việc sở hữu ID tập trung.

Với sự bổ sung này, giờ đây chúng tôi có một loạt các tùy chọn và ID tập trung được bọc ZK là duy nhất “thân thiện với noob”.

Để công việc này hoạt động, nó cần được triển khai với giao diện người dùng được tinh chỉnh và tích hợp: bạn chỉ cần chỉ định rằng bạn muốn “gate”example@gmail.comLà một người bảo vệ, nó nên tự động tạo địa chỉ Ethereum zk-email tương ứng dưới nắp động cơ. Người dùng nâng cao nên có thể nhập địa chỉ email của họ (cùng với một giá trị muối có thể được lưu trữ trong email đó để bảo mật), vào một ứng dụng bên thứ ba mã nguồn mở và xác nhận rằng địa chỉ được tạo ra là đúng. Điều này cũng đúng đối với bất kỳ loại người bảo vệ nào khác được hỗ trợ.

Bản vẽ mẫu giao diện An toàn có thể có

Lưu ý rằng ngày nay, một thách thức thực tế với zk-email cụ thể là nó phụ thuộc vào Chữ ký DKIM, sử dụng các khóa được xoay một lần sau mỗi vài tháng, và các khóa này không được ký bởi bất kỳ cơ quan nào khác. Điều này có nghĩa là zk-email hiện nay đòi hỏi một mức độ tin cậy ngoài nhà cung cấp; điều này có thể giảm đi nếu zk-email sử dụng TLSNotarytrong phần cứng đáng tin cậy để xác minh các khóa được cập nhật, nhưng đó không phải là lựa chọn lý tưởng. Hy vọng rằng các nhà cung cấp email sẽ bắt đầu ký xác nhận trực tiếp cho các khóa DKIM của họ. Hôm nay, tôi khuyến nghị sử dụng zk-email cho một người bảo vệ, nhưng không phải cho phần lớn người bảo vệ của bạn: đừng lưu trữ tiền trong một cài đặt mà việc zk-email bị vỡ có nghĩa là bạn mất quyền truy cập vào tài khoản của bạn.

Người dùng mới và ví trong ứng dụng

Người dùng mới thực tế không muốn phải nhập một số lượng lớn các người bảo vệ trong trải nghiệm đăng ký đầu tiên của họ. Do đó, ví nên cung cấp cho họ một tùy chọn rất đơn giản. Một tuyến đường tự nhiên là 2 trên 3 sử dụng zk-email trên địa chỉ email của họ, một khóa được lưu trữ cục bộ trên thiết bị của người dùng (có thể là một mã khóa), và một khóa sao lưu được giữ bởi nhà cung cấp. Khi người dùng trở nên thành thạo hơn hoặc tích lũy thêm tài sản, tại một số điểm, họ nên được nhắc nhở để thêm nhiều người bảo vệ hơn.

Ví được tích hợp trong các ứng dụng là không thể tránh khỏi, bởi vì các ứng dụng cố gắng thu hút người dùng không phải tiền điện tử không muốn trải nghiệm người dùng khó hiểu khi yêu cầu người dùng của họ tải xuống hai ứng dụng mới (bản thân ứng dụng, cộng với ví Ethereum) cùng một lúc. Tuy nhiên, người dùng nhiều ví ứng dụng sẽ có thể liên kết tất cả các ví của họ với nhau, do đó họ chỉ có một “điều kiểm soát truy cập” phải lo lắng. Cách đơn giản nhất để làm điều này là sơ đồ phân cấp, trong đó có quy trình “liên kết” nhanh chóng cho phép người dùng đặt ví chính của họ làm người bảo vệ tất cả các ví trong ứng dụng của họ. Máy khách Farcaster Warpcast đã hỗ trợ điều này:

Theo mặc định, việc khôi phục tài khoản của bạn trên Warpcast được kiểm soát bởi nhóm Warpcast. Tuy nhiên, bạn có thể “độc lập quyền chủ quyền” tài khoản Farcaster của mình và thay đổi việc khôi phục thành địa chỉ của riêng bạn.

Bảo vệ người dùng khỏi lừa đảo và các mối đe dọa bên ngoài khác

Ngoài bảo mật tài khoản, ví ngày nay còn làm rất nhiều để xác định địa chỉ giả mạo, lừa đảo, lừa đảo và các mối đe dọa bên ngoài khác và cố gắng bảo vệ người dùng của họ khỏi các mối đe dọa như vậy. Đồng thời, nhiều biện pháp đối phó vẫn còn khá sơ khai: ví dụ: yêu cầu nhấp chuột để gửi ETH hoặc các mã thông báo khác đến bất kỳ địa chỉ mới nào, bất kể bạn đang gửi 100 đô la hay 100.000 đô la. Ở đây, không có giải pháp viên đạn ma thuật duy nhất; Đó là một loạt các bản sửa lỗi và cải tiến chậm liên tục đối với các loại mối đe dọa khác nhau. Tuy nhiên, có rất nhiều giá trị trong việc tiếp tục làm công việc khó khăn để cải thiện ở đây.

Sự riêng tư

Bây giờ là lúc để bắt đầu coi trọng quyền riêng tư trên Ethereum hơn. Công nghệ ZK-SNARK hiện đã rất tiên tiến, các công nghệ bảo vệ quyền riêng tư giảm thiểu các rủi ro quy định mà không phụ thuộc vào cửa sau, như Bể Riêng Tư, đang trưởng thành hơn và cơ sở hạ tầng phụ trợ như Wakuvà ERC-4337 mempools đang dần trở nên ổn định hơn. Tuy nhiên, cho đến nay, việc thực hiện các giao dịch riêng tư trên Ethereum đã yêu cầu người dùng tải xuống và sử dụng một “ví được bảo mật”, như gate ví, một cách rõ ràng.Đường sắt(hoặcUmbrachođịa chỉ ẩn danh). Điều này gây rất nhiều bất tiện và giảm số người sẵn sàng thực hiện các giao dịch chuyển tiền riêng tư. Giải pháp là tích hợp các giao dịch chuyển tiền riêng tư trực tiếp vào các ví tiền.

Một cách triển khai đơn giản như sau. Một ví có thể lưu trữ một phần của tài sản của người dùng dưới dạng “số dư riêng tư” trong một hồ bơi bảo mật. Khi người dùng thực hiện một giao dịch, nó sẽ tự động rút tiền từ hồ bơi bảo mật trước. Nếu người dùng cần nhận tiền, ví có thể tự động tạo ra một địa chỉ ẩn.

Ngoài ra, một ví có thể tự động tạo ra một địa chỉ mới cho mỗi ứng dụng mà người dùng tham gia (ví dụ: một giao protocal defi). Tiền gửi sẽ đến từ hồ bảo mật và rút tiền sẽ đi thẳng vào hồ bảo mật. Điều này cho phép hoạt động của người dùng trong bất kỳ ứng dụng nào không liên kết với hoạt động của họ trong các ứng dụng khác.

Một ưu điểm của kỹ thuật này là nó là một con đường tự nhiên không chỉ để chuyển tài sản bảo vệ quyền riêng tư, mà còn bảo vệ quyền riêng tư của người dùng. Danh tính đã xảy ra trên chuỗi khối: bất kỳ ứng dụng nào sử dụng cổng kiểm chứng người (ví dụ: Gitcoin Grants), bất kỳ cuộc trò chuyện dựa trên token nào, Ethereum Theo Giao Thức, và nhiều hơn nữa là tất cả các danh tính onchain. Chúng tôi muốn hệ sinh thái này cũng được bảo vệ quyền riêng tư. Điều này có nghĩa là hoạt động onchain của người dùng không nên được thu thập ở một nơi: mỗi mục nên được lưu trữ riêng biệt và ví của người dùng phải là thứ duy nhất có “chế độ xem toàn cầu” nhìn thấy tất cả các chứng thực của bạn cùng một lúc. Một hệ sinh thái nhiều tài khoản cho mỗi người dùng giúp thực hiện điều này, cũng như các giao thức chứng thực offchain như EASvàZupass.

Điều này đại diện cho một tầm nhìn thực tế về quyền riêng tư Ethereum trong tương lai trung hạn. Nó có thể được triển khai ngay hôm nay, mặc dù có những tính năng có thể được giới thiệu tại L1 và L2 để làm cho việc chuyển tiền bảo vệ quyền riêng tư hiệu quả và đáng tin cậy hơn. Một số người ủng hộ quyền riêng tư cho rằng điều duy nhất chấp nhận được là quyền riêng tư hoàn toàn về mọi thứ: mã hóa toàn bộ EVM. Tôi sẽ đề xuất rằng điều này có thể là lý tưởng như một kết quả dài hạn, nhưng nó đòi hỏi một sự suy nghĩ cơ bản hơn về mô hình lập trình và hiện tại nó chưa đạt đến mức độ trưởng thành để sẵn sàng và triển khai trên Ethereum. Chúng ta cần quyền riêng tư mặc định để có được tập hợp nặc danh đủ lớn. Tuy nhiên, tập trung vào việc làm cho (i) việc chuyển tiền giữa các tài khoản và (ii) nhận dạng và các trường hợp sử dụng liên quan đến nhận dạng như chứng thực trở nên riêng tư là một bước tiến thực tế đầu tiên mà dễ dàng triển khai hơn và các ví tiền điện tử có thể bắt đầu ngay hôm nay.

Ví Ethereum cũng cần trở thành ví dữ liệu

Một hệ quả của bất kỳ giải pháp bảo mật hiệu quả nào, cho dù là thanh toán hay nhận dạng hoặc các trường hợp sử dụng khác, là nó tạo ra nhu cầu cho người dùng lưu trữ dữ liệu offchain. Điều này là hiển nhiên trong Tornado Cash, yêu cầu người dùng lưu từng “ghi chú” riêng lẻ đại diện cho khoản tiền gửi 0,1-100 ETH. Các giao thức bảo mật hiện đại hơn đôi khi lưu dữ liệu được mã hóa trên chuỗi và sử dụng một khóa riêng duy nhất để giải mã nó. Điều này là rủi ro, bởi vì nếu khóa bị rò rỉ, hoặc nếu máy tính lượng tử trở nên khả thi, tất cả dữ liệu sẽ trở nên công khai. Các chứng nhận offchain như EAS và Zupass có nhu cầu rõ ràng hơn về lưu trữ dữ liệu offchain.

Ví tiền cần trở thành không chỉ là phần mềm để lưu trữ quyền truy cập onchain, mà còn là phần mềm để lưu trữ dữ liệu riêng của bạn. Điều này là điều mà thế giới phi tiền điện tử ngày càng nhận ra, ví dụ như xem Tim Berners-Lee’s công việc gần đây trong các cửa hàng dữ liệu cá nhân. Tất cả những vấn đề mà chúng ta cần phải giải quyết xung quanh việc đảm bảo kiểm soát mạnh mẽ về quyền truy cập, chúng ta cũng cần phải giải quyết mạnh mẽ về việc đảm bảo tính sẵn có và không rò rỉ dữ liệu. Có lẽ các giải pháp có thể được đặt lên cùng nhau: nếu bạn có N người bảo vệ, hãy sử dụng chia sẻ bí mật M-trong-N giữa những người bảo vệ cùng để lưu trữ dữ liệu của bạn. Dữ liệu inherently khó để bảo mật, vì bạn không thể thu hồi phần của người nào đó, nhưng chúng ta nên đưa ra các giải pháp sở hữu phân tán mà an toàn nhất có thể.

Truy cập chuỗi an toàn

Ngày nay, ví tin tưởng các nhà cung cấp RPC của họ để cho họ biết bất kỳ thông tin nào về chuỗi. Đây là một lỗ hổng theo hai cách:

1. Nhà cung cấp RPC có thể cố gắng lấy cắp tiền bằng cách cung cấp cho họ thông tin sai lệch, ví dụ như về giá cả thị trường.
2. Nhà cung cấp RPC có thể trích xuất thông tin riêng về các ứng dụng và tài khoản khác mà người dùng tương tác

Lý tưởng nhất, chúng tôi muốn tắt cả hai lỗ này. Để tắt lỗ thứ nhất, chúng ta cần có khách hàng nhỏ chuẩn hóa cho L1 và L2s, trực tiếp xác minh sự nhất quán của blockchain.Heliosđã làm điều này cho L1, và đã thực hiện một số công việc sơ bộ để hỗ trợ một số L2 cụ thể. Để đảm bảo bao phủ đúng tất cả L2, điều chúng ta cần là một tiêu chuẩn mà theo đó một hợp đồng cấu hình đại diện cho một L2 (cũng được sử dụng cho địa chỉ cụ thể của chuỗi) có thể khai báo một hàm, có lẽ theo một cách tương tự như ERC-3668, chứa logic để có được các gốc trạng thái gần đây, và xác minh bằng chứng của trạng thái và biên lai so với các gốc trạng thái đó. Điều này giúp chúng ta có thể có một light client phổ quát, cho phép ví điện tử xác minh một cách an toàn bất kỳ trạng thái hoặc sự kiện nào trên L1 và L2.

Đối với quyền riêng tư, hiện nay cách tiếp cận duy nhất là chạy nút đầy đủ của riêng bạn. Tuy nhiên, bây giờ khi L2s đang xuất hiện, việc chạy một nút đầy đủ cho tất cả mọi thứ ngày càng khó khăn hơn. Tương đương của một khách hàng nhẹ ở đây là tìm kiếm thông tin riêng tư (PIR). PIR liên quan đến một máy chủ lưu trữ một bản sao của tất cả dữ liệu và một khách hàng gửi yêu cầu được mã hóa đến máy chủ. Máy chủ thực hiện một phép tính trên tất cả dữ liệu, trả về dữ liệu mong muốn của khách hàng, được mã hóa theo khóa của khách hàng, mà không tiết lộ cho máy chủ biết khách hàng đã truy cập vào mảnh dữ liệu nào.

Để duy trì tính trung thực của máy chủ, các mục cơ sở dữ liệu cá nhân sẽ là những nhánh Merkle, để khách hàng có thể xác minh chúng bằng cách sử dụng máy khách nhẹ của họ.

PIR rất tốn xử lý tính toán. Có một số cách để giải quyết vấn đề này:

• Brute force: cải tiến trong thuật toán, hoặc phần cứng chuyên biệt, có thể làm cho PIR nhanh đủ để chạy. Các kỹ thuật này có thể phụ thuộc vào tiền xử lý: máy chủ có thể lưu trữ dữ liệu được mã hóa và xáo trộn cho mỗi khách hàng, và khách hàng có thể truy vấn dữ liệu đó. Thách thức chính trong bối cảnh Ethereum là điều chỉnh các kỹ thuật này cho các bộ dữ liệu thay đổi nhanh chóng (như trạng thái làm). Điều này làm cho chi phí tính toán thời gian thực thấp hơn, nhưng có thể làm tăng tổng chi phí tính toán và lưu trữ.
• Giảm yêu cầu về quyền riêng tư: ví dụ, mỗi lần tìm kiếm chỉ có thể có 1 triệu ‘mixins’, vì vậy máy chủ sẽ biết được một triệu giá trị có thể mà khách hàng đã truy cập, nhưng không có bất kỳ độ chi tiết nào hơn.
• Đa máy chủ PIR: Các thuật toán PIR thường nhanh hơn nhiều nếu bạn sử dụng nhiều máy chủ với giả định trung thực 1 trong N giữa các máy chủ đó.
• Ẩn danh thay vì bảo mật: thay vì ẩn nội dung của yêu cầu, yêu cầu có thể được gửi qua một mixnet, ẩn người gửi yêu cầu. Tuy nhiên, làm điều này một cách hiệu quả chắc chắn sẽ làm tăng độ trễ, làm xấu đi trải nghiệm người dùng.

Tìm ra sự kết hợp phù hợp của các kỹ thuật để tối đa hóa quyền riêng tư trong khi vẫn duy trì tính thực tế trong ngữ cảnh Ethereum là một vấn đề nghiên cứu mở, và tôi hoan nghênh các nhà mật mã thử sức của họ.

Ví lưu trữ lý tưởng

Ngoài việc chuyển khoản và truy cập trạng thái, một quy trình làm việc quan trọng khác cần phải hoạt động một cách mượt mà trong ngữ cảnh chéo L2 là thay đổi cấu hình xác thực của một tài khoản: có thay đổi các khóa (ví dụ: khôi phục), hoặc thay đổi sâu hơn cho toàn bộ logic của tài khoản. Ở đây, có ba tầng giải pháp, theo thứ tự tăng dần về độ khó:

1. Cập nhật đã phát lại: khi người dùng thay đổi cấu hình của họ, một tin nhắn cho phép thay đổi này được phát lại trên mỗi chuỗi nơi ví phát hiện ra rằng người dùng có tài sản. Có thể, định dạng tin nhắn và quy tắc xác thực có thể trở nên độc lập với chuỗi, để có thể phát lại tự động trên nhiều chuỗi nhất có thể.
2. Keystores trên L1: thông tin cấu hình sống trên L1, và ví trên L2 đọc nó với mộtL1SLOADhoặcREMOTESTATICCALL. Bằng cách này, việc cập nhật cấu hình chỉ cần thực hiện trên L1 và cấu hình sẽ tự động có hiệu lực.
3. Cửa hàng khóa trên L2: thông tin cấu hình nằm trên L2 và ví trên L2 đọc nó bằng ZK-SNARK. Điều này cũng giống như (2), ngoại trừ các bản cập nhật kho khóa có thể rẻ hơn, mặc dù mặt khác các bài đọc đắt hơn.

Giải pháp (3) đặc biệt mạnh mẽ vì nó kết hợp tốt với sự riêng tư. Trong một “giải pháp về sự riêng tư” bình thường, người dùng có một bí mật s, một “giá trị lá” L được xuất bản trên chuỗi, và người dùng chứng minh rằng L = hash(s, 1) và N = hash(s, 2) cho một số (không bao giờ tiết lộ) bí mật mà họ kiểm soát. Nullifier N được xuất bản, đảm bảo rằng các giao dịch tiêu tiền tương tự sẽ thất bại trong tương lai, mà không bao giờ tiết lộ L. Điều này phụ thuộc vào việc người dùng bảo quản s cẩn thận. Một giải pháp về sự riêng tư thân thiện với việc phục hồi thay vì thế nói: s là một vị trí (ví dụ như địa chỉ và khe lưu trữ) trên chuỗi, và người dùng phải chứng minh một truy vấn trạng thái: L = hash(sload(s), 1) .

Bảo mật Dapp

Điểm yếu trong bảo mật của người dùng thường là dapp. Hầu hết thời gian, người dùng tương tác với ứng dụng bằng cách truy cập vào một trang web, mà ngầm tải mã giao diện người dùng từ máy chủ và thực thi nó trong trình duyệt. Nếu máy chủ bị hack, hoặc nếu DNS bị hack, người dùng sẽ nhận được một bản sao giả của giao diện, có thể đánh lừa người dùng làm bất kỳ điều gì. Các tính năng ví như mô phỏng giao dịch rất hữu ích trong việc giảm thiểu các rủi ro, nhưng chúng còn rất xa hoàn hảo.

Lý tưởng nhất, chúng ta sẽ chuyển hệ sinh thái sang phiên bản nội dung trên chuỗi: người dùng sẽ truy cập một ứng dụng phi tập trung thông qua tên ENS của nó, mà sẽ chứa băm IPFS của giao diện. Một giao dịch trên chuỗi từ ví đa chữ ký hoặc DAO sẽ cần thiết để cập nhật giao diện. Ví cũng sẽ hiển thị cho người dùng nếu họ đang tương tác với một giao diện trên chuỗi an toàn hơn, hoặc một giao diện web2 không an toàn hơn. Ví cũng có thể hiển thị cho người dùng nếu họ đang tương tác với một chuỗi an toàn (ví dụ: giai đoạn 1+, kiểm tra bảo mật nhiều lần).

Đối với người dùng quan tâm đến quyền riêng tư, các ví cũng có thể thêm chế độ siêu nhạy, yêu cầu người dùng nhấp vào chấp nhận các yêu cầu HTTP, không chỉ là các thao tác web3:

Bản vẽ mô phỏng giao diện có thể cho chế độ hoang tưởng

Một phương pháp tiến tiếp hơn là di chuyển ngoài HTML + Javascript và viết logic kinh doanh của dapps bằng một ngôn ngữ riêng, có thể là một lớp mỏng tương đối trên Solidity hoặc Vyper. Sau đó, trình duyệt có thể tự động tạo giao diện người dùng cho bất kỳ chức năng cần thiết nào.OKContractđã làm điều này từ trước.

Một hướng khác là bảo vệ thông tin kinh tế tiền điện tử: các nhà phát triển dapp, công ty bảo mật, người triển khai chuỗi và những người khác có thể đưa ra một trái phiếu sẽ được thanh toán cho người dùng bị ảnh hưởng nếu dapp bị tấn công hoặc gây hại cho người dùng bằng cách hành động theo cách gây hiểu lầm cao, như được xác định bởi một số DAO phân xử onchain. Ví có thể hiển thị cho người dùng điểm số dựa trên kích thước của trái phiếu.

Tương lai dài hạn

Tất cả những điều trên đều trong ngữ cảnh của giao diện truyền thống, mà liên quan đến việc chỉ vào và nhấp chuột vào các thứ và nhập vào các trường văn bản. Tuy nhiên, chúng ta cũng đang ở ngưỡng của việc thay đổi mô hình sâu hơn nhiều:

• AI, có thể dẫn đến chúng ta di chuyển khỏi mô hình click-và-gõ để chuyển sang một mô hình ‘nói những gì bạn muốn làm, và bot sẽ tìm hiểu’
• Giao diện não-máy tính, cả hai cách tiếp cận “nhẹ” như theo dõi mắt cũng như các kỹ thuật trực tiếp và thậm chí xâm lấn hơn (xem: Bệnh nhân Neuralink đầu tiên trong năm nay)
• Khách hàng tham gia phòng thủ chủ động: trình duyệt Brave tích cực bảo vệ người dùng khỏi quảng cáo, theo dõi và nhiều đối tượng không mong muốn khác. Nhiều trình duyệt, plugin và ví tiền điện tử có toàn bộ nhóm làm việc tích cực để bảo vệ người dùng khỏi mọi loại đe dọa về an ninh và quyền riêng tư. Những loại ‘bảo vệ tích cực’ này sẽ trở nên mạnh mẽ hơn trong thập kỷ tới.

Ba xu hướng này cùng nhau sẽ dẫn đến việc suy nghĩ sâu hơn về cách hoạt động của giao diện. Thông qua đầu vào ngôn ngữ tự nhiên, theo dõi ánh mắt, hoặc cuối cùng là BCI trực tiếp hơn, cùng với kiến thức về lịch sử của bạn (có thể bao gồm tin nhắn văn bản, miễn là tất cả dữ liệu được xử lý cục bộ), một “ví” có thể có được một ý tưởng rõ ràng và trực quan về những gì bạn muốn làm. Trí tuệ nhân tạo sau đó có thể dịch ý tưởng đó thành một “kế hoạch hành động” cụ thể: một loạt các tương tác trên chuỗi và ngoài chuỗi để thực hiện những gì bạn muốn. Điều này có thể giảm rất nhiều nhu cầu cho giao diện người dùng bên thứ ba. Nếu người dùng tương tác với một ứng dụng bên thứ ba (hoặc người dùng khác), Trí tuệ nhân tạo nên nghĩ theo kiểu đối đầu với lợi ích của người dùng, và xác định bất kỳ mối đe dọa nào và đề xuất kế hoạch hành động để tránh chúng. Lý tưởng, sẽ có một hệ sinh thái mở của những Trí tuệ nhân tạo này, do các nhóm khác nhau với các định kiến và cấu trúc động cơ khác nhau sản xuất.

Những ý tưởng cấp tiến hơn này phụ thuộc vào công nghệ ngày nay cực kỳ non nớt, và vì vậy tôi sẽ không đặt tài sản của mình ngày hôm nay vào một chiếc ví dựa vào chúng. Tuy nhiên, một cái gì đó như thế này dường như là khá rõ ràng về tương lai, và vì vậy nó đáng để bắt đầu tích cực hơn để khám phá theo hướng đó.

Thông báo từ chối trách nhiệm:

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