Được viết bởi: Vitalik Buterin

Biên soạn bởi: Yangz, Techub News

Ví là một lớp quan trọng trong cơ sở hạ tầng Ethereum, nhưng nó thường bị các nhà nghiên cứu và phát triển L1 cốt lõi đánh giá thấp. Ví là cửa sổ giữa người dùng và thế giới Ethereum và người dùng chỉ có thể hưởng lợi từ chúng nếu bản thân ví đó cũng có khả năng phân cấp, chống kiểm duyệt, bảo mật, quyền riêng tư hoặc các tính năng khác do Ethereum và các ứng dụng của nó cung cấp. Trong những năm gần đây, chúng ta đã thấy ví sinh thái Ethereum đạt được tiến bộ lớn trong việc cải thiện trải nghiệm, bảo mật và chức năng của người dùng. Mục đích của bài viết này là bày tỏ quan điểm cá nhân của tôi về một số thuộc tính mà một ví Ethereum lý tưởng nên có. Danh sách này sẽ không đầy đủ nhưng phản ánh khuynh hướng cypherpunk của tôi. Đối với ví, tôi coi trọng tính bảo mật và quyền riêng tư hơn, vì hầu như không có ví nào hoàn hảo về mặt trải nghiệm người dùng. Tôi không nghĩ danh sách mong muốn có hiệu quả trong việc tối ưu hóa trải nghiệm người dùng bằng việc chỉ triển khai và lặp lại dựa trên phản hồi, đồng thời tập trung vào các thuộc tính bảo mật và quyền riêng tư, theo tôi, là có giá trị nhất.

Hiện tại, lộ trình cải thiện trải nghiệm người dùng cross-L2 ngày càng trở nên chi tiết hơn, bao gồm cả các phần ngắn hạn và dài hạn. Ở đây tôi muốn nói về phần ngắn hạn, những ý tưởng mà về mặt lý thuyết vẫn có thể thực hiện được cho đến tận ngày nay. Ý tưởng cốt lõi của phần này là xây dựng các giao dịch xuyên L2 cũng như các địa chỉ và yêu cầu thanh toán theo chuỗi cụ thể. Ví sẽ cung cấp một địa chỉ như thế này:

Khi ai đó (hoặc một ứng dụng) cung cấp cho bạn địa chỉ ở định dạng này, bạn có thể dán địa chỉ đó vào trường "đến" của ví, sau đó nhấn "gửi" và ví sẽ tự động xử lý địa chỉ đó:

Trên đây là trường hợp sử dụng để "sao chép và dán địa chỉ (hoặc ENS, ví dụ: [email protected]) và nhờ ai đó trả tiền cho bạn". Nếu tiền gửi đang được thực hiện cho DApp (xem ví dụ về Polymarket ), thì quy trình lý tưởng là mở rộng API Web3 để cho phép DApp thực hiện các yêu cầu thanh toán theo chuỗi cụ thể. Bằng cách này, ví người dùng có thể đáp ứng yêu cầu theo bất kỳ cách nào. Để có trải nghiệm tốt cho người dùng, các yêu cầu getAvailableBalance cũng cần phải được chuẩn hóa và ví cần xem xét tài sản của người dùng sẽ được lưu trữ trên chuỗi nào theo mặc định để tối đa hóa tính bảo mật và dễ dàng chuyển tiền. Yêu cầu thanh toán cho một chuỗi cụ thể cũng có thể được đặt trong mã QR để quét trực tiếp bằng ví di động. Trong trường hợp thanh toán tiêu dùng trực tiếp (hoặc trực tuyến), người nhận thanh toán có thể gọi "Tôi muốn X đơn vị mã thông báo Y trên chuỗi Z có ID tham chiếu hoặc gọi lại W" thông qua mã QR hoặc API Web3 và ví có thể cảm nhận được tự do tuân thủ yêu cầu này dưới bất kỳ hình thức nào. Một giải pháp khác là yêu cầu một giao thức liên kết, nghĩa là ví người dùng có thể tạo mã QR hoặc URL, trong đó có quyền yêu cầu một số tiền nhất định từ hợp đồng trực tuyến của nó và công việc của người được trả tiền là tìm cách để chuyển số tiền này Chuyển vào ví của chính bạn. Một chủ đề liên quan khác là thanh toán gas. Nếu bạn nhận được một tài sản trên L2 chưa sở hữu ETH và cần gửi giao dịch trên L2 đó, ví sẽ có thể tự động sử dụng giao thức (chẳng hạn như RIP-7755 ) để thanh toán gas trên chuỗi nơi bạn sở hữu ETH. Nếu ví dự đoán rằng bạn sẽ thực hiện nhiều giao dịch hơn trên L2 đó trong tương lai, thì ví đó cũng nên sử dụng DEX để gửi ETH trị giá hàng triệu gas để các giao dịch trong tương lai có thể sử dụng gas trực tiếp (cũng rẻ hơn).

