Nghiên cứu điểm tương đồng và khác biệt của các giải pháp trừu tượng hóa tài khoản cho Ethereum, Solana và Cosmos

Tác giả: Zeqing Guo & Jinming Neo, HashKey Capital Bản dịch: Golden Finance xiaozou< /span>

1. Tại sao chúng ta cần trừu tượng hóa tài khoản (AA)?

Vẫn còn nhiều vấn đề chưa được giải quyết trong lĩnh vực blockchain. Trong số đó, khó khăn khi sử dụng blockchain, tức là trải nghiệm người dùng (UX) khi tương tác với blockchain, chắc chắn là lĩnh vực mà công chúng phàn nàn nhiều nhất.

Ví dụ: nhiều người cho rằng sử dụng khóa phức tạp hơn sử dụng email để quản lý tài khoản, rằng việc quản lý khóa khó và không an toàn và mỗi lần chuyển tiền ( chẳng hạn như USDC) Cũng cần phải sử dụng các token gốc (chẳng hạn như Ether và Sol), điều này phản trực giác.

Trong bối cảnh này, ngày càng có nhiều người chuyển sự chú ý sang lĩnh vực trừu tượng hóa tài khoản để cải thiện trải nghiệm người dùng khi tương tác trên chuỗi và thúc đẩy việc áp dụng đại trà.

Trong quá trình khám phá, Ethereum đã đề xuất các giải pháp trừu tượng hóa tài khoản như ERC-4337, EIP-3074 và EIP-7702. Các L1 khác (chẳng hạn như Solana) có các tính năng hỗ trợ trừu tượng hóa tài khoản ở cấp độ giao thức (chẳng hạn như các địa chỉ PDA có nguồn gốc từ chương trình) và Cosmos có thiết kế tương tự (chẳng hạn như x/authz và Mô-đun trừu tượng phí). Trong bài viết này, chúng tôi sẽ giới thiệu và so sánh các giải pháp trên, hiểu rõ sự tinh tế của các thiết kế giải pháp khác nhau, đồng thời chứng minh sự cân bằng và cân nhắc của các giải pháp khác nhau.

2, giới thiệu nền

(1 ) EOA và tài khoản hợp đồng

Tài khoản bên ngoài (EOS) và tài khoản hợp đồng là hai loại được xác định trong sách trắng Ethereum Kiểu tài khoản. Tài khoản EOA được kiểm soát bằng khóa riêng. Người dùng có thể ký nhiều giao dịch khác nhau và kiểm soát tài sản trong tài khoản thông qua khóa riêng. Tài khoản hợp đồng được kiểm soát bởi mã của chính tài khoản hợp đồng và các tài khoản khác có thể khiến tài khoản hợp đồng thực thi logic cụ thể bằng cách gọi mã của tài khoản hợp đồng.

(2) Trừu tượng hóa tài khoản

Khái niệm trừu tượng tài khoản có niên đại từ năm 2016. Việc trừu tượng hóa tài khoản dựa trên hai loại tài khoản hiện tại trong Ethereum, đó là tài khoản EOA và tài khoản hợp đồng. Điều này sẽ cải thiện trải nghiệm tương tác của người dùng Ethereum bằng cách:

· Cho phép người dùng sử dụng nhiều chữ ký, chẳng hạn như Schnorr, BLS, chữ ký sau lượng tử, v.v.;< /p>

· Cho phép người dùng thanh toán phí gas bằng cách sử dụng mã thông báo ERC20 hoặc logic thanh toán tùy chỉnh;

· Cho phép người dùng truy xuất tài khoản của họ bằng email, mạng xã hội, v.v.;

· Cho phép người dùng quản lý nội dung trong tài khoản của họ với các quyền chi tiết hơn Tài trợ, chẳng hạn như đặt giới hạn rút tiền hàng ngày;

· Cho phép thực hiện nhiều hoạt động trên chuỗi trong một giao dịch nguyên tử. Ví dụ: người dùng có thể sử dụng một chữ ký duy nhất để hoàn thành các hoạt động phê duyệt và quy đổi trong các giao dịch DEX.

