Tóm tắt ngắn gọn;

Kể từ năm 2022, trừu tượng hóa tài khoản đã được rộng rãi thảo luận trong lĩnh vực, và khung trò chơi tập trung vào EIP-4337 dường như đã trở thành một sự thống nhất chung trong ngành công nghiệp. Sự phổ biến của khái niệm trừu tượng hóa đã thúc đẩy mọi người chú ý hơn đến những thành phần tương tác người dùng ngưỡng thấp như vậy.

Tuy nhiên, EIP-4337 vẫn đối mặt với những điểm đau như sự phân mảnh Tài khoản Thông minh và trải nghiệm người dùng rất phân mảnh trên các chuỗi. Bài viết này lấy các dự án như Biconomy, Safe Core và Particle Network làm ví dụ để khám phá cách thúc đẩy phát triển lĩnh vực trừu tượng hóa tài khoản trong khung EIP-4337.

Từ quan điểm về trừu tượng hóa quá trình giao dịch, hiểu khái niệm “trừu tượng hóa tài khoản”

Về trừu tượng hóa tài khoản, Vitalik đã lần lượt chỉ ra rằng đó là điều kiện cần để giảm ngưỡng người dùng cho Ethereum và đạt được sự gia nhập đại trà. 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 việc thanh toán gas, và khởi xướng giao dịch trên chuỗi mà không có bất kỳ tài sản nào (phổ biến được biết đến với giao dịch không gas). Chỉ khi đạt được những tiền đề này, tỷ lệ chuyển đổi của người dùng mới sang ứng dụng Web3 mới có thể được cải thiện.

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

Trừu tượng hóa tài khoản nhằm tối ưu hóa từ cấu trúc cơ bản của các tài khoản hợp đồng thông minh, mở đường cho thế hệ tiếp theo của các hệ thống tài khoản thông minh.

Tuy nhiên, nếu chúng ta nhìn vào 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 sự tập trung của họ không phải là vào mô hình tài khoản chính. 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 / modularizing toàn bộ quá trình xử lý của một giao dịch từ việc khởi đầu đến khi được các nút nhận, xác minh chữ ký, thanh toán gas, v.v., thay vì tập trung thực sự vào việc trừu tượng hóa cấu trúc tài khoản. Do đó, có vẻ phù hợp hơn khi gọi các đề xuất này là “trừu tượng hóa giao dịch”.

Nếu chúng ta hiểu những đề xuất trừu tượng hóa tài khoản nổi tiếng từ góc nhìn của 'trừu tượng hóa quy trình xử lý giao dịch', chúng ta có thể dễ dàng hiểu rõ các điểm then chốt của chúng: loại trừ giao dịch này thực sự nhằm mục đích mang đến trải nghiệm của người dùng cấp Web2 khi nhập và sử dụng sản phẩm vào hệ thống Ethereum, chẳng hạn như danh sách đen/danh sách trắng, giao dịch khởi đầu trong một khoảng thời gian mà không cần xác minh danh tính, giao dịch miễn phí gas, thanh toán phí bằng tiền đồng, v.v.

Một số người có thể đặt câu hỏi: Không phải các chức năng này đã được thực hiện trong quá khứ với các ví hợp đồng thông minh hiện có sao? Giá trị của các chương trình trừu tượng hóa tài khoản như EIP-4337 là gì?

Bản chất của EIP-4337: Trừu tượng hóa tài khoản như một Giải pháp Cục bộ Tối ưu trong Hệ sinh thái Ethereum

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

Mục tiêu cốt lõi của các EIP liên quan đến trừu tượng hóa tài khoản là giải quyết những hạn chế hiện diện trong các dự án ví tiền điện tử khác nhau bằng cách giới thiệu một khung chuẩn cụ thể được thiết kế đặc biệt cho các ví hợp đồng thông minh. Khung này nhằm chuyển đổi cấu trúc tài khoản trong hệ sinh thái Ethereum từ một cấu trúc chức năng cơ bản sang một cấu trúc thông minh phức tạp hơn, từ đó tăng cường hiệu quả và khả năng mở rộng của hệ sinh thái tổng thể.