Sự hiểu biết của tôi về thách thức bảo mật tài khoản là một chiếc ví tốt sẽ bảo vệ người dùng khỏi tin tặc hoặc các cuộc tấn công độc hại của các nhà phát triển ví và khỏi những sai lầm của chính họ.

Những “lỗi” đánh máy trên trục tung là một lỗi thực sự. Tôi cảm thấy lỗi này phù hợp với ngữ cảnh nên không sửa đổi. Trong hơn một thập kỷ , giải pháp ưa thích của tôi là khôi phục xã hội và ví đa chữ ký với các biện pháp kiểm soát truy cập phân cấp. Một tài khoản người dùng được thiết lập với hai cấp độ khóa, bao gồm khóa chính và N người ký (ví dụ: N = 5). Khóa chính cho phép các hoạt động có giá trị thấp và phi tài chính. Nhưng để thực hiện các hoạt động có giá trị cao, chẳng hạn như gửi tất cả tài sản trong tài khoản hoặc thay đổi khóa chính hoặc bất kỳ người ký nào, cần phải có đa số người ký. Nếu muốn, khóa chính có thể được phép thực hiện các thao tác có giá trị cao với khóa thời gian. Trên đây chỉ là thiết kế cơ bản, chúng ta cũng có thể mở rộng nó. Ví dụ: khóa phiên và cơ chế cấp phép (như ERC-7715 ) có thể giúp hỗ trợ các ứng dụng khác nhau với sự cân bằng khác nhau giữa sự tiện lợi và bảo mật. Kiến trúc người ký phức tạp hơn, chẳng hạn như đặt nhiều khoảng thời gian khóa thời gian ở các ngưỡng khác nhau, có thể giúp tối đa hóa cơ hội khôi phục thành công tài khoản hợp pháp đồng thời giảm thiểu nguy cơ bị đánh cắp.

Đối với người dùng tiền điện tử có kinh nghiệm, một lựa chọn khả thi là bạn bè và gia đình của bạn. Trên thực tế, những người ký ví multisig của bạn thậm chí không cần biết nhau là ai. Khả năng họ thông đồng mà bạn không hề biết là rất ít. Tuy nhiên, đối với hầu hết người dùng mới, tùy chọn này không khả thi. Lựa chọn thứ hai là các đại lý, những công ty chuyên cung cấp dịch vụ. Những người ký như vậy sẽ chỉ ký giao dịch sau khi nhận được thông tin xác nhận bổ sung (chẳng hạn như mã xác nhận hoặc cuộc gọi điện video từ người dùng có giá trị ròng cao). Mọi người đã cố gắng tạo ra những công ty như thế này trong một thời gian dài, ví dụ như tôi đã lập hồ sơ về CryptoCorp vào năm 2013. Tuy nhiên, cho đến nay vẫn chưa có đại diện nào thành công cho loại hình công ty này. Tùy chọn thứ ba là sử dụng nhiều thiết bị cá nhân (ví dụ: thiết bị di động, máy tính để bàn, ví phần cứng). Cách tiếp cận này có thể hiệu quả nhưng cũng có thể gây khó khăn cho người dùng thiếu kinh nghiệm trong việc thiết lập và quản lý. Ngoài ra, 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 vị trí. Gần đây, chúng tôi bắt đầu thấy ngày càng có nhiều ví dựa trên mật mã xuất hiện. Mật mã chỉ có thể được sao lưu trên thiết bị, biến nó thành giải pháp cá nhân với thiết bị hoặc trên đám mây, khiến tính bảo mật của nó phụ thuộc vàosự kết hợp phức tạp giữa bảo mật mật khẩu, quyền hạn và các giả định phần cứng đáng tin cậy. Trên thực tế, mật mã là một lợi ích bảo mật có giá trị đối với người dùng bình thường, nhưng chỉ riêng nó thì không đủ để bảo vệ số tiền tiết kiệm cả đời của người dùng. May mắn thay, với ZK-SNARK, chúng tôi có tùy chọn thứ tư, ID tập trung được xử lý bởi ZK. Loại này bao gồm zk-email , Anon Aadhaar , Myna Wallet , v.v. Về cơ bản, bạn lấy bất kỳ hình thức ID tập trung nào (công ty hoặc chính phủ) và biến nó thành địa chỉ Ethereum và chỉ bằng cách tạo bằng chứng ZK-SNARK về quyền sở hữu ID đó, bạn mới có thể gửi giao dịch từ địa chỉ đó.

