Giải thích chi tiết 4D về trừu tượng hóa tài khoản Ethereum và ERC-4337: Cách mở lối vào người dùng cấp tỷ tiếp theo?

Bài viết gốc: "Viện Nghiên cứu Wanwu: Thị trường tỷ người dùng tiếp theo cho Web3? Giải thích toàn diện Trừu tượng hóa tài khoản và Công nghệ cũng như Ứng dụng của EIP4337"

Tác giả: Steve Wang , Nhà nghiên cứu tại Viện Vạn vật, Sinh viên Wharton, Kỹ sư Giao diện & Hợp đồng

Giới thiệu

Trừu tượng hóa tài khoản được định nghĩa bởi Đề án Cải tiến Ethereum 4337 (EIP 4337) là một tập hợp các giao diện cấp giao thức. Nó không chỉ tích hợp các tương tác quen thuộc với người dùng web2, chẳng hạn như xác thực đa yếu tố, mà còn giải quyết các điểm khó khăn riêng biệt của người dùng trong web3, chẳng hạn như giao dịch không gas. Là một giao diện giao thức cho hàng tỷ người dùng tiếp theo, trải nghiệm người dùng là mối quan tâm hàng đầu Trừu tượng hóa tài khoản.

Trong khi nhiều bài viết hiện có cung cấp những giải thích tuyệt vời về Trừu tượng hóa tài khoản, hầu hết đều có xu hướng hướng đến phổ cập chung, với một số ít đi sâu vào các chi tiết kỹ thuật. Bài viết này nhằm mục đích thu hẹp khoảng cách: cung cấp một giải thích kỹ thuật toàn diện về Trừu tượng hóa tài khoản đồng thời phân loại và phân tích các ví dụ về ứng dụng và cơ sở hạ tầng hiện có. Do đó, bài viết này được chia thành ba phần. Trong Phần 1, chúng ta sẽ khám phá nguồn gốc của EIP 4337 và đi sâu vào các chi tiết kỹ thuật của nó, bao gồm Hoạt động của người dùng, Bundler, Hợp đồng điểm vào, Paymaster, Nhà máy ví và Trình tổng hợp chữ ký. Trong Phần 2, chúng ta sẽ phân tích các đối thủ hiện có trên thị trường, bao gồm ví hợp đồng thông minh và các nhà cung cấp cơ sở hạ tầng của bên thứ ba. Trong Phần 3, chúng ta sẽ thảo luận về hướng đi tương lai của Trừu tượng hóa tài khoản, bao gồm triển vọng và dự đoán về sự đổi mới trong lĩnh vực này.

Bài viết này khá dài. Phần đầu chủ yếu giải thích các khía cạnh kỹ thuật của Trừu tượng hóa tài khoản. Độc giả nào chỉ quan tâm đến các tình huống ứng dụng của Trừu tượng hóa tài khoản có thể bỏ qua phần thứ hai.

Phần 1: Phân tích kỹ thuật toàn diện về EIP 4337

Trước tiên, hãy cùng xem lại những điều cơ bản. Có hai loại tài khoản Ethereum: tài khoản sở hữu bên ngoài (EOA) và tài khoản hợp đồng.

• EOA là một tài khoản do người dùng kiểm soát, có thể gửi giao dịch. EOA kiểm soát quyền sở hữu tài khoản thông qua private key và có thể thực hiện giao dịch bằng cách ký, qua đó thay đổi trạng thái nội bộ của EOA hoặc trạng thái của các tài khoản hợp đồng bên ngoài. Vì private key(hoặc cụm từ hạt giống) là đại diện duy nhất cho quyền sở hữu EOA, EOA không phù hợp để xác định quyền sở hữu hoặc logic giao dịch phức tạp, chẳng hạn như đăng nhập mạng xã hội và giao dịch chữ ký đa bên (bên long). Những hạn chế của EOA dẫn đến trải nghiệm người dùng kém: các bước rườm rà, chẳng hạn như quản lý private key và cụm từ hạt giống, trực tiếp cản trở người dùng Web2 truy cập Web3. Hầu hết các ví phổ biến, chẳng hạn như MetaMask, đều dựa trên mô hình tài khoản EOA.
• Tài khoản hợp đồng có thể lưu trữ mã Solidity tùy ý, do đó tận dụng tối đa tính toàn vẹn Turing của EVM. Tuy nhiên, tài khoản hợp đồng không thể gửi giao dịch, do đó chức năng của chúng phải được kích hoạt bởi EOA. Ví hợp đồng thông minh là tài khoản hợp đồng được kích hoạt gián tiếp bởi người dùng thông qua mạng EOA của nhà cung cấp ví, có thể thông qua relayer hoặc bundler.

 Hình: EOA và tài khoản hợp đồng (Nguồn: Bitcoin Insider)

Ví hợp đồng thông minh đã tồn tại từ rất lâu trước EIP 4337. EIP 4337 được đề xuất để chuẩn hóa chức năng chung của ví hợp đồng thông minh và cơ sở hạ tầng liên quan. EIP 4337 tuân thủ các nguyên tắc thiết kế sau:

• Nhìn chung, tất cả các triển khai kỹ thuật đều được triển khai ở lớp trên cùng (lớp hợp đồng thông minh) , tránh việc phải can thiệp vào cơ sở hạ tầng cơ bản như lớp đồng thuận và lớp thực thi. Việc sửa đổi các thiết kế cơ bản như mô hình tài khoản ở cấp độ này sẽ là một nâng cấp đáng kể, tương tự như việc hợp nhất mạng mainnet Ethereum PoS. Do nguồn lực phát triển hạn chế, một phương pháp nhẹ nhàng được triển khai ở lớp hợp đồng là lựa chọn duy nhất.
• Thiết kế giao diện giao thức phải theo mô-đun để người dùng có thể tùy chỉnh các tùy chọn, bao gồm gói giao dịch (Bundler), thanh toán gas(Paymaster) và tổng hợp chữ ký (Aggregator).
• Trong điều kiện lý tưởng, mỗi dịch vụ này sẽ trở thành một thị trường mở, cạnh tranh, nơi người dùng có thể lựa chọn dịch vụ tốt nhất dựa trên giá cả và uy tín.

EIP 4337 định nghĩa sáu giao diện hợp đồng cho ví hợp đồng thông minh được chuẩn hóa:

Đầu tiên, ví hợp đồng thông minh sẽ được kích hoạt gián tiếp bởi trình đóng gói kích hoạt hợp đồng nhập, xác minh giao dịch ngoài Chuỗi và sau đó thực hiện giao dịch trên Chuỗi.

Thứ hai, Bundler được sử dụng để xác minh hàng loạt và thực hiện các hoạt động của người dùng (UserOperation, là loại giao dịch của ví hợp đồng thông minh được xác định bởi EIP 4337).

Thứ ba, Hợp đồng Điểm vào là một hợp đồng toàn cầu chỉ tồn tại một lần trong Ethereum. Nó được sử dụng để chuẩn hóa việc thực hiện giao dịch và bảo vệ người đóng gói khỏi các cuộc tấn công DoS do các giao dịch độc hại gây ra.

Thứ tư, hợp đồng Paymaster được sử dụng để xử lý thanh toán gas thay mặt cho người dùng ví.

Thứ năm, Wallet Factory được sử dụng để chuẩn hóa các thông số và quy trình tạo ví.