Điều này tương tự như tình hình trước khi ERC-20 hoặc ERC-721 xuất hiện, nơi các phương pháp triển khai, chức năng và các chức năng/giao diện được cung cấp của nhiều mã thông báo không nhất quán. Sự không nhất quán này không có lợi cho việc phát triển các cơ sở hạ tầng bên thứ ba bổ sung và kiểm tra mã (rất khó để tưởng tượng mức độ mà các ứng dụng DeFi có thể phát triển mạnh mẽ không có giao thức ERC-20).

Các giao thức tiêu chuẩn/ tiêu chuẩn triển khai chức năng là tiền đề cho các câu chuyện modul, và các phương pháp phát triển modul gần như là tiền đề cho sự phát triển sôi động trong bất kỳ lĩnh vực nào (chia sẻ lao động là nguyên tắc cơ bản đầu tiên của việc cải thiện hiệu suất).

Cuối cùng, EIP-4337 đã xuất hiện.

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

EIP-4337 định nghĩa một bộ tiêu chuẩn giao diện hoàn chỉnh, làm rõ các module mà một ví thông minh theo giao thức 4337 nên có, và các chức năng/giao diện mà mỗi module nên triển khai, như Bundler, EntryPoint, và Paymaster, và các chức năng có thể gọi mà những thành phần này nên cung cấp.

Khi các thông số này được xác định rõ ràng, sự tương tác giữa các thành phần khác nhau trở nên rõ ràng hơn, giúp dễ dàng áp dụng tư duy thiết kế theo mô-đun vào việc thiết kế trừu tượng hóa tài khoản và ví thông minh, từ đó đem lại lợi ích lớn cho các nhà phát triển mô-đun ví.

Tất nhiên, hoàn toàn từ góc độ của người dùng, giá trị mà mô hình phát triển ví thông minh modul mang lại vẫn chưa rõ ràng vì người dùng có thể không cảm nhận được sự thay đổi nhiều trong ví trừu tượng hóa tài khoản trong thời gian ngắn. Tuy nhiên, trong 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. Nó đặt nền móng cho sự phát triển dài hạn của các ví trừu tượng hóa tài khoản và là một cột mốc mang ý nghĩa thời đại.

Tuy nhiên, EIP-4337 vẫn còn nhiều vấn đề chưa được giải quyết, như:

1. Chức năng của trừu tượng hóa tài khoản không đủ plug-and-play, làm cho việc cho các nhà phát triển khác nhau phải tự tạo lại từ đầu trở nên dễ dàng.

2. Khả năng tương thích kém của các mô-đun tài khoản dẫn đến một hệ sinh thái phân mảnh của các hệ thống tài khoản.

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

Trong các phần tiếp theo, chúng tôi sẽ thảo luận về các giải pháp cho những vấn đề này.

Hướng tối ưu hóa một: Tính năng cắm và chạy Modul hóa của 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 rằng một trong những điểm thảo luận cốt lõi hiện tại liên quan đến trừu tượng hóa tài khoản là làm thế nào để đạt được việc phân chia mô-đun tốt hơn của các ví trừu tượng hóa tài khoản và làm cho việc chia mỗi mô-đun trở nên tinh tế hơn.

Ví dụ, Biconomy, dựa trên EIP-4337 (và sẽ giới thiệu EIP-6900 tinh tế hơn trong tương lai), đề xuất câu chuyện về việc tăng cường tính linh hoạt và modularization của trừu tượng hóa tài khoản để khuyến khích sự phát triển modul hóa hơn của hệ sinh thái trừu tượng hóa tài khoản.

Chức năng cắm và chạy của trừu tượng hóa tài khoản được phân mảnh được thực hiện bằng cách rõ ràng qua một giao thức mô tả chi tiết các mô-đun chính liên quan đến ví hợp đồng thông minh, các giao diện/chức năng mà các mô-đun này nên thực thi, và cách mà các giao diện này được đặt tên và gọi. Sau đó, các nhà phát triển bên thứ ba sẽ phát triển các thành phần với các chi tiết khác nhau theo ý tưởng của riêng họ, nhưng các thành phần này sẽ tuân thủ tất cả các yêu cầu được đề cập trong giao thức.