Với tính năng mới này, chúng tôi có nhiều tùy chọn khác nhau và ID tập trung do ZK xử lý rất thân thiện với người mới. Để đạt được điều này, chúng ta cần sử dụng giao diện người dùng tích hợp hợp lý. Người dùng chỉ cần chỉ định "[email protected]" làm người ký và ví sẽ tự động tạo địa chỉ Ethereum zk-email tương ứng. Ngoài ra, người dùng nâng cao sẽ có thể nhập email của họ (cùng với muối riêng tư có thể được lưu trong email) vào ứng dụng nguồn mở của bên thứ ba và xác nhận rằng địa chỉ kết quả là chính xác. Điều tương tự cũng đúng với bất kỳ loại người ký được hỗ trợ nào khác.

Cần lưu ý rằng một thách thức thực tế mà zk-email hiện phải đối mặt là nó dựa vào chữ ký DKIM , sử dụng các khóa xoay vòng vài tháng một lần và bản thân các khóa đó không được ký bởi bất kỳ cơ quan nào khác. Điều này có nghĩa là cần có một mức độ tin cậy vượt ra ngoài chính nhà cung cấp; nếu zk-email sử dụng TLSNotary trên phần cứng đáng tin cậy để xác minh các khóa đã cập nhật thì yêu cầu về độ tin cậy có thể giảm xuống, nhưng điều này không lý tưởng. Hy vọng các nhà cung cấp email sẽ bắt đầu ký trực tiếp khóa DKIM. Ngoài ra, tôi khuyên bạn chỉ nên sử dụng zk-email cho một người ký chứ không phải cho đa số người ký. Bằng cách này, ngay cả khi zk-email gặp sự cố, bạn sẽ không mất quyền truy cập vào tiền của mình.

Trên thực tế, người dùng mới sẽ không muốn nhập một lượng lớn thông tin người ký ví đa chữ ký khi họ đăng ký lần đầu. Vì vậy, ví nên cung cấp một tùy chọn rất đơn giản. Một cách tiếp cận tự nhiên sẽ là sử dụng zk-email cho 2 trong số 3 chữ ký, 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ã) và một khóa dự phòng do nhà cung cấp nắm giữ. Khi người dùng tích lũy kinh nghiệm hoặc tích lũy tài sản, trong một số trường hợp, họ sẽ được nhắc thêm nhiều người ký hơn. Việc tích hợp ví vào ứng dụng là điều không thể tránh khỏi vì các ứng dụng đang cố gắng thu hút người dùng không sử dụng tiền điện tử sẽ không muốn tạo ra trải nghiệm xấu cho người dùng bằng cách yêu cầu người dùng tải xuống hai ứng dụng mới (chính ứng dụng và ví Ethereum) cùng một lúc. Người dùng sử dụng nhiều ví cũng có thể kết nối tất cả các ví với nhau để họ chỉ phải lo lắng về “vấn đề kiểm soát truy cập”. Cách tiếp cận đơn giản nhất là sử dụng phương pháp phân lớp, trong đó người dùng có thể thiết lập ví chính của họ làm người ký cho tất cả các ví trong ứng dụng thông qua quy trình "liên kết" nhanh chóng. Hiện tại, ứng dụng khách Warpcast của Farcaster đã hỗ trợ phương pháp này.