Thứ sáu, Signature Aggregator được sử dụng để tổng hợp chữ ký của nhiều giao dịch thành các byte để xác minh và thực hiện giao dịch nhanh hơn.

Dưới đây tôi sẽ giải thích chi tiết về UserOperation và sáu giao diện hợp đồng được đề cập ở trên, đây là bản diễn giải tài liệu EIP 4337 chính thức và loạt Trừu tượng hóa tài khoản của David Philipson tại Alchemy.

1. Thao tác của người dùng

UserOperation về cơ bản giống với giao dịch thông thường, ngoại trừ việc nó xác định các tham số bổ sung dựa trên giao diện hợp đồng của EIP 4337. Tóm lại, một giao dịch Ethereum thông thường được kích hoạt bởi EOA bao gồm các tham số như địa chỉ Ethereum, số lượng ETH được chuyển, số tiền gas và giá gas.

Ngoài ra, khi xem xét thiết kế mô-đun của giao diện hợp đồng EIP 4337, UserOperation bao gồm các tham số chính sau để xác định kích hoạt giao diện:

• Calldata: định nghĩa chữ ký hàm và các tham số đầu vào được gọi trên ví hợp đồng thông minh. Calldata cũng tồn tại trong các giao dịch thông thường.
• Chữ ký: Xác minh rằng giao dịch thực sự đến từ địa chỉ ví hợp đồng thông minh. Chữ ký cũng có trong các giao dịch thông thường.
• Nonce: ngăn chặn các cuộc tấn công phát lại và cũng được sử dụng trong các giao dịch thông thường
• người gửi: Chỉ định địa chỉ ví hợp đồng thông minh thực hiện UserOperation
• paymasterAndData: được sử dụng để trừu tượng hóa phí giao dịch (trừu tượng hóa gas ) , bao gồm địa chỉ hợp đồng thanh toán (Paymaster) và các tham số thanh toán gas
• initCode: được sử dụng để tạo ví , bao gồm địa chỉ hợp đồng của Wallet Factory và các tham số để tạo ví hợp đồng thông minh, chẳng hạn như mã hợp đồng của ví

Ngoài việc yêu cầu các tham số bổ sung, UserOperations tuân theo quy trình làm việc tương tự như các giao dịch thông thường: tất cả đều được phát đến mempool để xác thực, thực thi và cuối cùng là tạo khối. Việc xác thực và thực thi UserOperations được kích hoạt bởi các bundler , mà tôi sẽ giải thích bên dưới.

 Hình: Định nghĩa các tham số UserOperation trong tài liệu chính thức EIP 4337

2. Người đóng gói

Bundler là một tài khoản sở hữu bên ngoài (EOA) xác minh và thực hiện các giao dịch UserOperation thay mặt người dùng trên ví hợp đồng thông minh. Vì tất cả các giao dịch trên Ethereum phải được kích hoạt bởi EOA, Bundler cho phép người dùng kích hoạt các giao dịch ví hợp đồng thông minh mà không cần phải tạo và ghi nhớ private key cho EOA, vốn là mục đích ban đầu của ví hợp đồng thông minh.

Mặc dù Bundler có các đặc tính hàng hóa công cộng mạnh mẽ, nhưng chúng cũng có lợi về mặt kinh tế vì:

• Bundler có thể thu nhập khoản chênh lệch giữa phí Gas và lượng gas thực tế đã chi sau khi thực hiện UserOperation
• Tương tự như bộ chuyển tiếp các giao dịch thông thường, bộ đóng gói có thể lấy MEV bằng cách sắp xếp UserOperation trong giao dịch đóng gói.

Mặc dù người dùng trả giá phí, Bundler vẫn có lợi ích trong việc tiết kiệm gas . Mỗi giao dịch có chi phí cố định là 21.000 gas, và việc thực hiện các giao dịch theo gói có thể phân bổ chi phí cố định này cho nhiều UserOperation trong giao dịch theo gói, giúp tiết kiệm gas. Hơn nữa, khi sửa đổi lưu trữ lần trong cùng một giao dịch, phí Gas cho lần thao tác bổ sung sẽ giảm nhẹ.

Điều quan trọng cần lưu ý là mặc dù các giao dịch trên Ethereum được thực hiện tuyến tính (không song song) để tránh xung đột trạng thái, nhiều UserOperation có thể được thực hiện trong một giao dịch được đóng gói duy nhất vì Bundler có thể đặt cùng một địa chỉ ví hợp đồng thông minh để chứa tối đa một UserOperation, do đó các giao dịch được đóng gói sẽ không xung đột với nhau khi sửa đổi trạng thái.

Ngoài những khác biệt này, Bundler tương tự như Block Builder ở chỗ cả hai đều phát các UserOperations đã được xác minh đến một mempool công khai hoặc sở hữu tư nhân. Tiếp theo, chúng tôi sẽ giới thiệu Hợp đồng Điểm vào (Entry Point Contract), mà Bundler cần tương tác để thực thi UserOperations.

3. Hợp đồng điểm vào

Hợp đồng điểm vào là một hợp đồng singleton toàn cục mà tất cả Bundler cần gọi để thực thi UserOperation. Nó hoạt động như một đơn vị trung gian giữa Bundler và ví hợp đồng thông minh:

• Một mặt, Bundlers gọi hàm handleOp của hợp đồng điểm vào, chấp nhận UserOperation làm tham số đầu vào. handleOp chịu trách nhiệm xác minh và thực thi hàm ví hợp đồng thông minh dựa trên calldata của UserOperation

• handleOp đầu tiên 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 đã chỉ định hay không và ví có đủ gas để bù cho Bundler hay không
• Nếu xác minh thành công, handleOp sẽ thực thi chức năng ví hợp đồng thông minh theo chữ ký hàm và các tham số đầu vào được xác định trong calldata của UserOperation

• Mặt khác, ví hợp đồng thông minh cần gửi token vào hợp đồng điểm vào để trả phí gas cho Bundler. Khi Bundler kích hoạt hàm handleOp bằng EOA, phí gas sẽ được phát sinh.

• Ngoài ra, ví hợp đồng thông minh cũng có thể sử dụng số dư tài khoản của mình để thanh toán phí gas cho Bundler, hoặc yêu cầu hợp đồng thanh toán (Paymaster) thanh toán thay. Chúng tôi sẽ giải thích chi tiết sau.
• UserOperations không có đủ gas sẽ không thể vượt qua bước xác minh trong ví hợp đồng thông minh mục tiêu và do đó sẽ không thành công trước khi thực hiện.
• Ngay cả khi có đủ gas, UserOperation vẫn có thể bị lỗi trong bước thực thi, chẳng hạn như lỗi thời gian chạy.
• Bất kể việc thực hiện có thành công hay không, hợp đồng điểm vào sẽ trả phí gas cho Bundler để kích hoạt hàm handleOp
• Hợp đồng điểm vào cung cấp các chức năng để thêm hoặc rút tiền thế chấp mã thông báo từ ví hợp đồng thông minh.

 Hình: Quy trình làm việc hợp đồng điểm vào trong tài liệu EIP 4337 chính thức

4. Hợp đồng chính của ví hợp đồng thông minh

Hợp đồng chính của ví hợp đồng thông minh tách biệt các bước xác minh và thực hiện của UserOperation:

• Các bước xác thực được định nghĩa trong hàm validateOp. Hàm này được gọi lần: lần đầu tiên khi Bundler mô phỏng quá trình xác minh ngoài Chuỗi , xác minh chữ ký trong UserOperation và đảm bảo ví hợp đồng thông minh có đủ số dư gas ; lần thứ hai khi hợp đồng điểm vào thực hiện xác minh Chuỗi trước khi thực thi UserOperation.
• Các bước thực hiện được xác định trong calldata của UserOperation, được sử dụng để chỉ định chữ ký và các tham số đầu vào của hàm ví hợp đồng thông minh.

Bằng cách tách biệt việc xác thực và thực thi UserOperation, Bundler có thể xác minh UserOperation ngoài Chuỗi, do đó lọc ra các giao dịch độc hại mà không phải trả phí gas. Do đó, hàm validateOp cũng đóng vai trò như một API gỡ lỗi ngoài Chuỗi.

5. Thỏa thuận thanh toán (Paymaster)

Hợp đồng Paymaster định nghĩa logic cho việc trừu tượng hóa gas trong ví hợp đồng thông minh. Việc trừu tượng hóa gas bao gồm việc thanh toán gas Ethereum bằng token ERC20 và các giao dịch không gas, cả hai đều có thể được triển khai bởi Paymaster. Thiết kế mô-đun của ERC-4337 cho phép UserOperation chỉ định địa chỉ Paymaster tùy ý và các tham số đầu vào thông qua tham số paymasterAndData. Paymaster có các khả năng và yêu cầu sau:

• Về cơ bản, Paymaster là một hợp đồng thông minh được triển khai bởi dApp. Bạn có thể kích hoạt hàm validatePaymasterOp của Paymaster thông qua Bundler để thanh toán gas một cách có chọn lọc cho UserOperation được chỉ định bởi hợp đồng với logic tùy ý.
• Paymaster cần gửi Ethereum vào hợp đồng điểm vào để thanh toán phí gas của UserOperation
• Ngoài việc nạp gas, Paymaster cũng cần phải đặt cọc thêm Ethereum vào hợp đồng điểm vào. Khoản đặt cọc này sẽ không bị cắt giảm, nhưng nó có thể ngăn chặn robot tạo Paymaster theo đợt một cách ác ý.

Paymaster (ít nhất là trong viễn cảnh mong đợi chính thức ) là một thị trường mở, cạnh tranh. Mặc dù không có hệ thống đánh giá uy tín chính thức Chuỗi cho Paymaster, các Bundler có thể ghi nhận chất lượng dịch vụ Paymaster ngoài Chuỗi và ngừng sử dụng các Paymaster chất lượng thấp hơn, qua đó khích lệ Paymaster cung cấp dịch vụ đáng tin cậy cho UserOperations.

Giao diện Paymaster định nghĩa hai chức năng:

• validatePaymasterOp: định nghĩa logic trừu tượng hóa gas . Ví dụ: trong trường hợp ví hợp đồng thông minh thanh toán gas bằng token ERC20, hàm này sẽ đảm bảo ví có đủ số dư. validatePaymasterOp được gọi trước khi thực thi UserOperation, phù hợp với logic thiết kế tách bước xác minh khỏi bước thực thi.
• postOp: Được gọi ở bước cuối cùng trong quá trình thực thi hàm của ví hợp đồng thông minh. Nếu ví không đủ số dư ERC20 để thanh toán phí Gas cho Paymaster, postOp sẽ hủy việc thực thi hàm. Ngay cả khi việc thực thi hàm không thành công do lỗi thời gian chạy trong bước này, gas vẫn sẽ bị trừ.

 Hình: Quy trình làm việc của Paymaster trong tài liệu chính thức EIP 4337 

 Hình: Giao diện Paymaster trong tài liệu chính thức EIP 4337

6. Nhà máy sản xuất ví

Wallet Factory là một hợp đồng tạo ra một ví hợp đồng thông minh. Lưu ý rằng UserOperation có một trường initCode tùy chọn. Khi initCode trống, UserOperation chỉ cần kích hoạt chức năng của ví hợp đồng thông minh. Khi initCode được điền địa chỉ Wallet Factory và các tham số cho ví hợp đồng thông minh mới, Bundler sẽ kích hoạt Wallet Factory tương ứng để tạo một hợp đồng thông minh bằng các tham số được chỉ định.

Wallet Factory tạo điều kiện cho Trừu tượng hóa tài khoản theo những cách sau:

• Người dùng có thể yêu cầu Bundler tạo ví hợp đồng thông minh bằng cách gửi UserOperation chứa initCode mà không cần phải có EOA để tự tạo.
• Người dùng có thể tùy chỉnh ví hợp đồng thông minh của mình bằng cách chọn một Wallet Factory với các tùy chọn tùy chỉnh cụ thể và truyền các tham số riêng. Ngoài ra, vì hợp đồng Wallet Factory là công khai và phổ biến, Wallet Factory trải qua kiểm toán mã toàn diện, nên việc tạo ví mới bằng Wallet Factory sẽ an toàn hơn cho người dùng.
• Người dùng có thể chọn Paymaster thanh toán phí gas cần thiết để tạo ví hoặc thanh gas bằng bất kỳ token ERC20 nào mà không cần sở hữu Ethereum. Ngoài ra, Paymaster có thể chọn chỉ thanh toán phí gas cho các ví hợp đồng thông minh được triển khai bởi Wallet Factory đáng tin cậy của mình.
• Trước khi tạo ví, người dùng có thể lấy địa chỉ ví hợp đồng thông minh của mình bằng cách gọi hàm CREATE2. Hàm này sẽ tự động tạo địa chỉ hợp đồng thông minh bằng cách sử dụng địa chỉ EOA đã kích hoạt việc tạo ví hợp đồng thông minh, một salt và initCode. Người dùng không cần trả phí gas khi tạo ví; họ chỉ cần trả phí gas cho cả việc tạo ví và phí giao dịch khi thực hiện giao dịch đầu tiên với ví, giúp cải thiện trải nghiệm người dùng.

Wallet Factory cũng có những trách nhiệm khác. Tương tự như Paymasters, họ cần đặt cọc ETH vào hợp đồng điểm vào và liên tục cung cấp dịch vụ tốt cho UserOperations để có thêm lưu lượng truy cập từ Bundler.

7. Tổng hợp chữ ký

Do các ví hợp đồng thông minh khác nhau sử dụng các thuật toán chữ ký khác nhau, các UserOperations sử dụng cùng một thuật toán chữ ký trước tiên phải được tổng hợp và sau đó được xác minh riêng lẻ. Hơn nữa, vì các phép tính mật mã Chuỗi tiêu tốn một lượng gas lượng lớn , các lược đồ chữ ký hỗ trợ tổng hợp (như BLS) có thể tiết kiệm gas trong quá trình xác minh Chuỗi . Do đó, chúng ta cần một giao diện hợp đồng thông minh EIP 4337 có tên là Signature Aggregator. Giao diện này có thể hỗ trợ các thuật toán chữ ký cụ thể bằng cách triển khai hai chức năng sau:

• aggregateSignatures: Tham số đầu vào là một mảng UserOperations và sử dụng thuật toán chữ ký cụ thể để đưa ra chữ ký tổng hợp.
• validateSignatures: Các tham số đầu vào là một mảng UserOperations và một chữ ký tổng hợp, được sử dụng để xác minh chữ ký của tất cả UserOperations trong mảng.