(3) Lộ trình Ethereum

Ethereum Những điểm nổi bật trong lộ trình Con đường nâng cấp trong tương lai của Ethereum. Hiện tại, hầu hết các nghiên cứu trong cộng đồng Ethereum đều xoay quanh lộ trình Ethereum. Việc trừu tượng hóa tài khoản là một phần thiết yếu của việc này:

< p style="text-align: left;">Cộng đồng Ethereum hy vọng sẽ triển khai các giải pháp trừu tượng hóa tài khoản trong giao thức dựa trên ERC-4337 thông qua các đề xuất như EIP-3074 hoặc EIP-7702 và cuối cùng đạt được tính năng trừu tượng hóa tài khoản Endgame.

Mặc dù nó nâng cao trải nghiệm người dùng, nhưng việc trừu tượng hóa tài khoản cũng rất quan trọng đối với tính toán phản lượng tử của Ethereum, bởi vì thuật toán ECDSA hiện được các tài khoản EOA sử dụng có tác động đáng kể đến tính toán lượng tử không an toàn. Sử dụng tính năng trừu tượng hóa tài khoản để hỗ trợ chữ ký hậu lượng tử, bảo vệ tài khoản người dùng khỏi các mối đe dọa ngày càng tăng do điện toán lượng tử gây ra.

3, EIP-3074 và ERC-4337

Để hiểu tính năng trừu tượng hóa tài khoản, chúng ta cần hiểu cách thức hoạt động của EOA. Hình sau đây cho thấy quy trình mua và bán mã thông báo phổ biến nhất trên chuỗi:

Nói chung, người dùng cần thực hiện hai giao dịch khi mua và bán token: đầu tiên ủy quyền cho Uniswap chuyển USDC của họ để trao đổi, sau đó gửi một yêu cầu giao dịch khác tới Uniswap Làm điều này. Uniswap chuyển USDC của tài khoản người dùng và gửi số lượng ETH tương ứng cho người dùng dựa trên giá hiện tại.

ERC-4337 hợp nhất hai giao dịch trên thành một giao dịch:

Như có thể thấy từ hình trên, người dùng cần ký hai lần để ủy quyền cho trình đóng gói để vận hành Tài sản của người dùng trong tài khoản 4337, khác với tài khoản EOA của người dùng. Sau khi trình đóng gói nhận được ủy quyền, nó sẽ hợp nhất nội dung được ủy quyền vào gói giao dịch và xuất bản gói giao dịch để hoàn tất giao dịch. Đồng thời, nếu người dùng không sử dụng mã thông báo Ethereum để thanh toán phí gas, vai trò người quản lý thanh toán cũng có thể được giới thiệu để cho phép người quản lý thanh toán thanh toán phí gas và nhận mã thông báo ERC20 tương đương từ người dùng.

EIP-3074 và ERC-4337 có một số điểm tương đồng, nhưng việc triển khai EIP-3074 nằm trong giao thức Ethereum:

Trong ERC-4337 , chúng tôi ủy quyền cho người đóng gói xử lý tài sản trong ví hợp đồng thông minh trên chuỗi của chúng tôi thông qua chữ ký. Trong EIP-3074, gói được ủy quyền xử lý trực tiếp tài sản trong ví EOA của chúng tôi thông qua chữ ký. Để làm được điều này, cộng đồng Ethereum cần thêm hai mã opcode mới vào giao thức Ethereum: AUTH và AUTHCALL.

AUTH được sử dụng để xác minh xem hành vi xử lý tài sản tài khoản EOA của người dùng của gói có được ủy quyền hay không và AUTHCALL được sử dụng để "lừa đảo" hợp đồng thông minh về tương tác của người dùng ( trong ví dụ của chúng tôi về USDC và Uniswap), khiến hợp đồng thông minh nghĩ rằng giao dịch đến từ tài khoản EOA của người dùng. Ưu điểm của việc này là những người duy trì Uniswap và USDC không cần nâng cấp các hợp đồng thông minh đã triển khai và tài khoản EOA cũng có thể có chức năng trừu tượng hóa tài khoản.