Phiên bản V2 của Biconomy, dựa trên EIP-4337 như là khung giao thức, đã xây dựng các tiêu chuẩn chi tiết hơn và thêm một loạt các giao diện không được đề cập trong 4337. Trong khi xác định các chức năng mà Bundler, Smart Contract Wallet, Paymaster và các module khác nên có, Biconomy cho phép các nhà phát triển bên thứ ba triển khai các module với các chi tiết mã khác nhau nhưng có các tính năng tương tự và các phiên bản khác nhau, miễn là chúng tuân theo các quy tắc giao thức được xác định trước bởi Biconomy (tương thích với EIP-4337).

Trong khi đó, Biconomy cũng đã giới thiệu khẩu hiệu của “Cửa hàng Module.” Trong khi tích cực triển khai SDK module trừu tượng hóa tài khoản, Biconomy khuyến khích các nhà phát triển nộp các module trừu tượng hóa tài khoản do chính họ thiết kế và khởi xướng “Module as a Service,” cho phép tất cả các dự án ví tiền điện tử tuân thủ giao thức EIP-4337 có thể trực tiếp áp dụng các module trừu tượng hóa tài khoản này được viết bởi bên thứ ba. Khi người dùng tạo tài khoản thông minh thông qua giao diện trước, họ cũng sẽ có nhiều lựa chọn module đa dạng hơn để chọn lựa.

Modularization không chỉ giúp phân chia lao động mà còn cho phép người dùng nhanh chóng chuyển đổi, thêm hoặc loại bỏ các tính năng cụ thể trong ví thông minh (nói một cách đơn giản, nó phân chia sự tinh tế thành các thành phần tinh tế hơn).

Biconomy nhấn mạnh rằng, mức độ modularization càng cao trong các ví hợp đồng thông minh, càng ít thay đổi cần thiết khi cập nhật hoặc nâng cấp (không cần phải 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ố module bên ngoài cụ thể), giúp cho việc thay thế một số thành phần cụ thể dễ dàng hơn đối với các người dùng hoặc nhà phát triển khác nhau.

Trong phiên bản tương lai của giải pháp trừu tượng hóa tài khoản mới của Biconomy, nó cũng sẽ tham chiếu đến EIP-6900, điều này tạo điều kiện tốt hơn cho việc modularization hơn EIP-4337.

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

Về đề xuất EIP-6900, Safe (trước đây là Gnosis Safe) thực sự đã phát hành một bản trắng sách về Giao thức Safe Core liên quan đến nó vào tháng 8 năm nay, mà rút nhiều từ EIP-6900.

EIP-6900 chỉ ra rằng một vấn đề hiện tại của trừu tượng hóa tài khoản modulized là vấn đề “phân mảnh” hoặc vấn đề “đảo” của tài khoản. Ví dụ, trong khi 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 có thể tương thích với EIP-4337, mức độ trừu tượng của EIP-4337 cho các mô-đun khác nhau không đủ cao, và độ tinh mịch khá thô. Điều này để lại “quá mức” tự do cho các nhà phát triển mô-đun Tài khoản Thông minh (các tài khoản thông minh lưu trữ thông tin người dùng và ghi lại phần lõi của việc xác minh giao dịch tùy chỉnh và logic thanh toán gas).

Kết quả là, các dự án ví tiền điện tử khác nhau thường có xu hướng thiết kế các mô-đun Tài khoản Thông minh với các đặc tính độc đáo. Theo thời gian, 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ính tương thích với mô-đun Tài khoản Thông minh của người cung cấp, dẫn đến sự xuất hiện của một chuỗi cung ứng cố định từ trên xuống dưới. Điều này dẫn đến sự phân mảnh và sự ngắt kết nối không tránh khỏi trong hệ sinh thái mô-đun trừu tượng hóa tài khoản. (Điều này tương tự như vào những ngày đầu của ngành công nghiệp máy tính khi các nhà phát triển hệ điều hành phải xem xét tính tương thích với các thiết bị phần cứng từ các nhà sản xuất phần cứng máy tính khác nhau.)

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