Theo mặc định, việc khôi phục tài khoản Warpcast được kiểm soát bởi nhóm Warpcast. Nhưng người dùng có thể “chiếm đoạt” tài khoản Farcaster và đổi thành địa chỉ của chính mình.

Ngoài bảo mật tài khoản, các ví ngày nay còn làm rất nhiều việc để 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, đồng thời nỗ lực bảo vệ người dùng khỏi các mối đe dọa đó. Tuy nhiên, nhiều biện pháp đối phó vẫn còn khá thô sơ. Ví dụ: gửi ETH hoặc các mã thông báo khác đến bất kỳ địa chỉ mới nào chỉ bằng một cú nhấp chuột, cho dù bạn đang gửi 100 đô la hay 100.000 đô la. Không có giải pháp duy nhất nào về vấn đề này mà thay vào đó là một loạt các bản sửa lỗi và cải tiến chậm rãi, liên tục đối với các loại mối đe dọa khác nhau. Tuy nhiên, có giá trị lớn trong việc tiếp tục phấn đấu để cải thiện.

Công nghệ ZK-SNARK đã trở nên rất tiên tiến và các công nghệ bảo mật như Privacy Pools có thể giảm thiểu rủi ro pháp lý mà không cần dựa vào cửa sau đang ngày càng hoàn thiện hơn. Cơ sở hạ tầng thứ cấp như Waku và ERC-4337 cũng đang dần trở nên ổn định hơn. Tuy nhiên, cho đến nay, việc thực hiện chuyển khoản riêng tư trên Ethereum vẫn yêu cầu người dùng phải tải xuống và sử dụng một cách rõ ràng một "ví riêng" như Railway (hoặc Umbra cho các địa chỉ ẩn). Điều này mang đến sự bất tiện lớn cho người dùng và làm giảm số lượng người dùng như vậy. Giải pháp cho vấn đề này là tích hợp các giao dịch chuyển tiền đó trực tiếp vào ví. Một phương pháp triển khai đơn giản là ví có thể lưu trữ một phần tài sản của người dùng dưới dạng "số dư riêng tư" trong nhóm riêng tư. Khi người dùng thực hiện chuyển khoản, trước tiên nó sẽ tự động bị rút khỏi nhóm quyền riêng tư. Nếu người dùng cần nhận tiền, ví sẽ tự động tạo một địa chỉ ẩn. Ngoài ra, ví có thể tự động tạo địa chỉ mới cho mỗi ứng dụng mà người dùng tham gia (chẳng hạn như giao thức DeFi). Tiền gửi đến từ nhóm riêng tư và số tiền rút sẽ được chuyển trực tiếp vào nhóm riêng tư. Bằng cách này, hoạt động của người dùng trong bất kỳ ứng dụng nào sẽ độc lập với hoạt động của họ trong các ứng dụng khác.