(1) So sánh EIP-3074 và ERC-4337

Trong cộng đồng Ethereum, EIP thường đề cập đến các đề xuất yêu cầu hỗ trợ nâng cấp Ethereum, trong khi ERC đề cập đến các đề xuất có thể được hỗ trợ mà không cần thông số nâng cấp Ethereum.

Do đó, qua cách đặt tên có thể thấy rằng ERC-4337 dễ triển khai hơn EIP-3074 vì ERC-4337 không yêu cầu Ethereum Mạng trải qua một đợt phân nhánh cứng. Đây là một trong những lý do khiến ERC-4337 được phát hành và ngày càng được sử dụng nhiều trong đa giác và cơ sở, nhưng EIP-3074 vừa được Hội nghị điều hành nhà phát triển toàn lõi Ethereum (ACDE) lần thứ 183 chấp nhận.

Ngoài ra, ERC-4337 yêu cầu người dùng di chuyển tài khoản hiện tại của họ sang tài khoản hợp đồng mới và yêu cầu DApps hỗ trợ chức năng của EIP-1271. EIP-3074 không yêu cầu hỗ trợ bổ sung này. Đây là lý do chính khiến tỷ lệ chấp nhận ERC-4337 thấp. Đồng thời, ERC-4337 không thể hỗ trợ một chữ ký để ủy quyền cho nhiều hoạt động trên chuỗi mà không đưa ra hợp đồng nhiều cuộc gọi trung gian, nhưng EIP-3074 thì có thể, điều này cũng dẫn đến những hạn chế của ERC-4337.

Tuy nhiên, EIP-3074 cũng có những vấn đề riêng. Vấn đề quan trọng nhất là quyền hạn của mã hoạt động AUTH quá cao, điều này có thể cho phép kẻ tấn công kiểm soát hoàn toàn tài khoản EOA của người dùng. Xét cho cùng, chỉ cần hacker lừa bạn ký AUTH, tài sản trong ví EOA của bạn có thể được xử lý. Xem xét rằng các cuộc tấn công lừa đảo hiện đang lan tràn và hầu hết các cuộc tấn công đều bằng cách giả mạo chữ ký người dùng, điều này sẽ trở thành một vấn đề nghiêm trọng hơn sau khi EIP-3074 được triển khai.

Đáp lại, lightclient, một trong những tác giả của EIP-3074, đã đề xuất một phương pháp giảm nhẹ để chặn chữ ký độc hại ở cấp độ ví. ERC-4337 không gặp phải vấn đề này, mặc dù tin tặc vẫn có thể lừa người dùng ký UserOps độc hại. Điều này là do UserOp khó có được quyền truy cập vào tất cả nội dung trong tài khoản của người dùng. Tại thời điểm viết bài, các nhà phát triển của ACDE đã nhất trí loại bỏ EIP-3704 khỏi Pectra Devnet 0 và đưa EIP-7702 vào Pectra Devnet 1 sau đây.

(2) Điều gì đã thay đổi với EIP-7702?

EIP-7702 cố gắng tích hợp các ưu điểm của EIP-3074 và ERC-4337 và đi theo con đường trung gian. Người dùng gửi thao tác đã ký tới bộ đóng gói. Khi người đóng gói gửi giao dịch đến chuỗi, tài khoản EOA của người dùng sẽ tạm thời trở thành tài khoản hợp đồng thông minh giống như tài khoản 4337. Tiếp theo, tương tự như quy trình AUTH trong EIP-3074, tài khoản hợp đồng thông minh sẽ xác minh hoạt động của gói được người dùng ủy quyền. Sau đó, giống như AUTHCALL, thực hiện các thao tác được người dùng ủy quyền. Sau khi thực hiện giao dịch, tài khoản người dùng sẽ được khôi phục về tài khoản EOA bình thường.

Ưu điểm của EIP-7702 như sau:

· Kế thừa những ưu điểm của EIP-3074 Tất cả ưu điểm: người dùng không bắt buộc phải chuyển từ tài khoản EOA sang tài khoản hợp đồng thông minh có địa chỉ mới và có thể thực hiện nhiều thao tác trong một giao dịch nguyên tử;

