Vitalik just proposed EIP-7702.
It's one of the most impactful changes Ethereum is going to have... EVER.
So, here's everything you need to know about how it works and how we got here:
It's one of the most impactful changes Ethereum is going to have... EVER.
So, here's everything you need to know about how it works and how we got here:
The new EIP-7702 proposal is surprisingly short! Leaving some people confused as to how this is going to work.
To understand 7702, there are first three other proposals that it mentions that we'll walk through:
1/ EIP-4337
2/ EIP-3074
3/ EIP-5003
(1/23)
To understand 7702, there are first three other proposals that it mentions that we'll walk through:
1/ EIP-4337
2/ EIP-3074
3/ EIP-5003
(1/23)
Let's start with the goal of *all* of these proposals.
EOAs ("normal" accounts) on Ethereum suck. They're risky and have very limited capabilities.
Account abstraction allows you to use a smart contract as your account to add more features & safety to address this.
(2/23)
EOAs ("normal" accounts) on Ethereum suck. They're risky and have very limited capabilities.
Account abstraction allows you to use a smart contract as your account to add more features & safety to address this.
(2/23)
ERC-4337 went live on mainnet in March 2023.
It allowed smart contracts to be written in a way that they can act like accounts, such that they can validate and execute transactions (UserOps).
This enabled a lot of UX improvements, for example:
(3/23)
It allowed smart contracts to be written in a way that they can act like accounts, such that they can validate and execute transactions (UserOps).
This enabled a lot of UX improvements, for example:
(3/23)
https://x.com/jarrodWattsDev/status/1654373015046742022
Since its release, ERC-4337 has gained solid adoption, largely dominated by Polygon, with Base picking up in activity in the past few months.
As we can see thanks to this dashboard by @0xKofi -
(4/23) dune.com/niftytable/acc…
As we can see thanks to this dashboard by @0xKofi -
(4/23) dune.com/niftytable/acc…
The most recent innovation built with 4337 is from the Coinbase ecosystem with their Coinbase smart wallet.
With support for biometrics, the UX is amazing.
I built another little demo showcasing this on the weekend here at ETH Global Sydney:
(5/23)
With support for biometrics, the UX is amazing.
I built another little demo showcasing this on the weekend here at ETH Global Sydney:
(5/23)
https://twitter.com/jarrodWattsDev/status/1786757965078478955
So what's wrong with 4337? Why is there another account abstraction proposal today?
The answer: EOAs are still the most used type of account by far!
In addition to this, most 4337 smart contract accounts are controlled by a single EOA signer!
Example code below.
(6/23)
The answer: EOAs are still the most used type of account by far!
In addition to this, most 4337 smart contract accounts are controlled by a single EOA signer!
Example code below.
(6/23)
Because there is:
A) No way to "convert" your EOA to a smart contract account, we have this weird middle-step solution.
and
B) A lack of native support by web3 apps to connect smart contract accounts.
Most people still use EOAs through extensions like MetaMask today.
(6/23)
A) No way to "convert" your EOA to a smart contract account, we have this weird middle-step solution.
and
B) A lack of native support by web3 apps to connect smart contract accounts.
Most people still use EOAs through extensions like MetaMask today.
(6/23)
This leads us to our next proposal. EIP-3074.
Actually, this proposal was made *before* 4337 was! However, it has not been merged into mainnet.
EIP-3074's tries to give EOAs more power, by allowing them to delegate control of their EOA to a smart contract.
(7/23)
Actually, this proposal was made *before* 4337 was! However, it has not been merged into mainnet.
EIP-3074's tries to give EOAs more power, by allowing them to delegate control of their EOA to a smart contract.
(7/23)
The proposal outlines the following:
Add two new opcodes.
1/ AUTH: EOAs can call AUTH to authorize a given smart contract to perform actions on their EOA's behalf.
2/ AUTHCALL: An authorized smart contract can use AUTHCALL to perform transactions for the EOA.
(8/23)
Add two new opcodes.
1/ AUTH: EOAs can call AUTH to authorize a given smart contract to perform actions on their EOA's behalf.
2/ AUTHCALL: An authorized smart contract can use AUTHCALL to perform transactions for the EOA.
(8/23)
This enables many of the same use cases as 4337 does, without each user having to deploy a new smart contract.
One key difference is that transactions come from your EOA, not a new contract that has none of your account history, or ETH, NFTs, tokens, etc.
(9/23)
One key difference is that transactions come from your EOA, not a new contract that has none of your account history, or ETH, NFTs, tokens, etc.
(9/23)
A common reaction to 3074 was "what if people make malicious contracts and users delegate to them?"
Delegating to a malicious contract could result in EVERYTHING being drained from your wallet.
@adietrichs puts this well in this tweet below.
(10/23)
Delegating to a malicious contract could result in EVERYTHING being drained from your wallet.
@adietrichs puts this well in this tweet below.
(10/23)
https://twitter.com/adietrichs/status/1778574727113511323
The way around this is likely that wallet providers will not even allow you to AUTH to just any contract.
They would likely keep a list of allowed contracts that you can delegate to, and any contract outside this list is not shown to users.
(11/23)
They would likely keep a list of allowed contracts that you can delegate to, and any contract outside this list is not shown to users.
(11/23)
A key part of the EIP-3074 delegation is that the delegation is not permanent.
"A single tx from the EOA will cause the nonce to increase, invalidating outstanding authorizations"
Essentially, after you make a transaction, the delegation is no longer valid!
(12/23)
"A single tx from the EOA will cause the nonce to increase, invalidating outstanding authorizations"
Essentially, after you make a transaction, the delegation is no longer valid!
(12/23)
We also don't really want to give more power to EOAs.
After all, the goal of these proposals is to move users from EOAs to smart contract accounts, so why are we adding features to EOAs?
This leads us nicely to our next proposal: EIP-5003.
(13/23)
After all, the goal of these proposals is to move users from EOAs to smart contract accounts, so why are we adding features to EOAs?
This leads us nicely to our next proposal: EIP-5003.
(13/23)
EIP-5003 adds another opcode, "AUTHUSURP", that deploys code at an EIP-3074 authorized address.
- 3074 is a temporary delegation to a smart contract, which is revocable.
- 5003 is a permanent migration from EOA and "conversion" from EOA to a smart contract account.
(14/23)
- 3074 is a temporary delegation to a smart contract, which is revocable.
- 5003 is a permanent migration from EOA and "conversion" from EOA to a smart contract account.
(14/23)
A big issue with EIP-3074 + EIP-5003 is that it is not very compatible with the current account abstraction via ERC-4337.
Some of the Ethereum community is concerned that we would be "creating two separate code ecosystems" with both types of account abstraction.
(15/23)
Some of the Ethereum community is concerned that we would be "creating two separate code ecosystems" with both types of account abstraction.
(15/23)
That brings us to Vitalik's proposal today: EIP-7702.
His proposal modifies EIP-3074 to make it leaner and more compatible with ERC-4337; so that we don't end up with two separate AA ecosystems.
It also considers EIP-5003 as the next step for permanent migrations.
(16/23)
His proposal modifies EIP-3074 to make it leaner and more compatible with ERC-4337; so that we don't end up with two separate AA ecosystems.
It also considers EIP-5003 as the next step for permanent migrations.
(16/23)
EIP-7702 proposes a new transaction type that accepts both a contract_code and signature field.
At the start of executing a transaction, it sets the contract code of the signer account to contract_code.
At the end of the transaction, it sets the code back to empty.
(17/23)
At the start of executing a transaction, it sets the contract code of the signer account to contract_code.
At the end of the transaction, it sets the code back to empty.
(17/23)
This achieves the same temporary delegation of an EOA to a smart contract that EIP-3074 does.
However, instead of adding new opcodes (which require a hard fork), it defines functions to be called instead.
AUTH -> a call to "verify"
AUTHCALL -> a call to "execute"
(18/23)
However, instead of adding new opcodes (which require a hard fork), it defines functions to be called instead.
AUTH -> a call to "verify"
AUTHCALL -> a call to "execute"
(18/23)
To break this down, it:
1. Checks if your account contract code is empty
2. If it is empty, sets it to the provided contract code
3. Executes the transaction based on how the provided smart contract handles transactions
4. Sets the account contract code back to empty
(19/23)
1. Checks if your account contract code is empty
2. If it is empty, sets it to the provided contract code
3. Executes the transaction based on how the provided smart contract handles transactions
4. Sets the account contract code back to empty
(19/23)
"Contract code" is exactly what it sounds like.
It's where the code of the smart contract lives.
Since EOAs are not contracts, this is typically empty... however, EIP-7702 temporarily populates it with some smart contract code for the lifetime of the transaction.
(20/23)
It's where the code of the smart contract lives.
Since EOAs are not contracts, this is typically empty... however, EIP-7702 temporarily populates it with some smart contract code for the lifetime of the transaction.
(20/23)
It's a way of providing new behaviour (in the form of code) for how this particular transaction should be executed from your EOA.
The next step to this would be to make this a permanent behaviour change, by simply opting to "not set the code back to empty at the end".
(21/23)
The next step to this would be to make this a permanent behaviour change, by simply opting to "not set the code back to empty at the end".
(21/23)
One of the best parts about this proposal is that it is super compatible with all the AA work that has been built out for ERC-4337 so far.
"The contract code that users would need to sign could literally be existing ERC-4337 wallet code".
(22/23)
"The contract code that users would need to sign could literally be existing ERC-4337 wallet code".
(22/23)
Once this change goes through, your existing EOA will be able to execute any smart contract code.
With an additional EIP, EOAs will be able to permanently upgrade to run specific code!
Over time, this could completely change how all of us interact with web3 apps.
(23/23)
With an additional EIP, EOAs will be able to permanently upgrade to run specific code!
Over time, this could completely change how all of us interact with web3 apps.
(23/23)
If you enjoyed this breakdown, the best way to support it is by engaging with the original tweet below to give it more visibility :)
Consider following if you want to see more in the future!
Consider following if you want to see more in the future!
https://twitter.com/jarrodWattsDev/status/1788119041024168385
• • •
Missing some Tweet in this thread? You can try to
force a refresh