Sau khi vẽ trên các ý tưởng của EIP-6900, bản báo cáo trắng về Giao thức Safe Core đã thực hiện các tinh chỉnh chi tiết hơn cho Tài khoản Thông minh (tài khoản ví hợp đồng thông minh của người dùng). Giao thức Safe Core chia mỗi mô-đun gọi được của một tài khoản ví hợp đồng thông minh thành các danh mục khác nhau như Plugins, Hooks, validator chữ ký và bộ xử lý chức năng.

Các mô-đun tài khoản thông minh được tạo ra càng nhẹ càng tốt, với hợp đồng tài khoản chỉ lưu trữ các dữ liệu và chức năng cơ bản nhất, trong khi các chức năng có thể di chuyển ra ngoài được thực hiện bởi các mô-đun chuyên biệt như “bộ xử lý chức năng” hoặc “Plugin.” Điều này tuân theo nguyên lý của Dao cạo Occam: “Thực thể không nên được nhân đôi một cách không cần thiết.”

Nếu tài khoản thông minh chính nó đủ nhẹ và không liên quan đến quá nhiều chi tiết tinh tế, tài khoản thông minh được phát triển bởi các nhà sản xuất khác nhau sẽ giống nhau hơn về cấu trúc nội bộ, và tính tương thích cũng cao hơn.

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

Nói chung, UserOperation sẽ đầu tiên kích hoạt một Plugin cụ thể, sau đó hợp đồng Quản lý sẽ kiểm tra xem trạng thái của Plugin có bình thường không (được ghi trong danh sách đăng ký). Nếu bình thường, hợp đồng Quản lý sẽ cho phép yêu cầu của Plugin tiếp tục. Nếu cần thiết, Plugin có thể gọi một số chức năng cung cấp bởi một số Hooks, 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 sửa đổi.

Qua quá trình phân đoạn và lập lịch module tinh tế như đã đề cập ở trên, Giao thức Safe Core cố gắng thúc đẩy một giao thức tương thích module trừu tượng hóa tài khoản mã nguồn mở. Ý tưởng cốt lõi của nó là làm cho Smart Accounts nhẹ nhàng nhất có thể, biến chúng thành các tài khoản EOA đơn giản, nhằm cải thiện tính tương thích giữa các module Smart Account được phát triển bởi các nhà sản xuất khác nhau.

Tối Ưu Hóa Hướng Ba: Trừu Tượng Hóa Tài Khoản Thống Nhất Trên Các Chuỗi, Đạt Được Tài Khoản Nhất Quán Trên Các Chuỗi Khác Nhau

Tuy nhiên, ngay cả với những giải pháp đã đề cập, vẫn còn một vấn đề lớn chưa giải quyết: các chuỗi khác nhau và các giải pháp Layer 2 khác nhau đều đang tiến hành các kế hoạch thực hiện trừu tượng hóa tài khoản khác nhau với các hình thức xung đột, nhiều trong số đó xung đột với EIP-4337, như zkSync Era, Starknet, Flow, v.v. Sự phân mảnh này trong UX của ví, ví dụ, làm cho việc thống nhất địa chỉ ví thông minh của người dùng trên Starknet với địa chỉ trên Arbitrum trở nên không thể.

Hơn nữa, trong môi trường đa chuỗi, người dùng đã triển khai các 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 lưu trữ trong những hợp đồng này. Nếu dữ liệu người dùng như các khóa cần được cập nhật, các giao dịch phải được lặp lại trên nhiều chuỗi, làm cho việc đảm bảo tính nhất quán của Tài Khoản Thông Minh trở nên khó khăn.

Vitalik đã từng đề xuất một giải pháp tài khoản thông minh thống nhất và dễ quản lý trên tất cả các chuỗi. Giải pháp này sử dụng Ethereum hoặc một ZKRollup cực kỳ an toàn như chuỗi nguồn, triển khai một hợp đồng Keystore để lưu trữ các khóa toàn cầu của người dùng, sau đó tất cả các tài khoản hợp đồng thông minh trên Layer 2 chia sẻ các khóa toàn cầu được lưu trữ trong hợp đồng Keystore.

