Viết bởi: Peter Pan, Đồng sáng lập và CTO của Particle Network & Faust, Geek Web3

Việc trừu tượng hóa tài khoản đã là một chủ đề được thảo luận rộng rãi kể từ năm 2022 và khuôn khổ trong lĩnh vực trừu tượng hóa tài khoản với EIP-4337 làm cốt lõi dường như đã trở thành sự đồng thuận chung trong ngành. Sự phổ biến của khái niệm ý định đã thúc đẩy mọi người chú ý nhiều hơn đến các thành phần tương tác người dùng có ngưỡng thấp như vậy.

Tuy nhiên, EIP-4337 vẫn có những điểm yếu là tài khoản Tài khoản thông minh bị phân mảnh và trải nghiệm người dùng bị phân mảnh cao về việc trừu tượng hóa tài khoản chuỗi chéo. Bài viết này lấy các dự án như Biconomy, Safe Core và Particle Network làm ví dụ để thảo luận về cách thúc đẩy hơn nữa sự phát triển của trường trừu tượng hóa tài khoản trong khuôn khổ EIP-4337.

Hiểu khái niệm "trừu tượng hóa tài khoản" từ góc độ trừu tượng hóa quy trình giao dịch

Về việc trừu tượng hóa tài khoản, Vitalik đã nhiều lần chỉ ra rằng đây là điều kiện cần thiết để hạ thấp ngưỡng người dùng Ethereum và đạt được sự chấp nhận rộng rãi. Tầm nhìn cốt lõi của nó là cho phép người dùng tùy chỉnh phương thức xác minh chữ ký + tận hưởng thanh toán gas và có thể bật chuỗi không có bất kỳ tài sản nào. Bắt đầu một giao dịch (thường được gọi là giao dịch không cần gas). Chỉ bằng cách nhận ra những điều kiện tiên quyết này, tỷ lệ chuyển đổi người dùng mới của ứng dụng Web3 mới có thể được cải thiện.

Mặc dù các đề xuất trừu tượng không phải tài khoản hoặc ví hợp đồng thông minh trước đây có thể đạt được trải nghiệm tương tự, nhưng chúng vẫn chưa đủ linh hoạt và hiệu quả.Ví dụ: Gnosis Safe vẫn yêu cầu địa chỉ EOA để kích hoạt giao dịch và chi phí Gas cực kỳ cao.

Việc trừu tượng hóa tài khoản nhằm mục đích tối ưu hóa từ lớp dưới cùng của cấu trúc tài khoản hợp đồng thông minh để mở đường cho thế hệ hệ thống tài khoản thông minh tiếp theo.

Nhưng nếu chúng ta xem xét các đề xuất trừu tượng hóa tài khoản thực tế, chúng ta sẽ thấy rằng trọng tâm của chúng không nằm ở chính mô hình tài khoản. Ví dụ: các đề xuất liên quan đến trừu tượng hóa tài khoản như EIP-86, EIP-4337 và EIP-6900 tập trung vào việc trừu tượng hóa/mô-đun hóa toàn bộ quá trình xử lý giao dịch từ bắt đầu đến nhận nút, xác minh chữ ký, thanh toán gas, v.v. nhưng không thực sự tập trung vào Sự trừu tượng hóa cấu trúc tài khoản. Vì vậy, có vẻ thích hợp hơn khi gọi các đề xuất hiện tại là “trừu tượng hóa giao dịch”.

Nếu chúng ta hiểu các đề xuất trừu tượng hóa tài khoản nổi tiếng đó từ góc độ "trừu tượng hóa các quy trình xử lý giao dịch", chúng ta có thể dễ dàng hiểu điểm chính hơn: kiểu trừu tượng hóa giao dịch này thực sự là để cho phép người dùng cấp Web2 truy cập và sử dụng sản phẩm Được đưa vào hệ thống Ethereum, chẳng hạn như danh sách đen/danh sách trắng, không cần xác minh danh tính để bắt đầu giao dịch trong một khoảng thời gian, không có giao dịch Gas, phí thanh toán tiền tệ hợp pháp, v.v.

(Nguồn ảnh: Zengo)

Nhưng một số người có thể hỏi: Chẳng phải trước đây những điều này đã được triển khai trong ví hợp đồng thông minh sao? EIP-4337 Giá trị của loại giải pháp trừu tượng hóa tài khoản này là gì?

