RIP-7560: Proposal for Improving the Consensus Layer of Native Account Abstraction

Account Abstraction vs. Native Account Abstraction

In simple terms, Account Abstraction in ERC-4337 is an optional infrastructure on the blockchain. You can choose whether or not to adopt it. Once adopted, it provides similar functionalities to Contract Accounts (CA), such as multisig, paying gas fees with ERC-20 tokens, social recovery, and more. Many service providers, like stackup, are working on this infrastructure. However, this infrastructure has not been widely adopted for the following reasons:

• Bundler problem: Only bundlers participate in verification, leading to an excessive reliance on bundlers.
• Insufficient profit for bundlers: This is mainly due to the small scale, which requires more DApps to choose Account Abstraction infrastructure to save gas fees.
• Concentration of bundlers: Bundlers are concentrated in a few suppliers (Alchemy, Pimlico, Stackup), posing centralization risks.
• Retention rate: Apart from airdrops, the user retention rate for Account Abstraction services is very low.

Many Layer 2 solutions deploy Account Abstraction directly on the native chain for lower gas fees. This is known as Native Account Abstraction. However, this approach also has other issues, such as users who do not want this feature being unable to opt-out, limited cross-chain capabilities, and an overall lack of flexibility.

This article mentions some terms, such as the distinction between EOA and CA (in simple terms, Metamask is EOA, contracts is CA), as well as bundlers (in the ecosystem of Account Abstraction, users send UserOperations to bundlers for packaging and on-chain processing, instead of sending them to node validators/Mempool). For detailed explanations, you can click on the links to the two articles mentioned above and refer to the previously published articles on Gate Learn.

What is RIP-7560?

RIP-7560 is an improvement proposal for account abstraction (EIP-2938/ERC-4337). Introducing the new transaction type “AA_TX_TYPE” incorporates roles other than the bundle merchant (block builder/node validator) in the transaction verification and execution stages. It no longer relies solely on the bundle merchant for packaging and on-chain submission, thus addressing the centralization issues previously mentioned. Additionally, RIP-7560 provides standardized design to ensure greater conformity for future adopters. This article will further elaborate on the standards improved by the RIP-7560 proposal and address the concerns raised.

The Most Fundamental Change

This is a consensus layer protocol change \
The earliest proposal for account abstraction was actually made in September 2020 EIP-2938. It was eventually accepted by the community and deployed on Ethereum. The reason why ERC-4337 was ultimately adopted instead of 2938 is that 4337 does not require changes at the consensus layer, making it relatively easier for the community to accept.

Unlike ERC-4337, the RIP-7560 proposal will involve larger changes, specifically at the consensus layer protocol level (the prefix RIP indicates that this is a lower-level proposal for improving Rollup technology). The corresponding benefit it brings is the ability to avoid relying directly on the infrastructure of the L2 native chain.

Introducing a new transaction type \
A new transaction type has been introduced: the fourth transaction type, also known as “AA_TX_TYPE” (which was actually proposed in the old EIP-2938). It not only supports all the functionalities of a typical CA (such as the gas fee payment and recurring automatic payment functions mentioned in Visa’s article), but unlike ERC-4337, it also allows existing EOAs to submit transactions. This means that this proposal aims to promote broader adoption.

Transaction Execution Logic

This proposal is compatible with the ERC-4337 standard and adopts the transaction logic of separating execution and verification, which requires more Gas. Additionally, according to the documentation, transaction execution is the same as ERC-4337, where all steps in the verification phase must be completed without reverting. After verification, the call data will be sent to the account for execution. After execution, the Paymaster can perform post-transaction logic. The complete execution process is illustrated in the following diagram.

Execution Flowchart (Source: GitHub document of RIP-7560)

Main Concerns Regarding the Proposal

The author raised the following concerns during the discussion on the Ethereum Magicians forum: RIP-7560: Native Account Abstraction

Will it restrict the development of intent-based account abstraction services?

The main players in intent-based services are expected to be Uniswap V4 and UniswapX, with UniswapX planning to develop account abstraction services. Additionally, a similar direction has been proposed by ERC-7521. In response to community discussions, one of the authors of this proposal, Yoav Weiss, mentioned that along with RIP-7560, there is also an account abstraction verification rule called ERC-7562. The intent system design could be made compatible only with RIP-7560 and not with the verification rule. Then, a separate intent solver network could be used, allowing the benefits of RIP-7560 to be enjoyed without conflicting with the intent design.

Risk of Irreversibility

Some in the community have questioned whether this proposal is akin to “trying to embed an operating system into bare metal,” posing significant risks. To this, Yoav Weiss responded: This proposal is for chains that choose to embed an operating system (such as ERC-4337) into bare metal, namely L2 chains that choose to deploy native account abstraction. There are enough choices within the Ethereum ecosystem, and users can opt for other L2 chains that have not deployed native account abstraction.

Complexity and Cost Considerations

Regarding concerns about the complexity and resulting high costs of the proposal, Dror Tirosh, one of the authors, responded that this is inherent to account abstraction itself. Account abstraction stems from the fact that we want to validate external data using generic EVM code. Eliminating this complexity would expose block producers to DoS attacks or require the removal of general EVM code usage, which defeats the purpose of developing account abstraction technology.

Conclusion

Currently, at least providers of account abstraction infrastructure, such as the founder of Stackup, welcome such changes at the consensus layer, indicating that the core issues of current account abstraction services are still prevalent. If not enough dApps adopt this solution to reduce Gas Fees and introduce user-friendly CA-like features, then bundle providers will not profit, and user retention rates will never rise. However, if services developed based on this proposal can seamlessly support existing EOAs on-chain to natively support account abstraction, we will be closer to the ultimate goal (mass adoption, Metamask supporting account abstraction, etc.), and the user experience in interacting with DApps will improve progressively.