Tuy nhiên, giải pháp này đi kèm với chi phí cực kỳ cao. Mỗi khi có thay đổi trong các khóa toàn cầu được ghi lại bởi hợp đồng Keystore trên chuỗi nguồn, mỗi tài khoản trên chuỗi L2/mục tiêu cần đồng bộ hóa các khóa mới thông qua tương tác qua chuỗi. Tuy nhiên, chi phí của tương tác qua chuỗi giữa Ethereum và L2 quá cao đối với người dùng có thể chi trả. Ngoài ra, quan trọng phải lưu ý rằng tài khoản hợp đồng thông minh khác với tài khoản EOA. Trong khi tài khoản EOA, do phương pháp tạo địa chỉ duy nhất của họ, tự nhiên được thống nhất trên nhiều chuỗi (trong hệ sinh thái EVM), tài khoản hợp đồng thông minh là hoàn toàn khác biệt, làm cho việc người dùng có được tài khoản hợp đồng thông minh với cùng một địa chỉ trên các chuỗi khác nhau trở nên khó khăn.

Như một phản ứng với điều này, Mạng Hạt đã đề xuất phương pháp riêng của mình. Mặc dù ý tưởng chung tương thích với khái niệm của Vitalik về việc tách Biểu mẫu và Mã của các tài khoản thông minh, Mạng Hạt dự định sử dụng một chuỗi riêng - Chuỗi Mạng Hạt - như cơ sở dữ liệu Lưu trữ toàn chuỗi cho các tài khoản thông minh. Thông qua các giải pháp tin nhắn liên chuỗi của bên thứ ba (như LayerZero, CCIP, Axelar, Connext, v.v.), Mạng Hạt dự định đồng bộ hóa các thay đổi đối với Lưu trữ của một tài khoản đến các Tài khoản cục bộ của các chuỗi khác.

(Cấu trúc Trừu tượng Tài khoản Đa Chuỗi của Particle Network)

Cụ thể, hệ thống trừu tượng hóa tài khoản toàn chuỗi của Mạng Particle nhằm cung cấp cho người dùng một đị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. Điều này đòi hỏi triển khai một bộ Hợp đồng 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 ra một tài khoản mới trên Chuỗi Mạng Particle, sau đó Chuỗi Particle sẽ kích hoạt tất cả các Hợp đồng Triển khai trên các chuỗi khác nhau để đảm bảo rằng các địa chỉ tài khoản hợp đồng thông minh được tạo ra cho người dùng trên các chuỗi khác nhau là nhất quán. Hoặc người dùng có thể hoàn tất tương tác đa chuỗi thông qua các hợp đồng trên chuỗi Particle mà không cần nhận thức về các chuỗi khác, và họ có thể sử dụng Unified Gas Token như một phương thức thanh toán phí thống nhất.

Trừu tượng hóa tài khoản toàn chuỗi cũng cho phép Hoạt động Người dùng Liên chuỗi, cho phép người dùng kích hoạt giao dịch trên chuỗi mục tiêu thông qua Hoạt động Người dùng và thanh toán gas tương ứng trên chuỗi nguồn. Ví dụ, nó cho phép mua NFT trên Base bằng cách sử dụng USDC của Polygon.

Tuy nhiên, giải pháp của Particle Network yêu cầu sự phối hợp cao giữa Hợp đồng Triển khai và các thành phần gửi thông điệp qua chuỗi để đồng bộ tài khoản đa chuỗi và Bộ nhớ chuỗi nguồn. Điều này đặt ra yêu cầu cao đối với cầu nối hoặc cầu nối gửi thông điệp qua chuỗi được sử dụng (một thách thức có vẻ tồn tại trong tất cả các giải pháp liên quan đến tương thích toàn bộ chuỗi).

Tuy nhiên, đồng bộ tài khoản qua chuỗi của người dùng có thể được cấu hình linh hoạt với các kết hợp khác nhau của Cầu thông điệp, thay vì phụ thuộc vào một Cầu duy nhất. Ví dụ, nó có thể được cấu hình với một chính sách 2/3, nơi các thay đổi vào Lưu trữ trên chuỗi mục tiêu chỉ được xác nhận sau khi có bất kỳ hai trong số LayerZero, Axelar hoặc Connext xác nhận thay đổi, điều này có thể làm giảm vấn đề phụ thuộc vào một điểm duy nhất.