Bản chất của EIP-4337: giải pháp trừu tượng hóa tài khoản tối ưu cục bộ trong hệ sinh thái Ethereum

Như đã đề cập trong câu hỏi trên, mặc dù ví thông minh trước đây có thể đạt được các chức năng nêu trên nhưng phương pháp triển khai nhìn chung còn thô sơ và thường dựa vào cơ sở tập trung cao độ của bên thứ ba. Ví dụ: giải pháp thanh toán Gas trước đây yêu cầu giới thiệu các nút Chuyển tiếp của bên thứ ba (EIP-2771). Hơn nữa, thiếu các tiêu chuẩn thống nhất giữa các ví thông minh khác nhau, điều này không có lợi cho việc phát triển và bố trí các thành phần hỗ trợ.

Như đã đề cập trong câu hỏi trên, mặc dù ví thông minh trước đây có thể đạt được các chức năng nêu trên nhưng phương pháp triển khai nhìn chung còn thô sơ và thường dựa vào cơ sở tập trung cao độ của bên thứ ba. Ví dụ: giải pháp thanh toán Gas trước đây yêu cầu giới thiệu các nút Chuyển tiếp của bên thứ ba (EIP-2771). Hơn nữa, thiếu các tiêu chuẩn thống nhất giữa các ví thông minh khác nhau, điều này không có lợi cho việc phát triển và bố trí các thành phần hỗ trợ.

Sự hấp dẫn cốt lõi của EIP liên quan đến việc trừu tượng hóa tài khoản khác nhau là giải quyết những thiếu sót này trong các dự án ví khác nhau thông qua khung tiêu chuẩn được thiết kế cho ví hợp đồng thông minh và thúc đẩy cấu trúc tài khoản trong hệ sinh thái Ethereum từ cấu trúc chức năng cơ bản. Chuyển đổi thành cấu trúc thông minh với trần cao hơn.

(Nguồn hình ảnh: Liên kết Springer)

Điều này cũng giống như trước khi ERC-20 hoặc ERC-721 xuất hiện, các phương thức triển khai, chức năng và chức năng/giao diện được cung cấp bên ngoài của nhiều Token không nhất quán và "sự không nhất quán" không có lợi cho việc phát triển hỗ trợ bên thứ ba cơ sở vật chất, và nó không có lợi cho sự phát triển của các cơ sở hỗ trợ của bên thứ ba. Có lợi cho việc kiểm toán mã (thật khó để tưởng tượng làm thế nào các ứng dụng Defi có thể phát triển đến mức thịnh vượng như hiện nay nếu không có giao thức ERC-20).

Các giao thức/tiêu chuẩn triển khai chức năng được tiêu chuẩn hóa là điều kiện tiên quyết cho tường thuật mô-đun và các phương pháp phát triển mô-đun là điều kiện tiên quyết để hầu hết mọi lĩnh vực phát triển mạnh (phân công lao động là nguyên tắc đầu tiên để nâng cao hiệu quả).

Cuối cùng, EIP-4337 nổi bật.

EIP-4337 là một giải pháp tối ưu cục bộ, nhưng có nhiều góc độ trong khuôn khổ của nó cần được tối ưu hóa.

EIP-4337 xác định một bộ tiêu chuẩn giao diện hoàn chỉnh, làm rõ ít nhất những mô-đun nào mà một ví thông minh tuân theo giao thức 4337 phải có và những chức năng/giao diện nào mà mỗi mô-đun nên triển khai, chẳng hạn như những thành phần có thể gọi được như Bundler, EntryPoint và Paymaster nên cung cấp cho thế giới bên ngoài chức năng.

Sau khi làm rõ các quy tắc và quy định này, mối quan hệ tương tác giữa các thành phần khác nhau sẽ rõ ràng hơn, giúp việc đưa ý tưởng thiết kế mô-đun vào thiết kế trừu tượng hóa tài khoản và ví thông minh trở nên dễ dàng hơn, đồng thời các nhà phát triển mô-đun ví cũng sẽ được hưởng lợi rất nhiều.

