A study on the similarities and differences between Ethereum, Solana, and Cosmos account abstraction solutions

Author: Zeqing Guo & Jinming Neo, HashKey Capital; Translation: Golden Finance xiaozou

1, Why do we need account abstraction (AA)?

There are still many unresolved issues in the blockchain field. Among them, the difficulty of using blockchain, that is, the user experience (UX) of interacting with blockchain, is definitely the area that the public complains about the most.

For example, many people think that using keys is more complicated than using email to manage accounts, key management is difficult and not safe, and each transfer (such as USDC) also requires the use of native tokens (such as Ether and Sol), which is counterintuitive.

Against this backdrop, more and more people are turning their attention to the field of account abstraction to improve the user experience of on-chain interactions and promote large-scale adoption.

During the exploration process, Ethereum proposed account abstraction solutions such as ERC-4337, EIP-3074, and EIP-7702. Other L1s (such as Solana) have functions that support protocol-level account abstraction (such as program-derived addresses PDA), and Cosmos also has similar designs (such as x/authz and Fee Abstraction Module). In this article, we will introduce and compare the above solutions, understand the subtleties of the design of different solutions, and demonstrate the pros and cons and precautions of different solutions.

2, Background Introduction

(1) EOA and Contract Account

External Accounts (EOS) and Contract Accounts are two types of accounts defined in the Ethereum white paper. EOA accounts are controlled by private keys, and users can sign various transactions through private keys to control the assets in the account. The contract account is controlled by the code of the contract account itself, and other accounts can call the code of the contract account to let the contract account execute specific logic.

(2) Account Abstraction

The concept of abstract account can be traced back to 2016. Account abstraction is based on the current two types of accounts in Ethereum, namely EOA accounts and contract accounts. This will improve the interactive experience of Ethereum users in the following ways: · Allow users to use multi-signatures, such as Schnorr, BLS, post-quantum signatures, etc. · Allow users to pay gas fees using ERC20 tokens or custom payment logic · Allow users to retrieve their accounts using email, social media, etc. · Allow users to manage funds in their accounts with fine-grained permissions, such as setting daily withdrawal limits · Allow multiple on-chain operations to be performed in one atomic transaction. For example, users can use one signature to complete approval and redemption operations in DEX transactions. （3）Ethereum Roadmap The Ethereum roadmap emphasizes the future upgrade path of Ethereum. Currently, most of the research in the Ethereum community is centered around the Ethereum roadmap. Account abstraction is an essential part of it:

The Ethereum community hopes to build on ERC-4337 and implement account abstraction solutions within the protocol through proposals such as EIP-3074 or EIP-7702, and ultimately achieve Endgame account abstraction.

Although it enhances the user experience, account abstraction finality is also critical to Ethereum's anti-quantum computing, because the ECDSA algorithm currently used by EOA accounts is not secure in the era of quantum computing. Account abstraction is adopted to support post-quantum signatures and protect user accounts from the evolving threats posed by quantum computing.

3, EIP-3074, and ERC-4337

To understand account abstraction accounts, we need to understand how EOA works. The following figure shows the most common token buying and selling process on the chain:

Generally speaking, users need to issue two transactions when buying and selling tokens: first authorize Uniswap to transfer their USDC for exchange, and then send another transaction requesting Uniswap to perform the operation. Uniswap transfers the USDC of the user's account and sends the corresponding amount of ETH to the user based on the current price.

ERC-4337 combines the above two transactions into one transaction:

As can be seen from the above figure, the user needs to sign twice to authorize the bundler to operate the user's assets in the 4337 account, which is different from the user's EOA account. After the bundler obtains authorization, it merges the authorized content into a transaction package and publishes the transaction package to complete the transaction. At the same time, if the user does not have Ethereum tokens for paying gas fees, the paymaster role can also be introduced to let the paymaster pay the gas fee and obtain the equivalent ERC20 token from the user.

EIP-3074 and ERC-4337 have some similarities, but the implementation of EIP-3074 is within the Ethereum protocol:

In ERC-4337, we authorize the bundler to process the assets in our on-chain smart contract wallet by signing. In EIP-3074, the bundler is authorized to directly process the assets in our EOA wallet by signing. In order to do this, the Ethereum community needs to add two new opcodes to the Ethereum protocol: AUTH and AUTHCALL.

AUTH is used to verify that the bundler's behavior in processing the user's EOA account assets is authorized, and AUTHCALL is used to "deceive" the smart contract that the user interacts with (in our case, USDC and Uniswap) to make the smart contract think that the transaction comes from the user's EOA account. The advantage of this is that Uniswap and USDC maintainers do not need to upgrade the deployed smart contracts, and the EOA account can also have the function of account abstraction.

(1) Comparison of EIP-3074 and ERC-4337

In the Ethereum community, EIP usually refers to proposals that require Ethereum upgrades to support, while ERC refers to specifications that can be supported without Ethereum upgrades.

Therefore, from the naming of the two account abstraction schemes, it can be seen that ERC-4337 is easier to implement than EIP-3074 because ERC-4337 does not require the Ethereum network to hard fork. This is also one of the reasons why ERC-4337 has been released and is increasingly used in polygon and base, but EIP-3074 has just been accepted by the 183rd Ethereum All Core Developers Executive Meeting (ACDE).

In addition, ERC-4337 requires users to migrate their current accounts to new contract accounts and requires DApps to support the functions of EIP-1271. EIP-3074 does not require these additional supports. This is the main reason for the low adoption rate of ERC-4337. At the same time, ERC-4337 cannot support one signature to authorize multiple on-chain operations without introducing an intermediate multi-call contract, while EIP-3074 can, which also leads to the limitations of ERC-4337.

However, EIP-3074 also has its own problems. The most important problem is that the permission of the opcode AUTH is too high, which may allow attackers to fully control the user's EOA account. After all, as long as the hacker deceives you into signing AUTH, the assets in your EOA wallet can be processed. Considering that phishing attacks are rampant at present, and most of them are done by deceiving users to sign, this will become a more serious problem once EIP-3074 is implemented.

In response to this, lightclient, one of the authors of EIP-3074, proposed a mitigation method to intercept malicious signatures at the wallet level. ERC-4337 does not have this problem, although hackers can still deceive users to sign malicious UserOps. This is because it is difficult for UserOp to obtain disposal rights to all assets in the user's account. At the time of writing, ACDE's developers have unanimously agreed to remove EIP-3704 from Pectra Devnet 0 and include EIP-7702 in the next Pectra Devnet 1.

What changes does (2) EIP-7702 have?

EIP-7702 attempts to integrate the advantages of EIP-3074 and ERC-4337 and take a middle road. The user sends the signed action to the bundler. When the bundler sends the transaction to the chain, the user's EOA account will temporarily become a smart contract account like the 4337 account. Next, similar to the AUTH process in EIP-3074, the smart contract account will verify the user's authorized bundler action. Then, like AUTHCALL, the user's authorized action is executed. After the transaction is executed, the user account will be rolled back to a normal EOA account.

The advantages of EIP-7702 are as follows:

· Inherits all the advantages of EIP-3074: does not require users to switch from EOA accounts to smart contract accounts with new addresses, can perform multiple operations in one atomic transaction;

· The smart contract account code and infrastructure of ERC-4337 can be used again;

· The smart contract account abstraction represented by ERC-4337 and the EOA account abstraction solution represented by EIP-3074 can be merged to prevent Ethereum from splitting into two different account abstraction systems, paving the way for the abstract account endgame in the Ethereum roadmap;

In addition, EIP-7702 also inherits all the security risks of EIP-3074.

The community decided to include EIP-7702 in the Pectra upgrade in 2025. If implemented, it will greatly change the Ethereum ecosystem and gradually improve the current ERC-4337 version of the account abstraction infrastructure.

4、Solana's Program-derived Address (PDA)

（1）Solana's Account Abstraction