Tính tương thích mượt mà giữa cả hai chuỗi EVM và không phải EVM đại diện cho một bước tiến xa hơn trong trừu tượng hóa tài khoản toàn chuỗi trong hệ sinh thái Ethereum. Mặc dù đã tiến xa trong quản lý khóa và tài khoản thống nhất trên chuỗi EVM, vẫn còn chỗ cho việc tối ưu hóa trong 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, như Aptos, Solana và Sui, không thể đảm bảo tính nhất quán của địa chỉ tài khoản hợp đồng thông minh được tạo ra bởi người dùng với những chuỗi EVM. Ngoài ra, các chuỗi không phải EVM có thể gặp khó khăn trong việc áp dụng khái niệm trừu tượng hóa tài khoản toàn chuỗi được đề xuất bởi Vitalik và Particle Network mà không thực hiện các giải pháp tương đương với giao thức EIP-4337.

Hơn nữa, còn chỗ để cải thiện trong các dự án ví tiền điện tử tương thích với EIP-4337. Hầu hết các ví thông minh sử dụng các nút Bundler được vận hành độc lập bởi các nền tảng tương ứng, thường không được kết nối với nhau. Sự cô lập này mang lại các rủi ro như sự chống lại kiểm duyệt và sẵn có. Xây dựng một giao diện mặt trước thống nhất trên hầu hết các chuỗi sẽ rất khó khăn. Một phương pháp để giải quyết vấn đề này là giới thiệu thiết kế tập trung vào ý định, thêm một lớp lên trên trừu tượng hóa tài khoản toàn chuỗi, xem xét 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 bản địa của các chuỗi khác (như zkSync) như các trường hợp cụ thể trong danh mục Solver/Reactor, với việc chọn lựa Solver phù hợp là một nhiệm vụ cấp cao hơn.

Đưa Mạng Hạt như một ví dụ, nó đề xuất một sự trừu tượng súc tích về việc thực hiện Trung tâm Ý định, nơi các dự án trừu tượng tài khoản khác nhau chỉ đơn giản là các trường hợp được bao gồm trong danh mục Solver trong khuôn khổ Ý định.

Đầu tiên, giao diện người dùng chịu trách nhiệm dịch các yêu cầu bằng ngôn ngữ tự nhiên hoặc bất kỳ tương tác người dùng nào thành các mô tả cụ thể về chương trình, bao gồm ràng buộc đầu vào và ràng buộc đầu ra (nói cách khác, điều kiện cho đầu vào chấp nhận được và phạm vi cho kết quả đầu ra chấp nhận được). Sau đó, một hoặc nhiều bộ giải trong mạng lưới Giải quyết sẽ chuyển tiếp Giao dịch chứa các ràng buộc đầu vào-đầu ra cụ thể đến các hợp đồng Giải quyết triển khai trên chuỗi (Giải quyết không chỉ bao gồm các cơ sở nút mà còn các thành phần hợp đồng trên chuỗi). Hợp đồng Giải quyết sau đó sẽ chuyển tiếp các hướng dẫn Intent đến hợp đồng Reactor (quản lý tài khoản trên chuỗi của người dùng), ủy quyền việc thực thi để hoàn thành tương tác cuối cùng.

Yêu cầu của người dùng được nhận ban đầu bởi mạng Solver, cho phép người dùng không cần quá quan tâm đến các chuỗi cơ bản hoặc việc xây dựng các kế hoạch trừu tượng tài khoản khác nhau, vì phần này được xử lý bởi Solver để xây dựng các giải pháp cụ thể.