Tất nhiên, hoàn toàn từ góc độ người dùng, giá trị mà mô hình phát triển ví thông minh mô-đun mang lại vẫn chưa rõ ràng, bởi vì mọi người sẽ không cảm thấy nhiều thay đổi về bản thân ví trừu tượng tài khoản trong thời gian ngắn. Nhưng trong trung và dài hạn, giá trị của các giao thức như EIP-4337 tương tự như ERC-20 và ERC-721, đặt nền tảng cho sự phát triển lâu dài của ví trừu tượng tài khoản và là một cột mốc quan trọng tạo nên kỷ nguyên.

Nhưng EIP-4337 vẫn còn nhiều vấn đề chưa được giải quyết: chẳng hạn như:

1. Chức năng trừu tượng hóa tài khoản không đủ plug-in và các nhà phát triển khác nhau dễ dàng phát minh lại bánh xe;

2. Mô-đun tài khoản có khả năng tương thích kém và toàn bộ hệ thống tài khoản có xu hướng bị phân mảnh;

3. Hệ sinh thái trừu tượng hóa tài khoản giữa các chuỗi khác nhau rất phân tán, gây khó khăn cho việc cung cấp cho người dùng cuối và nhà phát triển trải nghiệm thống nhất và chất lượng cao để đạt được UX tốt hơn.

Dưới đây, chúng ta sẽ khám phá các giải pháp cho những vấn đề này.

Hướng tối ưu hóa thứ nhất: Plug-in chức năng trừu tượng hóa tài khoản sẽ trở thành cấu hình cơ bản

Có thể nói, một trong những điểm thảo luận cốt lõi liên quan đến việc trừu tượng hóa tài khoản là làm thế nào để triển khai tốt hơn việc mô-đun hóa ví trừu tượng tài khoản và cắt mức độ chi tiết của từng mô-đun thành các phần tốt hơn.

Ví dụ: Biconomy đã đề xuất bản tường thuật phần bổ trợ cho các chức năng trừu tượng hóa tài khoản dựa trên EIP-4337 (EIP-6900 chi tiết hơn sẽ được giới thiệu trong tương lai) để thúc đẩy hơn nữa sự phát triển mô-đun của hệ sinh thái trừu tượng hóa tài khoản.

Ví dụ: Biconomy đã đề xuất bản tường thuật phần bổ trợ cho các chức năng trừu tượng hóa tài khoản dựa trên EIP-4337 (EIP-6900 chi tiết hơn sẽ được giới thiệu trong tương lai) để thúc đẩy hơn nữa sự phát triển mô-đun của hệ sinh thái trừu tượng hóa tài khoản.

(Nguồn ảnh: Biconomy)

Cái gọi là plug-in của chức năng trừu tượng hóa tài khoản thực chất là sử dụng một bộ giao thức để làm rõ với thế giới bên ngoài những mô-đun chính nào có liên quan đến ví hợp đồng thông minh, những giao diện/chức năng mà các mô-đun này sẽ triển khai và tên là gì và các phương thức gọi của các giao diện này. Các nhà phát triển bên thứ ba sau đó sẽ phát triển các thành phần với các chi tiết khác nhau theo ý tưởng riêng của họ, nhưng các thành phần này đều sẽ tuân thủ các yêu cầu được đặt ra trong thỏa thuận.

Phiên bản V2 của Biconomy sử dụng EIP-4337 làm khung giao thức, xây dựng các tiêu chuẩn chi tiết hơn và bổ sung thêm một số giao diện chưa được đề cập trong 4337. Trong khi khai báo những chức năng mà các mô-đun này như Bundler, Ví hợp đồng thông minh và Paymaster nên có, Biconomy cho phép các nhà phát triển bên thứ ba sử dụng các chi tiết mã khác nhau để triển khai các mô-đun có cùng tính năng và phiên bản khác nhau, miễn là chúng tuân theo quy định trước của Biconomy. chi tiết thỏa thuận (Tương thích với EIP-4337).

(Tiêu chuẩn giao diện do Biconomy đề xuất chỉ định chức năng nào mà nhà phát triển mô-đun bên thứ ba nên triển khai trong mô-đun cho các lệnh gọi bên ngoài)