Thay vì xác minh từng UserOperations một, Bundler trước tiên tạo nhiều chữ ký tổng hợp (một chữ ký cho mỗi thuật toán chữ ký) bằng cách sử dụng nhiều hợp đồng tổng hợp chữ ký (một chữ ký cho mỗi thuật toán chữ ký). Sau đó, Bundler truyền mảng UserOperations, các chữ ký tổng hợp và địa chỉ tổng hợp đến hợp đồng điểm vào. Mỗi mảng UserOperations gọi hàm validateSignature của bộ tổng hợp chữ ký tương ứng. Sau khi được xác minh, Bundler thực thi tập hợp UserOperations trên ví hợp đồng thông minh.

Tương tự như Paymaster và Wallet Factory, các đơn vị tổng hợp cũng được yêu cầu đặt cọc Ethereum vào hợp đồng điểm vào và duy trì hồ sơ cung cấp dịch vụ tốt cho UserOperations.

 Hình: Giao diện tổng hợp chữ ký trong tài liệu EIP 4337 chính thức

8. Tóm tắt quy trình làm việc tổng thể

Thiết kế mô-đun của EIP 4337 chia chức năng Trừu tượng hóa tài khoản của ví hợp đồng thông minh thành nhiều giao diện. Chức năng của các giao diện này có thể được tóm tắt như quy trình làm việc sau:

• Người dùng gửi UserOperation đến Bundler
• Nếu UserOperation điền vào tham số initCode, Bundler sẽ kích hoạt Wallet Factory để tạo ví mới với địa chỉ cụ thể.
• Nếu tham số paymasterAndData được điền vào UserOperation, Bundler sẽ thu thập Ethereum được Paymaster đặt cọc trên hợp đồng điểm vào để thanh toán gas. Nếu paymasterAndData không được điền, Bundler sẽ thu thập số Ethereum được đặt cọc bởi ví hợp đồng thông minh trên hợp đồng điểm vào để thanh toán gas.
• Bundler có thể tùy chọn sử dụng trình tổng hợp chữ ký
• Bundler sẽ sử dụng các hàm validateOp, validatePaymasterOp và validateSignatures để mô phỏng và xác minh UserOperation ngoài Chuỗi để đảm bảo rằng chữ ký là chính xác và UserOperation có đủ gas.
• Nếu xác minh mô phỏng ngoài Chuỗi vượt qua, Bundler sẽ sử dụng hàm trên để xác minh UserOperation trên Chuỗi
• Nếu xác minh Chuỗi thành công, Bundler sẽ thực thi UserOperation trên Chuỗi. Bất kể việc thực thi thành công hay không, gas sẽ bị khấu trừ.

 Hình: Quy trình Trừu tượng hóa tài khoản mà không có trình tổng hợp chữ ký (Nguồn: Alchemy) 

 Hình: Quy trình Trừu tượng hóa tài khoản với trình tổng hợp chữ ký (Nguồn: Alchemy)

9. Ghi chú khác

UserOperation kích hoạt các hàm như validateOp cả ngoài Chuỗi và trên Chuỗi để xác minh giao dịch. Để ngăn chặn kết quả xác minh không nhất quán giữa ngoài Chuỗi và trên Chuỗi do thay đổi trạng thái bên ngoài hợp đồng Ví thông minh, EIP 4337 cấm các hàm xác thực sử dụng OpCode đọc bộ nhớ ngoài hoặc trạng thái toàn cục (chẳng hạn như dấu thời gian). Lệnh cấm này áp dụng cho các hàm xác thực như validateOp, validatePaymasterOp và validateSignatures.

Phần II: Những người tham gia thị trường Trừu tượng hóa tài khoản

1. Ví hợp đồng thông minh và SDK hỗ trợ

Ví hợp đồng thông minh là những công ty lớn nhất trong thị trường Trừu tượng hóa tài khoản. Để đạt được khả năng tương thích với EIP 4337, họ thường triển khai các bundler, paymaster, wallet factory và signature aggregator của riêng mình. Những ví này cũng đi kèm với các SDK hỗ trợ tích hợp dApp. Thị trường ví hợp đồng thông minh khá sôi động, với các công ty đã thành danh như ví đa chữ ký Gnosis Safe triển khai chức năng Trừu tượng hóa tài khoản trong các sản phẩm hiện có của họ, trong khi những công ty mới nổi như Candide tập trung vào việc xây dựng các ví hợp đồng thông minh hoàn toàn tương thích với EIP 4337. Phần này sẽ mô tả các tính năng chung của các ví này và sự khác biệt giữa chúng.

a. Đăng nhập xã hội và phục hồi xã hội

Đăng nhập xã hội cung cấp cho ví hợp đồng thông minh trải nghiệm tương tác quen thuộc với người dùng Web2, chẳng hạn như tạo và đăng nhập vào ví bằng tài khoản Google hiện có. Logic tương tự này cũng có thể được mở rộng sang phục hồi xã hội, chẳng hạn như đặt lại mật khẩu ví hợp đồng thông minh bằng địa chỉ email. Logic cho đăng nhập xã hội và phục hồi thường được định nghĩa trong hợp đồng chính của ví.

Ở đây, chúng tôi giới thiệu khái niệm Người giám hộ. Người giám hộ là một thực thể có thể cấp cho người dùng quyền truy cập vào tài khoản hoặc giúp người dùng khôi phục tài khoản. Người giám hộ có thể là tài khoản Web2 hoặc địa chỉ email. Khái niệm này đã được sử dụng rộng rãi trong Web2 và hiện có thể được triển khai trong ví hợp đồng thông minh thông qua khái niệm Trừu tượng hóa tài khoản.

Ví hợp đồng thông minh có thể có nhiều người giám hộ. Người dùng phải thiết lập người giám hộ trong hoặc sau khi tạo ví và đáp ứng một ngưỡng xác minh người giám hộ nhất định, chẳng hạn như hai trong ba, để đăng nhập hoặc khôi phục ví. Quá trình này thường được gọi là xác thực đa yếu tố . Sau đây là các loại người giám hộ phổ biến trong ví hợp đồng thông minh:

• Các nhà cung cấp dịch vụ Web2, chẳng hạn như tài khoản mạng xã hội của người dùng ví, thường được triển khai bằng cách áp dụng tiêu chuẩn OAuth (Ủy quyền Mở). Tiêu chuẩn này cho phép ví có được quyền truy cập của người dùng để truy cập thông tin tài khoản người dùng được lưu trữ bởi một ứng dụng Web2 khác.
• Thiết bị của người dùng: chẳng hạn như bộ nhớ trình duyệt và bộ nhớ di động
• Email: Ví dụ, bằng cách nhấn liên kết trong email để gửi chữ ký
• Đa chữ ký: Người dùng có thể thiết lập nhiều ví EOA hoặc ví hợp đồng thông minh do cá nhân sở hữu làm người giám hộ
• MPC: Người dùng có thể chia private key thành nhiều thị phần, thị phần được kiểm soát bởi một nút trong mạng MPC mà không tiết lộ toàn bộ khóa.
• SWIE (đăng nhập bằng Ethereum)

Chúng ta hãy cùng xem một số nhà cung cấp dịch vụ trên thị trường đã triển khai tính năng này như thế nào:

• Web3Auth là dịch vụ đăng nhập mạng xã hội và MPC được sử dụng bởi nhiều ví hợp đồng thông minh có lưu lượng truy cập cao, bao gồm Biconomy, Etherspot và 0xPass. Web3Auth chia khóa người dùng thành nhiều phần, được phân phối cho nhiều bên giám hộ khác nhau, bao gồm bên giám hộ đăng nhập mạng xã hội, thiết bị của người dùng và mạng lưới nút MPC của họ. Logic của sản phẩm được triển khai hoàn toàn ngoài Chuỗi, và không có bên giám hộ nào lưu trữ toàn bộ private key. (Xem sơ đồ bên dưới.)
• BLS Wallet và Argent sử dụng công nghệ đa chữ ký (multisig) để khôi phục khóa thông qua nhiều địa chỉ EOA do người dùng chỉ định.
• UniPass triển khai một phương pháp sáng tạo để khôi phục dữ liệu xã hội qua email. Người dùng gửi địa chỉ email của người giám hộ trên Chuỗi, và một hợp đồng thông minh sẽ xác minh chữ ký DKIM của email trên Chuỗi. DKIM (Thư được xác định bằng khóa tên miền) là một giao thức xác thực email được sử dụng để tạo chữ ký số. Nhà cung cấp email có thể sử dụng chữ ký số này để xác minh danh tính người gửi email. UniPass cũng sử dụng Bằng chứng không tri thức để vô hiệu hóa thông tin người dùng trên Chuỗi. UniPass cũng hỗ trợ phương pháp khôi phục dữ liệu xã hội ngoài email.
• Soul Wallet xác minh địa chỉ email của người giám hộ trên Chuỗi để phục hồi xã hội.

 Hình: Đăng nhập xã hội và phục hồi xã hội Web3Auth, trong trường hợp này có ba người giám hộ

gas . Khai thác gas

Trừu tượng hóa gas bao gồm các giao dịch không cần gas và khả năng thanh toán gas bằng bất kỳ token ERC20 nào. Logic này có thể được triển khai trong hợp đồng thanh toán (Paymaster) hoặc thông qua một đơn vị trung gian.

Nhiều ví hợp đồng thông minh đã triển khai hợp đồng Paymaster riêng tương thích với EIP 4337 và đặt cược token vào hợp đồng điểm vào để giúp người dùng thanh toán tiền gas.

Relayer là một giải pháp trừu tượng hóa gas khác đã tồn tại trước EIP 4337. Relayer là những người chuyển tiếp giao dịch đáng tin cậy thực hiện một loại giao dịch gas đặc biệt được gọi là meta-transaction. Meta-transaction là một giao dịch Ethereum chèn một giao dịch khác vào giao dịch gốc. Người dùng ký meta-transaction bằng private key của họ và gửi nó đến relayer, nơi xác minh nó, gửi nó đến blockchain và trả tiền gas. Relayer chỉ đơn giản là thực hiện giao dịch mà không thay đổi chính giao dịch đó. Relayer thu được lợi ích tài chính vì họ tính phí gas cộng với một khoản lợi nhuận nhỏ cho hợp đồng thực hiện giao dịch. Ví dụ: relayer có thể tính phí các ứng dụng phi tập trung (dApp) hỗ trợ giao dịch gas . Relayer có thể là bên thứ ba đáng tin cậy tập trung hoặc mạng phi tập trung. Relayer khác với paymaster ở những điểm sau:

• Ngoài việc thanh toán gas, Relayer còn ký giao dịch, tương tự như Bundler trong EIP 4337.
• Relayer không chỉ xử lý các giao dịch kiểu UserOperations
• Người chuyển tiếp không đặt cược gas đốt vào hợp đồng điểm vào

Chúng ta hãy cùng xem một số nhà cung cấp dịch vụ trên thị trường đã triển khai tính năng này như thế nào:

• Biconomy không chỉ triển khai Paymaster tương thích với EIP 4337 mà còn có mạng lưới Relayer hỗ trợ bất kỳ token ERC20 nào để thanh toán gas.
• Argent sử dụng bên chuyển tiếp thứ ba để thanh toán gas dưới dạng giao dịch siêu dữ liệu.
• Candide tự mình triển khai Paymaster.
• UniPass sử dụng nút Relayer của riêng mình để thanh toán gas và có kế hoạch thêm chế độ "giao dịch không mất tiền gas khi xem quảng cáo" trong tương lai và hỗ trợ việc sử dụng cầu nối xuyên chuỗi để thanh toán gas.

Cho đến nay, hầu hết các giải pháp thanh toán gas ERC20 (như Candide và Soul Wallet) chỉ hỗ trợ một số loại token rất hạn chế, chủ yếu là stablecoin, mặc dù tôi thấy trước điều này sẽ thay đổi trong tương lai.

 Hình: Biconomy sử dụng Paymaster để hỗ trợ các giao dịch không cần gas(dựa trên việc triển khai công nghệ EIP 4337) 

 Hình: Biconomy sử dụng bất kỳ ERC20 nào để thanh toán gas thông qua Relayer (không dựa trên EIP 4337)

c. Đường dốc nạp rút tiền tiền tệ Fiat và cầu nối xuyên chuỗi

Nhiều ví hiện có, chẳng hạn như MetaMask, đã tích hợp các cổng fiat on-and-nạp rút tiền và cầu nối xuyên chuỗi vào ví của họ thông qua hợp tác với các nhà cung cấp bên thứ ba. Nạp rút tiền cầu nối xuyên chuỗi này có thể được tích hợp thêm với hợp đồng Paymaster trong gas .

Chúng ta hãy cùng xem một số nhà cung cấp dịch vụ trên thị trường đã triển khai tính năng này như thế nào:

• Biconomy và 0xPass đã hợp tác với Transak để cung cấp các dịch vụ chuyển tiền fiat. Biconomy cũng cung cấp cầu nối xuyên chuỗi và dịch vụ giao tiếp liên Chuỗi.
• Argent Vault hợp tác với Moonpay, Transak và Wyre để cung cấp dịch vụ chuyển tiền fiat và có trình tổng hợp giao thức DeFi tích hợp sẵn.
• Etherspot, UniPass và Braavos hỗ trợ các kênh fiat, swap và cầu nối xuyên chuỗi.

d. Phân lô giao dịch

Xử lý giao dịch theo lô là một tính năng độc đáo của ví hợp đồng thông minh, cho phép người dùng ví thực hiện nhiều giao dịch trong một giao dịch Chuỗi duy nhất. Một phương pháp là gọi hàm multiCall, chấp nhận hai tham số: một mảng calldata (mỗi calldata xác định một lệnh gọi hàm) và một mảng địa chỉ hợp đồng (địa chỉ hợp đồng của mỗi lệnh gọi hàm). Hàm multiCall chứa một vòng lặp và thực hiện một lệnh gọi hàm duy nhất trong lần vòng lặp. Xử lý giao dịch theo lô cho phép nhiều giao dịch chia sẻ phí Gas cố định của một giao dịch Ethereum duy nhất, do đó giảm chi phí.

Xin lưu ý rằng xử lý hàng loạt giao dịch khác với xử lý tổng hợp chữ ký, vốn chấp nhận một mảng UserOperation làm đầu vào và xuất ra một byte chữ ký tổng hợp để tăng tốc độ xác minh nhiều chữ ký. Mỗi UserOperation trong mảng này có thể gọi một multiCall để thực hiện xử lý hàng loạt giao dịch.