Tất nhiên, những ý tưởng này hiện chỉ là một khung lý thuyết, và chi tiết triển khai vẫn đang chờ sự triển khai chính thức từ Particle Network. Điều rõ ràng là sẽ không thể tránh khỏi việc phát triển một thị trường Solver cạnh tranh trong tương lai, nơi người dùng có thể khởi động đấu giá cho nhiều Solver để đề xuất các giải pháp khác nhau. Thông qua các giao dịch mô phỏng cục bộ, giải pháp tối ưu có thể được chọn và Solver tương ứng có thể được thưởng. Còn đối với hình thức khuyến khích, nó phụ thuộc vào sự xem xét của các nhà thiết kế giao thức của mạng Solver (Particle Network dự định sử dụng token PNT làm khuyến khích cho thị trường đấu giá Solver của mình).

Intent hiện tại về cơ bản bảo vệ các chi tiết phức tạp cơ bản và trừu tượng hóa một tầng cao hơn. Một thiết kế lớp lớp như giao thức TCP/IP là cần thiết cho cả trải nghiệm người dùng và nhà phát triển trong tính tương tác liền mạch qua các chuỗi.

Chấp nhận sự phổ biến của trừu tượng hóa tài khoản

Khi chúng tôi tối ưu hóa khung 4337 trong hệ sinh thái Ethereum từ nhiều góc độ và đồng thời thúc đẩy tính tương thích liền mạch trên cả hệ sinh thái Ethereum và không phải Ethereum, để hỗ trợ việc áp dụng rộng rãi của trừu tượng hóa tài khoản, chúng tôi tin rằng vẫn cần một sản phẩm bao gồm cả phần cung lẫn cầu. Nó không chỉ giảm ngưỡng cho người dùng cuối sử dụng các dịch vụ sản phẩm Web3 khác nhau mà còn tập trung vào các nhà phát triển dịch vụ để giảm ngưỡng của họ.

Một trong những sản phẩm tốt nhất để thực hiện vai trò này là sản phẩm Ví Thông Minh Modul hóa Dịch vụ Ví Thông Minh Modul của Particle Network:

Dịch vụ cung cấp một API dễ sử dụng cho phép các nhà phát triển tích hợp chức năng trừu tượng hóa tài khoản mô-đun vào ứng dụng của họ một cách mượt mà. Các nhà phát triển có thể sử dụng dịch vụ này để tạo và quản lý tài khoản trên các chuỗi, thực hiện tương tác giữa các chuỗi và sử dụng phương thức thanh toán phí thống nhất. Dịch vụ như vậy sẽ cung cấp cho các nhà phát triển một cách linh hoạt và tiện lợi hơn để xây dựng các ứng dụng đa chuỗi, từ đó thúc đẩy việc áp dụng rộng rãi của trừu tượng hóa tài khoản.

Ngoài những tính năng dễ sử dụng dành cho các nhà phát triển được đề cập ở trên, khía cạnh quan trọng nhất là Sản phẩm Ví Thông Minh Modul-as-a-Service (Ví Thông Minh Modul-as-a-Service) của Particle Network đã xây dựng một hệ sinh thái mở cho trừu tượng hóa tài khoản trong cộng đồng phát triển, dựa trên việc tính toán chữ ký. Ngoài việc cung cấp các mô-đun sản phẩm trừu tượng hóa tài khoản phát triển bởi chính mình, nó tích hợp các loại sản phẩm và dịch vụ trừu tượng hóa tài khoản khác nhau, tạo điều kiện cho việc áp dụng nhanh chóng các sản phẩm và dịch vụ từ các nhà phát triển khác nhau trong toàn bộ lĩnh vực trừu tượng hóa tài khoản.

Bằng cách cân bằng công nghệ với nhu cầu và giải quyết các hạn chế của khung công việc ERC-4337 từ mọi khía cạnh, việc cải thiện trải nghiệm của nhà phát triển sẽ kích thích sự xuất hiện của nhiều sản phẩm với trải nghiệm người dùng xuất sắc hơn. Điều này sẽ thúc đẩy quá trình chuyển đổi của ngành công nghiệp Web3 từ việc thân thiện với người yêu thích tiền điện tử sang việc thân thiện với người tiêu dùng và phổ biến hơn.

免责声明：

1. Bài viết này được sao chép từ[腾讯网]Tất cả bản quyền thuộc về tác giả gốc [Peter Pan, CTO và Đồng sáng lập viên của Particle Network & Faust, Geek Web3]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Học cửađội, và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các 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 đội ngũ Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.