Đồng thời, Biconomy cũng đề xuất khẩu hiệu "Cửa hàng mô-đun", đồng thời tích cực ra mắt SDK mô-đun trừu tượng hóa tài khoản, khuyến khích các nhà phát triển gửi mô-đun trừu tượng hóa tài khoản do chính họ thiết kế và khởi chạy "Mô-đun dưới dạng dịch vụ" để tất cả các nhà phát triển tuân thủ với giao thức EIP-4337, tất cả các dự án ví có thể trực tiếp sử dụng các mô-đun trừu tượng hóa tài khoản này do người ngoài viết. Khi người dùng tạo tài khoản thông minh thông qua trang giao diện người dùng, họ cũng có nhiều lựa chọn đa dạng hơn về việc sử dụng mô-đun nào.

Tính mô-đun không chỉ tạo điều kiện thuận lợi cho việc phân công lao động mà còn giúp người dùng nhanh chóng chuyển đổi hoặc thêm hoặc xóa một số chức năng nhất định trong ví thông minh (nói một cách thẳng thắn, nó có nghĩa là chia mức độ chi tiết thành các phần tốt hơn).

Biconomy chỉ ra rằng tính mô-đun của ví hợp đồng thông minh càng cao thì càng cần ít thay đổi khi cập nhật hoặc nâng cấp nó (không cần cập nhật hợp đồng Ví hợp đồng thông minh hiện tại của người dùng hoặc sử dụng DelegateCall, chỉ cần cập nhật một số mô-đun bên ngoài nhất định) . Việc thay thế một số thành phần nhất định sẽ thuận tiện cho những người dùng hoặc nhà phát triển khác nhau.

Trong phiên bản mới trong tương lai của Biconomy về sơ đồ trừu tượng hóa tài khoản, đề xuất EIP-6900, có tính mô-đun cao hơn EIP-4337, cũng sẽ được đề cập đến.

Hướng tối ưu hóa thứ hai: phân đoạn mô-đun chi tiết hơn để giải quyết vấn đề phân mảnh tài khoản

Liên quan đến đề xuất EIP-6900, Safe (trước đây là Gnosis Safe) thực sự đã đưa ra sách trắng về Giao thức cốt lõi an toàn có liên quan vào tháng 8 năm nay và tài liệu được tham khảo nhiều nhất là EIP-6900.

(Sơ đồ EIP-6900)

EIP-6900 đã chỉ ra rằng một trong những vấn đề hiện tại với việc trừu tượng hóa tài khoản theo mô-đun là sự "phân mảnh" của các tài khoản hoặc vấn đề về hòn đảo. Ví dụ: mặc dù các nhà cung cấp mô-đun trừu tượng hóa tài khoản khác nhau hoặc các ứng dụng DAPP khác nhau sẽ tương thích với EIP-4337, nhưng EIP-4337 không trừu tượng hóa các mô-đun khác nhau đủ cao và mức độ chi tiết của việc phân chia tương đối thô, khiến các nhà phát triển mô-đun Tài khoản Thông minh gặp phải " " Mức độ tự do quá cao (tài khoản thông minh là phần cốt lõi của việc lưu trữ thông tin người dùng, ghi lại xác minh giao dịch tùy chỉnh và logic thanh toán gas).

Do đó, các dự án ví khác nhau có xu hướng thiết kế các mô-đun tài khoản thông minh với các thuộc tính độc đáo. Nếu mọi việc cứ tiếp diễn như vậy, các nhà cung cấp mô-đun trừu tượng hóa tài khoản khác phải ưu tiên tương thích với mô-đun Tài khoản thông minh do người khác cung cấp và dần dần một chuỗi cung ứng thượng nguồn và hạ nguồn cố định sẽ được hình thành, điều này chắc chắn sẽ dẫn đến sự phân mảnh và tách rời của hệ sinh thái mô-đun trừu tượng hóa tài khoản. (Điều này cũng giống như những ngày đầu của ngành công nghiệp máy tính, các nhà phát triển hệ điều hành trước tiên phải xem xét nhà sản xuất phần cứng máy tính nào cung cấp thiết bị tương thích)

Để giải quyết vấn đề phân mảnh sinh thái và cải thiện khả năng tương thích của các mô-đun trừu tượng hóa tài khoản do các nhà cung cấp khác nhau phát triển, cách tốt nhất là trừu tượng hóa hơn nữa tài khoản ví hợp đồng thông minh và làm cho mức độ chi tiết của phân đoạn mô-đun trở nên tốt hơn.