Một ưu điểm của công nghệ này là nó không chỉ đạt được sự riêng tư trong việc chuyển giao tài sản mà còn cả sự riêng tư trong việc nhận dạng danh tính. Hiện tại, nhận dạng danh tính được triển khai trên chuỗi. Bất kỳ ứng dụng nào sử dụng bằng chứng nhận dạng cá nhân (chẳng hạn như Gitcoin Grants), bất kỳ cuộc trò chuyện nào yêu cầu mã thông báo cụ thể và giao thức Ethereum Follow đều là nhận dạng danh tính trên chuỗi. Chúng tôi hy vọng rằng hệ sinh thái này cũng có thể ở chế độ riêng tư, nghĩa là các hoạt động của người dùng trên chuỗi không được tập trung ở một nơi, mỗi dự án phải đượ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". " , bạn có thể xem tất cả bằng chứng của mình cùng một lúc. Giống như các giao thức xác thực ngoài chuỗi như EAS và Zupass , hệ sinh thái gốc gồm nhiều tài khoản cho mỗi người dùng giúp đạt được mục tiêu này. Điều này thể hiện tầm nhìn thực tế về quyền riêng tư của Ethereum trong trung hạn. Mặc dù nó có thể được triển khai ngay hôm nay, nhưng việc giới thiệu một số tính năng ở giai đoạn L1 và L2 sẽ giúp các giao dịch bảo vệ quyền riêng tư trở nên hiệu quả và đáng tin cậy hơn. Một số người ủng hộ quyền riêng tư tin rằng điều duy nhất có thể chấp nhận được là mọi thứ phải hoàn toàn riêng tư và toàn bộ EVM phải được mã hóa. Nhưng tôi nghĩ đây có lẽ là kết quả mong muốn lâu dài và đòi hỏi phải xem xét lại cơ bản hơn về mô hình lập trình và nó vẫn chưa đủ trưởng thành để triển khai trên Ethereum. Chúng tôi thực sự cần "quyền riêng tư theo mặc định" để đạt được mức độ ẩn danh đầy đủ. Tuy nhiên, tập trung vào quyền riêng tư của việc chuyển tiền giữa các tài khoản, cũng như các trường hợp sử dụng danh tính và liên quan đến danh tính) là bước đầu tiên thực tế, dễ thực hiện hơn và có thể được xây dựng cho ví ở giai đoạn này.

Bất kỳ giải pháp bảo mật hiệu quả nào, cho dù là thanh toán, nhận dạng hay các trường hợp sử dụng khác, đều sẽ dẫn đến việc người dùng cần lưu trữ dữ liệu ngoài chuỗi. Điều này được thể hiện rõ trong Tornado Cash, yêu cầu người dùng lưu từng “tờ tiền” đại diện cho khoản tiền gửi từ 0,1-100 ETH. Và 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ó. Tuy nhiên, điều này tiềm ẩn nhiều rủi ro, vì nếu khóa bị rò rỉ hoặc máy tính lượng tử trở thành hiện thực, tất cả dữ liệu sẽ được công khai. Đến lúc đó, nhu cầu lưu trữ dữ liệu ngoài chuỗi để xác thực ngoài chuỗi như EAS và Zupass sẽ rõ ràng hơn. Ví cần phải là phần mềm không chỉ lưu trữ quyền truy cập trên chuỗi mà còn lưu trữ dữ liệu riêng tư. Điều này ngày càng được công nhận trong thế giới không phải tiền điện tử, hãy xem nghiên cứu gần đây của Tim Berners-Lee về lưu trữ dữ liệu cá nhân. Tất cả các vấn đề chúng ta cần giải quyết không chỉ là đảm bảo hiệu quả việc kiểm soát quyền truy cập mà còn đảm bảo dữ liệu có thể truy cập được và không bị rò rỉ. Có thể hai giải pháp này có thể được xếp chồng lên nhau, giả sử bạn thiết lập N người ký nhiều người, thì bạn có thể sử dụng tính năng chia sẻ bí mật M-of-N giữa N người ký này để lưu trữ dữ liệu. Dữ liệu vốn khó bảo mật hơn vì bạn không thể thu hồi quyền chia sẻ dữ liệu của người khác, nhưng chúng ta nên đưa ra các giải pháp lưu trữ phi tập trung an toàn bất cứ khi nào có thể.