Cách thức triển khai xử lý hàng loạt giao dịch trong EIP 4337 như sau: hợp đồng điểm vào gọi hàm handleOp, sau đó gọi hàm multiCall được xác định trong hợp đồng chính của ví hợp đồng thông minh.

Chúng ta hãy cùng xem một số nhà cung cấp dịch vụ trên thị trường đã triển khai tính năng này như thế nào:

• Biconomy thiết lập hợp đồng MultiCall, có thể được gọi bằng ví hợp đồng thông minh để thực hiện giao dịch theo lô.
• Argent xử lý các giao dịch theo lô thông qua mô-đun hợp đồng thông minh có tên là Transaction Manager, mô-đun trợ nhiều cuộc gọi và Key phiên người dùng.
• Etherspot, Candide, Openfort và 0xpass đều hỗ trợ xử lý giao dịch theo lô.

 Hình: Ví dụ về hợp đồng MultiCall (Được cung cấp bởi Solidity by Example)

e. Thiết kế mô-đun của ví hợp đồng thông minh

Một lợi thế quan trọng của ví hợp đồng thông minh so với ví EOA là thiết kế mô-đun . Chức năng ví có thể được mở rộng thông qua mô-đun hợp đồng do nhà cung cấp ví phát triển. Mô-Đun này cung cấp chức năng không được định nghĩa trong giao diện EIP 4337 và có thể được tùy chỉnh bởi người dùng. Thiết kế mô-đun này cho phép ví hợp đồng thông minh nâng cấp. Thực tiễn này đã là một tiêu chuẩn công nghiệp trước khi EIP 4337 được phát hành, tiên phong bởi các sản phẩm như Gnosis Safe. Gnosis Safe là ví đa chữ ký chủ yếu hướng đến người dùng doanh nghiệp, cung cấp một loạt các tính năng không được định nghĩa trong EIP 4337:

• Giới hạn chi tiêu: Giới hạn số tiền mà tài khoản có thẩm quyền ký tên có thể rút khỏi ví.
• Thanh toán định kì: Tự động thanh toán theo lịch trình tùy chỉnh.
• Nhân vật và quyền hạn: Xác định nhân vật và quyền hạn cần thiết cho các giao dịch và hành vi ví khác nhau.
• Quyền của tổ chức: Cài đặt quyền dựa trên nhân vật khác nhau trong tổ chức.
• Danh sách trắng và danh sách đen

Thiết kế mô-đun tự cũng được kế thừa bởi các ví tương thích với EIP 4337, bao gồm Argent, Candide, Soul Wallet và zeroDev.

Một phương pháp khác để mở rộng chức năng của ví hợp đồng thông minh là tích hợp các ứng dụng phi tập trung(dApp) vào ví. Ví dụ: Gnosis Safe cung cấp một SDK cho dApp. Sử dụng SDK này, dApp sẽ xuất hiện trực tiếp trong giao diện ví, tạo ra một kho ứng dụng tích hợp sẵn. Các giải pháp tương tự khác bao gồm WalletConnect. Tuy nhiên, các giải pháp front-end này không được thiết kế ở cấp độ giao thức và do đó nằm ngoài phạm vi của bài viết này.

 Hình: Thiết kế mô-đun của ví Candide tương tự như Safe của Gnosis Safe (Nguồn: trang web ví Candide)

2. Nhà cung cấp cơ sở hạ tầng

Phần sau đây thảo luận về nhiều hỗ trợ Layer 2 cho Trừu tượng hóa tài khoản và các nhà cung cấp cơ sở hạ tầng bên thứ ba cho bên đóng gói và bên thanh toán.

a. Trừu tượng hóa tài khoản trên Layer 2

Với sự tăng trưởng gần đây của L2, nhiều ví hợp đồng thông minh đã chuyển trọng tâm phát triển sang L2. Nhiều L2 hỗ trợ sẵn tiêu chuẩn Hợp đồng Trừu tượng hóa tài khoản, rất giống với EIP 4337 và sẽ được tìm hiểu trong phần này.

Optimism

Phiên bản đầu tiên của Optimism đã triển khai Trừu tượng hóa tài khoản bằng cách giới thiệu ba OVM OpCode, vốn không được EVM hỗ trợ. Trong triển khai kỹ thuật của Optimism, hợp đồng thông minh là loại tài khoản duy nhất (không có EOA), vì vậy tất cả ví người dùng đều là ví hợp đồng thông minh. Ví hợp đồng thông minh cũng có thể nâng cấp mã hợp đồng bằng cách gọi hàm nâng cấp.

Thật không may, để duy trì tính nhất quán hoàn toàn với EVM và vì lý do bảo mật, phiên bản thứ hai của Optimism đã loại bỏ ba mã OVM này và hỗ trợ cho Trừu tượng hóa tài khoản.

Trong khi một số ví hợp đồng thông minh hiện đang được xây dựng trên Optimism , vẫn chưa có thông báo chính thức liên quan đến việc hỗ trợ Trừu tượng hóa tài khoản .

Arbitrum

Trong khi một số ví hợp đồng thông minh hiện đang được xây dựng trên Arbitrum , vẫn chưa có thông báo chính thức liên quan đến việc hỗ trợ Trừu tượng hóa tài khoản .

Starknet

Không giống như Ethereum, Starknet không phân biệt giữa EOA và tài khoản hợp đồng. Do đó, tất cả tài khoản Starknet đều là tài khoản hợp đồng thông minh. Mô hình tài khoản của Starknet chịu ảnh hưởng đáng kể từ EIP 4337, cụ thể ở các khía cạnh sau:

• Tất cả tài khoản hợp đồng thông minh Starknet phải chứa các hàm xác thực và thực thi. Hàm xác thực là bắt buộc, xác minh chữ ký để đảm bảo rằng chỉ chủ tài khoản mới có thể khởi tạo giao dịch và người thực thi giao dịch nhận đủ phí Gas. Người dùng có thể triển khai logic tùy ý trong các hàm xác thực và thực thi, cho phép mở rộng linh hoạt chức năng tài khoản. Ví dụ: người dùng có thể triển khai các thuật toán xác minh chữ ký khác nhau trong hàm xác thực.
• Để ngăn chặn các giao dịch được xác minh nhưng không thể thực hiện, Starknet cấm hàm xác thực gọi trạng thái của các hợp đồng bên ngoài.

Việc triển khai Trừu tượng hóa tài khoản của Starknet vẫn có những điểm khác biệt đáng kể so với Ethereum:

• Starknet không phân biệt giữa các giao dịch thông thường và UserOperations, vì tất cả các giao dịch đều được kích hoạt bởi tài khoản hợp đồng. Trong Ethereum , Bundler thực hiện các giao dịch UserOperation, trong khi ở Starknet, Sequencer thực hiện tất cả các giao dịch.
• Starknet vẫn chưa triển khai giao thức trừu tượng hóa phí giao dịch tương tự như Paymaster.
• Starknet yêu cầu một tài khoản có số dư token để tạo một tài khoản hợp đồng mới bằng cách gọi hàm deploy_account chuyên dụng. Tuy nhiên, trong EIP 4337, Bundler triển khai một tài khoản hợp đồng bằng cách thực hiện giao dịch UserOperation với tham số initCode không rỗng. Quy trình triển khai này không yêu cầu tài khoản có số dư token , vì phí Gas có thể được thanh toán bởi Paymaster.
• Nếu giao dịch đã xác minh không thành công ở bước thực hiện, trình tự của Starknet sẽ không thể trích xuất bất kỳ phí Gas, trong khi Ethereum không gặp phải vấn đề này.

 Hình: Starknet không có loại tài khoản EOA, chỉ có tài khoản hợp đồng (Ảnh do trang web chính thức của Starknet cung cấp)

