Tại sao chúng ta cần Trừu tượng hóa tài khoản?

Vẫn còn nhiều vấn đề chưa được giải quyết trong lĩnh vực blockchain hiện tại. 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 chuỗi, phải là lĩnh vực bị công chúng chỉ trích nhiều nhất.

Ví dụ: nhiều người nghĩ rằng sử dụng khóa phức tạp hơn sử dụng email để quản lý tài khoản; quản lý khóa rất khó khăn và không an toàn; và mỗi lần chuyển (như USDC) yêu cầu tiêu thụ mã thông báo gốc (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ú ý của họ 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 về các tương tác on-chain và tạo điều kiện cho việc áp dụng hàng loạt.

Trong quá trình thăm dò, Ethereum đề xuất trừu tượng hóa tài khoản giải pháp như ERC-4337, EIP-3074 và EIP-7702. Các L1 khác như Solana có các tính năng cho phép trừu tượng hóa tài khoản cấp giao thức như Địa chỉ dẫn xuất chương trình (PDA) và Cosmos cũng có thiết kế tương tự 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 nêu trên, sắp xếp sự tinh tế trong thiết kế của các giải pháp khác nhau và chứng minh sự đánh đổi và cân nhắc của các giải pháp khác nhau.

Background

EOA so với Tài khoản hợp đồng

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

Trừu tượng

tài khoản Khái niệm về tài khoản trừu tượng có thể được bắt nguồn từ năm 2016 (https://github.com/ethereum/EIPs/issues/86). Công trừu tượng hóa tài khoản dựa trên và được xây dựng dựa trên hai loại tài khoản hiện tại trong Ethereum - 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 thông qua các cách sau:

1. Cho phép người dùng sử dụng nhiều chữ ký, chẳng hạn như Schnorr, BLS, chữ ký hậu lượng tử, v.v.;
2. Cho phép người dùng thanh toán phí gas bằng token ERC20 hoặc logic thanh toán tùy chỉnh;
3. Cho phép người dùng truy xuất tài khoản của họ bằng email, phương tiện truyền thông xã hội, v.v.;
4. Cho phép người dùng quản lý tiền trong tài khoản của họ với các quyền chi tiết, chẳng hạn như đặt giới hạn rút tiền hàng ngày;
5. Cho phép nhiều hoạt động on-chain được thực hiện trong một giao dịch nguyên tử. Ví dụ: người dùng có thể hoàn thành các hoạt động phê duyệt và hoán đổi trong một giao dịch DEX bằng một chữ ký.

Ethereum Lộ trình

Lộ trình Ethereum (https://ethereum.org/en/roadmap/) nêu bật lộ trình nâng cấp trong tương lai của Ethereum. Hiện nay, hầu hết các nghiên cứu trong cộng đồng Ethereum đều xoay quanh lộ trình Ethereum. Trừu tượng hóa tài khoản là một phần bắt buộc của việc này:

Nguồn: https://x.com/VitalikButerin/status/1741190491578810445

Cộng đồng Ethereum hy vọng sẽ xây dựng trên ERC-4337 và thực hiện các giải pháp trừu tượng hóa tài khoản trong giao thức, thông qua các đề xuất như EIP-3074 hoặc EIP-7702, và cuối cùng đến Endgame trừu tượng hóa tài khoản.

Mặc dù nâng cao trải nghiệm người dùng, Endgame trừu tượng hóa tài khoản cũng rất quan trọng đối với điện toán chống lượng tử của Ethereum, bởi vì thuật toán ECDSA được sử dụng bởi tài khoản EOA hiện tại không an toàn trong kỷ nguyên điện toán lượng tử. Việc áp dụ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 chống lại các mối đe dọa đang phát triển của điện toán lượng tử.

EIP-3074 so với ERC-4337

Để hiểu tài khoản tài khoản trừu tượng, chúng ta cần hiểu cách hoạt động của EOA. Hình dưới đây là quy trình mua và bán token phổ biến nhất trên chuỗi:

Nói chung, người dùng cần phát hành hai giao dịch khi mua và bán: đầu tiên ủy quyền cho Uniswap chuyển USDC của họ để hoán đổi, sau đó gửi một yêu cầu giao dịch khác để Uniswap thực hiện hành động. 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 theo giá hiện tại.

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

Như có thể thấy từ hình trên, người dùng cần ký hai lần để ủy quyền cho bundler 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 bundler nhận được ủy quyền, nó sẽ hợp nhất nội dung được ủy quyền thành một gói và phát hành nó để hoàn tất giao dịch. Đồng thời, nếu người dùng không có mã thông báo Ethereum cho phí gas, vai trò của 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 có giá trị tương đương từ người dùng.

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

Trong ERC-4337, chúng tôi ủy quyền cho Bundler xử lý tài sản trong ví hợp đồng thông minh on-chain của chúng tôi thông qua chữ ký. Trong EIP-3074, bundler được ủy quyền xử lý trực tiếp các tài sản trong ví EOA của chúng tôi thông qua chữ ký. lệnh để làm điều này, cộng đồng Ethereum cần thêm hai opcode mới vào Ethereum giao thức: 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ó được ủy quyền hay không và AUTHCALL được sử dụng để "đánh lừa" hợp đồng thông minh tương tác người dùng (trong ví dụ của chúng tôi là USDC và Uniswap), khiến hợp đồng thông minh nghĩ rằng giao dịch là 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 bảo trì Uniswap và USDC không cần nâng cấp hợp đồng thông minh đã triển khai, đồng thời, tài khoản EOA có thể tận hưởng các chức năng của trừu tượng hóa tài khoản.

So sánh giữa 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 thông số kỹ thuật có thể được hỗ trợ mà không cần nâng cấp Ethereum.

Do đó, có thể thấy từ việc đặt tên cho hai sơ đồ trừu tượng hóa tài khoản rằng ERC-4337 dễ thực hiện hơn EIP-3074, vì ERC-4337 không yêu cầu fork cứng của mạng Ethereum. Đây cũng là một trong những lý do tại sao ERC-4337 đã được ra mắt và ngày càng được sử dụng nhiều hơn trên đa giác và cơ sở, nhưng EIP-3074 vừa được chấp nhận bởi 183rd Ethereum All Core Developers Execution Call (ACDE).

Nguồn: https://dune.com/niftytable/account-abstraction

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 DApp hỗ trợ để EIP-1271 hoạt động. EIP-3074 không yêu cầu các hỗ trợ bổ sung này. Đây là một lý do chính cho 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 on-chain mà không giới thiệu hợp đồng đa cuộc gọi trung gian, nhưng EIP-3074 có thể, điều này cũng gây ra những hạn chế của ERC-4337.

Tuy nhiên, EIP-3074 cũng có những vấn đề riêng. Điều quan trọng nhất là mã hoạt động AUTH có quyền 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. Rốt cuộc, long như một hacker lừa đảo chữ ký AUTH của bạn, anh ta có thể xử lý tài sản trong ví EOA của bạn. 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 chúng đều đánh lừa chữ ký của người dùng, một khi EIP-3074 được triển khai, điều này sẽ trở thành một vấn đề nghiêm trọng hơn.

Về vấn đề này, lightclient, một trong những tác giả của EIP-3074, đã đề xuất một phương pháp giảm thiểu để chặn các chữ ký độc hại ở cấp ví. Để biết chi tiết, vui lòng tham khảo: https://x.com/lightclients/status/1778823652584120497. ERC-4337 không có vấn đề này, mặc dù tin tặc vẫn có thể đánh lừa người dùng ký UserOps độc hại. Điều này là do UserOp khó có được quyền xử lý đối với tất cả các tài sản trong tài khoản người dùng. Tính đến thời điểm viết bài, các nhà phát triển trong ACDE đã đồng ý loại bỏ EIP-3704 khỏi Pectra Devent 0 và bao gồm EIP-7702 trong Pectra Devnet 1 tiếp theo.

Điều gì đã thay đổi trong EIP-7702?

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

Những lợi ích của EIP-7702 như sau:

1. Kế thừa tất cả các ưu điểm của EIP-3074: không yêu cầu người dùng chuyển từ tài khoản EOA sang tài khoản hợp đồng thông minh với địa chỉ mới; có thể thực hiện nhiều hoạt động trong một giao dịch nguyên tử;
2. Hợp đồng thông minh tài khoản mã và cơ sở hạ tầng của ERC-4337 có thể được tái sử dụng;
3. Hợp đồng thông minh trừu tượng hóa tài khoản đại diện bởi ERC-4337 và giải pháp trừu tượng hóa tài khoản EOA được đại diện bởi EIP-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 và mở đường cho Tài khoản trừu tượng Endgame trong lộ trình Ethereum;
4. Hai opcode AUTH và AUTHCALL sẽ không được thêm vào EVM của Ethereum: có tài khoản lộ trình Ethereum, các tài khoản EOA sẽ được chuyển đổi thành trừu tượng hóa tài khoản trong tương lai và hai opcode này sẽ trở nên dư thừa.

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

Cộng đồng đã quyết định đưa EIP-7702 vào bản nâng cấp Pectra tiếp theo vào năm 2025. Nếu được thực hiện, nó sẽ thay đổi đáng kể hệ sinh thái Ethereum và mang lại những cải tiến gia tăng cho 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.

Solana's Program Derived Địa chỉ

Account Abstraction on Solana

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

Nói chung, các tài khoản có thể được phân loại là tài khoản thực thi có thể thực thi mã hoặc tài khoản không thể thực thi không thể làm như vậy. Kiểm tra thêm điều này, 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 việc triển khai trình xác thực và cung cấp các chức năng cốt lõi cho mạng Solana như tạo tài khoản dữ liệu mới và các 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 định nghĩa của tài khoản chương trình chủ sở hữu.

Mô hình tài khoản này nguyên bản cho phép các 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 các 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ý chúng. Được kích hoạt bởi mô hình tài khoản này, Địa chỉ dẫn xuất chương trình (PDA), một loại tài khoản dữ liệu, mở rộng khả năng trừu tượng hóa tài khoản trên Solana từ việc 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 phép các cơ chế phục hồi xã hội trong số những người khác.

Program Derived Địa chỉ

Đố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 ngoài đường cong Ed25519, là một chuỗi 32 byte có nguồn gốc xác định trông giống như khóa công khai và không đi kèm với 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ế chữ ký giao dịch có thể cho phép chủ sở hữu chương trình tài khoản PDA tự động thực hiện các giao dịch thay mặt cho PDA, được công nhận và hỗ trợ đầy đủ bởi mạng Solana

PDA và trừu tượng tài khoản

Được rồi, bây giờ chúng ta đã hiểu PDA có nguồn gốc như thế nào, bạn có thể tự hỏi làm thế nào các khái niệm này được gắn với trừu tượng hóa tài khoản. Sự trừu tượng hóa tài khoản xảy ra dưới mui xe thông qua việc thực hiện một chức năng được gọi là Gọi chương trình chéo (CPI).

CPI là các chức năng cho phép một chương trình gọi các hướng dẫn của một chương trình khác, cho phép kết hợp các chương trình Solana. Khi một chương trình bắt đầu một CPI thông qua invoke_signed, các chương trình có thể ký thay mặt cho PDA có nguồn gốc.

Nguồn: Solana

Để 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 PDA hợp lệ được tìm thấy, thời gian chạy sẽ liên kết PDA với chương trình gọi và nhận ra chương trình là người ký được ủy quyền.

Hiện tại, Squads đang phát triển một giải pháp trừu tượng hóa tài khoản trê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à vẫn chưa phát triển đầy đủ chức năng trừu tượng hóa tài khoản của nó.

Lợi ích của PDA

1. Thực hiện hợp đồng thông minh tự động: PDA cho phép các thiết kế hợp đồng thông minh phức tạp hơn có thể tự động thực hiện nhiều hoạt động thay mặt cho người dùng thông qua các lệnh gọi chương trình chéo.
2. Nâng cao trải nghiệm người dùng: Người dùng không cần phải quản lý nhiều giao dịch hoặc tiếp xúc với sự phức tạp về kỹ thuật.
3. Tăng cường bảo mật và tính linh hoạt: Nếu không có khóa riêng, điều này sẽ giảm nguy cơ xâm phạm khóa. PDA có thể được sử dụng cho ví đa chữ ký hoặc phù hợp với các mô hình quản trị linh hoạt khác giúp giảm một đ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 chia sẻ lớn.

Hạn chế của PDA

1. PDA, mặc dù có lợi trong việc đặt nền tảng cho các khả năng trừu tượng hóa tài khoản, có thể phức tạp để thực hiện so với một cặp khóa tài khoản.
2. Và giống như ERC-4337, nó yêu cầu người dùng thực hiện tài khoản di chuyển sang một tài khoản mới có thể ngăn chặn tỷ lệ chấp nhận Solana trừu tượng hóa tài khoản.

Account Abstraction on Cosmos (Authz &; Fee Grant)

Cosmos x/authz

Với trừu tượng hóa tài khoản ngày càng chiếm lĩnh tâm trí của các nhà phát triển, authz, một phần của Cosmos SDK cốt lõi, đã được đưa ra để cho phép một tài khoản thực hiện một số hành động nhất định thay mặt cho một tài khoản khác thông qua việc sử dụng các khoản cấp ủy quyền tương tự như EIP-3074 và EIP-7702.

Authz đi kèm với một số loại ủy quyền được xác định trước ủy quyền thực hiện một số hành động nhất định như đặt cọc cho người được cấp, nâng cao trải nghiệm người dùng.

Với authz, có thể cung cấp 3 loại Ủy quyền:

1. GenericAuthorization. Khoản cấp ủy quyền này cho phép không hạn chế để người được cấp thực hiện thông điệp thay mặt cho người cấp.
2. GửiỦy quyền. Ủy quyền này, giống như phê duyệt trong ERC20, tìm cách cung cấp cho người được cấp quyền truy cập vào giới hạn chi tiêu tích cực xác định số tiền tối đa có thể được chi tiêu thay mặt cho người cấp.
3. StakeAuthorization. Khoản tài trợ này cho phép những người được cấp quản lý các hành động đặt cọc như ủy quyền, hủy ủy quyền hoặc ủy quyền lại thay mặt cho người cấp.

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

Hiểu khung hoạt động

Authz có thể được sử dụng để cấp ủy quyền cho nhiều hành động khác nhau, tuy nhiên để đơn giản, chúng tôi sẽ kiểm tra cách authz hoạt động để cho phép các giao dịch bỏ phiếu chung.

1. Triển khai giao diện ủy quyền trước khi bất kỳ ủy quyền nào có thể được thực thi. Ở giai đoạn này, loại tin nhắn cũng sẽ được xác định trong trường hợp này sẽ là MsgVote. Ở đây, chúng ta thấy một ủy quyền tài trợ từ Alice cho một hành động bỏ phiếu quản trị.
2. Bob tạo ra một giao dịch bỏ phiếu không ký.
3. Bob tạo ra một giao dịch đã ký và thực hiện phiếu bầu từ người được cấp. Giao dịch được hoàn tất và ủy quyền sẽ bị xóa nếu hết hạn.

Lợi ích mà authz mang lại?

1. Bảo mật hoạt động: Người xác thực và những người dùng khác có thể cấp quyền cho một tài khoản riêng biệt để bỏ phiếu cho các đề xuất quản trị hoặc thực hiện một số hành động nhất định, tăng cường bảo mật tài khoản và giảm gánh nặng bảo mật.
2. Hoạt động được sắp xếp hợp lý: Các giao dịch có thể được thực hiện với nhu cầu truy cập vào khóa xác thực, các giao dịch ví đa chữ ký cũng có thể được sắp xếp hợp lý bằng cách sử dụng một giao dịch duy nhất để cấp Authz cho tài khoản người được cấp.
3. Không cần di chuyển: Tương tự như EIP-3074 và EIP-7702, các hoạt động ủy quyền xảy ra trong tài khoản ban đầu của người dùng. Người dùng không cần phải chuyển tài sản của họ từ tài khoản gốc sang tài khoản mới để bật trừu tượng hóa tài khoản.
4. DAO Hiệu quả hoạt động và tính linh hoạt: Một tập hợp con các quyền thực thi có thể được trao cho các thành viên DAO cá nhân cho các hành động cụ thể.
5. Staking Thưởng gộp: Authz tạo điều kiện thuận lợi cho việc sử dụng các dịch vụ lấy lại và các dịch vụ tương đương để tự động gộp phần thưởng đặt cược.

Hạn chế và rủi ro đối với Authz:

Hãy chú ý đến các loại giao dịch mà bạn đang ủy quyền qua 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 bất lợi cho người dùng.

1. GenericAuthorization: cho phép không hạn chế để thực hiện MSG được cung cấp thay mặt cho người cấp. Trừ khi nhận thức đầy đủ về những gì bạn đang ký, bạn nên tránh ký các loại ủy quyền như vậy. Một số ví cũng có thể không cung cấp cảnh báo khi ký giao dịch Authz.
2. SendAuthorization: Cho phép người được cấp gửi số lượng token tối đa mà người được cấp có thể chi tiêu nếu không được người cấp chỉ định. Điều quan trọng nữa là phải xác minh Danh sách cho phép chỉ định địa chỉ cụ thể mà người được cấp có thể gửi mã thông báo đến.

Mô-đun cấp phí

Một trở ngại khác đối với trải nghiệm người dùng khiến nhiều người thất vọng là người dùng blockchain cần phải giữ các mã thông báo gốc khác nhau lệnh tương tác với các hệ sinh thái khác nhau này. Điều này làm ô uế trải nghiệm người dùng tổng thể, đặc biệt là đối với những người bản địa không phải 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 trên hệ sinh thái Cosmos.

Tuy nhiên, rào cản này đã có bước đột phá với việc tích hợp Mô-đun tài trợ phí. Tương tự như hợp đồng paymaster cho phép 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 cấp cấp phụ cấp phí cho người được cấp, thanh toán một phần hoặc tất cả phí giao dịch. Các quỹ vẫn nằm trong tầm kiểm soát của người cấp và nó có thể thu hồi trợ cấp bất cứ lúc nào.

Các loại trợ cấp phí

Trợ cấp lệ phí có thể được phân thành hai loại: BasicAllowance và PeriodicAllowance.

BasicAllowance cho phép người được cấp sử dụng phí từ người cấp tài khoản cho đến khi đạt đến giới hạn chi tiêu hoặc thời gian hết hạn. Khoản trợ cấp sau đó sẽ bị chấm dứt khỏi tiểu bang. Điều quan trọng cần lưu ý là BasicAllowance thực hiện trợ cấp phí một lần. Nếu giới hạn chi tiêu và thời gian trống, không có giới hạn hết hạn và chi tiêu cho trợ cấp phí.

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

Hiểu khung hoạt động

Sử dụng AllowedMsgAllowance sẽ tạo một khoản trợ cấp cho các loại thư đượ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 trong tiểu bang với tiền tố hết hạn được thêm vào khoản trợ cấp và Endblocker kiểm tra trạng thái FeeAllowanceQueue để tìm các khoản trợ cấp đã hết hạn, cắt tỉa bất kỳ khoản nào nếu tìm thấy. Ngoài MsgGrantAllowance, một khoản trợ cấp lệ phí cũng có thể bị thu hồi bằng cách sử dụng MsgRevokeAllowance.

Kết hợp với nhau, các mô-đun Authz và Fee Grant mở ra các trường hợp sử dụng sáng tạo và đa dạng, cuối cùng xây dựng trải nghiệm người dùng tốt hơn trên hệ sinh thái Cosmos.

Kết luận

Trừu tượng hóa tài khoản Tính đến ngày 27 tháng 5 năm 2024, số liệu được ước tính.

Với sự chấp thuận của các quỹ ETF BTC giao ngay và ETF ETH, nhu cầu tổ chức và bán lẻ đã tăng lên đáng kể, hứa hẹn sẽ mở ra một làn sóng người dùng mới muốn tiếp xúc với ngành. Trừu tượng hóa tài khoản sẽ trở thành một câu chuyện quan trọng 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 cộng đồng của họ.

DISCLAIMER

Tài liệu này chỉ dành cho thông tin chung và không cấu thành, cũng không nên được hiểu là bất kỳ hình thức kết quả nghiên cứu, tư vấn chuyên nghiệp, chào mời, đề nghị, khuyến nghị hoặc chiến lược giao dịch nào. Không có đảm bảo, đại diện, bảo hành hoặc cam kết, rõ ràng hay ngụ ý, được thực hiện về tính công bằng, chính xác, kịp thời, đầy đủ hoặc đúng đắn của bất kỳ thông tin, phân tích và / hoặc ý kiến chung về tài chính và thị trường nào được cung cấp trong báo cáo này và không có trách nhiệm pháp lý hoặc trách nhiệm nào được HashKey Capital chấp nhận liên quan đến việc sử dụng hoặc dựa vào bất kỳ thông tin nào như vậy. Bất kỳ thông tin nào về báo cáo này có thể thay đổi mà không cần thông báo. Báo cáo này chưa được xem xét bởi Ủy ban Chứng khoán và Hợp đồng tương lai Hồng Kông, Cơ quan Tiền tệ Singapore hoặc bất kỳ cơ quan quản lý nào ở Hồng Kông hoặc Singapore.

Xin lưu ý rằng các tài sản kỹ thuật số, bao gồm cả tiền điện tử, có tính biến động cao và chịu rủi ro thị trường. Giá trị của tài sản kỹ thuật số có thể dao động đáng kể và không có gì đảm bảo lợi nhuận hoặc bảo toàn vốn. Bạn nên xem xét cẩn thận khả năng chấp nhận rủi ro và tình hình tài chính của chính mình trước khi đưa ra bất kỳ quyết định nào.

Việc phân phối báo cáo này có thể bị hạn chế ở một số khu vực pháp lý nhất định. Tài liệu này không cấu thành việc phân phối bất kỳ thông tin nào hoặc đưa ra bất kỳ đề nghị hoặc chào mời nào của bất kỳ khu vực tài phán nào mà hành động đó không được phép hoặc cho bất kỳ người nào mà việc phân phối báo cáo đó là bất hợp pháp.

Luôn cập nhật những tin tức mới nhất về HashKey Capital -

Trang web — https://hashkey.capital/

Twitter - https://twitter.com/HashKey_Capital

LinkedIn - https://www.linkedin.com/company/hashkeycapital/

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Medium]. Tất cả bản quyền thuộc về tác giả gốc [HashKey Capital]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn và họ sẽ xử lý kịp thời.

2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.

3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.