Solana's account abstraction is similar to Ethereum's ERC-4337. They are accounts derived from original accounts (similar to EOA accounts), similar to 4337 contract accounts. Before understanding Solana's account abstraction, it is necessary to first understand the account model used by Solana.

Broadly speaking, accounts can be divided into executable accounts that can execute code and non-executable accounts that cannot execute code. Looking further, there are three types of accounts on Solana: Native Program, Program Account, and Data Account.

Native programs are part of the validator implementation and provide core functionality to the Solana network, such as creating new data accounts and custom programs. Program accounts are custom programs that contain executable code. Data accounts can store data and manage program state as defined by their owner, the program account.

This account model enables program accounts to create and manage specific accounts, providing developers with the ability to define custom rules and logic to manage accounts. Powered by this account model, program-derived addresses (PDAs), a type of data account, expand the possibilities of account abstraction capabilities on Solana, from enhancing user security through multi-signature wallets and two-factor authentication to enabling social recovery mechanisms.

(2) Program-derived Address

For context, all accounts are on the Ed25519 curve and have a public-private key pair. A PDA is off the Ed25519 curve and is a deterministically derived 32-byte string that looks like a public key but has no corresponding private key. PDAs allow developers to create custom rules and transaction signing mechanisms, allowing program account owners of PDAs to autonomously execute transactions on behalf of the PDA, fully recognized and supported by the Solana network.

(3) PDA and Account Abstraction

Now that we understand how PDAs are derived, you may also wonder how these concepts are tied together with account abstraction. Account abstraction is implemented at the bottom level through a function called cross-program invocation (CPI).

CPI is a function that enables one program to call instructions from another program, thereby enabling the composability of Solana programs. When a program initiates a CPI via invoke_signed, the program is able to sign on behalf of the derived PDA.

To verify the legitimacy of PDA-related transactions, the Solana runtime internally calls create_program_address using the caller's signers_seeds and program_id. If a valid PDA is found, the runtime will associate the PDA with the caller and identify the program as an authorized signer.

Currently, Squads is developing a Solana account abstraction solution based on PDA. However, the product offered by Squads is currently more similar to Gnosis Safe's smart contract account solution, and its account abstraction capabilities have not yet been fully developed.

(4) Advantages of PDA

· Automatic execution of smart contracts: PDA supports more complex smart contract design, which can autonomously execute multiple operations on behalf of users through cross-program calls.

· Enhanced user experience: Users do not need to manage multiple transactions or face technical complexity.

· Enhanced security and flexibility: There is no private key, which reduces the risk of key leakage. PDA can be used for multi-signature wallets or other flexible governance models that can reduce single points of risk and are particularly useful for organizations that manage large shared resources.

(5) Limitations of PDA

While PDA helps lay the foundation for account abstraction capabilities, it can be complex to implement compared to key pair accounts.

Like ERC-4337, it requires users to perform an account migration to a new account, which may inhibit the adoption of Solana's account abstraction.

5, Account Abstraction on Cosmos (Authz and Fee Grant)

(1) Cosmos x/authz

As account abstraction increasingly occupies the attention of developers, authz (part of the core Cosmos SDK) was launched, allowing one account to perform certain actions on behalf of another account through authorization, similar to EIP-3074 and EIP-7702.

Authz has several predefined authorization types that delegate the performance of certain operations (such as staking) to the grantee, thereby enhancing the user experience.

With authz, 3 types of authorizations can be given:

· GenericAuthorization: This authorization gives the grantee unrestricted permission to execute messages on behalf of the authorizer.

· SendAuthorization: Like approvals in ERC20, this authorization is designed to provide the grantee with a positive spending limit that defines the maximum amount that can be spent on behalf of the authorizer.

· StakeAuthorization: This authorization allows the grantee to manage staking operations, such as delegating staking on behalf of the authorizer, revoking delegation, or re-delegate.

A grant consists of the address bytes of the authorizer, the address bytes of the grantee, and the grant type. A time period can also be defined to limit permissions to a specific time period. At the end of each block, the network will remove expired grants through a process called pruning.

Understanding the Operational Framework

