Cho dù đó là thị trường tăng giá hay thị trường giá xuống, hệ sinh thái Ethereum không ngừng xây dựng và tự tối ưu hóa. Trong số đó, Trừu tượng hóa tài khoản (AA) đã đạt được tiến bộ quan trọng trong những năm gần đây và đã thâm nhập vào tất cả các phần của hệ sinh thái Ethereum, bao gồm ứng dụng, cơ sở hạ tầng, người dùng và nhà phát triển. Chúng ta có thể thấy trước rằng việc áp dụng AA trên quy mô lớn sẽ hạ thấp ngưỡng sử dụng chuỗi khối nói chung và đưa trải nghiệm người dùng của web2 vào ngành công nghiệp web3.
Để nắm bắt cơ hội của thị trường AA tiềm năng trị giá hàng tỷ đô la, BlockPI có kế hoạch tích hợp AA vào các dịch vụ cơ sở hạ tầng của mình. Thông qua tích hợp và đổi mới trong lĩnh vực AA, BlockPI cam kết cung cấp cho người dùng AA một cách thuận tiện và hiệu quả hơn để tương tác với các tài khoản ví hợp đồng blockchain và hy vọng trở thành người dẫn đầu trong ngành này.
Trong bài viết này, nhóm BlockPI sẽ đi sâu vào hiểu biết của họ về AA và chia sẻ suy nghĩ từ quan điểm của một nhà cung cấp dịch vụ cơ sở hạ tầng.
EOA và ví hợp đồng
Khái niệm về AA bắt nguồn từ những hạn chế của tài khoản EOA. Tài khoản EOA (tài khoản thuộc sở hữu bên ngoài) là tài khoản người dùng trong Ethereum, được đại diện bởi khóa công khai (địa chỉ chuỗi khối) và được truy cập thông qua khóa riêng. Nó là một thành phần chính của hệ sinh thái Ethereum, cho phép người dùng chuyển tiền trên blockchain hoặc tương tác với các hợp đồng thông minh. Tuy nhiên, đối với nhiều người, bản thân việc sử dụng EOA có thể là một nhiệm vụ khó khăn. Hơn nữa, tài khoản EOA hiện tại vẫn còn một số bất tiện khi sử dụng làm ảnh hưởng đến trải nghiệm của người dùng.
Đầu tiên là vấn đề phí xăng. Mỗi giao dịch sẽ tiêu tốn của người dùng một lượng ETH đáng kể dưới dạng phí Gas (lấy giá Gas là 25 Gwei làm ví dụ, phí Gas cho một lần chuyển ETH đơn giản là khoảng 0,5 đô la Mỹ và sẽ đắt hơn khi tương tác với hợp đồng hoặc khi giá Gas cao hơn). Điều này làm cho các giao dịch nhỏ trở nên rất tốn kém, đặc biệt là trong thời gian tắc nghẽn mạng nghiêm trọng. Ngoài ra, chỉ ETH mới có thể được sử dụng để thanh toán cho Gas, điều đó có nghĩa là người dùng phải giữ ETH trong ví của họ, điều này tạo thành rào cản gia nhập cao đối với nhiều người dùng.
Thứ hai, đối với một số hoạt động phức tạp mà người dùng muốn đạt được, EOA phải dựa vào các hợp đồng thông minh khác. Ví dụ: nếu người dùng muốn đặt chuyển khoản định kỳ theo thời gian, người dùng cần chuyển ETH sang hợp đồng thông minh có chức năng này để thực hiện thao tác này.
Vấn đề thứ ba với EOA là thuật toán mã hóa chữ ký cố định. Mạng Ethereum sử dụng thuật toán chữ ký số có tên secp256k1 để đảm bảo tính xác thực và bảo mật của các giao dịch. Thuật toán này được mã hóa cứng vào hệ thống và người dùng không thể chọn sử dụng các thuật toán mã hóa khác.
Ngoài 3 vấn đề trên, mối quan hệ ràng buộc giữa khóa công khai và khóa riêng của EOA cũng là một vấn đề. Khóa riêng tư là cách duy nhất để người dùng truy cập vào EOA, nếu khóa riêng tư bị mất sẽ không lấy lại được. Điều này cũng có nghĩa là tất cả nội dung trong EOA được liên kết với nó sẽ không thể lấy lại được.
Đồng thời, EOA cũng có những hạn chế khi thực hiện một số tác vụ tuyến tính. Ví dụ: nếu người dùng muốn phê duyệt (phê duyệt), trao đổi (swap) và không phê duyệt mã thông báo (unapprove token) trong một thao tác, cần thực hiện ba giao dịch riêng biệt, điều này không hiệu quả và tốn thời gian.
Tin tốt là ví hợp đồng có thể giải quyết tất cả các vấn đề trên. Ví hợp đồng về cơ bản là một loại tài khoản hợp đồng thông minh cụ thể triển khai AA, có thể được sử dụng làm ví của người dùng trên Ethereum. Và nó có thể cung cấp cho người dùng một cách linh hoạt và cá nhân hóa hơn để quản lý tiền. Miễn là logic có thể được thực hiện bởi hợp đồng thông minh Ethereum, ví hợp đồng có thể nhận ra và cung cấp các chức năng tương ứng.
Cụ thể, nhiều hoạt động ví hợp đồng có thể được đóng gói thành một giao dịch trên chuỗi và các hoạt động này có thể chia sẻ chi phí Gas của giao dịch này. Nếu bên thứ ba sẵn sàng trả phí Gas, thì không cần phải trả Gas cho người dùng sử dụng ví hợp đồng. Ví hợp đồng cũng có thể hoàn thành nhiều nhiệm vụ tuyến tính cùng một lúc. Ngoài ra, ví hợp đồng cũng hỗ trợ thuật toán mã hóa chữ ký tùy chỉnh và thiết lập chức năng khôi phục ví, v.v.
Khi cuộc thảo luận về những lợi thế của ví hợp đồng vẫn tiếp tục, cộng đồng Ethereum đã thực sự tiến hành nghiên cứu dài hạn về ví hợp đồng. Mặc dù nhiều EIP đã khám phá các vấn đề liên quan đến việc trừu tượng hóa tài khoản, nhưng kể từ năm 2021, không có tiêu chuẩn thống nhất nào được thiết lập. Dưới đây là một số EIP tiêu biểu.
EIP-86
Được đề xuất lần đầu vào năm 2017 bởi Vitalik Buterin. Lược đồ này thực hiện một loạt các thay đổi với mục đích chung là xác minh chữ ký "trừu tượng hóa" và kiểm tra nonce, do đó cho phép người dùng tạo "hợp đồng tài khoản" có thể thực hiện kiểm tra chữ ký/nonce tùy ý.
EIP-2938
Trình bày vào năm 2020. Tiêu đề của EIP này là Tóm tắt tài khoản. Khái niệm về AA được mô tả rõ ràng trong EIP này. Nó giới thiệu một loại giao dịch mới, giao dịch AA. Giao dịch được bắt đầu bởi địa chỉ điểm vào (EntryPoint address) và gọi ví hợp đồng AA. EIP-2938 cung cấp một đặc điểm kỹ thuật thống nhất và chính thức giới thiệu bản tóm tắt tài khoản AA vào sự đồng thuận của Ethereum. Cụ thể, nó giới thiệu hai opcode mới, ba biến toàn cầu và cấu trúc tải trọng khác cho sự đồng thuận của Ethereum.
EIP-3074
Trình bày vào năm 2020. EIP này giới thiệu hai hướng dẫn EVM, AUTH và AUTHCALL. AUTH đặt các biến môi trường theo cơ quan ký ECDSA. AUTHCALL gửi cuộc gọi dưới dạng tài khoản được ủy quyền. Điều này cho phép các hợp đồng thông minh gửi giao dịch thay mặt cho EOA. Nhưng đây vẫn chưa phải là một giải pháp hoàn hảo cho AA. Trong quá trình giao dịch ủy quyền, EIP-3074 có một số hạn chế nhất định đối với việc truyền giá trị gốc. Và nếu người dùng mất quyền truy cập vào EOA, vẫn không có cách nào để lấy lại tài sản của mình. Nếu khóa riêng tư bị rò rỉ, người dùng cần chuyển tất cả nội dung sang tài khoản mới.
Không có đề xuất nào ở trên được chính thức đưa vào giao thức Ethereum do nhu cầu thay đổi ở lớp đồng thuận hoặc do các đề xuất không đủ toàn diện. Do đó, cộng đồng Ethereum tiếp tục khám phá cách đưa AA vào giao thức Ethereum mà không thay đổi sự đồng thuận và cuối cùng đề xuất EIP4337.
ERC - 4337
EIP-4337 ban đầu được đề xuất vào tháng 9 năm 2021 và được ủy quyền là ERC-4337 vào tháng 3 năm 2023. Các tác giả của nó bao gồm Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson và Tjaden Hess.
EIP-4337 là một đề xuất đột phá sẽ giới thiệu AA mà không thay đổi giao thức Ethereum cốt lõi. EIP-4337 cuối cùng đã trở thành tiêu chuẩn ERC-4337, mà các nhà xây dựng có thể sử dụng để triển khai ví hợp đồng thông minh của riêng họ. Đồng thời, tiêu chuẩn cũng giới thiệu một số cơ sở hạ tầng bổ sung bao gồm "Bundlers" và "UserOperation mempool". Theo cách này, nó thực sự sao chép một Ethereum mempool với các chức năng tương tự ở lớp trên của hệ thống chuỗi khối. Những gì người dùng gửi không còn là một giao dịch đơn lẻ, mà là UserOperation. Các UserOperations này có thể được đóng gói thành một giao dịch duy nhất và được gửi tới Ethereum.
Sau đây là giải thích kỹ thuật chi tiết về ERC-4337 trong Ethereum [tài liệu chính thức], với một số nhận xét hữu ích.
Vai trò chính của ERC-4337 và định nghĩa của chúng
UserOperation—mô tả cấu trúc của giao dịch được gửi thay mặt cho người dùng. Để tránh nhầm lẫn, nó không được đặt tên là "giao dịch" và nó sẽ được gửi tới Gói để được đóng gói cùng với các Hoạt động người dùng khác dưới dạng Gói. Gói sau đó được gửi trực tuyến dưới dạng một giao dịch.
Sender—tài khoản hợp đồng gửi UserOperation. Hợp đồng ví phải tuân theo tiêu chuẩn ERC-4337 để định cấu hình giao diện IAccount.
EntryPoint - hợp đồng đơn lẻ toàn cầu thực thi gói UserOperations. Điểm truy cập được hỗ trợ trong danh sách trắng Bundlers/Clients. Hợp đồng được nhóm Infinitism kiểm tra và phê duyệt để triển khai, đồng thời chịu trách nhiệm xử lý tất cả Hoạt động của người dùng và kết nối hợp đồng với các vai trò khác, bao gồm Nhà máy Ví, Trình tổng hợp và Người quản lý thanh toán. Tất cả hợp đồng đều ở cùng một địa chỉ trên chuỗi tương thích EVM.
Bundler—Nút đóng gói nhiều UserOperations từ mempool và tạo giao dịch EntryPoint.handleOps() (nút tạo khối hiện tại). Dịch vụ Bundler có thể chạy độc lập với các nút chuỗi khối và gửi UserOperations được đóng gói thông qua RPC.
Aggregator — Một hợp đồng phụ được các tài khoản tin cậy để xác minh chữ ký tổng hợp. Trình tổng hợp chữ ký được hỗ trợ trong danh sách trắng Bundlers/Clients. Trình tổng hợp phải định cấu hình giao diện IAggregator theo tiêu chuẩn ERC-4337.
Paymaster—một hợp đồng thông minh có thể thanh toán Gas thay cho bạn. Nếu ký gửi đủ ETH trong hợp đồng EntryPoint, nó có thể trả cho người gửi hợp đồng thông minh phí Gas của UserOperation, triển khai hiệu quả việc trừu tượng hóa Gas. Paymaster phải tuân theo tiêu chuẩn ERC-4337 để định cấu hình giao diện Paymaster. Paymaster có thể thỏa thuận với Người gửi. Ví dụ: Người gửi thanh toán USDC cho Paymaster và Paymaster sử dụng ETH để thanh toán Gas của UserOperations mà họ gửi. Trên thực tế, Paymaster có thể chọn hỗ trợ bất kỳ
Mã thông báo
, bao gồm cả ERC-20
Mã thông báo
thậm chí các chuỗi khác
Mã thông báo
。
Wallet Factory—một hợp đồng thông minh có thể tạo ví hợp đồng cho người dùng ERC-4337. Triển khai Wallet Factory không cần giấy phép. Là một hợp đồng thông minh trên chuỗi, mã của nó được mở cho công chúng và bất kỳ ai cũng có thể xem lại. Một Nhà máy Ví được sử dụng rộng rãi phải được kiểm toán đầy đủ bởi các chuyên gia.
Sơ đồ bên dưới giải thích cách hợp đồng EntryPoint tương tác với các tác nhân khác.
Các gói gọi hàm handleOps của hợp đồng EntryPoint, hàm này chấp nhận UserOperation làm đầu vào.
handleOps sẽ xác minh UserOperation trên chuỗi, kiểm tra xem nó có được ký bởi địa chỉ ví hợp đồng thông minh được chỉ định hay không và xác nhận xem ví có đủ Gas để bồi thường cho Bundler hay không.
Nếu xác minh được thông qua, handleOps sẽ thực thi chức năng ví hợp đồng thông minh theo chức năng và tham số đầu vào được xác định trong calldata của UserOperation.
Mặt khác, khi Bundler sử dụng EOA để kích hoạt chức năng handleOps, phí Gas sẽ phát sinh. Ví hợp đồng thông minh có thể thanh toán phí Bundlers Gas từ số dư tài khoản của chính nó hoặc yêu cầu hợp đồng Paymaster thanh toán cho nó. UserOperations không thể vượt qua bước xác minh ngoài chuỗi nếu không có đủ Gas, nghĩa là nó không thành công trước khi thực hiện giao dịch trên chuỗi. Ngay cả khi có đủ Gas, UserOperations vẫn có thể thất bại do lỗi thời gian chạy và các lý do khác trong quá trình thực thi. Đối với UserOperation, bất kể việc thực thi hợp đồng có thành công hay không, hợp đồng EntryPoint sẽ trả phí Gas cho Bundler kích hoạt chức năng handleOps.
Sau khi ERC-4337 có hiệu lực, giờ đây người dùng có thể bắt đầu giao dịch chuỗi khối theo hai cách. Một là cách truyền thống, nghĩa là EOA trực tiếp bắt đầu giao dịch. Cách khác là sử dụng tiêu chuẩn ERC-4337 để khởi tạo UserOperation thông qua Bundler, sau đó Bundler sẽ đóng gói nó với các UserOperations khác và gửi nó đến chuỗi mạng. Lưu đồ bên dưới minh họa sự khác biệt giữa giao dịch gửi EOA thông thường và giao dịch gửi UserOperation của ví hợp đồng ERC-4337.
Đường đã trải nhựa nhưng chưa có nhiều người đi bộ
ERC-4337 cung cấp một khuôn khổ mạnh mẽ cho người dùng và nhà phát triển sử dụng và xây dựng AA trên Ethereum. Mặc dù khuôn khổ này là một bước tiến quan trọng, nhưng vẫn còn một số thách thức và sự không chắc chắn cần được giải quyết.
Việc áp dụng AA vẫn còn ở giai đoạn sơ khai. Theo bảng phân tích Dune ERC-4337 [Trừu tượng hóa tài khoản ERC-4337], chỉ hơn 65k+ Thao tác người dùng được thực thi trên chuỗi, 90% trong số đó đến từ Đa giác. Do đó, số lượng UserOperations được thực hiện hiện tại vẫn còn rất ít, hầu hết là các thử nghiệm của nhà phát triển và chỉ một phần nhỏ đến từ người dùng thực. Chúng tôi lưu ý rằng các sản phẩm tích hợp AA vẫn đang ở giai đoạn đầu. Hiện tại, chúng ta có thể quan sát thấy rằng toàn bộ Bundlers vẫn đang trong tình trạng thua lỗ và khoản lỗ hiện tại là khoảng hơn 700 MATIC. Điều này chủ yếu là do một số Bundler trên Polygon ước tính sai lượng gas cần thiết, dẫn đến lượng Gas do EntryPoint trả về ít hơn lượng gas mà Gói đã gửi tiêu thụ. Vấn đề này cần được giải quyết ở cấp độ máy khách Bundler.
Ngoài ra, có một vài vấn đề cần được giải quyết. Một vấn đề như vậy là cách Bundler xử lý các lỗi giao dịch.
Sau khi đóng gói nhiều UserOperations lại với nhau, trước tiên, Bundlers sẽ mô phỏng giao dịch, phát hiện xem có xảy ra lỗi thực thi hợp đồng hay không và tính toán xem phí Gas do Người gửi hoặc Paymaster trả lại có lớn hơn phí Gas đã thanh toán hay không.
Nếu có lãi, Bundler sẽ gửi lô UserOperations này tới nút khối dưới dạng giao dịch. Tuy nhiên, vẫn có khả năng giao dịch không thành công, dẫn đến việc Bundler thanh toán phí Gas nhưng không nhận được khoản hoàn trả Gas từ EntryPoint. Ví dụ: người dùng có thể gửi hành động đến các Gói khác nhau. Nếu có chỗ cho lợi nhuận và mô phỏng thành công, Bundler cam kết nó vào chuỗi. Trong trường hợp này, nếu một UserOperation được gửi tới nút khối bởi các Bundler khác nhau cùng một lúc, thì chỉ một giao dịch sẽ thành công, điều đó có nghĩa là chỉ một Bundler sẽ nhận được phí Gas do EntryPoint trả lại và tất cả các Bundler khác sẽ không thành công do đến xích Và mất Khí. Mặc dù một số người có thể nghĩ rằng hành vi này nên được coi là một cuộc tấn công độc hại và lập luận rằng Bundler có thể cấm địa chỉ Người gửi và từ chối mọi yêu cầu trong tương lai từ địa chỉ này, đây không phải là giải pháp hợp lý vì người dùng có thể vô tình thực hiện hành động này. . Vấn đề này cần được giải quyết đúng cách bằng mã, có thể thông qua mạng bộ nhớ chung công khai đang được phát triển. Hơn nữa, Bundlers có thể bị thua lỗ do biến động gas đột ngột ngay cả khi giao dịch được gửi thành công và kết quả mô phỏng cho thấy vẫn có lợi nhuận.
Một vấn đề khác là giá trị có thể trích xuất tối đa (MEV) có thể thu được từ AA. Trong ngữ cảnh của Ethereum, MEV thường đề cập đến giá trị mà các công cụ khai thác hoặc bộ xử lý giao dịch khác trích xuất bằng cách thao túng thứ tự giao dịch trong một khối hoặc chèn các giao dịch của chính họ vào một khối. Người ta có thể nhận thấy rằng logic của MEV cũng có thể được áp dụng cho AA. Điều này là do trong AA, các Bundler có thể tự do đặt hàng UserOps, điều này cung cấp cho họ khả năng có được MEV. Tuy nhiên, việc Bundler có thể trích xuất MEV hay không tùy thuộc vào việc có thể gộp đủ các UserOperations lại với nhau hay không. Bây giờ toàn bộ thị trường AA vẫn còn ở giai đoạn sơ khai, vì vậy Bundler MEV cũng có thể được coi là ở giai đoạn sơ khai. Có thể thấy rằng MEV của AA có thể phát triển theo hai hướng: một là tương tự như mạng chính Ethereum, với sự tham gia của các bên tham gia như Flashbots, Ultra Sound và BloXroute; hướng còn lại là hình thành sự đồng thuận của Bundler để thực hiện phân loại công bằng. Cái sau sẽ loại bỏ hoàn toàn khả năng trích xuất MEV trong AA.
Sự phát triển tương lai
bộ nhớ công khai
Trong khi hệ sinh thái AA đã hoạt động, vẫn còn rất nhiều công việc phát triển phải được thực hiện. Nhìn vào toàn bộ hệ sinh thái AA, phần còn thiếu lớn nhất hiện nay là mempool công khai. Nhóm Etherspot, các nhà phát triển của ứng dụng khách Skandha Bundler, hiện đang phát triển mạng p2p với một mempool công khai. Mạng p2p của các mempool công cộng dự kiến sẽ ra mắt vào tháng 8 năm nay.
Thuật toán gói
Đồng thời, Ethereum Foundation đã tài trợ cho một số nhóm phát triển AA xuất sắc. Cho đến nay, một số ứng dụng khách Bundler đã được phát triển và hiện đang có sẵn. Trong số họ, một số rất trưởng thành. Chúng là Candide (Voltaire Bundler viết bằng Python), Pimlico (Alto Bundler viết bằng Type), Etherspot (Skandha Bundler viết bằng Type), Stackup (Stackup-Bundler viết bằng Go), v.v.
Ở đây có vấn đề về chiến lược đóng gói. Hiện tại, do số lượng UserOperations nhỏ, Bundlers có thể áp dụng logic đóng gói đơn giản, chẳng hạn như khoảng thời gian cố định hoặc một số UserOperations nhất định trong mỗi Bundle. Tuy nhiên, khi số lượng UserOperations tăng lên, đặc biệt là sau khi giới thiệu bộ nhớ công khai, chiến lược để chọn và đóng gói UserOperations trở nên phức tạp hơn. Lý do rất đơn giản: trong hệ sinh thái AA, không có cơ chế nào tương tự như giao thức đồng thuận chuỗi khối và nhóm Bundler đã trở thành một khu rừng tối tăm, mỗi Bundler ưu tiên các nhiệm vụ theo sở thích của mình và cạnh tranh với nhau. Trái ngược với các mempool công cộng, các mempool riêng có thể xuất hiện sớm hơn. Bởi vì khi đóng gói UserOperations từ public mempool sẽ không mang lại lợi nhuận thì vẫn có thể đóng gói UserOperations trong private mempool. Trong trường hợp này, Bundler cạnh tranh hơn với các Bundler khác khi đóng gói.
Ngoài ra, với sự phổ biến dần dần của mempool công khai, UserOperations trong đó có nhiều đặc điểm khác nhau, chẳng hạn như kỳ vọng lợi nhuận Gas khác nhau và độ phức tạp thực thi trên chuỗi. Các nhà đóng gói sẽ tiến hành mô phỏng ngoài chuỗi để đánh giá khả năng sinh lợi của các kết hợp Hoạt động người dùng khác nhau nhằm thiết lập các chiến lược đóng gói tương ứng của họ. Đóng gói nhiều UserOperations hơn có khả năng tạo ra lợi nhuận cao hơn, nhưng nó cũng làm tăng nguy cơ lỗi xác thực. Ngay cả khi quá trình xác minh được thông qua, rủi ro thực thi không thành công trên chuỗi vẫn tồn tại. Ngược lại, UserOperations ít đóng gói hơn thì ngược lại.
Các nhà đóng gói cần thiết lập các tham số khí giao dịch của riêng họ, điều này sẽ ảnh hưởng đến mức độ ưu tiên của các nhà sản xuất khối để thực hiện giao dịch này. Trong các điều kiện giá Gas ước tính và biến động Gas khác nhau, Bundlers có thể có các chiến lược đóng gói khác nhau. Đồng thời, cũng cần xem xét chi phí tài nguyên máy tính phần cứng cục bộ và tài nguyên nút chuỗi khối cho các tính toán chính sách và xác minh này. Ngoài ra, Bundler cũng cần đảm bảo trải nghiệm người dùng tốt cho người dùng và đảm bảo rằng người dùng không gặp phải sự chậm trễ quá mức sau khi gửi UserOperations.
Mặc dù các giải pháp cho những thách thức này vẫn chưa rõ ràng, nhưng chúng tôi có thể tự tin nói rằng sự phát triển của ngành AA và nỗ lực chung của các nhà phát triển cuối cùng sẽ giải quyết được những vấn đề này. Là một nhà xây dựng cơ sở hạ tầng, BlockPI hy vọng sẽ đóng vai trò là người giải quyết vấn đề trong sự phát triển của ngành công nghiệp AA, cho dù với tư cách là nhà phát triển hay cung cấp cơ sở hạ tầng thân thiện với AA cho các nhà phát triển khác.
*Cơ sở hạ tầng phải thích ứng với AA
AA trừu tượng hóa các vai trò khác nhau liên quan đến giao dịch trên chuỗi, bao gồm Người gửi, Người đóng gói, Người trả tiền gas, ví hợp đồng và Người ký, để người dùng có mức độ tự do cao hơn khi sử dụng chuỗi khối. Đồng thời, các nhà cung cấp cơ sở hạ tầng có thể triển khai độc lập các dịch vụ này theo đánh giá của riêng họ về thị trường.
Để thích ứng với việc áp dụng AA trên quy mô lớn, trước tiên các nhà cung cấp cơ sở hạ tầng cần cung cấp ít nhất hai dịch vụ cơ bản: dịch vụ Bundler và dịch vụ Paymaster.
Trong dịch vụ Bundler, nhà cung cấp cơ sở hạ tầng có thể cần phát triển mempool riêng cùng với Bundler để cung cấp trải nghiệm người dùng tốt. Cụ thể, các nhà cung cấp cơ sở hạ tầng cần tích hợp nhiều ứng dụng khách Bundler khác nhau để đảm bảo tính ổn định của các dịch vụ Bundler. Các ứng dụng khách Bundler này hiện cung cấp cho người dùng một số phương thức JSON RPC tiêu chuẩn do nhóm phát triển cốt lõi ERC-4337 cung cấp. Có thể thấy trước rằng sẽ có nhiều phương thức RPC hơn cho người dùng trong tương lai. Các nhà cung cấp dịch vụ cơ sở hạ tầng cần cập nhật hỗ trợ cho các phương pháp này một cách kịp thời trong quá trình này.
Ngoài ra, điều quan trọng là phải tối ưu hóa giữa API Bundler và RPC máy khách nút gốc. Máy khách nút hiện tại không được tối ưu hóa cho AA. Một số phương thức API của Bundler yêu cầu một chỉ mục đối với dữ liệu được cung cấp cho AA. Ví dụ: khi ứng dụng khách hiện tại tra cứu UserOperation theo hàm băm, ứng dụng đó cần quét nhật ký hợp đồng EntryPoint trong tất cả các khối. Nếu không có chỉ mục dữ liệu, mức tiêu thụ tài nguyên phần cứng của yêu cầu đơn lẻ này sẽ khá lớn và thời gian trả lại yêu cầu cũng sẽ trở nên rất dài.
Ngoài ra, để cung cấp cho người dùng trải nghiệm người dùng Gas-free và các dịch vụ đa dạng, các nhà cung cấp cơ sở hạ tầng cần hợp tác với các nhà cung cấp dịch vụ Paymaster khác nhau để tích hợp các dịch vụ Paymaster khác nhau. Đồng thời, theo nhu cầu thị trường, các nhà cung cấp cơ sở hạ tầng cũng có thể thiết kế các giải pháp tích hợp tiện lợi hơn dựa trên các dịch vụ Paymaster hiện có. Các dịch vụ khác, chẳng hạn như chữ ký tổng hợp, nhà máy ví, v.v., cũng là những hướng tiềm năng để phát triển và tích hợp cơ sở hạ tầng trong tương lai.
Nói tóm lại, để thích ứng với ứng dụng quy mô lớn của AA, các nhà cung cấp cơ sở hạ tầng cần liên tục cải thiện và mở rộng dịch vụ của họ. Điều này bao gồm tối ưu hóa các dịch vụ Bundler, hợp tác với các nhà cung cấp dịch vụ Paymaster khác nhau, tích hợp các giao diện API khác nhau và phát triển các dịch vụ tiềm năng khác. Khi ngành công nghiệp AA tiếp tục phát triển, những nỗ lực này sẽ giúp cung cấp trải nghiệm chuỗi khối hiệu quả, an toàn và thuận tiện hơn.
Hiện tại, BlockPI đang nỗ lực để đạt được các mục tiêu trên. Không chỉ vậy, chúng tôi đã liên lạc với hầu hết tất cả các khách hàng Bundler và nhà cung cấp dịch vụ Paymaster trong cộng đồng và sẽ tích hợp AA vào mạng BlockPI như nhiệm vụ phát triển hàng đầu của chúng tôi. Đồng thời, chúng tôi cũng tiến hành liên lạc chuyên sâu với các nhà phát triển ví AA để hiểu nhu cầu của người dùng. Chúng tôi chân thành chào đón tất cả các Bundler, Paymaster và ví liên lạc và hợp tác với chúng tôi.
Mục tiêu của BlockPI là xây dựng và phát triển hệ sinh thái AA cùng với cộng đồng và làm mọi thứ có thể để thúc đẩy sự tiến bộ và thịnh vượng của hệ sinh thái AA. Chúng tôi hy vọng rằng thông qua hợp tác với cộng đồng, chúng tôi sẽ đóng góp cho toàn bộ ngành công nghiệp AA với tư cách là người dẫn đầu ngành và hỗ trợ quá trình phát triển tiếp theo của nó, để người dùng Web2 có thể trải nghiệm công nghệ chuỗi khối mà không gặp rào cản.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Cơ sở hạ tầng hỗ trợ hàng tỷ người dùng thông qua việc trừu tượng hóa tài khoản như thế nào?
Cho dù đó là thị trường tăng giá hay thị trường giá xuống, hệ sinh thái Ethereum không ngừng xây dựng và tự tối ưu hóa. Trong số đó, Trừu tượng hóa tài khoản (AA) đã đạt được tiến bộ quan trọng trong những năm gần đây và đã thâm nhập vào tất cả các phần của hệ sinh thái Ethereum, bao gồm ứng dụng, cơ sở hạ tầng, người dùng và nhà phát triển. Chúng ta có thể thấy trước rằng việc áp dụng AA trên quy mô lớn sẽ hạ thấp ngưỡng sử dụng chuỗi khối nói chung và đưa trải nghiệm người dùng của web2 vào ngành công nghiệp web3.
Để nắm bắt cơ hội của thị trường AA tiềm năng trị giá hàng tỷ đô la, BlockPI có kế hoạch tích hợp AA vào các dịch vụ cơ sở hạ tầng của mình. Thông qua tích hợp và đổi mới trong lĩnh vực AA, BlockPI cam kết cung cấp cho người dùng AA một cách thuận tiện và hiệu quả hơn để tương tác với các tài khoản ví hợp đồng blockchain và hy vọng trở thành người dẫn đầu trong ngành này.
Trong bài viết này, nhóm BlockPI sẽ đi sâu vào hiểu biết của họ về AA và chia sẻ suy nghĩ từ quan điểm của một nhà cung cấp dịch vụ cơ sở hạ tầng.
EOA và ví hợp đồng
Khái niệm về AA bắt nguồn từ những hạn chế của tài khoản EOA. Tài khoản EOA (tài khoản thuộc sở hữu bên ngoài) là tài khoản người dùng trong Ethereum, được đại diện bởi khóa công khai (địa chỉ chuỗi khối) và được truy cập thông qua khóa riêng. Nó là một thành phần chính của hệ sinh thái Ethereum, cho phép người dùng chuyển tiền trên blockchain hoặc tương tác với các hợp đồng thông minh. Tuy nhiên, đối với nhiều người, bản thân việc sử dụng EOA có thể là một nhiệm vụ khó khăn. Hơn nữa, tài khoản EOA hiện tại vẫn còn một số bất tiện khi sử dụng làm ảnh hưởng đến trải nghiệm của người dùng.
Đầu tiên là vấn đề phí xăng. Mỗi giao dịch sẽ tiêu tốn của người dùng một lượng ETH đáng kể dưới dạng phí Gas (lấy giá Gas là 25 Gwei làm ví dụ, phí Gas cho một lần chuyển ETH đơn giản là khoảng 0,5 đô la Mỹ và sẽ đắt hơn khi tương tác với hợp đồng hoặc khi giá Gas cao hơn). Điều này làm cho các giao dịch nhỏ trở nên rất tốn kém, đặc biệt là trong thời gian tắc nghẽn mạng nghiêm trọng. Ngoài ra, chỉ ETH mới có thể được sử dụng để thanh toán cho Gas, điều đó có nghĩa là người dùng phải giữ ETH trong ví của họ, điều này tạo thành rào cản gia nhập cao đối với nhiều người dùng.
Thứ hai, đối với một số hoạt động phức tạp mà người dùng muốn đạt được, EOA phải dựa vào các hợp đồng thông minh khác. Ví dụ: nếu người dùng muốn đặt chuyển khoản định kỳ theo thời gian, người dùng cần chuyển ETH sang hợp đồng thông minh có chức năng này để thực hiện thao tác này.
Vấn đề thứ ba với EOA là thuật toán mã hóa chữ ký cố định. Mạng Ethereum sử dụng thuật toán chữ ký số có tên secp256k1 để đảm bảo tính xác thực và bảo mật của các giao dịch. Thuật toán này được mã hóa cứng vào hệ thống và người dùng không thể chọn sử dụng các thuật toán mã hóa khác.
Ngoài 3 vấn đề trên, mối quan hệ ràng buộc giữa khóa công khai và khóa riêng của EOA cũng là một vấn đề. Khóa riêng tư là cách duy nhất để người dùng truy cập vào EOA, nếu khóa riêng tư bị mất sẽ không lấy lại được. Điều này cũng có nghĩa là tất cả nội dung trong EOA được liên kết với nó sẽ không thể lấy lại được.
Đồng thời, EOA cũng có những hạn chế khi thực hiện một số tác vụ tuyến tính. Ví dụ: nếu người dùng muốn phê duyệt (phê duyệt), trao đổi (swap) và không phê duyệt mã thông báo (unapprove token) trong một thao tác, cần thực hiện ba giao dịch riêng biệt, điều này không hiệu quả và tốn thời gian.
Tin tốt là ví hợp đồng có thể giải quyết tất cả các vấn đề trên. Ví hợp đồng về cơ bản là một loại tài khoản hợp đồng thông minh cụ thể triển khai AA, có thể được sử dụng làm ví của người dùng trên Ethereum. Và nó có thể cung cấp cho người dùng một cách linh hoạt và cá nhân hóa hơn để quản lý tiền. Miễn là logic có thể được thực hiện bởi hợp đồng thông minh Ethereum, ví hợp đồng có thể nhận ra và cung cấp các chức năng tương ứng.
Cụ thể, nhiều hoạt động ví hợp đồng có thể được đóng gói thành một giao dịch trên chuỗi và các hoạt động này có thể chia sẻ chi phí Gas của giao dịch này. Nếu bên thứ ba sẵn sàng trả phí Gas, thì không cần phải trả Gas cho người dùng sử dụng ví hợp đồng. Ví hợp đồng cũng có thể hoàn thành nhiều nhiệm vụ tuyến tính cùng một lúc. Ngoài ra, ví hợp đồng cũng hỗ trợ thuật toán mã hóa chữ ký tùy chỉnh và thiết lập chức năng khôi phục ví, v.v.
Khi cuộc thảo luận về những lợi thế của ví hợp đồng vẫn tiếp tục, cộng đồng Ethereum đã thực sự tiến hành nghiên cứu dài hạn về ví hợp đồng. Mặc dù nhiều EIP đã khám phá các vấn đề liên quan đến việc trừu tượng hóa tài khoản, nhưng kể từ năm 2021, không có tiêu chuẩn thống nhất nào được thiết lập. Dưới đây là một số EIP tiêu biểu.
EIP-86
Được đề xuất lần đầu vào năm 2017 bởi Vitalik Buterin. Lược đồ này thực hiện một loạt các thay đổi với mục đích chung là xác minh chữ ký "trừu tượng hóa" và kiểm tra nonce, do đó cho phép người dùng tạo "hợp đồng tài khoản" có thể thực hiện kiểm tra chữ ký/nonce tùy ý.
EIP-2938
Trình bày vào năm 2020. Tiêu đề của EIP này là Tóm tắt tài khoản. Khái niệm về AA được mô tả rõ ràng trong EIP này. Nó giới thiệu một loại giao dịch mới, giao dịch AA. Giao dịch được bắt đầu bởi địa chỉ điểm vào (EntryPoint address) và gọi ví hợp đồng AA. EIP-2938 cung cấp một đặc điểm kỹ thuật thống nhất và chính thức giới thiệu bản tóm tắt tài khoản AA vào sự đồng thuận của Ethereum. Cụ thể, nó giới thiệu hai opcode mới, ba biến toàn cầu và cấu trúc tải trọng khác cho sự đồng thuận của Ethereum.
EIP-3074
Trình bày vào năm 2020. EIP này giới thiệu hai hướng dẫn EVM, AUTH và AUTHCALL. AUTH đặt các biến môi trường theo cơ quan ký ECDSA. AUTHCALL gửi cuộc gọi dưới dạng tài khoản được ủy quyền. Điều này cho phép các hợp đồng thông minh gửi giao dịch thay mặt cho EOA. Nhưng đây vẫn chưa phải là một giải pháp hoàn hảo cho AA. Trong quá trình giao dịch ủy quyền, EIP-3074 có một số hạn chế nhất định đối với việc truyền giá trị gốc. Và nếu người dùng mất quyền truy cập vào EOA, vẫn không có cách nào để lấy lại tài sản của mình. Nếu khóa riêng tư bị rò rỉ, người dùng cần chuyển tất cả nội dung sang tài khoản mới.
Không có đề xuất nào ở trên được chính thức đưa vào giao thức Ethereum do nhu cầu thay đổi ở lớp đồng thuận hoặc do các đề xuất không đủ toàn diện. Do đó, cộng đồng Ethereum tiếp tục khám phá cách đưa AA vào giao thức Ethereum mà không thay đổi sự đồng thuận và cuối cùng đề xuất EIP4337.
ERC - 4337
EIP-4337 ban đầu được đề xuất vào tháng 9 năm 2021 và được ủy quyền là ERC-4337 vào tháng 3 năm 2023. Các tác giả của nó bao gồm Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson và Tjaden Hess.
EIP-4337 là một đề xuất đột phá sẽ giới thiệu AA mà không thay đổi giao thức Ethereum cốt lõi. EIP-4337 cuối cùng đã trở thành tiêu chuẩn ERC-4337, mà các nhà xây dựng có thể sử dụng để triển khai ví hợp đồng thông minh của riêng họ. Đồng thời, tiêu chuẩn cũng giới thiệu một số cơ sở hạ tầng bổ sung bao gồm "Bundlers" và "UserOperation mempool". Theo cách này, nó thực sự sao chép một Ethereum mempool với các chức năng tương tự ở lớp trên của hệ thống chuỗi khối. Những gì người dùng gửi không còn là một giao dịch đơn lẻ, mà là UserOperation. Các UserOperations này có thể được đóng gói thành một giao dịch duy nhất và được gửi tới Ethereum.
Sau đây là giải thích kỹ thuật chi tiết về ERC-4337 trong Ethereum [tài liệu chính thức], với một số nhận xét hữu ích.
Vai trò chính của ERC-4337 và định nghĩa của chúng
UserOperation—mô tả cấu trúc của giao dịch được gửi thay mặt cho người dùng. Để tránh nhầm lẫn, nó không được đặt tên là "giao dịch" và nó sẽ được gửi tới Gói để được đóng gói cùng với các Hoạt động người dùng khác dưới dạng Gói. Gói sau đó được gửi trực tuyến dưới dạng một giao dịch.
Sender—tài khoản hợp đồng gửi UserOperation. Hợp đồng ví phải tuân theo tiêu chuẩn ERC-4337 để định cấu hình giao diện IAccount.
EntryPoint - hợp đồng đơn lẻ toàn cầu thực thi gói UserOperations. Điểm truy cập được hỗ trợ trong danh sách trắng Bundlers/Clients. Hợp đồng được nhóm Infinitism kiểm tra và phê duyệt để triển khai, đồng thời chịu trách nhiệm xử lý tất cả Hoạt động của người dùng và kết nối hợp đồng với các vai trò khác, bao gồm Nhà máy Ví, Trình tổng hợp và Người quản lý thanh toán. Tất cả hợp đồng đều ở cùng một địa chỉ trên chuỗi tương thích EVM.
Bundler—Nút đóng gói nhiều UserOperations từ mempool và tạo giao dịch EntryPoint.handleOps() (nút tạo khối hiện tại). Dịch vụ Bundler có thể chạy độc lập với các nút chuỗi khối và gửi UserOperations được đóng gói thông qua RPC.
Aggregator — Một hợp đồng phụ được các tài khoản tin cậy để xác minh chữ ký tổng hợp. Trình tổng hợp chữ ký được hỗ trợ trong danh sách trắng Bundlers/Clients. Trình tổng hợp phải định cấu hình giao diện IAggregator theo tiêu chuẩn ERC-4337.
Paymaster—một hợp đồng thông minh có thể thanh toán Gas thay cho bạn. Nếu ký gửi đủ ETH trong hợp đồng EntryPoint, nó có thể trả cho người gửi hợp đồng thông minh phí Gas của UserOperation, triển khai hiệu quả việc trừu tượng hóa Gas. Paymaster phải tuân theo tiêu chuẩn ERC-4337 để định cấu hình giao diện Paymaster. Paymaster có thể thỏa thuận với Người gửi. Ví dụ: Người gửi thanh toán USDC cho Paymaster và Paymaster sử dụng ETH để thanh toán Gas của UserOperations mà họ gửi. Trên thực tế, Paymaster có thể chọn hỗ trợ bất kỳ
Mã thông báo
, bao gồm cả ERC-20
Mã thông báo
thậm chí các chuỗi khác
Mã thông báo
。
Sơ đồ bên dưới giải thích cách hợp đồng EntryPoint tương tác với các tác nhân khác.
Các gói gọi hàm handleOps của hợp đồng EntryPoint, hàm này chấp nhận UserOperation làm đầu vào.
handleOps sẽ xác minh UserOperation trên chuỗi, kiểm tra xem nó có được ký bởi địa chỉ ví hợp đồng thông minh được chỉ định hay không và xác nhận xem ví có đủ Gas để bồi thường cho Bundler hay không.
Nếu xác minh được thông qua, handleOps sẽ thực thi chức năng ví hợp đồng thông minh theo chức năng và tham số đầu vào được xác định trong calldata của UserOperation.
Mặt khác, khi Bundler sử dụng EOA để kích hoạt chức năng handleOps, phí Gas sẽ phát sinh. Ví hợp đồng thông minh có thể thanh toán phí Bundlers Gas từ số dư tài khoản của chính nó hoặc yêu cầu hợp đồng Paymaster thanh toán cho nó. UserOperations không thể vượt qua bước xác minh ngoài chuỗi nếu không có đủ Gas, nghĩa là nó không thành công trước khi thực hiện giao dịch trên chuỗi. Ngay cả khi có đủ Gas, UserOperations vẫn có thể thất bại do lỗi thời gian chạy và các lý do khác trong quá trình thực thi. Đối với UserOperation, bất kể việc thực thi hợp đồng có thành công hay không, hợp đồng EntryPoint sẽ trả phí Gas cho Bundler kích hoạt chức năng handleOps.
Sau khi ERC-4337 có hiệu lực, giờ đây người dùng có thể bắt đầu giao dịch chuỗi khối theo hai cách. Một là cách truyền thống, nghĩa là EOA trực tiếp bắt đầu giao dịch. Cách khác là sử dụng tiêu chuẩn ERC-4337 để khởi tạo UserOperation thông qua Bundler, sau đó Bundler sẽ đóng gói nó với các UserOperations khác và gửi nó đến chuỗi mạng. Lưu đồ bên dưới minh họa sự khác biệt giữa giao dịch gửi EOA thông thường và giao dịch gửi UserOperation của ví hợp đồng ERC-4337.
Đường đã trải nhựa nhưng chưa có nhiều người đi bộ
ERC-4337 cung cấp một khuôn khổ mạnh mẽ cho người dùng và nhà phát triển sử dụng và xây dựng AA trên Ethereum. Mặc dù khuôn khổ này là một bước tiến quan trọng, nhưng vẫn còn một số thách thức và sự không chắc chắn cần được giải quyết.
Việc áp dụng AA vẫn còn ở giai đoạn sơ khai. Theo bảng phân tích Dune ERC-4337 [Trừu tượng hóa tài khoản ERC-4337], chỉ hơn 65k+ Thao tác người dùng được thực thi trên chuỗi, 90% trong số đó đến từ Đa giác. Do đó, số lượng UserOperations được thực hiện hiện tại vẫn còn rất ít, hầu hết là các thử nghiệm của nhà phát triển và chỉ một phần nhỏ đến từ người dùng thực. Chúng tôi lưu ý rằng các sản phẩm tích hợp AA vẫn đang ở giai đoạn đầu. Hiện tại, chúng ta có thể quan sát thấy rằng toàn bộ Bundlers vẫn đang trong tình trạng thua lỗ và khoản lỗ hiện tại là khoảng hơn 700 MATIC. Điều này chủ yếu là do một số Bundler trên Polygon ước tính sai lượng gas cần thiết, dẫn đến lượng Gas do EntryPoint trả về ít hơn lượng gas mà Gói đã gửi tiêu thụ. Vấn đề này cần được giải quyết ở cấp độ máy khách Bundler.
Ngoài ra, có một vài vấn đề cần được giải quyết. Một vấn đề như vậy là cách Bundler xử lý các lỗi giao dịch.
Sau khi đóng gói nhiều UserOperations lại với nhau, trước tiên, Bundlers sẽ mô phỏng giao dịch, phát hiện xem có xảy ra lỗi thực thi hợp đồng hay không và tính toán xem phí Gas do Người gửi hoặc Paymaster trả lại có lớn hơn phí Gas đã thanh toán hay không.
Nếu có lãi, Bundler sẽ gửi lô UserOperations này tới nút khối dưới dạng giao dịch. Tuy nhiên, vẫn có khả năng giao dịch không thành công, dẫn đến việc Bundler thanh toán phí Gas nhưng không nhận được khoản hoàn trả Gas từ EntryPoint. Ví dụ: người dùng có thể gửi hành động đến các Gói khác nhau. Nếu có chỗ cho lợi nhuận và mô phỏng thành công, Bundler cam kết nó vào chuỗi. Trong trường hợp này, nếu một UserOperation được gửi tới nút khối bởi các Bundler khác nhau cùng một lúc, thì chỉ một giao dịch sẽ thành công, điều đó có nghĩa là chỉ một Bundler sẽ nhận được phí Gas do EntryPoint trả lại và tất cả các Bundler khác sẽ không thành công do đến xích Và mất Khí. Mặc dù một số người có thể nghĩ rằng hành vi này nên được coi là một cuộc tấn công độc hại và lập luận rằng Bundler có thể cấm địa chỉ Người gửi và từ chối mọi yêu cầu trong tương lai từ địa chỉ này, đây không phải là giải pháp hợp lý vì người dùng có thể vô tình thực hiện hành động này. . Vấn đề này cần được giải quyết đúng cách bằng mã, có thể thông qua mạng bộ nhớ chung công khai đang được phát triển. Hơn nữa, Bundlers có thể bị thua lỗ do biến động gas đột ngột ngay cả khi giao dịch được gửi thành công và kết quả mô phỏng cho thấy vẫn có lợi nhuận.
Một vấn đề khác là giá trị có thể trích xuất tối đa (MEV) có thể thu được từ AA. Trong ngữ cảnh của Ethereum, MEV thường đề cập đến giá trị mà các công cụ khai thác hoặc bộ xử lý giao dịch khác trích xuất bằng cách thao túng thứ tự giao dịch trong một khối hoặc chèn các giao dịch của chính họ vào một khối. Người ta có thể nhận thấy rằng logic của MEV cũng có thể được áp dụng cho AA. Điều này là do trong AA, các Bundler có thể tự do đặt hàng UserOps, điều này cung cấp cho họ khả năng có được MEV. Tuy nhiên, việc Bundler có thể trích xuất MEV hay không tùy thuộc vào việc có thể gộp đủ các UserOperations lại với nhau hay không. Bây giờ toàn bộ thị trường AA vẫn còn ở giai đoạn sơ khai, vì vậy Bundler MEV cũng có thể được coi là ở giai đoạn sơ khai. Có thể thấy rằng MEV của AA có thể phát triển theo hai hướng: một là tương tự như mạng chính Ethereum, với sự tham gia của các bên tham gia như Flashbots, Ultra Sound và BloXroute; hướng còn lại là hình thành sự đồng thuận của Bundler để thực hiện phân loại công bằng. Cái sau sẽ loại bỏ hoàn toàn khả năng trích xuất MEV trong AA.
Sự phát triển tương lai
bộ nhớ công khai
Trong khi hệ sinh thái AA đã hoạt động, vẫn còn rất nhiều công việc phát triển phải được thực hiện. Nhìn vào toàn bộ hệ sinh thái AA, phần còn thiếu lớn nhất hiện nay là mempool công khai. Nhóm Etherspot, các nhà phát triển của ứng dụng khách Skandha Bundler, hiện đang phát triển mạng p2p với một mempool công khai. Mạng p2p của các mempool công cộng dự kiến sẽ ra mắt vào tháng 8 năm nay.
Thuật toán gói
Đồng thời, Ethereum Foundation đã tài trợ cho một số nhóm phát triển AA xuất sắc. Cho đến nay, một số ứng dụng khách Bundler đã được phát triển và hiện đang có sẵn. Trong số họ, một số rất trưởng thành. Chúng là Candide (Voltaire Bundler viết bằng Python), Pimlico (Alto Bundler viết bằng Type), Etherspot (Skandha Bundler viết bằng Type), Stackup (Stackup-Bundler viết bằng Go), v.v.
Ở đây có vấn đề về chiến lược đóng gói. Hiện tại, do số lượng UserOperations nhỏ, Bundlers có thể áp dụng logic đóng gói đơn giản, chẳng hạn như khoảng thời gian cố định hoặc một số UserOperations nhất định trong mỗi Bundle. Tuy nhiên, khi số lượng UserOperations tăng lên, đặc biệt là sau khi giới thiệu bộ nhớ công khai, chiến lược để chọn và đóng gói UserOperations trở nên phức tạp hơn. Lý do rất đơn giản: trong hệ sinh thái AA, không có cơ chế nào tương tự như giao thức đồng thuận chuỗi khối và nhóm Bundler đã trở thành một khu rừng tối tăm, mỗi Bundler ưu tiên các nhiệm vụ theo sở thích của mình và cạnh tranh với nhau. Trái ngược với các mempool công cộng, các mempool riêng có thể xuất hiện sớm hơn. Bởi vì khi đóng gói UserOperations từ public mempool sẽ không mang lại lợi nhuận thì vẫn có thể đóng gói UserOperations trong private mempool. Trong trường hợp này, Bundler cạnh tranh hơn với các Bundler khác khi đóng gói.
Ngoài ra, với sự phổ biến dần dần của mempool công khai, UserOperations trong đó có nhiều đặc điểm khác nhau, chẳng hạn như kỳ vọng lợi nhuận Gas khác nhau và độ phức tạp thực thi trên chuỗi. Các nhà đóng gói sẽ tiến hành mô phỏng ngoài chuỗi để đánh giá khả năng sinh lợi của các kết hợp Hoạt động người dùng khác nhau nhằm thiết lập các chiến lược đóng gói tương ứng của họ. Đóng gói nhiều UserOperations hơn có khả năng tạo ra lợi nhuận cao hơn, nhưng nó cũng làm tăng nguy cơ lỗi xác thực. Ngay cả khi quá trình xác minh được thông qua, rủi ro thực thi không thành công trên chuỗi vẫn tồn tại. Ngược lại, UserOperations ít đóng gói hơn thì ngược lại.
Các nhà đóng gói cần thiết lập các tham số khí giao dịch của riêng họ, điều này sẽ ảnh hưởng đến mức độ ưu tiên của các nhà sản xuất khối để thực hiện giao dịch này. Trong các điều kiện giá Gas ước tính và biến động Gas khác nhau, Bundlers có thể có các chiến lược đóng gói khác nhau. Đồng thời, cũng cần xem xét chi phí tài nguyên máy tính phần cứng cục bộ và tài nguyên nút chuỗi khối cho các tính toán chính sách và xác minh này. Ngoài ra, Bundler cũng cần đảm bảo trải nghiệm người dùng tốt cho người dùng và đảm bảo rằng người dùng không gặp phải sự chậm trễ quá mức sau khi gửi UserOperations.
Mặc dù các giải pháp cho những thách thức này vẫn chưa rõ ràng, nhưng chúng tôi có thể tự tin nói rằng sự phát triển của ngành AA và nỗ lực chung của các nhà phát triển cuối cùng sẽ giải quyết được những vấn đề này. Là một nhà xây dựng cơ sở hạ tầng, BlockPI hy vọng sẽ đóng vai trò là người giải quyết vấn đề trong sự phát triển của ngành công nghiệp AA, cho dù với tư cách là nhà phát triển hay cung cấp cơ sở hạ tầng thân thiện với AA cho các nhà phát triển khác.
*Cơ sở hạ tầng phải thích ứng với AA
AA trừu tượng hóa các vai trò khác nhau liên quan đến giao dịch trên chuỗi, bao gồm Người gửi, Người đóng gói, Người trả tiền gas, ví hợp đồng và Người ký, để người dùng có mức độ tự do cao hơn khi sử dụng chuỗi khối. Đồng thời, các nhà cung cấp cơ sở hạ tầng có thể triển khai độc lập các dịch vụ này theo đánh giá của riêng họ về thị trường.
Để thích ứng với việc áp dụng AA trên quy mô lớn, trước tiên các nhà cung cấp cơ sở hạ tầng cần cung cấp ít nhất hai dịch vụ cơ bản: dịch vụ Bundler và dịch vụ Paymaster.
Trong dịch vụ Bundler, nhà cung cấp cơ sở hạ tầng có thể cần phát triển mempool riêng cùng với Bundler để cung cấp trải nghiệm người dùng tốt. Cụ thể, các nhà cung cấp cơ sở hạ tầng cần tích hợp nhiều ứng dụng khách Bundler khác nhau để đảm bảo tính ổn định của các dịch vụ Bundler. Các ứng dụng khách Bundler này hiện cung cấp cho người dùng một số phương thức JSON RPC tiêu chuẩn do nhóm phát triển cốt lõi ERC-4337 cung cấp. Có thể thấy trước rằng sẽ có nhiều phương thức RPC hơn cho người dùng trong tương lai. Các nhà cung cấp dịch vụ cơ sở hạ tầng cần cập nhật hỗ trợ cho các phương pháp này một cách kịp thời trong quá trình này.
Ngoài ra, điều quan trọng là phải tối ưu hóa giữa API Bundler và RPC máy khách nút gốc. Máy khách nút hiện tại không được tối ưu hóa cho AA. Một số phương thức API của Bundler yêu cầu một chỉ mục đối với dữ liệu được cung cấp cho AA. Ví dụ: khi ứng dụng khách hiện tại tra cứu UserOperation theo hàm băm, ứng dụng đó cần quét nhật ký hợp đồng EntryPoint trong tất cả các khối. Nếu không có chỉ mục dữ liệu, mức tiêu thụ tài nguyên phần cứng của yêu cầu đơn lẻ này sẽ khá lớn và thời gian trả lại yêu cầu cũng sẽ trở nên rất dài.
Ngoài ra, để cung cấp cho người dùng trải nghiệm người dùng Gas-free và các dịch vụ đa dạng, các nhà cung cấp cơ sở hạ tầng cần hợp tác với các nhà cung cấp dịch vụ Paymaster khác nhau để tích hợp các dịch vụ Paymaster khác nhau. Đồng thời, theo nhu cầu thị trường, các nhà cung cấp cơ sở hạ tầng cũng có thể thiết kế các giải pháp tích hợp tiện lợi hơn dựa trên các dịch vụ Paymaster hiện có. Các dịch vụ khác, chẳng hạn như chữ ký tổng hợp, nhà máy ví, v.v., cũng là những hướng tiềm năng để phát triển và tích hợp cơ sở hạ tầng trong tương lai.
Nói tóm lại, để thích ứng với ứng dụng quy mô lớn của AA, các nhà cung cấp cơ sở hạ tầng cần liên tục cải thiện và mở rộng dịch vụ của họ. Điều này bao gồm tối ưu hóa các dịch vụ Bundler, hợp tác với các nhà cung cấp dịch vụ Paymaster khác nhau, tích hợp các giao diện API khác nhau và phát triển các dịch vụ tiềm năng khác. Khi ngành công nghiệp AA tiếp tục phát triển, những nỗ lực này sẽ giúp cung cấp trải nghiệm chuỗi khối hiệu quả, an toàn và thuận tiện hơn.
Hiện tại, BlockPI đang nỗ lực để đạt được các mục tiêu trên. Không chỉ vậy, chúng tôi đã liên lạc với hầu hết tất cả các khách hàng Bundler và nhà cung cấp dịch vụ Paymaster trong cộng đồng và sẽ tích hợp AA vào mạng BlockPI như nhiệm vụ phát triển hàng đầu của chúng tôi. Đồng thời, chúng tôi cũng tiến hành liên lạc chuyên sâu với các nhà phát triển ví AA để hiểu nhu cầu của người dùng. Chúng tôi chân thành chào đón tất cả các Bundler, Paymaster và ví liên lạc và hợp tác với chúng tôi.
Mục tiêu của BlockPI là xây dựng và phát triển hệ sinh thái AA cùng với cộng đồng và làm mọi thứ có thể để thúc đẩy sự tiến bộ và thịnh vượng của hệ sinh thái AA. Chúng tôi hy vọng rằng thông qua hợp tác với cộng đồng, chúng tôi sẽ đóng góp cho toàn bộ ngành công nghiệp AA với tư cách là người dẫn đầu ngành và hỗ trợ quá trình phát triển tiếp theo của nó, để người dùng Web2 có thể trải nghiệm công nghệ chuỗi khối mà không gặp rào cản.