OKX Ventures: Phân tích hệ thống làn xe Trừu tượng Tài khoản trong quá khứ, hiện tại và tương lai
Tuyển chọn TechFlowTuyển chọn TechFlow
OKX Ventures: Phân tích hệ thống làn xe Trừu tượng Tài khoản trong quá khứ, hiện tại và tương lai
OKX Ventures bắt đầu từ điểm khởi nguyên của khái niệm này, một cách có hệ thống đã tổng hợp lại quá khứ, hiện trạng và các cơ hội trong tương lai của tài khoản trừu tượng (account abstraction).
Chuyên sâu báo cáo Web3Tác giả: Kiwi - Nhà nghiên cứu tại OKX Ventures
Bài viết này không cấu thành bất kỳ lời khuyên đầu tư nào.
Kể từ khi Vitalik Buterin đưa ra EIP-4337 vào tháng 9 năm 2021, khái niệm tài khoản trừu tượng (account abstraction) đang dần được đưa vào các ví Web3 chính thống. OKX Ventures lấy điểm khởi đầu là nguồn gốc của khái niệm này để hệ thống hóa lại quá khứ, hiện trạng và cơ hội tương lai của tài khoản trừu tượng.
Những điểm chính trong bài viết
Về thông tin cơ bản:
-
Tài khoản trừu tượng (AA), hỗ trợ session key giúp tách biệt nguồn giao dịch và chữ ký, đồng thời giúp người dùng tránh được các thao tác phức tạp như sao lưu khóa riêng, phí gas, làm giảm rào cản tham gia Web3;
-
Để đơn giản hóa loại tài khoản, mang lại sự tự do hơn cho hành vi trên chuỗi, đồng thời nâng cao mức độ bảo mật của tài khoản, cần đến tài khoản trừu tượng.
-
Sau các EIP-86, EIP-1014, EIP-2938, EIP-3074, EIP-4337 vì không cần thay đổi tầng đồng thuận, về cơ bản có thể coi là phương án cuối cùng cho AA trên Ethereum.
Hai hướng đi cho tài khoản trừu tượng đa chuỗi: Phương pháp tương thích 4337 (4337 compatible method), phương án tài khoản trừu tượng bản địa (native account abstraction).
-
Phương pháp tương thích 4337: Hiện tại Arbitrum, Polygon, Optimism và BNB chưa tích hợp bản địa tài khoản trừu tượng. Tuy nhiên, nhiều dự án hỗ trợ thông qua sản phẩm liên quan đến 4337 (như Biconomy, Stackup,...), việc xây dựng cơ sở hạ tầng vẫn ở giai đoạn khái niệm;
-
Phương án tài khoản trừu tượng bản địa: Starknet và zkSync hỗ trợ tài khoản trừu tượng bản địa, khác biệt với phương án 4337. Điểm khác biệt: Starknet không có Bundler và Paymaster, Sequencer xác định thứ tự giao dịch, thanh toán gas và thực thi; zkSync sử dụng Operator xác định thứ tự giao dịch, thanh toán gas, sau đó gọi bootloader để thực hiện cùng nhau.
Dữ liệu phát triển: Hơn 520.000 tài khoản AA đã được triển khai trên Ethereum, Arbitrum, Optimism và Polygon, trong đó hơn 80% tài khoản được tạo mới trong tháng 7-8, chủ yếu là hai chuỗi Polygon và Optimism tận dụng sự ra mắt của sản phẩm AA để đạt tăng trưởng mạnh mẽ. Số lượng giao thức hiện đang làm về Bundler và Paymasters còn ít, hiện tại trên mọi chuỗi đều bị độc quyền bởi các dự án như Pimlico, StackUp, v.v.
Cơ hội mà AA mang lại:
-
Paymaster là hợp đồng thông minh do dApp triển khai, thông qua Bundler kích hoạt Paymaster để thanh toán gas cho UserOperation cụ thể. Paymaster là dịch vụ tiêu chuẩn hóa, khó trở thành dự án độc lập, các bên trung gian web2 có thể tích hợp chức năng này để phục vụ nghiệp vụ web3. Cơ hội kinh doanh cho bên thanh toán trước: cổng dẫn lưu lượng, tự động chuyển đổi, tích hợp giới thiệu lưu lượng với các dự án DeFi, game, về tổng thể giống tình hình đổi mới trong ngành thanh toán. Hướng đổi mới của Paymaster khá đơn nhất nhưng là mắt xích thu hút giá trị ổn định nhất, làm giảm rào cản cho người dùng web2 bước vào web3, có thể sẽ có rất nhiều tổ chức web2 triển khai dịch vụ Paymaster.
-
Bundler là một trong những thành phần tiềm năng nhất, bản chất tương tự relayer, hướng kiếm tiền chủ yếu xoay quanh việc đóng gói giao dịch mở rộng ra hàng loạt cơ hội (như kiếm chênh lệch gas, MEV và hồ riêng tư thiên về nhu cầu doanh nghiệp), tuy nhiên nếu đóng gói giao dịch thất bại sẽ khiến bundler lỗ tiền, do đó chọn giao dịch là vấn đề nan giải.
-
Giao thức vốn có nút và dịch vụ Relayer thì sẽ dễ dàng xây dựng mạng Bundler hơn, ví dụ RPC như một cơ sở hạ tầng phân tán có thể giúp bundler phi tập trung hóa;
-
Hợp tác giữa Bundler với searcher, sequencer là lựa chọn tốt hơn, trong tương lai có thể thông qua hình thức mev share để phản hồi lợi nhuận cho người dùng qua các kênh, cuối cùng sẽ ngày càng công bằng hơn;
-
Hiện tại Bundler đều là hồ riêng, không có hồ công cộng, hiện chỉ có stackup vận hành tốt và có lợi nhuận, Biconomy ở mức trung bình;
-
Bundler là một hàng hóa công cộng sinh thái cực kỳ cần thiết nhưng rất khó kiếm lời, hiện trên thị trường chưa có mô hình vận hành hàng hóa công cộng trưởng thành, và phần lớn các dự án hiện tại vì cân nhắc lợi nhuận nên có xu hướng tư hữu hóa nó;
-
Hướng cải tiến kỹ thuật cho Bundler gồm: tránh va chạm nonce, mạng p2p có thể tối ưu vấn đề này thông qua đánh dấu và xóa bỏ; và sửa đổi storage hợp đồng khiến bundler không nhận đủ bồi thường, phần này cần đề xuất để tối ưu hóa tiếp theo.
-
-
Sự kết hợp giữa AA và MEV: AA, Sequencer và intent về bản chất kéo dài chuỗi thao tác trên chuỗi, chuỗi MEV cần hối lộ dài hơn, cả Bundler của AA và intent solve đều có khả năng hợp tác với các vai trò như Searcher trong chuỗi MEV để hình thành dạng chia sẻ MEV. Do AA cung cấp Bundler và hợp đồng entrypoint, về lý thuyết AA cũng có thể chia sẻ thu nhập từ PEV (Prover Extractable Value);
-
NFT: Việc cải thiện trải nghiệm sử dụng bản thân đã có thể thu hút thêm người dùng mới, đồng thời giúp giám sát và giao dịch trên thị trường tự động hóa hơn. ERC6551 và 4337 ở góc độ người dùng đều có khả năng tài khoản, có thể tích hợp trò chơi toàn chuỗi, DID và middleware. Trong tương lai, trò chơi toàn chuỗi cần tính kết hợp của ERC-6551 để hoàn thành trải nghiệm trò chơi đa chuỗi + tài khoản thiết bị có thể giao dịch;
-
Xã hội và trò chơi: Tối ưu hóa cơ sở hạ tầng danh tính sẽ nâng cao đáng kể tính dễ sử dụng của sản phẩm, đồng thời việc giảm rào cản thao tác trò chơi toàn chuỗi + tối ưu hóa mô hình tài khoản + hệ thống tài khoản đa chuỗi sẽ mang lại thế giới quan trò chơi đa chuỗi;
AA và intent:
-
Về bản chất, intent và AA không có mối liên hệ ràng buộc tất yếu. Intent về bản chất là đổi mới ở lớp trải nghiệm người dùng, hiểu và phân tích nhu cầu người dùng nhanh và tốt hơn, biến nó thành một hoặc nhiều UserOperation; AA là tối ưu hóa phía sau, thực hiện lệnh người dùng tốt hơn. Bot Telegram là ví dụ điển hình về đổi mới intent, nhưng phía sau vẫn sử dụng ví EOA, không ảnh hưởng đến trải nghiệm người dùng.
-
Intent là quá trình giải quyết tuyến đường op tối ưu cho mục tiêu cụ thể. Trước đây intent thiên về nhu cầu đơn giản, sau này có thể hình thành: vấn đề phức tạp nhiều điều kiện, nhiều bước, nhiều môi trường thực thi, thậm chí đưa vào AI agent.
-
Cơ hội Intent: Có thể giảm số lần ký tên ở đầu thao tác, nâng cao trải nghiệm người dùng. Đầu ứng dụng có thể dựa trên câu chuyện ý định để hình thành cơ sở hạ tầng mới, ngôn ngữ mới và hình thức giải pháp mới, là một trong những trường hợp sử dụng tiềm năng nhất trong tương lai
-
Hồ trung gian ý định hoặc chuỗi công khai ý định: Các ứng dụng dựa trên ý định không chỉ liên quan đến định dạng tin nhắn mới để tương tác với hợp đồng thông minh, mà còn liên quan đến cơ chế lan truyền và phát hiện đối tác giao dịch dưới dạng mempool thay thế. Thiết kế một cơ chế phát hiện và ghép nối ý định vừa tương thích khuyến khích vừa không tập trung là khá khó khăn.
-
Đa dạng hóa đường đi thực hiện Solver: Ngắn hạn, các Super Smart Contract đã trưởng thành sẽ tích hợp trước tiên, dài hạn nhìn xa hơn thì AI tự do cao hơn sẽ là hình thái lý tưởng nhất, nhưng độ khó thực hiện rất lớn; Solver sẽ mang lại phạm thức mới là xử lý trước ngoài chuỗi rồi lên chuỗi, có lợi cho một số giao thức tự động hóa (như Uniswap X); Hiện tại ZK coprocessor Axiom có thể là một demo cho giải pháp riêng tư.
-
Ngôn ngữ mới để biểu đạt ý định: Hiện đã có Juvix và Essential, các dự án loại này cần đi trước, cần xây dựng niềm tin của người dùng sớm;
-
-
Cơ hội ví và cổng vào: Ví hoàn toàn có thể trở thành đầu xây dựng lớp intent, vị thế chiến lược tăng mạnh, có thể trở thành cơ sở hạ tầng dẫn lưu và cổng vào cho các giao thức. Backend intent có thể tích hợp ví EOA, MPC và ví hợp đồng thông minh truyền thống; các ứng dụng giao dịch và đa chuỗi sẽ cải thiện trải nghiệm nhờ sự đa dạng hóa đầu vào (như tự động hóa, đa giải pháp);
-
Cơ hội ứng dụng loại ZK: Ý định của người dùng có nhu cầu mã hóa lớn, bản thân cơ chế 4337 đã có thể đáp ứng thanh toán riêng tư, tích hợp sâu hơn sẽ phát triển trong thị trường zkProof.
-
Rủi ro và rào cản: Ý định cần kỳ vọng tin cậy mạnh mẽ, tương ứng với rào cản tham gia cao, dẫn đến tập trung quá mức và đổi mới thiếu hụt.
Dự án trọng điểm:
-
Thị trường tài khoản trừu tượng có hai loại người tham gia: một loại là ví hợp đồng thông minh có chức năng đăng nhập xã hội & khôi phục, trừu tượng hóa gas, xử lý giao dịch theo lô, cũng như tích hợp và tổng hợp dịch vụ bên thứ ba (như nạp/rút tiền pháp định và giao thức DeFi), lĩnh vực này có nhiều dự án khởi nghiệp, giải pháp sơ khai; một loại là nhà cung cấp mô-đun hóa Bundler và Paymaster, ngoài biconomy và stackup, phần lớn còn ở giai đoạn đầu.
-
Dự án trọng điểm: Biconomy, Stackup và Pimlico là các giải pháp 4337 trưởng thành hơn trên thị trường hiện nay, tiếp tục hoàn thiện SDK và giải pháp mô-đun hóa sẽ giúp chiếm lĩnh thị trường tiên phong, đạt được tỷ lệ bao phủ thị trường cao về mặt kỹ thuật, hiện Stackup đã thực hiện hai loại Paymaster và mô hình Bundler, trong tương lai giải pháp toàn bộ quy trình + thư viện thành phần đa dạng sẽ là con đường để các dự án hàng đầu này tiếp tục mở rộng lợi thế.
-
Pimlico có thị phần bundler (chiếm tỷ lệ52% userop bundle toàn chuỗi) và lợi nhuận (lợi nhuận đứng đầu trên polygon, đạt 637 MATIC vào tháng 7, cũng có lợi nhuận trên optimism) đều dẫn đầu;
-
Stackup có hoạt động bundler trên mọi chuỗi, dẫn đầu về lợi nhuận trên Arbitrum (5 ETH tháng 8) và Ethereum (0,4 ETH tháng 7). Bundler ở trạng thái thất bại nhiều nhưng kiếm cũng nhiều;
-
-
Dự án đổi mới: Riêng tư là nhu cầu cứng, ví dụ ZK coprocessor Axiom có thể là một demo cho giải pháp riêng tư; Nocturne là lớp AA riêng tư có thể kết hợp, người dùng gửi tiền từ EOA hoặc hợp đồng tương tác với hợp đồng, sử dụng zkp để đạt được bảo vệ riêng tư. AI là chủ đề nóng trên thị trường, ví dụ Echooo Wallet kết hợp công nghệ MPC và AI, có thể đạt được đa ký và giám sát rủi ro AI; đồng thời đổi mới dựa trên các dự án truyền thống cũng là điểm sáng, ví dụ Universal Paymaster của đội Uniswap có thể khớp cặp giữa người dùng ví và nhà vận hành Paymaster tạo thành thị trường thanh khoản.
Các EIP khác và cơ hội:
-
Các EIP liên quan đến 4337, do chính thức định hướng 4337, hiện hầu hết đề xuất chủ yếu xoay quanh tối ưu hóa hướng triển khai AA. Như ERC 6551 là sản phẩm phụ trợ từ 4337; EIP 6662, ERC 6900, ERC 1271, ERC 6492, EIP 7204 và EIP 7197 đều là các hướng tối ưu AA; ERC 7377 thì hỗ trợ di chuyển tài khoản về sau;
-
Các dự án đoạt giải khác: Ethereum đã tài trợ 4 dự án liên quan đến tài khoản trừu tượng trong quý I-II năm 23, trong đó hai dự án do đội ngũ chính thức 4337 sản xuất (đội AA chính thức và ví trình duyệt 4337 do họ phát triển là trampoline), hai dự án còn lại chủ yếu xoay quanh đổi mới kết hợp giữa 4337 với các giao thức/công nghệ hiện tại (zkShield dùng ZKP và tài khoản trừu tượng để ẩn chữ ký đa ký riêng tư của chủ sở hữu tài khoản, Universal Paymaster do đội Uniswap phát triển là thị trường thanh khoản đơn lẻ cho thanh toán gas ERC-20)
Phát triển tương lai: Ngắn hạn chủ yếu là mở rộng thị trường, đồng thời hình thành mô hình thúc đẩy lẫn nhau với layer2; trung hạn tập trung triển khai Bundler và Paymaster mô-đun hóa cũng như triển khai SDK, đồng thời tối ưu hóa trải nghiệm sử dụng ở chi tiết (như giảm chi phí gas, thêm tùy chọn chuyển đổi EOA-to-ERC-4337, v.v.); dài hạn sẽ xem xét chuyển đổi bắt buộc ví EOA.
1. Giới thiệu về tài khoản trừu tượng
Định nghĩa và tóm tắt:
-
Bản chất của tài khoản trừu tượng là: tách biệt nguồn giao dịch và chữ ký;
-
Tại sao chúng ta cần tài khoản trừu tượng:
1) Đơn giản hóa loại tài khoản;
2) Tách biệt tài khoản và chữ ký, mang lại sự tự do hơn cho hành vi trên chuỗi, đồng thời đặt tài khoản ở mức độ bảo mật cao hơn;
-
Diễn tiến của tài khoản trừu tượng: Phân biệt trực tiếp có khối lượng công việc và độ phức tạp lớn, EIP 2938 và EIP 3074 lại cần thay đổi tầng đồng thuận, cuối cùng chọn phương án EIP 4337 không cần thay đổi底层.
Nguyên lý ERC 4337:
-
Vai trò: EIP 4337 chuẩn hóa ví hợp đồng thông minh và cơ sở hạ tầng liên quan thành năm giao diện hợp đồng: Bộ đóng gói (Bundler), Hợp đồng điểm vào (Entry Point Contract), Hợp đồng trả phí hộ (Paymaster), Nhà máy ví hợp đồng (Wallet Factory) và Bộ tổng hợp chữ ký (Signature Aggregator). Cùng với một loại giao dịch mới (UserOperation).
-
Các bước giao dịch: 4337 giới thiệu logic thao tác mới useroperation mà không thay đổi tầng đồng thuận Ethereum, thêm Bundler chịu trách nhiệm đóng gói userop. Sau quy trình ban đầu, thêm EntryPoint và hợp đồng Wallet để tách quá trình xác minh và thực thi nhằm hoàn thành nhiệm vụ tùy chỉnh, cuối cùng thông qua Paymaster tách rời logic thanh toán phí gas. Người dùng khởi tạo userop — userop được gửi đến "mempool userop" — Bundler chịu trách nhiệm đóng gói các UserOps được chọn thành một giao dịch gửi tới EntryPoint — EntryPoint xác minh thao tác người dùng, ví hợp đồng thông minh thực hiện thao tác người dùng và đưa vào khối.
So sánh 4337 với các phương án khác:
-
Phương án AA EIP-3074: Cần đưa vào hai op code mới để tài khoản EOA sử dụng hợp đồng, liên quan đến thay đổi tầng đồng thuận, do đó bị bỏ rơi;
1.1 Định nghĩa và tóm tắt giải pháp
Tài khoản trừu tượng là gì:
-
Ethereum có hai loại tài khoản: Tài khoản bên ngoài (EOA) và tài khoản hợp đồng (CA), EOA như giải pháp truyền thống quá phụ thuộc vào quản lý khóa và chữ ký ECDSA, logic thao tác cứng nhắc, cơ chế buộc quyền chữ ký và tài khoản gắn chặt này sẽ ảnh hưởng đến việc người dùng mới tham gia và phát triển sau này;
-
Cần một giải pháp cho phép người dùng sử dụng ví hợp đồng thông minh chứa logic xác minh tùy ý để giải quyết vấn đề này, giải pháp này được gọi là tài khoản trừu tượng (Account Abstract, AA), nguyên lý là tách biệt nguồn giao dịch và chữ ký.
Tại sao chúng ta cần tài khoản trừu tượng:
1) Đơn giản hóa loại tài khoản;
2) Tách biệt tài khoản và chữ ký, mang lại sự tự do hơn cho hành vi trên chuỗi, đồng thời đặt tài khoản ở mức độ bảo mật cao hơn;
Diễn tiến tài khoản trừu tượng: Phân biệt trực tiếp có khối lượng công việc và độ phức tạp lớn, EIP 2938 và EIP 3074 lại cần thay đổi tầng đồng thuận, cuối cùng chọn phương án EIP 4337 không cần thay đổi底层.
-
Phân biệt trực tiếp: Như thông qua EIP 86, EIP 101, EIP 859 để thêm loại giao dịch mới để phân biệt;
-
Nâng cao vị thế một loại tài khoản:
-
EIP 2938, khiến tài khoản hợp đồng trở thành tài khoản "cao cấp" có thể thanh toán phí và thực hiện giao dịch;
-
EIP 3074, đưa vào hai op code mới để tài khoản EOA sử dụng hợp đồng;
-
EIP 4337: Đưa vào logic thao tác mới - nhóm thao tác người dùng;
1.2 Nguyên lý kiến thức cơ bản ERC 4337
-
Giới thiệu: Tháng 9 năm 2021, Vitalik Buterin cùng các nhà nghiên cứu Ethereum từ OpenGSN và Nethermind đã đề xuất EIP-4337. EIP-4337 thêm nhóm thao tác người dùng mới mong muốn hoàn toàn thay thế nhóm giao dịch hiện tại, từ đó thực hiện tài khoản trừu tượng.
Vai trò
-
UserOperation: Giao dịch mà người dùng cần khởi tạo, sẽ được đóng gói gửi đến Bundler, và cùng với các UserOperations khác được đóng gói thành một Bundle;
-
Bundler: Nút chịu trách nhiệm chọn giao dịch từ nhóm giao dịch, đóng gói nhiều UserOperations và tạo giao dịch EntryPoint.handleOps().
-
EntryPoint: Hợp đồng thông minh xử lý xác minh và thực thi gói UserOperations, đóng vai trò trung gian giữa Bundler và ví hợp đồng thông minh:
-
Hợp đồng ví: Hợp đồng thông minh có thể tạo ví hợp đồng cho người dùng 4337;
-
Aggregator: Dùng để xác minh chữ ký tổng hợp;
-
Paymaster: Hợp đồng thông minh có thể giúp người dùng thanh toán phí gas.
Các bước giao dịch
-
Chữ ký giao dịch: Người dùng khởi tạo thao tác ví người dùng, sử dụng hình thức khóa riêng bất kỳ để ký thao tác (lệnh không đổi, nhưng nội dung trường thay đổi, có thể chọn chữ ký không phải ECDSA) tạo ra một thao tác người dùng có chữ ký (UserOperations), UserOp này sẽ được gửi đến nhóm thao tác người dùng chờ xử lý;
-
Gửi giao dịch: Bundler đóng gói các thao tác người dùng trong nhóm thao tác người dùng, sau đó ký riêng một giao dịch để bao bọc lệnh người dùng, xử lý hàng loạt UserOp thành một giao dịch và gửi đến hợp đồng điểm vào; Sau khi đóng gói nhiều UserOperations lại với nhau, Bundlers trước tiên sẽ mô phỏng giao dịch, kiểm tra xem có xảy ra thất bại thực thi hợp đồng hay không, và tính toán xem Gas có đủ hay không. Nếu mô phỏng thành công thì sẽ gửi gói UserOperations này thành một giao dịch gửi đến nút tạo khối;
-
Xử lý thao tác người dùng: Hợp đồng điểm vào xác minh ví có tồn tại hay không - yêu cầu ví xác minh thao tác người dùng - gửi thao tác người dùng đến ví hợp đồng thông minh để thực thi, đóng vai trò trung gian giữa Bundler và ví hợp đồng thông minh;
-
Khối lên chuỗi: Ví hợp đồng thông minh thực hiện thao tác người dùng và đưa vào khối.
1.3 So sánh với ví truyền thống và ví MPC
1.4 Phương án AA của EIP-3074
-
EIP-3074: Cần đưa vào hai op code mới để tài khoản EOA sử dụng hợp đồng, liên quan đến thay đổi tầng đồng thuận, do đó bị bỏ rơi;
-
Nếu nói EIP-4337 giúp tài khoản CA có thể sử dụng như EOA, thì EIP-3074 là để EOA bên ngoài có thể sở hữu chức năng lập trình của tài khoản hợp đồng. Cốt lõi là thông qua chữ ký, cho phép người khác sử dụng tài khoản của tôi để phát ra lệnh.
-
EIP-3074 thêm hai OpCodes mới, lần lượt là AUTH và AUTHCALL, nó hướng đến việc cho phép User (EOA) có thể ủy quyền cho hợp đồng (Invoker Contract, Invoker không thể nâng cấp) đại diện mình thực hiện các hành động khác nhau, đồng thời cho phép nhà phát triển thiết kế đối tượng giao dịch và cơ chế xác minh (thuật toán chữ ký) theo một khuôn khổ linh hoạt hơn, khiến bất kỳ EOA nào cũng có thể hoạt động như một tài khoản hợp đồng (Contract Account), mà không cần tự triển khai bất kỳ hợp đồng nào.
-
Ưu điểm: 1) Tự do cao hơn, có thể thực hiện các cách như giao dịch theo lô, giao dịch bao bì, nộp phí, đa ký, v.v.; 2) Có thể thanh toán nhiều loại phí, tài khoản bên ngoài cũng có thể sử dụng token yêu thích để thanh toán phí Invoker;
-
Nhược điểm: 1) EIP-3074 liên quan đến thay đổi lớn ở tầng đồng thuận, một khi có vấn đề sẽ cần hard fork để giải quyết; 2) Vì EIP-3074 cho phép tài khoản EOA bên ngoài có đặc tính của tài khoản hợp đồng, cơ chế chữ ký vẫn sử dụng chữ ký ECDSA cố định, không thể như EIP-4337 sử dụng bất kỳ hình thức chữ ký nào;
-
EIP-5003: Là đề xuất mở rộng của EIP-3074 (AUTH và AUTHCALL), nó đưa vào op code mới AUTHUSURP. Nếu sử dụng cơ chế EIP-3074, địa chỉ EOA A đã ủy quyền cho địa chỉ B khác hành động thay mình, thì AUTHUSURP cho phép B thiết lập mã cho A. Tức là nâng cấp EOA hiện tại thành hợp đồng, và cho phép chuyển từ ECDSA sang các phương án chữ ký hiệu quả hơn hoặc chống lượng tử.
2. Giải pháp tài khoản trừu tượng đa chuỗi
Tóm tắt
-
Hai hướng đi: Giải pháp tương thích 4337 (4337 compatible method), giải pháp tài khoản trừu tượng bản địa (native account abstraction).
-
Giải pháp tương thích 4337:
-
Hiện tại Arbitrum, Polygon, Optimism và BNB chưa tích hợp bản địa tài khoản trừu tượng. Tuy nhiên, nhiều dự án hỗ trợ thông qua sản phẩm liên quan đến 4337 (như Biconomy, Stackup,...), việc xây dựng cơ sở hạ tầng vẫn ở giai đoạn khái niệm;
-
Arbitrum đã thông qua đề xuất hỗ trợ điểm vào AA vào tháng 7 năm nay;
-
Polygon zkEVM trong tài liệu chính thức cho biết sẽ hỗ trợ thanh toán gas bằng nhiều loại token;
-
Optimism và BNB cung cấp một phần cơ sở hạ tầng tài khoản trừu tượng, như Alchemy, Biconomy, Pimlico và Stackup, v.v.
-
Giải pháp tài khoản trừu tượng bản địa: Hai chuỗi Starknet và zkSync hỗ trợ tài khoản trừu tượng bản địa, khác biệt với giải pháp 4337
Giải pháp tương thích 4337
Arbitrum:
-
Arbitrum đã thông qua đề xuất AIP-2 về hỗ trợ điểm vào tài khoản trừu tượng vào ngày 17 tháng 7 năm 23, hiện Offchain Labs đã chính thức kích hoạt hỗ trợ điểm vào tài khoản trừu tượng trên Arbitrum One và Arbitrum Nova;
-
Đề xuất này cho biết, các nhà nghiên cứu Ethereum đề xuất một endpoint RPC mới eth_sendRawTransactionConditional, giúp bộ sắp xếp L2 thích nghi với nhu cầu đặc biệt của bộ đóng gói ERC-4337 (bundlers).
Polygon:
-
Polygon tương thích 4337, đã công bố các giải pháp liên quan đến giao dịch meta, như Biconomy (giao thức trung gian đa chuỗi), Gas Station Network (GSN) (giao thức hàng hóa công cộng phi tập trung, có thể giúp trừu tượng hóa quá trình người dùng thanh toán Gas), Infura (nhà cung cấp nút) và Gelato (SDK trung gian, có thể thanh toán bằng nhiều loại token)
-
Polygon trong tài liệu chính thức cho biết, Polygon zkEVM hỗ trợ tài khoản trừu tượng thông qua ERC 4337 và sẽ cho phép người dùng sử dụng bất kỳ token nào để thanh toán phí, chi tiết thêm sẽ được công bố.
Optimism: Hiện tại OP Mainnet đã cung cấp một phần cơ sở hạ tầng tài khoản trừu tượng, như các dự án Alchemy, Biconomy, CyberConnect, Pimlico và Stackup, chi tiết kiến trúc chưa được công bố;
BNB: Trong roadmap công nghệ năm 2023 của BNB Chain, chính thức cho biết sẽ xây dựng cơ sở hạ tầng tài khoản trừu tượng, hiện 4377 đã tương thích trên BNB, chi tiết thêm sẽ được công bố.
Giải pháp tài khoản trừu tượng bản địa
Starknet hỗ trợ bản địa tài khoản trừu tượng, tức là tất cả tài khoản đều là tài khoản thông minh.
- Mục tiêu giải pháp: Trừu tượng hóa chữ ký (các hợp đồng tài khoản khác nhau sử dụng các phương án xác minh chữ ký khác nhau) và trừu tượng hóa thanh toán (các mô hình thanh toán và dạng token giao dịch khác nhau)
- Quy trình: Giao dịch được xác minh nouce trước khi đưa vào pool, sau đó được gửi đến địa chỉ hợp đồng tài khoản để xác minh, rồi mới thêm vào khối. Hai giai đoạn này được mã hóa trong hai hàm riêng biệt validate và execute trong hợp đồng tài khoản.
-
Sequencer đầu tiên yêu cầu hợp đồng tài khoản xác minh giao dịch; Để ngăn chặn tấn công DoS, Sequencer chấp nhận giao dịch phải mô phỏng cục bộ theo trạng thái đã biết trước khi thêm giao dịch vào mempool và phát sóng cho các Sequencer khác.
-
Sau khi mô phỏng thành công, giao dịch được thực thi, vào pool và lan truyền trong mạng.
-
Sự khác biệt giữa Starknet và giải pháp Ethereum:
-
Trong tài khoản trừu tượng bản địa Starknet, tất cả tài khoản đều là tài khoản thông minh, phải chứa các hàm validate và execution, người dùng thực hiện logic tùy chỉnh trong hai hàm này để mở rộng chức năng tài khoản.
-
StarkNet hỗ trợ nhiều đường cong elliptic, xác minh chữ ký có thể lập trình cao; validate đảm bảo chỉ chủ sở hữu tài khoản mới có thể khởi tạo giao dịch bằng cách xác minh chữ ký, đồng thời đảm bảo người thực thi giao dịch có thể nhận đủ phí gas, người dùng có thể thực hiện các thuật toán xác minh chữ ký khác nhau trong hàm validate;
-
Loại bỏ độ phức tạp bổ sung do Bundler mang lại: Starknet đơn giản hóa quy trình bằng cách chỉ định Sequencer thực hiện vai trò của Bundler;
-
Starknet không có giao thức trừu tượng hóa phí giao dịch tương tự Paymaster;
-
Starknet không phân biệt giao dịch thông thường và UserOperations: Vì tất cả giao dịch trên Starknet đều do tài khoản hợp đồng khởi tạo. Trên Ethereum, Bundlers thực hiện giao dịch UserOperation, còn trên Starknet, Sequencer thực hiện tất cả giao dịch;
-
Cách triển khai tài khoản hợp đồng khác nhau:
-
Starknet yêu cầu triển khai tài khoản hợp đồng trước mới có thể gọi, Starknet yêu cầu tài khoản có số dư token phải gọi một hàm deploy_account chuyên dụng để tạo tài khoản hợp đồng mới, tài khoản được triển khai này có thể thanh toán gas;
-
EIP 4337 không cần triển khai trước, Bundler triển khai tài khoản hợp đồng bằng cách thực hiện giao dịch UserOperation có tham số initCode không rỗng, quá trình triển khai không cần tài khoản có số dư token, phí gas có thể do Paymaster thanh toán hộ;
-
zkSync: zkSync Era thuộc giải pháp tài khoản trừu tượng bản địa, nhưng đồng thời tương thích EVM.
-
Mục tiêu giải pháp: Trừu tượng hóa chữ ký (các hợp đồng tài khoản khác nhau sử dụng các phương án xác minh chữ ký khác nhau) và trừu tượng hóa thanh toán (các mô hình thanh toán và dạng token giao dịch khác nhau)
-
Quy trình: Người dùng gửi giao dịch đã ký từ máy cục bộ đến Operator, Operator gửi Transaction đến bootloader để xác minh, sau khi hoàn thành xác minh và nhận phí, bootloader sẽ gọi hàm executeTransaction trên Account Contract để thực hiện giao dịch
-
Sự khác biệt giữa giải pháp zkSync và 4337:
-
zkSync không phân biệt EOA và tài khoản hợp đồng;
-
zkSync cho phép hàm validateTransaction gọi hợp đồng bên ngoài đã triển khai: Vì hợp đồng đã triển khai trên zkSync là không thay đổi (immutable); còn Ethereum cấm hàm xác minh gọi hợp đồng bên ngoài, để tránh thay đổi trạng thái (state change) gây ra xác minh giao dịch thành công nhưng thực thi giao dịch thất bại;
-
zkSync cho phép validateTransaction và Paymaster gọi bộ nhớ bên ngoài của tài khoản hợp đồng phát ra giao dịch này: Như số dư token của tài khoản hợp đồng trên hợp đồng bên ngoài, còn Ethereum cấm.
-
So sánh giải pháp zkSync, Starknet và 4337
Tương đồng:
-
Cơ chế AA của zkSync, Starknet và 4337 đều tương tự nhau, đều là Giai đoạn xác minh → Cơ chế phí (do Account Contract hoặc Paymaster thanh toán) → Giai đoạn thực thi; giao diện ví hợp đồng thông minh chia thành validateTransaction và executeTransaction;
-
Đối mặt với mối đe dọa DoS: Logic hợp đồng zkSync chỉ cho phép chạm vào các slots của chính nó, logic hợp đồng không thể sử dụng biến Toàn cục; Sequencer của Starknet yêu cầu phải mô phỏng cục bộ trước khi thêm giao dịch vào mempool và phát sóng; UserOperation của 4337 giới hạn gas cho bước validateUserOp, và Paymaster cần đặt cọc token.
Chào mừng tham gia cộng đồng chính thức TechFlow Nhóm Telegram:https://t.me/TechFlowDaily Tài khoản Twitter chính thức:https://x.com/TechFlowPost Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
OKX Ventures