·  ;Mã tài khoản hợp đồng thông minh và cơ sở hạ tầng của ERC-4337 có thể được sử dụng lại;

· Sự trừu tượng hóa tài khoản hợp đồng thông minh được thể hiện bằng Các giải pháp trừu tượng hóa tài khoản ERC-4337 và EIP EOA được đại diện bởi -3074 có thể được hợp nhất để ngăn Ethereum tách thành hai hệ thống trừu tượng hóa tài khoản khác nhau, mở đường cho việc kết thúc các tài khoản trừu tượng trong lộ trình Ethereum;

· Hai opcode AUTH và AUTHCALL sẽ không được thêm vào EVM của Ethereum: Theo lộ trình của Ethereum, tài khoản EOA sẽ được chuyển đổi thành tài khoản trừu tượng tài khoản trong tương lai, khi hai hoạt động này mã sẽ trở nên dư thừa.

Ngoài ra, EIP-7702 cũng thừa hưởng mọi rủi ro bảo mật của EIP-3074.

Cộng đồng đã quyết định đưa EIP-7702 vào bản nâng cấp Pectra 2025. Nếu được triển khai, nó sẽ thay đổi đáng kể hệ sinh thái Ethereum và dần dần cải thiện phiên bản ERC-4337 hiện tại của cơ sở hạ tầng trừu tượng hóa tài khoản.

4, Địa chỉ bắt nguồn từ chương trình của Solana (PDA)< /strong> h2>

(1) Tóm tắt tài khoản của Solana

Việc trừu tượng hóa tài khoản của Solana tương tự như ERC-4337 của Ethereum. Chúng là những tài khoản được lấy từ tài khoản gốc (tương tự như tài khoản EOA), tương tự như tài khoản hợp đồng 4337. Trước khi hiểu sự trừu tượng hóa tài khoản của Solana, trước tiên cần phải hiểu mô hình tài khoản được Solana sử dụng.

Nói một cách rộng rãi, tài khoản có thể được chia thành tài khoản thực thi có thể thực thi mã và tài khoản không thực thi được không thể thực thi mã. Nhìn xa hơn, có ba loại tài khoản trên Solana: Chương trình gốc, Tài khoản chương trình và Tài khoản dữ liệu.

Các chương trình gốc là một phần của quá trình triển khai trình xác thực và cung cấp chức năng cốt lõi cho mạng Solana, chẳng hạn như tạo tài khoản dữ liệu mới và chương trình tùy chỉnh. Tài khoản chương trình là các chương trình tùy chỉnh có chứa mã thực thi. Tài khoản dữ liệu có thể lưu trữ dữ liệu và quản lý trạng thái chương trình theo quy định của tài khoản chương trình chủ sở hữu.

Mô hình tài khoản này cho phép tài khoản chương trình tạo và quản lý các tài khoản cụ thể, cung cấp cho nhà phát triển khả năng xác định các quy tắc và logic tùy chỉnh để quản lý tài khoản. Được hỗ trợ bởi mô hình tài khoản này, Địa chỉ phái sinh được lập trình (PDA), một loại tài khoản dữ liệu, mở rộng khả năng cho các tính năng trừu tượng hóa tài khoản trên Solana, từ tăng cường bảo mật người dùng thông qua ví đa chữ ký và xác thực hai yếu tố cho đến kích hoạt cơ chế phục hồi xã hội và hơn thế nữa .

(2) Địa chỉ bắt nguồn từ chương trình

Đối với ngữ cảnh, tất cả các tài khoản đều nằm trên đường cong Ed25519 và có cặp khóa công khai-riêng tư . PDA nằm bên ngoài đường cong Ed25519 và là một chuỗi 32 byte có nguồn gốc xác định trông giống như khóa chung nhưng không có khóa riêng tương ứng. PDA cho phép các nhà phát triển tạo các quy tắc tùy chỉnh và cơ chế ký giao dịch, cho phép chủ sở hữu tài khoản chương trình của PDA tự động thực hiện các giao dịch thay mặt cho PDA, được mạng Solana công nhận và hỗ trợ đầy đủ.