zkSync

zkSync cũng không phân biệt giữa EOA và tài khoản hợp đồng , do đó hỗ trợ Trừu tượng hóa tài khoản một cách tự nhiên. Mô hình tài khoản của zkSync rất giống với EIP 4337, cụ thể ở các khía cạnh sau:

• Giao diện tài khoản (ví hợp đồng thông minh) cũng tách các hàm validateTransaction và executeTransaction.
• Giao diện hợp đồng Paymaster cũng bao gồm các hàm validateAndPayForPaymasterTransaction và postOp. Hàm trước xác định logic cho giao dịch thanh toán của Paymaster. Hàm sau đảm bảo Paymaster có thể thu phí Gas sau khi giao dịch được thực hiện, mặc dù chức năng này vẫn chưa được triển khai.
• Người dùng cũng gọi Paymaster bằng cách điền địa chỉ paymaster và các tham số paymasterInput trong giao dịch, tương tự như UserOperation trong EIP 4337.

Tuy nhiên, Trừu tượng hóa tài khoản được zkSync triển khai cũng khác biệt đáng kể so với Ethereum:

• zkSync cho phép hàm validateTransaction gọi các hợp đồng bên ngoài đã triển khai vì các hợp đồng đã triển khai là bất biến trong zkSync. Ethereum cấm hàm xác thực gọi các hợp đồng bên ngoài để ngăn ngừa các thay đổi trạng thái có thể khiến việc xác thực giao dịch thành công nhưng việc thực thi giao dịch lại thất bại.
• zkSync cho phép validateTransaction gọi bộ lưu trữ bên ngoài của tài khoản hợp đồng phát hành giao dịch này, chẳng hạn như số số dư token của tài khoản hợp đồng trên hợp đồng bên ngoài, vì cùng lý do như trên.
• Trong quá trình xác minh giao dịch, Paymaster có thể truy cập bộ nhớ ngoài vì những lý do tương tự như trên.

b. Nhà cung cấp cơ sở hạ tầng bên thứ ba (ví không phải hợp đồng thông minh)

Như đã đề cập ở trên, cơ sở hạ tầng Trừu tượng hóa tài khoản bao gồm các SDK máy trạm có thể gửi UserOperations, bundler, paymaster và signature aggregator. Cơ sở hạ tầng này thường được triển khai bởi chính các ví hợp đồng thông minh, cho phép tích hợp tốt hơn với các ngành công nghiệp thượng nguồn và hạ nguồn. Tuy nhiên, hầu hết không được thiết kế để sử dụng cho bên thứ ba. Do đó, cần có các nhà cung cấp cơ sở hạ tầng bên thứ ba cung cấp các dịch vụ bundler và paymaster mô-đun đun và có thể tùy chỉnh. Các công ty cơ sở hạ tầng có tiếng, chẳng hạn như Alchemy, đã tham gia vào thị trường này. Phần này sẽ đi sâu hơn vào các nhà cung cấp cơ sở hạ tầng bên thứ ba này.

Xếp chồng lên nhau

Stackup là một nhà cung cấp bundler và paymaster. Bundler của họ được triển khai bằng ngôn ngữ Go, đáp ứng tất cả các yêu cầu của bộ kiểm thử EIP 4377, hoàn toàn mã nguồn mở và miễn phí sử dụng. Stackup Bundler hỗ trợ các chế độ khác nhau:

• Chế độ sở hữu tư nhân: UserOperations sẽ được đưa vào một mempool sở hữu tư nhân, đánh đổi việc thực hiện giao dịch chậm hơn để đổi lấy quyền riêng tư tốt hơn. UserOperations sẽ không được hiển thị trong mempool công khai, do đó tránh được các cuộc tấn công MEV.
• Chế độ tìm kiếm: Được sử dụng bởi các nhà điều hành bot (còn được gọi là người tìm kiếm, chẳng hạn như bot chênh lệch giá DeFi) trong hệ sinh thái Ethereum và tích hợp với các trình xây dựng khối như Flashbot, gửi UserOperations qua MEV-Boost, cho phép người tìm kiếm đặt giá thầu cho sắp xếp giao dịch cụ thể để các trình xây dựng khối có thể chọn sắp xếp giao dịch có MEV lớn nhất để xây dựng khối.

Stackup cũng hỗ trợ hai loại Paymaster:

• Xác minh Paymaster: Cung cấp gas cho các giao dịch yêu cầu giao dịch ngoài Chuỗi(chẳng hạn như gửi nạp rút tiền fiat). Ví dụ: người dùng có thể chọn đăng ký dịch vụ Paymaster và phí Gas bằng thẻ tín dụng. Người dùng cũng có thể tùy chỉnh logic thanh toán gas . Stackup sẽ tính phí người dùng theo mô hình "trả tiền khi sử dụng".
• Deposit Paymaster: Cho phép người dùng thanh toán phí Gas bằng token ERC20.

 Hình: Bộ sản phẩm cơ sở hạ tầng của Stackup

Blocknative

Blocknative chủ yếu là một trình khám phá mempool và cung cấp công cụ trực quan hóa. Nhờ hiểu biết sâu sắc về mempool, Blocknative cung cấp dịch vụ bundler với các tính năng độc đáo, chẳng hạn như:

• Sử dụng EIP 4337 UserOps Explorer để trực quan hóa trạng thái của UserOperations trong nhóm bộ nhớ, giúp ví và dApp dễ dàng theo dõi trạng thái giao dịch theo thời gian thực.
• Sản phẩm cốt lõi của Blocknative, trình khám phá mempool, cũng có thể theo dõi các giao dịch Bundler đang chờ xử lý và đã xác nhận trong hợp đồng điểm vào.

Thuật giả kim

Alchemy hiện đang phát triển các dịch vụ Bundler và Paymaster và người dùng tiềm năng có thể tham gia danh sách chờ.

 Hình: Các dịch vụ cơ sở hạ tầng EIP 4337 của Alchemy vẫn đang được phát triển

chủ nghĩa vô hạn

eth-infinitism là một đội ngũ chính thức của Quỹ Ethereum đã triển khai Bundler và Paymaster theo tiêu chuẩn EIP 4337. Có rất ít tài liệu về đội ngũ này, nhưng theo một bài viết trên Stackup, tính đến tháng 2 năm 2023, eth-infinitism là một trong hai bundler duy nhất (nhóm còn lại là Stackup) đã vượt qua bộ kiểm tra chính thức EIP 4337.

Phần III: Tương lai của Trừu tượng hóa tài khoản

1. Cuối cùng, sự tồn tại của thị trường Trừu tượng hóa tài khoản phụ thuộc vào việc hệ sinh thái áp dụng EIP 4337 và thị trường này vẫn đang trong giai đoạn đầu.

Theo báo cáo gần đây của Web3Caff Research, tổng số địa chỉ gốc được loại bỏ trùng lặp (từ các tham số) trong tất cả các giao dịch Ethereum là khoảng 150 triệu. Tuy nhiên, tổng số ví hợp đồng thông minh, ước tính dựa trên tài khoản Gnosis Safe và Argent kết hợp (hai sản phẩm có nhiều người dùng nhất), chỉ là 150.000.

