Rob Behnke
May 20th, 2024
Ethereum seems to be in a state of perpetual innovation. The next big break could come with the implementation of two new Ethereum Improvement Proposals (or EIPs): EIP-3074 and EIP-7702.
EIP-3074 introduces a new framework for programmable transactions and account abstraction, while EIP-7702 (drafted by Vitalik Buterin in 22 minutes!) seeks to improve upon the former by eliminating a few vulnerabilities and emphasizing forward compatibility.
Let’s take a closer look at both proposals, which are likely to make it into the upcoming Pectra Upgrade.
EIP-3074 is an Ethereum proposal that upgrades regular accounts with smart contract-like abilities. This lets them benefit from features like gas sponsorship, bundled transactions, and even recovery options, all without needing to deploy a separate contract. It aims to improve user experience and make Ethereum more accessible.
Under the current framework of ERC-4337, users transition from traditional externally owned accounts (EOAs) to what are known as smart contract wallets. This shift allows for new functionalities like gas abstraction and session keys, which simplify the onboarding and transaction processes for new Ethereum users.
While this setup reduces entry barriers, it does little to address the needs of existing users accustomed to traditional EOAs.
EIP-3074 proposes a new approach. It allows users to retain their EOAs while granting them the ability to authorize a smart contract, referred to as an “invoker contract”, to perform actions on their behalf.
This mechanism maintains familiarity with EOAs for existing users and introduces several enhancements to improve user experience and network efficiency.
Source: https://blog.mycrypto.com/eip-3074
EIP-3074 introduces two new opcodes to the Ethereum Virtual Machine (EVM):
AUTH: Verifies a valid signature that authorizes the invoker contract to act on behalf of an EOA. It takes the signature as input and places the EOA's address in a special EVM context variable.
AUTHCALL: This opcode allows the authorized invoker contract to send transactions. This includes specifying the destination address, value, and input data, just like a standard transaction.
The EOA (user) establishes a relationship with an invoker smart contract. This can often be done through a user-friendly interface provided by a wallet or a dApp.
Users can then generate a signature (using their private key) that authorizes the specific invoker to act on their behalf. This authorization message contains:
Information to identify the EOA
The address of the authorized invoker smart contract
A nonce to prevent replay attacks
Optional limitations (like maximum gas usage, validity period, etc.)
The user or a relayer submits the transaction (containing the authorization signature) to the Ethereum network. Then, the EVM recovers the signer's address (the EOA) from the signature and executes the AUTH opcode. It verifies that the recovered address authorizes the invoker to act on its behalf before allowing the transaction to proceed.
If everything looks good, the AUTHCALL opcode is executed, and the invoker contract sends the actual transaction from the EOA's address. The invoker handles gas fees, and the transaction's effects are the same as if the user had sent it directly.
In simple terms, think of the invoker as an “assistant”. You give permission to this assistant to perform actions like making transfers. So, next time you want to perform any operation, the assistant does all the work like paying the gas fees, or executing multiple transactions — all you do is tell it once what to do.
Users need to safeguard their private keys to retain access to their Ethereum wallets (or other blockchains). Losing private keys means losing assets.
According to Chainalysis, nearly 20% of BTC is out of circulation due to lost private keys. The value of these coins alone is in the billions. Now think of how the value that is lost across all other blockchains because the users lost their private keys or seed phrases.
EIP-3074 changes that by introducing a “social recovery” mechanism.
The proposal doesn't directly address lost keys, but it allows invoker contracts to be designed with social recovery features.
The idea is that you can designate a group of trusted entities to help you recover your account if you lose your private key.
In other words, social recovery is not an intended aspect of EIP-3074, but a product of the functionalities that an invoker contract opens up.
As users can provide these invoker contracts with “special permissions”, they can also delegate ownership to an invoker contract managed by an entity (say “guardian”) to which they are able to prove identity and reclaim ownership of assets.
Source: https://vitalik.eth.limo/general/2021/01/11/recovery.html
One of the key features introduced by EIP-3074 is gas sponsorship. This allows an invoker contract to cover the transaction fees (gas) associated with an EOA (Externally Owned Account) initiated transaction.
Currently, users need to hold enough ETH (Ethereum's native token) in their EOA to pay gas fees for any interaction with the Ethereum network. This can be a barrier for new users or those who don't want to hold ETH specifically for gas.
For instance, in TradFi (traditional finance), the modern consumer is used to paying a transaction fee in the same currency they purchase goods with. For instance, a consumer pays transaction fees in USD when they purchase goods with a credit card in USD.
How would it be if the consumers were asked to hold a separate currency/asset (and manage it) just to pay for transaction fees? Rather inconvenient.
Similarly, holding ETH (or any other blockchain-native token) just to cover transaction costs is non-intuitive and inconvenient.
Broadly, there are 6 steps in the gas sponsorship process:
Agreement: You and the sponsor agree on an invoker contract that they trust to handle transactions, potentially using ERC-20 tokens for gas fees.
Signing: You sign the transaction details, including what actions you want to perform (like sending tokens), and send this signature to the sponsor without executing the transaction.
Verification and Preparation: The sponsor checks your signed transaction off-chain. If everything is correct and you have enough ERC-20 tokens, the sponsor prepares to submit the transaction through the invoker contract.
Submission and Token Handling:
The invoker contract first locks up an estimated amount of your ERC-20 tokens to cover the potential gas fees.
- It then uses the AUTH opcode to verify your signature, ensuring the transaction is genuinely from you.
Execution:
The invoker contract executes your transaction using the AUTHCALL opcode, performing the action on your behalf.
After the transaction, the actual gas cost is calculated.
Refunding and Payment:
Any excess ERC-20 tokens that were initially withheld but not used for gas are refunded to you.
The exact amount of ERC-20 tokens needed to cover the gas costs is transferred from your account to the sponsor's address.
EIP-3074's transaction batching is a feature that allows you to group multiple transactions into one. It reduces the total cost and complexity of executing them individually.
The entire process can be outlined in three simple steps:
Multiple Actions Prepared: You prepare multiple actions that you want to execute. For example, these could be transferring tokens, interacting with a contract, or executing trades.
Signing a Single Message: Instead of signing a separate transaction for each action, you sign one message that includes all the actions. This message is structured to detail each action and the order in which they should be executed.
Using AUTH and AUTHCALL:
AUTH: The invoker contract uses the AUTH opcode to verify the signature of the batched transaction message, confirming that all included actions are authorized by you, the account holder.
AUTHCALL: This opcode is then used to execute each action in the sequence you specified. The AUTHCALL effectively lets the invoker contract perform these actions on your behalf, treating the contract as if it were the original sender (your account).
By batching multiple transactions into a single operation, the overall gas cost is typically less than the sum of individual transactions. This is because certain overheads, like the base cost for transaction initiation, are incurred only once.
EIP-3074’s introduction of invoker contracts introduces a point of vulnerability and increases the attack surface of Ethereum.
Since invokers gain significant control over user accounts, vulnerabilities or malicious code in the invoker contract can be exploited to steal funds, execute unauthorized transactions, or cause other damage.
If a small number of invoker contracts become popular, a vulnerability in one of them could impact many users, creating a major risk.
Such scenarios could eventually lead to the centralization of the Ethereum ecosystem, similar to how most of the modern web (web2) relies on a handful of profit-driven companies.
Two risk mitigation steps are have been proposed widely:
Reputable independent entities, like Halborn, should regularly audit Invoker contracts.
Wallets could take it upon themselves to perform due diligence and whitelist invoker contracts.
Safe is advocating for the implementation of EIP-5003 to address some of the security issues of EIP-3074.
EIP-5003 introduces the AUTHUSURP opcode which provides a mechanism to permanently transition an EOA (Externally Owned Account) into a smart contract account. As a result, the accounts could benefit from security features like multi-sig and quantum-resistance.
There’s also the risk of phishing — here an attacker could trick users into delegating permissions/ownership to fraudulent invoker contracts. To mitigate this, EIP-3074 also proposes a phishing protection registry. Therefore, users can verify the authenticity of the invoker contract before interacting with it — while not an ironclad solution, it certainly helps with screening for legitimacy.
The newest proposal on the block is EIP-7702, authored by the Ethereum mastermind, Vitalik Buterin, himself.
EIP-7702 builds on the ideas of EIP-3074 but takes a more conservative approach by making the upgrade temporary and avoiding the introduction of new opcodes. This addresses some of the major concerns raised about EIP-3074 while still moving towards the goal of account abstraction.
As we’ve seen already, EIP-3074 proposed introducing new opcodes (AUTH and AUTHCALL) that would effectively turn EOAs into smart contract wallets. However, it faced criticism due to potential security risks and the introduction of new opcodes, which might become obsolete in the long term as Ethereum moves towards a fully account-abstracted system.
EIP-7702 introduces a new transaction type that allows a temporary upgrade to smart contract accounts for a single transaction. The motivation behind this proposal is to ensure forward compatibility.
Here's how EIP-7702 achieves forward compatibility:
No New Opcodes: EIP-7702 avoids introducing new opcodes. This prevents potential conflicts or redundancies with future account abstraction models, ensuring that the upgrade remains relevant even as Ethereum evolves.
Alignment with ERC-4337: EIP-7702 is explicitly designed to be compatible with ERC-4337. This means that existing ERC-4337 wallets and infrastructure can readily leverage the temporary upgrade mechanism proposed by EIP-7702.
Flexibility: The proposal leaves the specifics of the temporary upgrade mechanism open for future iterations. This allows for greater flexibility in adapting to new account abstraction models or technological advancements that may emerge.
Minimal Changes: EIP-7702 introduces a minimal set of changes to the Ethereum protocol, focusing on the core functionality of temporary smart contract account upgrades. This reduces the risk of introducing unforeseen compatibility issues with future upgrades.
How it works:
Account Code: The EOA gets an ephemeral account code for one transaction. This code is executed when the transaction is processed.
Transaction Flow: When a transaction is sent, the EOA's temporary code is executed, performing operations as a smart contract would.
Lifecycle: The account code is discarded after the transaction completes, reverting the EOA to its original state.
The exact implementation details have not been finalized yet.
Account abstraction is a crucial stepping stone to blockchain’s mass adoption as it, as the name suggests, abstracts away the UX complexities often associated with blockchain-based accounts.
ERC-4337 significantly improved blockchain UX. But there’s more work to be done and the EIPs discussed in this article would nudge the Ethereum dev community in the right direction.