Authz can be used to provide authorization for a variety of operations, but for simplicity, we will look at how Authz operates to enable general voting transactions.

· Implement the authorization interface before performing any authorization. This stage will also define the message type, in this case MsgVote. Here we see Alice granting the governance voting operation.

· Bob generates an unsigned voting transaction.

· Bob generates a signed and executed voting transaction from the grantee. The transaction is completed and the expired transaction will be deleted.

What are the benefits of authz?

· Operational security: Validators and other users can authorize independent accounts to vote on governance proposals or perform certain actions, thereby enhancing account security and reducing security burden.

· Simplified operations: Transactions can be performed without access to validator keys, and multi-signature wallet transactions can also be simplified by using a single transaction to perform Authz authorization for the authorized account.

· No migration required: Similar to EIP-3074 and EIP-7702, authorization operations are performed in the user's original account. Users do not need to transfer their assets from the original account to the new account to enable account abstraction.

·DAO operation efficiency and flexibility: A portion of execution rights can be delegated to individual DAO members to perform specific operations.

·Staking reward synthesis: Authz facilitates the use of re-staking and equivalent services to automatically synthesize staking rewards.

Authz limitations and risks:

Be careful about the types of transactions authorized through Authz. Malicious authorizations can perform various types of authorizations that can be harmful to users.

·GenericAuthorization: Grants unrestricted permissions to perform all multi-signatures on behalf of the authorizer. It is strongly recommended to avoid signing this type of authorization unless you fully understand what you are signing. Some wallets may also not provide warnings when signing Authz transactions.

·SendAuthorization: Allows the grantee to send the maximum amount of tokens that the grantee can spend, if the grantor does not specify a specific amount. It is also important to verify the AllowList, which specifies the specific addresses that can receive the tokens sent by the grantee.

(2) Fee Grant Module

Another barrier to user experience is that blockchain users need to hold various native tokens to interact with different ecosystems. This hurts the overall user experience, especially for non-crypto native users who are first exposed to the countless chains that exist in the Cosmos ecosystem.

However, this problem has been overcome with the integration of the Fee Grant module. Similar to the paymaster contract that implements account abstraction on Ethereum, the Fee Grant module on Cosmos allows authorizers to grant fee allowances to grantees to pay part or all of the transaction fees. The funds remain under the control of the authorizer, and the authorization allowance can be revoked at any time.

Expense Authorization Categories

Expense allowances can be divided into two categories: BasicAllowance (basic allowance) and PeriodicAllowance (periodic allowance).

BasicAllowance allows the authorizer to use the expenses in the authorizer's account until the spending limit or expiration time is reached, and then the authorization is terminated in the state. It is important to note that BasicAllowance implements a one-time expense authorization. If the spending limit and time are set to null, the expense allowance has no validity period and spending limit.

PeriodicAllowance allows expense authorizations to be renewed periodically after each specified period. Period_spend_limit specifies the maximum number of tokens that can be spent in a period. Period_reset tracks the time of the next period, and period_can_spend tracks the number of tokens remaining before the new period begins.

Understanding the Operational Framework

Use AllowedMsgAllowance to create an Allowance allowance for a specified message type. The allowance can be a BasicAllowance basic allowance or a PeriodicAllowance periodic allowance. If an expiration is set, the FeeAllowance will be queued in the state with the expiration prefix, and the Endblocker will check the FeeAllowanceQueue state to check for expired authorizations and delete any expired authorizations found. In addition to MsgGrantAllowance, MsgRevokeAllowance can also be used to revoke fee allowances.

In summary, Authz and the Fee Grant module unlock a variety of innovative use cases that will ultimately build a better user experience on the Cosmos ecosystem.

6, Conclusion

The estimated data of account abstraction as of May 27, 2024 are as follows:

With the approval of spot BTC ETF and ETH ETF, institutional and retail demand has increased significantly, and a new wave of users who want to get involved in the crypto industry is expected to join. Account abstraction will become an important narrative this year as protocols and dApps seek to create a seamless experience to expand the size of their communities.