Sau khi dựa trên ý tưởng của EIP-6900, sách trắng về giao thức Safe Core thực hiện tối ưu hóa chi tiết hơn cho Tài khoản thông minh (tài khoản ví thông minh của người dùng). Giao thức Safe Core chia các mô-đun mà mỗi tài khoản ví thông minh có thể gọi thành nhiều danh mục khác nhau như Plugin, Hook, trình xác minh chữ ký và bộ xử lý chức năng.

Mô-đun tài khoản thông minh càng nhẹ càng tốt, hợp đồng tài khoản chỉ lưu trữ những dữ liệu và chức năng cơ bản nhất, tất cả các chức năng có thể di chuyển ra bên ngoài đều được thực hiện bởi các mô-đun chia nhỏ như "bộ xử lý chức năng" hoặc "Plugin". Điều này phù hợp với cái gọi là nguyên tắc dao cạo của Occam - "Không thêm các thực thể trừ khi cần thiết."

Nếu bản thân tài khoản thông minh đủ nhẹ và không chứa các chi tiết quá phức tạp thì tài khoản thông minh do các nhà sản xuất khác nhau phát triển sẽ gần gũi hơn về cấu trúc bên trong và có khả năng tương thích cao hơn.

Giao thức Safe Core cũng giới thiệu một sổ đăng ký, tương tự như iPhone App Store, chứa tất cả các mô-đun có sẵn và được phê duyệt. Người dùng có thể chọn mô-đun nào để kích hoạt và mỗi lần kích hoạt mô-đun mới, mô-đun đó phải được xử lý thông qua hợp đồng Manger.

Giao thức Safe Core cũng giới thiệu một sổ đăng ký, tương tự như iPhone App Store, chứa tất cả các mô-đun có sẵn và được phê duyệt. Người dùng có thể chọn mô-đun nào để kích hoạt và mỗi lần kích hoạt mô-đun mới, mô-đun đó phải được xử lý thông qua hợp đồng Manger.

Trong trường hợp bình thường, UserOperation trước tiên sẽ kích hoạt một trình cắm, sau đó hợp đồng Manger sẽ kiểm tra xem trạng thái của trình cắm có bình thường hay không (có một bản ghi trong sổ đăng ký). Nếu bình thường, yêu cầu của trình cắm thêm sẽ được thả ra. Nếu cần, plug-in Plugin sẽ gọi một số chức năng do Hook cung cấp hoặc không. Sau đó, trạng thái của tài khoản thông minh liên quan đến UserOperation sẽ được thay đổi.

Thông qua phương pháp lập kế hoạch và phương pháp phân đoạn mô-đun chi tiết nêu trên, Giao thức lõi an toàn cố gắng triển khai một tập hợp các giao thức tương tác mô-đun trừu tượng hóa tài khoản nguồn mở. Ý tưởng cốt lõi là làm cho Tài khoản thông minh nhẹ và đơn giản như tài khoản EOA để tạo điều kiện thuận lợi Cải thiện khả năng tương thích của các mô-đun Tài khoản thông minh từ các nhà sản xuất khác nhau.

Hướng tối ưu hóa thứ ba: trừu tượng hóa tài khoản toàn chuỗi để đạt được các tài khoản thống nhất trên các chuỗi khác nhau

Nhưng ngay cả với các giải pháp nói trên, vẫn còn một vấn đề lớn chưa được giải quyết: các chuỗi khác nhau và Layer2 khác nhau đang thúc đẩy các giải pháp triển khai trừu tượng hóa tài khoản với các chi tiết khác nhau và nhiều trong số chúng áp dụng các hình thức xung đột với EIP-4337, chẳng hạn như zkSync Kỷ nguyên, Starknet, Dòng chảy, v.v. Điều này đã dẫn đến sự phân mảnh trong UX ví của người dùng, chẳng hạn như địa chỉ ví thông minh của người dùng trên Starknet và địa chỉ ví thông minh trên Arbitrum hoàn toàn không thể thống nhất.