Nhiều ví tin tưởng nhà cung cấp RPC sẽ cho họ biết bất kỳ thông tin nào về chuỗi. Điều này có sai sót ở hai điểm. Thứ nhất, nhà cung cấp RPC có thể cố gắng lấy cắp tiền bằng cách cung cấp thông tin sai lệch (chẳng hạn như giá thị trường); thứ hai, nhà cung cấp RPC có thể trích xuất thông tin cá nhân về ứng dụng và tài khoản khác mà người dùng tương tác. Lý tưởng nhất là chúng ta cần ngăn chặn cả hai lỗ hổng xảy ra. Để ngăn chặn lỗ hổng đầu tiên, chúng tôi cần các máy khách nhẹ L1 và L2 được tiêu chuẩn hóa để xác minh trực tiếp sự đồng thuận của blockchain. Helios đã triển khai chức năng này cho L1 và một số công việc ban đầu đã được thực hiện để hỗ trợ một số L2 cụ thể. Để bao quát chính xác tất cả L2, chúng tôi cần một tiêu chuẩn mà theo đó hợp đồng cấu hình đại diện cho L2 (cũng dành cho một địa chỉ chuỗi cụ thể) có thể xuất bản một chức năng (có lẽ theo cách tương tự như ERC-3668 ) có chức năng tận dụng tối đa logic gốc trạng thái gần đây và xác thực các chứng chỉ và biên lai trạng thái đối với các gốc trạng thái này. Bằng cách này, chúng ta có thể có một ứng dụng khách phổ quát cho phép ví xác minh một cách an toàn mọi trạng thái hoặc sự kiện trên L1 và L2. Đối với lỗ hổng thứ hai, cách khả thi duy nhất vào lúc này là chạy nút đầy đủ của riêng bạn. Tuy nhiên, khi L2 trở nên phổ biến hơn, việc chạy một nút đầy đủ với mọi thứ được bao gồm ngày càng khó khăn hơn. Để giải quyết vấn đề này, một giải pháp tương đương với các client hạng nhẹ là Truy xuất thông tin cá nhân (PIR). PIR liên quan đến một máy chủ chứa bản sao của tất cả dữ liệu và một máy khách gửi yêu cầu được mã hóa đến máy chủ. Máy chủ thực hiện tính toán trên tất cả dữ liệu, trả về dữ liệu khách hàng cần (được mã hóa bằng khóa của khách hàng) mà không tiết lộ cho máy chủ dữ liệu nào khách hàng đã truy cập.

Để máy chủ luôn trung thực, bản thân các mục cơ sở dữ liệu riêng lẻ cần phải là nhánh cây Merkle để khách hàng có thể xác minh chúng bằng ứng dụng khách nhẹ của riêng họ. PIR tốn kém về mặt tính toán, nhưng có một số cách để tiếp cận vấn đề này:

Trong môi trường Ethereum, việc tìm ra sự kết hợp các công nghệ có thể tối đa hóa khả năng bảo vệ quyền riêng tư trong khi vẫn duy trì tính thực tiễn là một chủ đề nghiên cứu mở và các nhà mật mã được hoan nghênh thử nghiệm nó.

Ngoài khả năng truy cập trạng thái và vận chuyển, một quy trình công việc quan trọng khác cần chạy trơn tru trên môi trường L2 là thay đổi cấu hình xác thực của tài khoản (cho dù đó là thay đổi khóa hay thực hiện các thay đổi sâu hơn đối với toàn bộ logic của tài khoản). Dưới đây là các giải pháp ba tầng, với độ khó tăng dần:

Giải pháp thứ ba đặc biệt mạnh mẽ vì nó phù hợp với quyền riêng tư. Trong "giải pháp bảo mật" thông thường, giả sử rằng người dùng có bí mật s và xuất bản "giá trị lá" L trên chuỗi, người dùng chứng minh rằng L = hash(s,1) và N = hash(s,2) là Đó là một bí mật kiểm soát nào đó (không bao giờ được tiết lộ). N sẽ được công bố để đảm bảo rằng việc chi tiêu trong tương lai cho cùng một Lá sẽ không thất bại và L sẽ không bị rò rỉ. Trong giải pháp bảo mật thân thiện với việc khôi phục tài khoản, s là một vị trí trên chuỗi (chẳng hạn như địa chỉ và khe lưu trữ) và người dùng phải chứng minh truy vấn trạng thái, nghĩa là L = hash(sload(s), 1).

