Ethereum developers propose new transaction type with EIP-7702

A group of prominent ethereum developers, including Vitalik Buterin, proposed a new transaction type (EIP-7702) to improve the functionality and security of externally owned accounts (EOA). The proposal aims to address common issues such as transaction bundling, sponsorship, and privilege reduction.

According to the ethereum/EIPs/blob/9e04cf1094eae64172ce04e0a04ec40f1edbdc5d/EIPS/eip-7702.md” target=”_blank” rel=”noopener nofollow noreferrer”>Draft EIP-7702, the new transaction type “adds a contract_code field and a signature, and converts the signing account (not necessarily the same as tx.origin) into a smart contract wallet for the duration of that transaction.” The proposal aims to offer functionality similar to EIP-3074.

The motivation behind EIP-7702 is to provide short-term functionality improvements to EOAs, increasing application usability and, in some cases, enabling greater security. The proposal describes three particular applications: lots, sponsorship and reduction of privileges.

While EIP-3074 solves these use cases, the authors of EIP-7702 believe it has future compatibility issues. They claim that EIP-3074 “introduces two opcodes, AUTH and AUTHCALL, which would have no use in a 'final account abstraction' world where eventually all users use smart contract wallets.”

Furthermore, they argue that EIP-3074 “leads to the development of a 'summoner contract' ecosystem that would be separate from the 'smart contract wallet' ecosystem, leading to potential fragmentation of the effort.”

The EIP-7702 specification details the transaction payload format and the transaction execution process, which involves temporarily setting the contract code of the signing account and reverting it to empty at the end of the transaction.

The authors provide a justification for how EIP-7702 can convert EIP-3074 use cases, stating that it “requires fairly little work to convert an existing EIP-3074 workflow.”

They also argue that EIP-7702 is designed to be compatible with future account abstractions, avoiding the creation of separate code ecosystems and the need for new opcodes that may become obsolete.

Despite the potential benefits, the authors acknowledge that EIP-7702 breaks the invariant that an account balance can only decrease as a result of transactions originating from that account, which may have consequences for mempool design and others. EIP.

As with any proposal that requires users to sign a contract code, the authors emphasize the importance of user wallets being cautious about which contract code they sign, highlighting security considerations shared with EIP-3074.