Hơn nữa, trong môi trường đa chuỗi, người dùng đã triển khai Tài khoản thông minh độc lập trên các chuỗi khác nhau và dữ liệu người dùng tương ứng thường được phân tán và lưu trữ trong các hợp đồng này. Nếu dữ liệu người dùng như khóa cần được cập nhật, thì các giao dịch cần phải được bắt đầu liên tục trên nhiều chuỗi, gây khó khăn cho việc đảm bảo tính nhất quán của Tài khoản thông minh.

Bản thân Vitalik trước đây đã đề xuất giải pháp tài khoản thông minh thống nhất và dễ quản lý cho toàn bộ chuỗi, giải pháp này sử dụng Ethereum hoặc ZKRollup có độ bảo mật cao làm chuỗi nguồn, triển khai hợp đồng Keystore, lưu trữ khóa toàn cầu của người dùng và sau đó là người dùng. Tất cả các tài khoản hợp đồng thông minh trên L2 đều chia sẻ khóa chung được lưu trữ trong hợp đồng Keystore.

(Nguồn hình ảnh: https://vitalik.ca/general/2023/06/20/deeperdive.html)

Tuy nhiên, giải pháp này cực kỳ tốn kém, tức là mỗi khi khóa toàn cầu được hợp đồng Keystore ghi lại trên chuỗi nguồn thay đổi, mỗi tài khoản trên chuỗi L2/chuỗi đích cần đồng bộ hóa khóa mới thông qua tương tác chuỗi chéo. Chi phí tương tác chuỗi chéo giữa Ethereum và L2 quá cao và người dùng đơn giản là không đủ khả năng chi trả. Cũng cần lưu ý rằng tài khoản hợp đồng thông minh khác với tài khoản EOA, tài khoản EOA vốn là hợp nhất nhiều chuỗi (thống nhất giữa các chuỗi EVM) do phương thức tạo địa chỉ duy nhất, nhưng tài khoản hợp đồng thông minh lại hoàn toàn khác và gây khó khăn cho người dùng để có được tài khoản hợp đồng thông minh có cùng địa chỉ trên các chuỗi khác nhau.

Về vấn đề này, Particle Network đã đề xuất một cách tiếp cận của riêng mình. Mặc dù ý tưởng chung nhất quán với ý tưởng của Vitalik, đó là tách riêng bộ lưu trữ và mã của các tài khoản thông minh, Particle Network có kế hoạch sử dụng một chuỗi độc lập - Particle Network Chain làm cơ sở dữ liệu lưu trữ toàn chuỗi của các tài khoản thông minh, thông qua bên thứ ba. giải pháp nhắn tin chuỗi chéo (LayerZero, CCIP, Axelar, Connext, v.v.) Đồng bộ hóa các thay đổi của người dùng đối với bộ nhớ tài khoản với tài khoản cục bộ trên các chuỗi khác.

(Cấu trúc trừu tượng tài khoản đa chuỗi của Mạng hạt)

Cụ thể, hệ thống trừu tượng tài khoản toàn chuỗi của Particle Network cho phép người dùng có địa chỉ tài khoản hợp đồng thông minh thống nhất trên các chuỗi EVM khác nhau, yêu cầu triển khai một bộ Hợp đồng người triển khai trên các chuỗi khác nhau;

Người dùng phải kích hoạt việc tạo tài khoản mới trên Chuỗi mạng hạt và sau đó Chuỗi hạt sẽ kích hoạt Hợp đồng người triển khai trên tất cả các chuỗi để đảm bảo rằng địa chỉ tài khoản hợp đồng thông minh được tạo cho người dùng trên các chuỗi khác nhau được thống nhất hoặc người dùng có thể kích hoạt việc tạo tài khoản mới trên các chuỗi khác. Trong trường hợp nhận thức, quá trình tương tác đa chuỗi được hoàn thành thông qua hợp đồng trên chuỗi Hạt và Mã thông báo Khí hợp nhất có thể được sử dụng làm phương thức thanh toán phí thống nhất.

Việc trừu tượng hóa tài khoản toàn chuỗi cũng giúp cho Hoạt động của người dùng trên chuỗi chéo có thể thực hiện được. Thông qua Hoạt động của người dùng của chuỗi nguồn và Gas tương ứng để thanh toán, Giao dịch của chuỗi mục tiêu có thể được kích hoạt. Ví dụ: USDC của Polygon có thể được sử dụng để mua NFT trên cơ sở.

Tuy nhiên, giải pháp của Particle Network yêu cầu mức độ cộng tác cao giữa Hợp đồng người triển khai và thành phần nhắn tin chuỗi chéo để đạt được sự đồng bộ hóa của Tài khoản đa chuỗi và Lưu trữ chuỗi nguồn. Điều này thực sự đặt ra các yêu cầu cao hơn đối với cầu nối tin nhắn oracle hoặc chuỗi chéo được sử dụng (vấn đề này dường như tồn tại trong tất cả các giải pháp liên quan đến khả năng tương tác toàn chuỗi).

Tuy nhiên, việc đồng bộ hóa tài khoản chuỗi chéo của người dùng có thể cấu hình linh hoạt các kết hợp Message Bridge khác nhau, thay vì chỉ dựa vào một Bridge nhất định. , Axelar và Connext nằm trên chuỗi mục tiêu. Việc xác nhận thay đổi Bộ lưu trữ có thể giải quyết gần đúng vấn đề phụ thuộc một điểm này.

Khả năng tương tác toàn chuỗi liền mạch trên EVM và không phải EVM là một bước tiến nữa hướng tới việc trừu tượng hóa tài khoản toàn chuỗi trong hệ sinh thái Ethereum.

Mặc dù có quản lý khóa và các tài khoản thống nhất trên toàn chuỗi EVM, vẫn còn chỗ để tối ưu hóa trong việc trừu tượng hóa tài khoản toàn chuỗi: các chuỗi không tương thích với EVM, chẳng hạn như Aptos, Solana, Sui, v.v., không thể đảm bảo rằng Địa chỉ tài khoản hợp đồng thông minh do người dùng tạo phù hợp với Tính nhất quán EVM trên chuỗi; đồng thời, nếu chuỗi không phải EVM không triển khai giao thức EIP-4337 với giải pháp tương đương thì sẽ khó tuân theo khái niệm toàn diện -sự trừu tượng hóa tài khoản chuỗi do Vitalik và Particle Network đề xuất trong bài viết trước.

Ngoài ra, còn có chỗ cần cải thiện trong chính dự án ví tương thích EIP-4337. Các nút Bundler được hầu hết các ví thông minh sử dụng chính thức chạy độc lập và thậm chí không liên lạc với nhau. Nhiều dự án ví thông minh thực sự hình thành chuỗi riêng, điều này sẽ mang lại nhiều rủi ro (chống kiểm duyệt, tính khả dụng). Việc xây dựng một giao diện mặt trước duy nhất được thống nhất trên hầu hết các chuỗi sẽ rất khó khăn. Một giải pháp là giới thiệu thiết kế tập trung vào mục đích, thêm một lớp phía trên tính năng trừu tượng hóa tài khoản toàn chuỗi và xử lý hệ sinh thái EIP-4337 của Ethereum hoặc các cơ sở trừu tượng hóa tài khoản gốc của chuỗi khác (chẳng hạn như zkSync) dưới dạng Bộ giải/phiên bản cụ thể trong loại Lò phản ứng và cách chọn Bộ giải thích hợp là một nhiệm vụ cấp cao hơn.

Lấy Mạng hạt làm ví dụ, nó đề xuất một tập hợp các giải pháp triển khai Ý định tập trung vào trừu tượng ngắn gọn và các dự án trừu tượng hóa tài khoản khác nhau chỉ là một loại phiên bản có trong danh mục Bộ giải trong giải pháp Ý định.

Trước hết, giao diện người dùng sẽ chịu trách nhiệm chuyển đổi các yêu cầu ngôn ngữ tự nhiên hoặc tương tác tùy ý của người dùng thành các mô tả theo chương trình cụ thể, bao gồm các ràng buộc đầu vào và các ràng buộc đầu ra (nói một cách thẳng thắn, nó có nghĩa là các điều kiện đầu vào và phạm vi kết quả đầu ra đáp ứng nhu cầu của người dùng). yêu cầu) , thì một hoặc một số Bộ giải trong mạng Bộ giải sẽ chuyển tiếp Giao dịch có chứa các ràng buộc đầu vào và đầu ra cụ thể tới hợp đồng Bộ giải được triển khai trên chuỗi (Bộ giải không chỉ có cơ sở nút mà còn có các phần hợp đồng trên chuỗi). Hợp đồng Solver sẽ gửi hướng dẫn Intent đến hợp đồng Reactor (quản lý tài khoản của người dùng trên chuỗi) và hợp đồng sau sẽ gọi các mô-đun khác để hoàn thành tương tác cuối cùng.