(3)PDA và Trừu tượng hóa tài khoản

Bây giờ chúng tôi đã hiểu PDA được tạo ra như thế nào, bạn cũng có thể thắc mắc làm thế nào những khái niệm này gắn liền với sự trừu tượng hóa tài khoản. Việc trừu tượng hóa tài khoản được triển khai một cách bí mật thông qua việc thực hiện một chức năng có tên là Gọi chương trình chéo (CPI).

CPI là chức năng cho phép một chương trình gọi hướng dẫn từ chương trình khác, nhờ đó đạt được khả năng kết hợp của các chương trình Solana. Khi một chương trình khởi tạo CPI thông qua Invo_signed, chương trình đó có thể ký thay mặt cho PDA dẫn xuất.

Để xác minh tính hợp pháp của các giao dịch liên quan đến PDA, thời gian chạy Solana gọi nội bộ create_program_address bằng cách sử dụng signers_seeds và Program_id của chương trình gọi. Nếu tìm thấy một PDA hợp lệ, bộ thực thi sẽ liên kết PDA với chương trình gọi và xác định chương trình đó là người ký được ủy quyền.

Hiện tại, Squads đang phát triển giải pháp trừu tượng hóa tài khoản Solana dựa trên PDA. Tuy nhiên, sản phẩm do Squads cung cấp hiện giống với giải pháp tài khoản hợp đồng thông minh của Gnosis Safe hơn và khả năng trừu tượng hóa tài khoản của nó vẫn chưa được phát triển đầy đủ.

(4) Ưu điểm của PDA

· Tự động thực hiện hợp đồng thông minh: PDA hỗ trợ các thiết kế hợp đồng thông minh phức tạp hơn và có thể thực hiện nhiều thao tác một cách tự động thay mặt người dùng thông qua các cuộc gọi giữa các chương trình.

· Trải nghiệm người dùng nâng cao: Người dùng không cần quản lý nhiều giao dịch hoặc gặp phải sự phức tạp về kỹ thuật.

· Tăng cường bảo mật và tính linh hoạt: Không có khóa riêng, giúp giảm nguy cơ bị xâm phạm khóa. PDA có thể được sử dụng với ví đa chữ ký hoặc các mô hình quản trị linh hoạt khác giúp giảm các điểm rủi ro duy nhất và đặc biệt hữu ích cho các tổ chức quản lý tài nguyên dùng chung lớn.

(5) Hạn chế của PDA

Mặc dù PDA giúp đặt nền tảng cho chức năng trừu tượng hóa tài khoản nhưng việc triển khai chúng có thể phức tạp hơn so với các tài khoản cặp khóa.

Giống như ERC-4337, nó yêu cầu người dùng thực hiện di chuyển tài khoản sang tài khoản mới, điều này có thể cản trở việc áp dụng tính năng trừu tượng hóa tài khoản Solana.

Trừu tượng hóa tài khoản trên 5, Cosmos (Authz và Cấp phí)

(1)Cosmos x/authz

< p style="text-align: left;">Khi việc trừu tượng hóa tài khoản ngày càng thu hút sự chú ý của các nhà phát triển, authz (một phần của Cosmos SDK cốt lõi) được giới thiệu để cho phép một tài khoản đại diện cho một tài khoản khác thông qua ủy quyền. Thực hiện một số hành động, tương tự như EIP- 3074 và EIP-7702.

Authz có một số loại cấp phép được xác định trước nhằm nâng cao trải nghiệm người dùng bằng cách ủy quyền thực hiện một số hoạt động nhất định (chẳng hạn như đặt cược) cho người được cấp.

Thông qua authz, có thể cấp 3 loại ủy quyền:

· < strong >Ủy quyền chung: Ủy quyền này cung cấp cho người được ủy quyền quyền không hạn chế để thực thi các tin nhắn thay mặt cho người ủy quyền.

· SendAuthorization: Giống như phê duyệt trong ERC20, ủy quyền này được thiết kế để cung cấp giới hạn chi tiêu linh hoạt cho người được cấp , giới hạn xác định số tiền tối đa mà người ủy quyền có thể chi tiêu thay mặt cho người ủy quyền.

