Được viết bởi Kiwi Yao, nhà nghiên cứu @OKX Ventures
Giải pháp trừu tượng hóa tài khoản đa chuỗi (AA) là cách thức mới mẻ và sáng tạo để tương tác với nhiều blockchain. Chúng cho phép người dùng tạo và quản lý tài khoản trên nhiều blockchain mà không phải lo lắng về các chi tiết kỹ thuật cơ bản, chẳng hạn như có đủ token gốc để thanh toán phí gas. Điều này giúp người dùng bắt đầu với công nghệ blockchain dễ dàng hơn nhiều và sử dụng nhiều blockchain cùng một lúc. Có hai loại giải pháp AA đa chuỗi chính: hỗ trợ tự nhiên và khả năng tương thích với ERC-4337.
Hỗ trợ tự nhiên là khi một blockchain trực tiếp hỗ trợ AA đa chuỗi. Khả năng tương thích với ERC-4337 là khi giải pháp mở rộng quy mô blockchain hoặc lớp 2 sử dụng hợp đồng thông minh để triển khai AA đa chuỗi. Trong bài viết này, chúng ta sẽ khám phá cả khả năng hỗ trợ tự nhiên và tương thích với ERC-4337 cho các giải pháp AA đa chuỗi. Chúng ta cũng sẽ thảo luận về những lợi ích và hạn chế của từng phương pháp.
Các mạng tương thích với tính năng trừu tượng hóa tài khoản ERC-4337
Arbitrum
Arbitrum chính thức kích hoạt các điểm cuối AA trên Arbitrum One và Arbitrum Nova sau khi áp dụng đề xuất AIP-2. Đề xuất giới thiệu điểm cuối RPC mới - eth_sendRawTransactionConditional - được thiết kế đặc biệt nhằm đáp ứng nhu cầu của bundler ERC-4337.
Polygon
Polygon tuân thủ ERC-4337 và đạt được điều này bằng cách tận dụng các giải pháp như Biconomy, Gas Station Network (GSN), Infura và Gelato cho các siêu giao dịch. Ngoài ra, zkEVM của Polygon hỗ trợ AA thông qua ERC-4337, cho phép người dùng thanh toán bằng bất kỳ token nào.
Optimism
Nhiều cơ sở hạ tầng AA khác nhau hiện có sẵn trên mạng chính OP thông qua các dự án như Alchemy, Biconomy, CyberConnect, Pimlico và Stackup, mặc dù thông tin về kiến trúc chi tiết vẫn chưa được công bố.
BNB
Trong lộ trình công nghệ cho Chuỗi BNB cho năm 2023, nhóm đề cập đến việc thiết lập cơ sở hạ tầng AA. Khả năng tương thích với ERC-4337 cũng được xác nhận và nhiều thông tin chi tiết hơn sẽ sớm được công bố.
Trừu tượng hóa tài khoản gốc
Starknet
Starknet vốn hỗ trợ AA bằng cách hiển thị tất cả các tài khoản dưới dạng tài khoản hợp đồng (CA) hoặc tài khoản thông minh. Mục tiêu của việc hỗ trợ AA theo cách tự nhiên bao gồm trừu tượng hóa chữ ký và trừu tượng hóa thanh toán. Điều này nhằm mục đích cho phép những hợp đồng tài khoản khác nhau sử dụng các chương trình xác thực chữ ký đa dạng và mô hình thanh toán khác nhau cho giao dịch. Qua đó, trải nghiệm quản lý tài khoản sẽ được cải thiện đáng kể vì các cá nhân giờ có nhiều lựa chọn hơn về xác thực chữ ký và thanh toán từ bên thứ ba hoặc hợp đồng thông minh.
Quá trình giao dịch Starknet
Khi một giao dịch được chọn để thêm vào khối, trình sắp xếp chuỗi sẽ chọn và thực hiện giao dịch đó. Việc thực hiện giao dịch xảy ra trong hai giai đoạn. Đầu tiên, trình sắp xếp chuỗi yêu cầu hợp đồng tài khoản xác thực giao dịch. Sau đó, trình sắp xếp chuỗi yêu cầu hợp đồng tài khoản thực hiện giao dịch đó. Hai giai đoạn này được mã hóa thành hai chức năng riêng biệt trong hợp đồng tài khoản – xác thực và thực thi.
Sự khác biệt giữa các giai đoạn này cho phép Starknet OS đảm bảo thanh toán cho trình sắp xếp chuỗi. Để ngăn chặn tấn công từ chối dịch vụ (DoS) lên bể giao dịch Starknet với các giao dịch không hợp lệ, Starknet yêu cầu một nút (node) chấp nhận giao dịch phải mô phỏng cục bộ giao dịch đó so với trạng thái đã biết trước khi thêm giao dịch vào bể và truyền phát nó đến các nút khác cũng như trình sắp xếp chuỗi. Sau khi hoàn thành mô phỏng, giao dịch có thể được nhập vào bể và truyền phát trên mạng.
Nguồn: StarkNet
Starknet AA và ERC-4337 AA
Starknet loại bỏ độ phức tạp bổ sung do bundler đưa vào và chỉ định trình sắp xếp chuỗi để hoàn thành vai trò của bundler. Điều này không giống như giải pháp AA của ERC-4337, vốn yêu cầu các bundler thực thi hoạt động của người dùng (user ops)
So với giải pháp AA của ERC-4337, Starknet không tích hợp giao thức trừu tượng hóa phí giao dịch giống như paymaster
Starknet cũng không phân biệt giữa giao dịch thông thường và hoạt động của người dùng, giúp đơn giản hóa quy trình
Một sự khác biệt đáng chú ý nằm ở việc triển khai. Starknet triển khai CA trước khi có thể kích hoạt CA. Về cơ bản, Starknet yêu cầu các tài khoản có số dư token để tạo CA mới bằng cách kích hoạt chức năng "triển khai_tài khoản” chuyên dụng. Hợp đồng tài khoản đã triển khai này có thể trả phí gas. Tương tự, giải pháp AA của ERC-4337 không yêu cầu triển khai trước. Bundler triển khai CA bằng cách thực hiện giao dịch hoạt động của người dùng với tham số initCode không null. Không yêu cầu sở hữu tài khoản có số dư token cho quá trình triển khai và phí gas có thể được paymaster thanh toán.
zkSync
zkSync hỗ trợ AA gốc và cung cấp khả năng tương thích với Máy ảo Ethereum (EVM). Tương tự như Starknet, mục đích của zkSync là trừu tượng hóa chữ ký và thanh toán, hỗ trợ nhiều chương trình xác minh chữ ký khác nhau cho các hợp đồng tài khoản khác nhau cũng như mô hình thanh toán và hình thức token đa dạng cho các giao dịch.
Quá trình giao dịch zkSync
Quá trình giao dịch của zkSync bao gồm việc cá nhân gửi giao dịch đã ký cho nhà vận hành, sau đó giao dịch này sẽ được gửi đến trình khởi động để xác thực. Sau khi xác thực và thu phí, trình khởi động gọi CA để thực hiện giao dịch.
zkSync AA so với ERC-4337 AA
Không giống như giải pháp AA của ERC-4337, zkSync không phân biệt giữa tài khoản thuộc sở hữu bên ngoài (EOA) và CA.
zkSync cho phép hàm validTransaction kích hoạt các hợp đồng bên ngoài đã triển khai. Đây là tính năng bị hạn chế trong Ethereum vì nó có thể tạo ra sự thay đổi trạng thái khiến quá trình xác thực giao dịch thành công và việc thực thi giao dịch lại không thành công.
Một điểm khác biệt nữa là zkSync cho phép hàm validTransaction và paymaster kích hoạt bộ nhớ ngoài của CA đã phát hành giao dịch này. Ví dụ: có thể xem số dư token của CA trên hợp đồng bên ngoài nhờ chức năng paymaster và validateTransaction. Ngược lại, Ethereum cấm tính năng tương tự.
So sánh giải pháp AA giữa các mạng tương thích zkSync, Starknet và ERC-4337
Điểm tương đồng
Các mạng tương thích zkSync, Starknet và ERC-4337 chia sẻ quy trình AA giống nhau. Chúng bao gồm giai đoạn xác minh, cơ chế tính phí (được thanh toán bằng hợp đồng tài khoản hoặc paymaster) và giai đoạn thực thi. Ngoài ra, giao diện ví hợp đồng thông minh được phân loại thành các hàm validTransaction và execTransaction.
zkSync, Starknet và ERC-4337 xử lý các cuộc tấn công DoS tương tự. Logic hợp đồng của zkSync chỉ dành cho các vị trí lưu trữ dữ liệu của riêng nó và không được phép sử dụng biến toàn cục. Tương tự, trình sắp xếp chuỗi của Starknet yêu cầu mô phỏng cục bộ trước khi thêm các giao dịch vào nhóm bộ nhớ và truyền phát chúng. Cuối cùng, hoạt động của người dùng ERC-4337 đặt giới hạn gas cho bước validateUserOp và yêu cầu paymaster phải thế chấp token.
Sự khác biệt
Điểm khác biệt lớn nhất nằm ở việc zkSync và StarkNet đều là AA gốc với sự khác nhau về kiến trúc so với các mạng tương thích ERC-4337
Về mức tiêu thụ gas on-chain, zkSync và StarkNet đều là những giải pháp mở rộng quy mô lớp 2 cần xem xét chi phí Rollup
Có nhiều vai trò khác nhau liên quan đến việc thực thi AA. Kiến trúc zkSync có nhà vận hành và trình khởi động (hợp đồng hệ thống) làm việc cùng nhau nhằm đáp ứng hoạt động của người dùng. Đối với StarkNet, trình sắp xếp chuỗi xử lý các hoạt động của người dùng mà không cần cơ chế bundler và paymaster. Cuối cùng, các mạng tương thích với ERC-4337 có kiến trúc khác nhau liên quan đến bundler và hợp đồng điểm vào
Một điểm khác biệt quan trọng là liệu các giao dịch có thể được gửi trước khi triển khai CA hay không. Trong cả StarkNet và zkSync, hợp đồng điểm vào không có trường initCode cho phép triển khai CA cho cá nhân. Điều này khiến cả hai không thể gửi giao dịch trước khi tài khoản được triển khai.
Cuối cùng, có sự khác biệt trong việc kích hoạt các hợp đồng bên ngoài. zkSync cho phép hàm validTransaction kích hoạt các hợp đồng bên ngoài đã triển khai. Tuy nhiên, cả mạng tương thích với ERC-4337 và Starknet đều không cho phép điều này.
Sự khác biệt về paymaster
Starknet không có giao diện paymaster
Đối với các mạng tương thích với ERC-4337, giao diện paymaster xác định validPaymasterOp. Điều này xác định logic để paymaster thanh toán cho một giao dịch. Giao diện cũng sử dụng chức năng postOp, đảm bảo paymaster có thể rút khoản bồi thường phí gas sau khi giao dịch được thực hiện. Paymaster cần nạp Ethereum trên hợp đồng điểm vào như một hình thức thanh toán phí gas và thế chấp Ethereum trên hợp đồng điểm vào để ngăn chặn bot tạo ra các lô giao dịch độc hại.
zkSync tương tự như các mạng tương thích với ERC-4337, trong đó giao diện xác định chức năng validPaymasterOp và postOp. Các định nghĩa tương tự như ERC-4337 nhưng phần chức năng này vẫn chưa được triển khai. Không giống như paymaster của ERC-4337, paymaster của zkSync sẽ không bắt đầu thực thi cho đến khi kích hoạt postTransaction vào thời điểm có đủ gas. Mặt khác, paymaster của ERC-4337 sẽ không kích hoạt postOp nếu validPaymasterUserOp không trả dữ liệu về.
Bảng so sánh
Bạn cần tham khảo nhanh để tìm ra sự khác biệt giữa hỗ trợ tự nhiên và mạng có tính năng tương thích với ERC-4337? Kiểm tra bảng của chúng tôi dưới đây.
So sánh | ERC-4337 | Starknet | zkSync |
---|---|---|---|
Tài khoản AA | Hợp đồng thông minh | Giao thức gốc | Giao thức gốc |
Quá trình logic | Giai đoạn xác minh → Cơ chế tính phí (thanh toán bằng hợp đồng tài khoản hoặc paymaster) → Giai đoạn thực thi | ||
Quá trình thực thi/kích hoạt | Bundler → điểm vào | Trình sắp xếp chuỗi | Nhà vận hành → trình khởi động |
Vai trò trong việc xác định thứ tự giao dịch | Bundler | Trình sắp xếp chuỗi | Nhà điều hành |
Vai trò trong việc xác định gas | Bundler | Trình sắp xếp chuỗi | Nhà điều hành |
Tiêu thụ phí gas | Lớp 1 | Lớp 1 on-chain + lớp 2 | Lớp 1 on-chain + lớp 2 |
Giao dịch có thể được gửi trước khi triển khai hợp đồng tài khoản | Có | Không | Không |
Quy tắc xác thực Paymaster | Logic được xác định thông qua validatePaymasterOp và postOp, paymaster cần nạp và stake Ether | Không có paymaster | Logic được xác định thông qua validPaymasterOp và postOp, trong đó logic kích hoạt postOp hơi khác so với Ethereum |
Hợp đồng bên ngoài có thể được gọi là | Không | Không | Có |
Cách giảm thiểu các mối đe dọa DoS | Hoạt động của người dùng đặt giới hạn gas ở bước validateUserOp và paymaster cần stake token | Các giao dịch phải được thêm vào nhóm bộ nhớ (mempool) và được mô phỏng cục bộ trước khi truyền phát | Chỉ được phép tiếp cập vị trí lưu trữ dữ liệu của riêng mình, không được sử dụng biến toàn cục |
Điểm mấu chốt
Khi Ethereum giới thiệu AA, chúng ta đang chứng kiến nhiều mạng khác làm theo bằng cách giải quyết rất nhiều vấn đề có thể khiến việc áp dụng đại trà trở nên khó khăn hơn. Với AA đa chuỗi, các hệ sinh thái cạnh tranh có thể cho thấy rằng họ không hề chậm trễ trong việc giải quyết những vấn đề tồn đọng như tính không linh hoạt khi thanh toán phí gas và sự phụ thuộc vào khóa riêng tư.
AA Đa chuỗi có khơi dậy sự tò mò của bạn khi khám phá không gian Web3 cùng chúng tôi không? Tìm hiểu cách OKX sẽ tích hợp AA vào ví đa chuỗi.
© 2024 OKX. Có thể sao chép hoặc phân phối toàn bộ bài viết này, hoặc dùng đoạn trích từ 100 từ trở xuống trong bài viết này, cho mục đích phi thương mại. Mọi hành vi sao chép hoặc phân phối toàn bộ bài viết đều cần nêu rõ: "Bài viết này thuộc bản quyền của © 2024 OKX và được sử dụng với sự cho phép". Các đoạn trích hợp lệ phải trích dẫn tên của bài viết và đưa phần ghi công vào, ví dụ: "Tên Bài viết, [tên tác giả nếu có], © 2024 OKX". Không được tạo tác phẩm phái sinh hay dùng bài viết này cho mục đích khác.