Yêu cầu của người dùng được mạng Bộ giải biết trước tiên, do đó người dùng không cần biết quá nhiều về chuỗi cơ bản hoặc việc xây dựng các giải pháp trừu tượng hóa tài khoản khác nhau. Phần này có thể được giao cho Bộ giải để xây dựng một giải pháp cụ thể.

Tất nhiên, những ý tưởng này hiện chỉ là khung lý thuyết và các chi tiết triển khai tiếp theo vẫn chưa được Particle Network chính thức đưa ra.

Điều tương đối rõ ràng hiện nay là một thị trường Bộ giải cạnh tranh chắc chắn sẽ xuất hiện trong tương lai và người dùng có thể bắt đầu đấu giá và để nhiều Người giải quyết đưa ra các giải pháp khác nhau. Giải pháp tốt nhất có thể được chọn thông qua các giao dịch mô phỏng cục bộ. Bộ giải tương ứng. Đối với hình thức khuyến khích, nó phụ thuộc vào sự cân nhắc của các nhà thiết kế giao thức của mạng Bộ giải (Mạng hạt có kế hoạch sử dụng mã thông báo PNT làm mã thông báo khuyến khích cho thị trường đấu giá Bộ giải của nó).

Ý định hiện tại về cơ bản che chắn các chi tiết phức tạp của lớp thấp hơn và trừu tượng hóa lớp cao hơn. Thiết kế phân lớp như vậy với bản chất của giao thức TCP/IP là điều cần thiết cho trải nghiệm và sự phát triển của người dùng với khả năng tương tác liền mạch trên toàn bộ chuỗi. tình trạng.