· Ủy quyền cổ phần: Việc ủy ​​quyền này cho phép người được ủy quyền quản lý các hoạt động cầm cố, chẳng hạn như ủy quyền cầm cố thay mặt cho người ủy quyền, hủy bỏ sự ủy quyền hoặc ủy quyền lại.

Ủy quyền bao gồm byte địa chỉ của người ủy quyền, byte địa chỉ của người được ủy quyền và loại ủy quyền. Bạn cũng có thể xác định khoảng thời gian để giới hạn quyền trong một khoảng thời gian cụ thể. Ở cuối mỗi khối, mạng sẽ xóa các ủy quyền đã hết hạn thông qua một quá trình gọi là cắt bớt.

Hiểu khung hoạt động

Authz có thể được sử dụng để cấp quyền cho nhiều hoạt động khác nhau, nhưng để đơn giản Vì mục đích này, chúng ta sẽ xem xét cách Authz hoạt động để kích hoạt các giao dịch bỏ phiếu chung.

· Triển khai giao diện ủy quyền trước khi thực hiện bất kỳ ủy quyền nào. Giai đoạn này cũng sẽ xác định loại tin nhắn, trong trường hợp này là MsgVote. Ở đây chúng ta thấy Alice cho phép thực hiện hoạt động bỏ phiếu quản trị.

· Bob tạo giao dịch biểu quyết không dấu.

· Bob tạo giao dịch biểu quyết được ký và thực hiện từ người được ủy quyền. Sau khi giao dịch hoàn tất, giao dịch hết hạn sẽ bị xóa.

Lợi ích củaauthz là gì?

· Bảo mật hoạt động: Người xác thực và những người dùng khác có thể ủy quyền cho các tài khoản độc lập bỏ phiếu về các đề xuất quản trị hoặc thực hiện một số hành động nhất định, từ đó tăng cường bảo mật tài khoản và giảm tính bảo mật gánh nặng.

· Thao tác đơn giản hóa: các giao dịch có thể được thực hiện mà không cần truy cập vào khóa xác thực và các giao dịch ví nhiều chữ ký cũng có thể được ủy quyền bằng cách sử dụng một Tài khoản giao dịch duy nhất được ủy quyền với Authz để đơn giản hóa hoạt động.

· Không cần di chuyển: Tương tự như EIP-3074 và EIP-7702, hoạt động ủy quyền diễn ra trong tài khoản ban đầu của người dùng. Người dùng không cần chuyển tài sản của mình từ tài khoản gốc sang tài khoản mới để kích hoạt tính năng trừu tượng hóa tài khoản.

· DAOHiệu quả và tính linh hoạt trong hoạt động: Một phần quyền thực thi có thể được trao cho mỗi thành viên DAO để thực hiện các hoạt động cụ thể.

·Tổng hợp phần thưởng đặt cược: Authz tạo điều kiện cho việc sử dụng các dịch vụ đặt cược lại và ngang hàng để tự động tổng hợp phần thưởng đặt cược.

Hạn chế và rủi ro củaAuthz:

Hãy cẩn thận với vượt qua Loại giao dịch được ủy quyền bởi Authz. Ủy quyền độc hại có thể thực hiện nhiều loại ủy quyền khác nhau có thể gây hại cho người dùng.

· Ủy quyền chung: Cấp quyền không hạn chế để thực hiện nhiều chữ ký thay mặt cho người ủy quyền. Chúng tôi đặc biệt khuyên bạn nên tránh ký loại giấy ủy quyền này trừ khi bạn hoàn toàn hiểu rõ mình đang ký những gì. Một số ví cũng có thể không đưa ra cảnh báo khi ký giao dịch Authz.

· SendAuthorization: Cho phép người ủy quyền gửi số lượng token tối đa mà người ủy quyền có thể chi tiêu, nếu không được chỉ định bởi người ủy quyền Đối với số tiền cụ thể. Điều quan trọng nữa là phải xác minh AllowList, trong đó chỉ định các địa chỉ cụ thể có thể nhận mã thông báo do người được ủy quyền gửi.