Liên kết yếu nhất trong bảo mật người dùng thường là DApp. Trong hầu hết các trường hợp, người dùng tương tác với các ứng dụng bằng cách truy cập một trang web, trang web này tải mã giao diện người dùng xuống theo thời gian thực từ máy chủ và sau đó thực thi mã đó trong trình duyệt. Nếu máy chủ bị hack hoặc DNS bị hack, người dùng sẽ nhận được một bản sao giao diện giả, có thể lừa người dùng làm những việc tùy ý. Các tính năng của ví như mô phỏng giao dịch rất hữu ích trong việc giảm thiểu rủi ro nhưng vẫn chưa đủ. Lý tưởng nhất là chúng ta cần chuyển hệ sinh thái sang phiên bản nội dung trực tuyến, nơi người dùng sẽ truy cập DApp thông qua tên ENS của nó, tên này sẽ chứa hàm băm IPFS của giao diện. Để cập nhật giao diện, cần phải có giao dịch trực tuyến từ nhiều ID hoặc DAO. Ví sẽ hiển thị cho người dùng xem họ đang tương tác với giao diện trên chuỗi an toàn hơn hay giao diện Web2 kém an toàn hơn. Ví cũng có thể hiển thị cho người dùng xem họ có đang tương tác với một blockchain an toàn hay không (ví dụ: giai đoạn 1+, kiểm tra bảo mật nhiều lần). Đối với những người dùng quan tâm đến quyền riêng tư, ví cũng có thể khó khăn hơn một chút và yêu cầu người dùng nhấp để chấp nhận các yêu cầu HTTP, không chỉ các hoạt động Web3.

Một cách tiếp cận nâng cao hơn là vượt xa HTML + Javascript và viết logic nghiệp vụ của DApp bằng ngôn ngữ chuyên dụng, chẳng hạn như phủ một ngôn ngữ tương đối nhẹ trên Solidity hoặc Vyper. Bằng cách này, 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 đã thực hiện việc này. Một hướng khác là bảo vệ thông tin kinh tế được mã hóa, tức là các nhà phát triển DApp, công ty bảo mật, nhà triển khai trên chuỗi và những người khác có thể thiết lập một khoản tiền gửi. Nếu DApp bị hack hoặc gây tổn hại cho người dùng theo cách gây hiểu lầm cao, khoản tiền gửi sẽ được thực hiện sau. DAO cai trị trên chuỗi đưa ra quyết định và số tiền này sẽ được thanh toán cho người dùng bị ảnh hưởng. Ví có thể hiển thị cho người dùng xếp hạng dựa trên kích thước ký quỹ.

Những điều trên đều được thực hiện trong bối cảnh truyền thống và chúng ta hiện đang đứng trước những thay đổi sâu sắc về mô hình:

Kết hợp lại với nhau, ba xu hướng này sẽ thúc đẩy việc suy nghĩ lại sâu sắc hơn về cách thức hoạt động của ví. Thông qua đầu vào ngôn ngữ tự nhiên, theo dõi bằng mắt hoặc cuối cùng là nhận dạng sinh trắc học trực tiếp hơn (BCI), cùng với kiến ​​thức về lịch sử của người dùng, "ví" có thể biết chính xác những gì người dùng muốn làm bằng trực giác. Sau đó, AI có thể chuyển trực giác này thành một “kế hoạch hành động” cụ thể, chẳng hạn như một loạt các tương tác trên chuỗi và ngoài chuỗi, để đạt được mục đích của người dùng. Điều này có thể làm giảm đáng kể nhu cầu về giao diện người dùng của bên thứ ba. Nếu người dùng tương tác với ứng dụng của bên thứ ba (hoặc người dùng khác), AI cũng sẽ thay mặt người dùng suy nghĩ theo hướng bất lợi, 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 nhất là những AI này sẽ hình thành một hệ sinh thái mở, được tạo ra bởi các nhóm khác nhau với những thành kiến ​​và cơ cấu khuyến khích khác nhau. Tất nhiên, những ý tưởng cấp tiến hơn này dựa trên các công nghệ hiện còn cực kỳ non nớt, vì vậy tôi sẽ không đặt tài sản của mình vào ví dựa trên những công nghệ này. Tuy nhiên, loại công nghệ này dường như là xu hướng của tương lai nên rất đáng để chúng ta bắt đầu khám phá tích cực hơn theo hướng này.