Chuẩn bị cho việc áp dụng rộng rãi việc trừu tượng hóa tài khoản

Sau khi chúng tôi tối ưu hóa khung 4337 trong hệ sinh thái Ethereum từ mọi góc độ, chúng tôi cũng đã thúc đẩy khả năng tương tác liền mạch trên toàn bộ hệ sinh thái Ethereum và không phải Ethereum. bao gồm cả phía cung và phía cầu. Trong khi giảm nhu cầu người dùng cuối sử dụng các sản phẩm và dịch vụ Web3 khác nhau, nó cũng có thể tập trung vào việc phục vụ các nhà phát triển và hạ thấp ngưỡng cho các nhà phát triển.

Một trong những sản phẩm tốt nhất để đảm nhận vai trò này là sản phẩm ví dưới dạng dịch vụ trừu tượng hóa tài khoản mô-đun của Particle Network (Modular Smart Wallet-as-as-Service):

(Kiến trúc ví thông minh dưới dạng dịch vụ của Particle Network)

Ngoài các tính năng thân thiện với nhà phát triển ở trên, tính năng quan trọng nhất là sản phẩm Ví thông minh dạng mô-đun dưới dạng dịch vụ của Particle Network, sản phẩm này xây dựng trường trừu tượng hóa tài khoản hướng đến nhà phát triển dựa trên tính toán chữ ký. Các mô-đun sản phẩm trừu tượng hóa tài khoản tự phát triển, tích hợp nhiều loại sản phẩm và dịch vụ trừu tượng hóa tài khoản, có thể nhanh chóng thúc đẩy việc các nhà phát triển áp dụng các sản phẩm và dịch vụ trong toàn bộ lĩnh vực trừu tượng hóa tài khoản.

(Thiết kế mô-đun của Ví thông minh dưới dạng dịch vụ của Mạng hạt)

Hãy để công nghệ phục vụ nhu cầu. Sau khi giải quyết các hạn chế của khung ERC-4337 từ mọi góc độ, việc cải thiện trải nghiệm của nhà phát triển sẽ thúc đẩy việc sản xuất nhiều sản phẩm hơn với trải nghiệm người dùng tuyệt vời và đẩy nhanh quá trình chuyển đổi ngành Web3 từ ngành tài chính thân thiện với cypherpunk cho ngành công nghiệp cấp tiêu dùng thân thiện với công chúng.