(2)Mô-đun cấp phí

Một trở ngại khác đối với trải nghiệm người dùng là người dùng blockchain cần nắm giữ nhiều mã thông báo gốc khác nhau để tương tác với các hệ sinh thái khác nhau. Điều này gây tổn hại đến trải nghiệm chung của người dùng, đặc biệt đối với những người dùng gốc không sử dụng tiền điện tử, những người lần đầu tiên tiếp xúc với vô số chuỗi tồn tại trong hệ sinh thái Cosmos.

Tuy nhiên, với việc tích hợp module Fee Grant, vấn đề này đã được khắc phục. Tương tự như hợp đồng paymaster thực hiện tính năng trừu tượng hóa tài khoản trên Ethereum, mô-đun Cấp phí trên Cosmos cho phép người ủy quyền cấp trợ cấp phí cho người được cấp, thanh toán một phần hoặc toàn bộ phí giao dịch. Các quỹ vẫn nằm dưới sự kiểm soát của người ủy quyền và các khoản trợ cấp được ủy quyền có thể bị thu hồi bất cứ lúc nào.

Phân loại ủy quyền chi phí

Trợ cấp chi phí có thể được chia thành hai loại: BasicAllowance (Trợ cấp cơ bản) vàTrợ cấp định kỳ(Trợ cấp định kỳ).

BasicAllowance cho phép người được ủy quyền sử dụng các chi phí trong tài khoản của người ủy quyền cho đến khi đạt đến giới hạn chi tiêu hoặc thời gian hết hạn và sau đó việc ủy ​​quyền sẽ chấm dứt ở trạng thái. Cần lưu ý rằng BasicAllowance thực hiện ủy quyền phí một lần. Nếu cài đặt giới hạn chi tiêu và thời gian trống, khoản trợ cấp chi phí không có thời hạn hiệu lực và không có giới hạn chi tiêu.

PeriodicAllowance cho phép gia hạn ủy quyền tính phí định kỳ sau mỗi khoảng thời gian được chỉ định. Period_spend_limit chỉ định số lượng token tối đa có thể được chi tiêu trong một khoảng thời gian nhất định. Period_reset theo dõi thời gian của giai đoạn tiếp theo và Period_can_spend theo dõi số lượng mã thông báo còn lại trước khi giai đoạn mới bắt đầu.

Hiểu khung hoạt động

Sử dụng AllowedMsgAllowance để tạo Phụ cấp cho loại thông báo được chỉ định . Phụ cấp có thể là BasicAllowance hoặc PeriodicAllowance. Nếu thời gian hết hạn được đặt, FeeAllowance sẽ được xếp hàng ở trạng thái có tiền tố hết hạn. Endblocker sẽ kiểm tra trạng thái FeeAllowanceQueue để kiểm tra các ủy quyền đã hết hạn và xóa mọi ủy quyền đã hết hạn được tìm thấy. Ngoài MsgGrantAllowance, MsgRevokeAllowance cũng có thể được sử dụng để thu hồi các khoản phụ cấp phí.

Tóm lại, các mô-đun Authz và Fee Grant mở khóa nhiều trường hợp sử dụng sáng tạo khác nhau mà cuối cùng sẽ tạo ra trải nghiệm người dùng tốt hơn trên hệ sinh thái Cosmos.

6, Kết luận

Tính đến ngày 27 tháng 5 năm 2024 Dữ liệu ước tính trừu tượng của tài khoản trong ngày như sau:

< p style="text-align: left;">Với sự chấp thuận của BTC ETF và ETH ETF giao ngay, nhu cầu của tổ chức và bán lẻ đã tăng lên đáng kể, điều này được kỳ vọng sẽ mở ra một làn sóng người dùng mới muốn tiếp xúc đến ngành công nghiệp tiền điện tử. Việc trừu tượng hóa tài khoản sẽ là một câu chuyện lớn trong năm nay khi các giao thức và dApp tìm cách tạo ra trải nghiệm liền mạch để mở rộng quy mô cộng đồng của họ.