Why do we need Account Abstraction?

There are still many unsolved problems in the current blockchain field. Among them, the difficulty of using blockchain, that is, the user experience (UX) of interacting with the chain, must be the most criticized area by the public.

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

In this context, increasingly many people are turning their attention to the field of account abstraction to improve the user experience of on-chain interactions and facilitate mass adoption.

In the process of exploration, Ethereum proposed account abstraction solutions such as ERC-4337, EIP-3074, and EIP-7702. Other L1 such as Solana have features that enable protocol-level account abstraction such as Program Derived Addresses (PDAs), and Cosmos also has similar designs such as x/authz and Fee Abstraction Module. In this article, we will introduce and compare the above-mentioned solutions, sort out the subtleties of the design of different solutions, and demonstrate the trade-offs and considerations of different solutions.

Background

EOA vs Contract Account

Externally Owned Account (EOA) and Contract Account are two account types defined in the Ethereum whitepaper. EOA accounts are controlled by private keys, and users can sign various transactions through the private keys to control the assets in the account. The contract account is controlled by the code of the account itself, and other accounts can make the contract account execute specific logic by calling the code of the contract account.

Account Abstraction

The concept of abstracted accounts can be traced back to 2016 (https://github.com/ethereum/EIPs/issues/86). The account abstraction is based on and builds atop the two current account types in Ethereum — EOA and contract accounts. This will improve the interactive experience of Ethereum users through the following ways:

1. Allows users to use multiple signatures, such as Schnorr, BLS, post-quantum signatures, etc.;
2. Allows users to pay gas fees using ERC20 tokens or custom payment logic;
3. Allows users to retrieve their accounts using email, social media, etc.;
4. Allows users to manage the funds in their accounts with fine-grained permissions, such as setting a daily withdrawal limit;
5. Allows multiple on-chain operations to be performed in one atomic transaction. For example, a user can complete the approval and swap operations in a DEX transaction with one signature.

Ethereum Roadmap

The Ethereum roadmap (https://ethereum.org/en/roadmap/) highlights the future upgrade route of Ethereum. Currently, most research in the Ethereum community revolves around the Ethereum roadmap. Account abstraction are an imperative part of this:

Source: https://x.com/VitalikButerin/status/1741190491578810445

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 finally reach Endgame account abstraction.

Notwithstanding the enhancement to user experience, Endgame account abstraction is also crucial to Ethereum’s anti-quantum computing, because the ECDSA algorithm used by the current EOA account is unsafe in the quantum computing era. Adopting account abstraction supports post-quantum signatures that protect user accounts against the evolving threats of quantum computing.

EIP-3074 vs ERC-4337

To understand account abstracted accounts, we need to understand how EOA works. The picture below is the most common token buying and selling process on the chain:

Generally speaking, users need to issue two transactions when buying and selling: first authorize Uniswap to transfer their USDC for the swap, and then send another transaction request for Uniswap to execute the action. Uniswap transfers the USDC of the user account and sends the corresponding amount of ETH to the user according to the current price.

ERC-4337 merges the above two transactions into single one:

As can be seen from the above figure, the user needs to sign twice to authorize bundler to operate the user’s assets in the 4337 account which is different from the user’s EOA account. After bundler obtains authorization, it merges the authorized content into a bundle and issues it to complete the transaction. At the same time, if the user does not have Ethereum tokens for gas fees, the role of paymaster can also be introduced, allowing the paymaster to pay the gas fees and obtain ERC20 tokens of equal value from the user.

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

In ERC-4337, we authorize Bundler to handle assets in our on-chain smart contract wallet through signatures. In EIP-3074, bundler is authorized to directly handle the assets in our EOA wallet through signatures. 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 whether bundler’s behavior of processing user EOA account assets is authorized, and AUTHCALL is used to “fool” the smart contract of user interaction (in our example, USDC and Uniswap), making the smart contract think that the transaction is from the user’s EOA account. The advantage of this is that the maintainers of Uniswap and USDC do not need to upgrade the deployed smart contracts, and at the same time, EOA accounts can enjoy the functions of account abstraction.

A Comparison Between EIP-3074 and ERC-4337

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

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

Source: https://dune.com/niftytable/account-abstraction

Additionally, ERC-4337 requires users to migrate their current accounts to new contract accounts and necessitates DApp support for EIP-1271 to function. EIP-3074 does not require these additional supports. This is a major 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, but EIP-3074 can, which also causes the limitations of ERC-4337.

However, EIP-3074 also has its own problems. The most important one is that the operation code AUTH has too high permissions, which may allow the attacker to completely control the user’s EOA account. After all, as long as a hacker defrauds your AUTH signature, he can dispose of the assets in your EOA wallet. Considering that phishing attacks are currently rampant, and most of them deceive users’ signatures, once EIP-3074 is implemented, this will become a more serious problem.

In this regard, lightclient, one of the authors of EIP-3074, has proposed a mitigation method to intercept malicious signatures at the wallet level. For details, please refer to: https://x.com/lightclients/status/1778823652584120497. ERC-4337 does not have this problem, although hackers can still deceive users into signing malicious UserOps. This is due to the difficulty for a UserOp to gain disposal authority over all assets in the user account. As of the time of writing, developers in ACDE agreed to remove EIP-3704 from Pectra Devent 0 and include EIP-7702 in the next Pectra Devnet 1.

What changed in EIP-7702?

EIP-7702 attempts to integrate the benefits of EIP-3074 and ERC-4337 to form a middle path. The user sends the signed operation 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 4337 account. Next, similar to the progress of AUTH in EIP-3074, the smart contract account will validate the user’s authorized bundler operation. Then, just like AUTHCALL, perform operations authorized by the user. After executing the transaction, the user account will be rolled back to an ordinary EOA account.

The benefits of EIP-7702 are as follows:

1. 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;
2. The smart contract account code and infrastructure of ERC-4337 can be reused;
3. 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 and pave the way for the Endgame Abstraction Account in the Ethereum roadmap;
4. The two opcodes AUTH and AUTHCALL will not be added to Ethereum’s EVM: taking into account the Ethereum roadmap, EOA accounts will be converted into account abstraction in the future, and these two opcodes will become redundant.

Beyond that, EIP-7702 inherits all security risks from EIP-3074.

Community decided to include EIP-7702 in the next Pectra upgrade in 2025. If implemented, it will greatly change the Ethereum ecosystem and bring incremental improvements to the current ERC-4337 version of account abstraction infrastructure.

Solana’s Program Derived Address

Account Abstraction on Solana

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

Broadly speaking, accounts can be classified as either executable accounts which can execute code or non-executable accounts which are unable to do so. Examining this 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 functions for the Solana network such as the creation of 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 its owner program account.

This account model natively enables program accounts to create and manage specific accounts, offering developers the ability to define custom rules and logic for managing them. Enabled by this account model, the Program Derived Address (PDA), a type of data account, extends the possibilities of account abstraction capabilities on Solana from enhancing user security through multisig wallets and two-factor authentication to enabling social recovery mechanisms among others.

Program Derived Address

For context, all accounts lie on the Ed25519 curve and have a public-private key pair. PDA, which lies outside of the Ed25519 curve, is a deterministically derived 32 byte string that looks like a public key and does not come with a corresponding private key. PDAs allow developers to create custom rules and transaction signature mechanisms that can allow PDA’s program account owner to autonomously perform transactions on behalf of the PDAs, fully recognized and supported by the Solana network.

PDA and Account Abstraction

Okay now that we understand how PDAs are derived, you might be wondering how these concepts are tied to account abstraction. Account abstraction happens under the hood through the performance of a function known as the Cross Program Invocation (CPI).

CPIs are functions that enable a program to invoke the instructions of another program, allowing for composability of Solana programs. When a program initiates a CPI either through invoke_signed, programs are able to sign on behalf of the PDAs derived.

Source: Solana

To verify the legitimacy of transactions involving PDAs, Solana runtime internally calls the create_program_address using the signers_seeds and the program_id of the calling program. If a valid PDA is found, the runtime will associate the PDA with the calling program and recognize the program as an authorized signer.

Currently, Squads is developing an account abstraction solution on Solana based on PDA. However, the product provided by Squads is currently more akin to Gnosis Safe’s smart contract account solution and has not yet fully developed its account abstraction functionality.

Benefits of PDAs

1. Automated smart contract execution: PDAs allow for more complex smart contract designs that can autonomously perform multiple operations on behalf of the user through cross program invocations.
2. Enhanced user experience: Users do not need to manage multiple transactions or be exposed to the technical complexity.
3. Enhanced security and flexibility: Without a private key, this reduces the risk of a key compromise. PDAs can be used for multisig wallets or accommodate other flexible governance models that reduce a single point of risk and are especially useful for organizations that manage large shared resources.

Limitations of PDAs

1. PDAs, although beneficial in laying the foundation for account abstraction capabilities, can be complex to implement as compared to a keypair account.
2. And like ERC-4337, it requires users to perform account migration to a new account which may suppress the adoption rate of Solana account abstraction.

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

With account abstraction increasingly taking up the mindshare of developers, authz, part of the core Cosmos SDK, was launched to allow an account to perform certain actions on behalf of another account through the use of authorization grants which is similar with EIP-3074 and EIP-7702.

Authz comes with several predefined authorization types that delegate the performance of certain actions such as staking to a grantee, enhancing the user experience as a result.

With authz, 3 types of Authorizations can be given:

1. GenericAuthorization. This authorization grant gives unrestricted permission for the grantee to execute the message on behalf of the granter.
2. SendAuthorization. This authorization, like the approve in ERC20, seeks to give the grantee access to a positive spend limit that defines that maximum amount that can be spent on behalf of the granter.
3. StakeAuthorization. This grant allows the grantees to manage staking actions such as delegate, undelegate or redelegate on behalf of the granter.

A grant consists of the address bytes of the granter, address bytes of the grantees, and the authorization types. Time period can also be defined to limit the permissions within 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 give authorizations for a variety of actions, however for simplicity, we will examine how authz works to enable generic vote transactions.

1. Implements authorization interface before any authorizations can be executed. At this phase, the message type will also be defined which in this case will be MsgVote. Here, we see a grant authorization from Alice for a governance vote action.
2. Bob generates an unsigned vote transaction.
3. Bob generates a signed and executed transaction of the vote from the grantee. Transaction is completed and authorization will be removed if it is expired.

Benefits that authz brings?

1. Operational security: Validators and other users can grant permissions to a separate account to vote on governance proposals or perform certain actions, enhancing account security and reducing the security burden.
2. Streamlined operations: Transactions can be performed with needing access to validator keys, multisig wallet transactions can also be streamlined using a single transaction to grant Authz to the grantee account.
3. No need for migration: Similar to EIP-3074 and EIP-7702, the authorization operations occur in the user’s original account. Users do not need to transfer their assets from the original account to a new account to enable account abstraction.
4. DAO Operational Efficiency and Flexibility: A subset of execution rights can be given to individual DAO members for specific actions.
5. Staking Reward Compounding: Authz facilitates the usage of restaking and equivalent services for automated compounding of staking rewards.

Limitations and risks to Authz:

Pay attention to the types of transactions that you are authorizing via Authz. A malicious Authorizations can execute various types of authorizations that could be detrimental to the user.

1. GenericAuthorization: gives unrestricted permission to execute the provided Msg on behalf of the granter. Unless fully aware of what you are signing, it is strongly advised to avoid signing such authorization types. Some wallets may also not provide warnings when signing Authz transactions.
2. SendAuthorization: Allows the grantee to send the maximum amount of tokens the grantee can spend if not specified by the granter. It is also important to verify the AllowList which specifies the specific address to which the grantee can send the tokens to.

Fee Grant Module

Another hurdle to user experience that frustrated many is the need for blockchains users to hold various native tokens in order to interact with these different ecosystems. This tainted the overall user experience especially for non-crypto native people who were first exposed to a myriad of chains existing on the Cosmos ecosystem.

However, this hurdle has seen breakthrough with the integration of the Fee Grant Module. Similar to the paymaster contract that enables account abstraction on Ethereum, the Fee Grant Module on Cosmos allows the granter to grant fee allowances to the grantee, paying for some or all of the transaction fees. The funds remain in the granter’s control and it is able to revoke grant allowance at any time.

Types of Fee Grants

Fee Allowance can be categorized into two types: BasicAllowance and PeriodicAllowance.

BasicAllowance allows the grantee to use fees from the granter account until the spending limit or expiration time is hit. The grant will then be terminated from the state. It is important to note that BasicAllowance implements a one-time grant of fees. If spending limit and time are empty, there is no expiration and spending caps on the fee allowance.

PeriodicAllowance enables fee grants to be periodically renewed after each specified time period. Period_spend_limit specifies the maximum number of coins that can be spent in the period. Period_reset keeps track of when the next period should happen and period_can_spend tracks the amount of coins left before a new period starts.

Understanding The Operational Framework

Using AllowedMsgAllowance creates an allowance for specified message types. Allowance can either be BasicAllowance or PeriodicAllowance. If expiration time is set, FeeAllowance will be queued in the state with the prefix of expiration appended to the grant and Endblocker checks the FeeAllowanceQueue state for expired grants, pruning any if found. Aside from MsgGrantAllowance, a fee allowance can also be revoked using MsgRevokeAllowance.

Taken together, Authz and Fee Grant modules unlock innovative and diverse use cases that ultimately build a better user experience on the Cosmos ecosystem.

Conclusion

Account Abstraction As of 27 May 2024, figures are estimated.

With the approval of spot BTC ETFs and ETH ETFs, institutional and retail demand have significantly increased, promising to usher in a new wave of users looking to gain exposure to the industry. Account abstraction will become an important narrative this year as protocols and dapps seek to create a seamless experience to expand their communities.

DISCLAIMER

This material is for general information only, and does not constitute, nor should it be interpreted as, any form of research output, professional advice, solicitation, offer, recommendation, or trading strategy. No guarantee, representation, warranty or undertaking, express or implied, is made as to the fairness, accuracy, timeliness, completeness or correctness of any general financial and market information, analysis, and/or opinions provided on this report, and no liability or responsibility is accepted by HashKey Capital in relation to the use of or reliance on any such information. Any information on this report subject to change without notice. This report has not been reviewed by the Securities and Futures Commission of Hong Kong, the Monetary Authority of Singapore or any regulatory authority in Hong Kong or Singapore.

Please be aware that digital assets, including cryptocurrencies, are highly volatile and subject to market risks. The value of digital assets can fluctuate significantly, and there is no guarantee of profit or preservation of capital. You should carefully consider your own risk tolerance and financial situation before making any decision.

Distribution of this report may be restricted in certain jurisdictions. This material does not constitute the distribution of any information or the making of any offer or solicitation by in any jurisdiction in which such action is not authorised or to any person to whom it is unlawful to distribute such a report.

Stay updated with the latest HashKey Capital news -

Website — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

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

Disclaimer：

1. This article is reprinted from [Medium]. All copyrights belong to the original author [HashKey Capital]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.

2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.

3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.