EIP-7702: A new approach to account abstraction on Ethereum

FacebookLinkedInTwitter
EIP-7702 - a new approach to account abstraction

Account abstraction continues to be a hot topic and an important pursuit for the Ethereum community. Previously, we talked about the importance of account abstraction and the most notable attempts at achieving it. We primarily focused on the EIP-4337, which, at the time, was the frontrunner. 

But most recently there has been some excitement around some of the earlier approaches, thanks to none other than the Ethereum creator himself, Vitalik Buterin. Ok, let’s elaborate.

Brief refresher on account abstraction

Account abstraction seeks to remove externally owned accounts – those that are typically owned by users – and replace all of them with smart contract accounts. This will allow developers to write custom logic for user accounts, improve usability and security, make the interface much more convenient and so on. The problem is that Ethereumis not designed to support account abstraction. But that hasn’t stopped Ethereum developers from trying.

Last year, the account abstraction discourse centered around EIP-4337, which envisions account abstraction as an extension of the smart wallet concept that has already been well realized in the Web3 space. EIP-4337 also proposed adding a higher-level mempool that works with a new object called UserOperations. In short, this approach allows for the smart wallet approach to be implemented much more easily.

The significant interest in EIP-4337 drew the focus away from alternative approaches such as those proposed in EIP-3074 and EIP-2938. However, recently, there has been a renewed interest in EIP-3074 as key figures in the Ethereum community have been attempting to make it compatible with the current approach. The result was an Ethereum improvement proposal, co-authored by Vitalik Buterin, that aims to refine EIP-3074’s proposed approach.

How EIP-7702 improves EIP-3074

EIP-3074 was one of the most promising approaches to achieving account abstraction. It was focused on allowing externally owned accounts to delegate control to smart contracts. To make this possible, EIP-3074 adds two new opcodes to the Ethereum Virtual Machine – AUTH and AUTHCALL. Also, a user who wants to delegate control to a smart contract is required to sign a message with their EOA. Using the signed message and the two opcodes, a so called ‘invoker’ smart contract is able to handle transactions for the corresponding EOA.

The method proposed via EIP-3074 is more than capable of accomplishing the main objective of account abstraction. The authors of EIP-7702 point to three use cases that are solved by the earlier improvement proposal: batching, where multiple actions from the same user can be executed in a single atomic transaction; sponsorship, which allows for an account to pay transaction fees on behalf of another account; and privilege de-escalation, which allows users to sign subkeys that have weaker permissions that global access to an account.

However, there are also some caveats that make EIP-3074 a less viable method than the more recent alternative . Buterin and the team behind EIP-7702 has cited forward compatibility concerns stemming in part from the addition of the AUTH and AUTHCALL opcodes. They’ve also pointed out that implementing the EIP-3074 method would lead to the development of an “invoker contract ecosystem” that would exist separately from the smart wallet ecosystem and could lead to fragmentation of effort.

EIP-7702 aims to address these issues and make the EIP-3074 use cases work within the EIP-4337 method, which is being implemented under the ErC-4337 standard. EIP-7702 outlines a way to achieve the same results without needing to add new opcodes, utilizing existing functions instead. 

In addition, the code that users would need to sign could be part of the existing  ERC-4337 wallet code. The authors of the improvement proposal also note note that “the ‘code pathways’ that are used are code pathways that would, in many cases (though perhaps not all), continue to ‘make sense’ in a pure-smart-contract-wallet world”, meaning that the problem of creating two separate code ecosystems can be avoided.

Conclusion

Account abstraction could be one of the most important catalysts for the mass adoption of Web3 products and services. The potential benefits that account abstraction can bring in terms of improved usability, better security and developer empowerment cannot be overstated. That’s why it’s great to see that the topic continues to be a major focus of the Ethereum community. The continued drive to improve the account abstraction approach is a strong indication that the industry is moving in the right direction.

FacebookLinkedInTwitter