Giả sử số lượng ví EOA và ví hợp đồng thông minh cuối cùng bằng nhau, chúng ta có thể dự đoán rằng thị trường ví hợp đồng thông minh có tiềm năng tăng trưởng gấp 1.000 lần. Tuy nhiên, việc áp dụng ví hợp đồng thông minh trong hệ sinh thái sẽ không diễn ra suôn sẻ. Các công ty ví EOA lớn như MetaMask vẫn chưa công bố kế hoạch áp dụng EIP 4337. Mặc dù chúng ta không biết ý định của họ, nhưng có thể dễ dàng suy đoán rằng lợi nhuận đáng kể của các ví EOA lớn không biện minh cho việc đội ngũ của họ áp dụng một tiêu chuẩn mới với cơ sở hạ tầng hoàn thiện . UserOperation vẫn chưa phải là một loại giao dịch được sử dụng rộng rãi trong các dApp. Mặc dù vậy, tôi vẫn lạc quan về thị trường ví hợp đồng thông minh và dự đoán rằng những cải tiến đáng kể về trải nghiệm người dùng do ví hợp đồng thông minh mang lại sẽ thúc đẩy tăng trưởng theo cấp số nhân trong thị trường Trừu tượng hóa tài khoản , mặc dù sự bùng nổ này vẫn có thể mất thêm một hoặc hai năm nữa.

2. EIP 4337 vẫn chưa hoàn thành, các đồng chí vẫn cần phải nỗ lực hơn nữa

Mặc dù EIP 4337 định nghĩa các giao diện hợp đồng cho cơ sở hạ tầng như bundler, paymaster và signature aggregator, Ethereum vẫn chưa chính thức cung cấp giải pháp cho nhiều vấn đề kỹ thuật quan trọng. Những vấn đề này đòi hỏi các nhà phát triển dự án phải liên tục thử nghiệm các phương án triển khai kỹ thuật khác nhau, chẳng hạn như:

• Hiện tại, Bundler chủ yếu phát sóng các giao dịch trong sở hữu tư nhân , với UserOperations được gửi trực tiếp đến các trình xây dựng khối được chỉ định. Mạng Bundler có thể sử dụng mempool công khai không?
• Bundler có thể trích xuất MEV bằng cách sắp xếp UserOperations không? Block Builder có thể trích xuất MEV bằng cách sắp xếp bundles không? MEV sẽ được phân phối như thế nào giữa Bundler và Block Builder? Chúng ta có nên tách Bundler và Block Builder không?
• Với việc Bundler cần thực hiện lượng lớn mô phỏng ngoài Chuỗi và xác minh trên Chuỗi, liệu chúng có thể đóng vai trò là trình xây dựng khối đáng tin cậy không?
• Nhóm bộ nhớ UserOperation và nhóm bộ nhớ giao dịch thông thường nên được phối hợp như thế nào để tránh xung đột trạng thái?

3. Việc áp dụng EIP 4337 ở cấp độ L2 với tốc độ khác nhau

Mặc dù zkSync và Starknet đã hỗ trợ tính năng trừu tượng Trừu tượng hóa tài khoản , nhưng chúng vẫn chưa triển khai tất cả các giao diện EIP 4337 và khác biệt so với Ethereum về mặt triển khai kỹ thuật. Mặc dù nhiều đội ngũ dự án đang xây dựng ví hợp đồng thông minh, bundler và paymaster cho Optimism và Arbitrum, các L2 này vẫn chưa chính thức công bố kế hoạch hỗ trợ EIP 4337, và Trừu tượng hóa tài khoản không phải là ưu tiên phát triển.

Xét về mặt kỹ thuật thuần túy, việc triển khai cơ sở hạ tầng Trừu tượng hóa tài khoản L2 phức tạp hơn L1 . Ví dụ: trong bước xác minh, ví hợp đồng thông minh L2 cần ước tính cả phí Gas L1 và L2 và phân bổ chúng cho từng UserOperation trong gói.

4. Ngoài các chi tiết kỹ thuật, một ví hợp đồng thông minh tốt cần có những tính năng gì?

Mặc dù thị trường ví có nhiều tính năng đột phá (như trích xuất gas, phục hồi xã hội, MPC, v.v.), hầu hết các ví hợp đồng thông minh đều hỗ trợ tất cả các tính năng trên vì việc triển khai kỹ thuật các tính năng này không khó. Do đó, khía cạnh kinh doanh của ví hợp đồng thông minh cũng quan trọng như trải nghiệm người dùng. Các yếu tố kinh doanh quan trọng bao gồm:

• Hợp tác với dApp: Hợp tác với các dApp cấp đầu vào của từng Chuỗi L1 hoặc L2, đặc biệt là các dApp cơ sở hạ tầng (như stablecoin hoặc giao thức DeFi), là cách chính để thu hút người dùng.
• Các chức năng thực tế: chẳng hạn như thị trường NFT tích hợp vào ví, bệ phóng hoặc thu thập nhanh cặp giao dịch mới
• Hỗ trợ bên ngoài: chẳng hạn như hỗ trợ chính thức từ các VC hoặc Quỹ Ethereum , có thể giúp ví tìm được người dùng đầu tiên

5. Một bundler tốt cần có những tính năng gì?

Dịch vụ Bundler không cần cấp phép và mô-đun là một tài sản công cộng. Bản chất mã nguồn mở của hầu hết các dịch vụ Bundler khiến chúng không thể loại trừ và không cạnh tranh. Bất kỳ điểm cuối RPC nào cũng có thể chạy Bundler bằng cách phân nhánh mã mã nguồn mở mở. Ngay cả khi điểm cuối RPC chạy Bundler tính phí sử dụng dịch vụ thông qua khóa API, thì dịch vụ Bundler vẫn khó kiếm tiền hơn so với các cơ sở hạ tầng khác, chẳng hạn như Paymasters, vốn có thể dễ dàng hưởng lợi từ chênh lệch phí thông qua quan hệ đối tác với các nhà cung cấp nạp rút tiền rút tiền của bên thứ ba hoặc các đơn vị tổng hợp giao thức DeFi. Mặc dù khó thương mại hóa hơn, Bundler là một tài sản công cộng quan trọng vì việc xác minh và thực hiện UserOperations yêu cầu sự tham gia của càng nhiều Bundler càng tốt để đạt được phi tập trung lớn hơn. Vì Stackup và eth-infinitism hiện là hai nhà cung cấp dịch vụ Bundler của bên thứ ba duy nhất, nên chắc chắn chúng ta cần nhiều hơn nữa.

Các nhà cung cấp dịch vụ Bundler cần phải khắc phục nhiều khó khăn về mặt kỹ thuật:

• Chúng tôi đã tiến hành nghiên cứu chuyên sâu về nhiều bước xác minh ngoài Chuỗi và Chuỗi để đảm bảo UserOperations có thể được thực thi thành công. Khó khăn kỹ thuật bao gồm việc hiểu các xung đột trạng thái có thể phát sinh giữa nhiều UserOperations.
• Hiểu về việc vô hiệu hóa một số OpCode nhất định bằng chức năng xác minh:

• Vì việc đọc trạng thái bên ngoài có thể thay đổi có thể khiến việc xác minh giao dịch thành công nhưng việc thực thi lại không thành công, EIP 4337 cấm các hàm xác minh gọi OpCode đọc trạng thái