GM Everyone!
As I discussed in the last article Future of your Ethereum wallets, wallets of the future will be smart contract wallets. A natural progressive question is: how will you move all your EOA (Externally owned accounts like Metamask) assets to the smart contract wallets (SCW)?
Will you have to transfer all the assets one by one? This is not a plausible solution because this requires a transaction per asset (making it extremely expensive). At worst, some powers (like hard-coded owners in a smart contract, or SBTs) might not be transferable at all.
EIP-4337, as discussed in Future of Ethereum wallets, propose a ton of security benefits. Though, the biggest roadblock to its adoption is the existence of 71M EOA Wallets. We can’t leave these wallets that holds the total Ethereum economy as of today. Hence we need a way to help the majority of the Ethereum platform to move away from EOA to SCW.
Well where there is a problem, there is a solution. Let’s discuss the two ways in which we can make the transition of EOA to SCW possible in an affordable way.
NOTE: None of the ways listed below has been finalised as of now & we have no clarity as to what will finally be adopted by the Ethereum community.
Typed Transaction Envelope
EIP-2718 introduces a way for users to define the type of transaction. This allows EVM to run special codes based on the type of transaction. Using this we can introduce a special transaction, let’s call it replace code, that will replace the original account data with the new SCW account call data (SCW’s deployment initdata). This would allow users to migrate their accounts in a single transaction & also sign for a previous public address with newly SCW address.
Introduction of AUTH_USURP opcode
Another interesting approach to solving the problem is the use of EIP-5003 & EIP-3074. EIP-5003 builds over the foundation laid by EIP-3074, especially with the introduction of opcode AUTH.
Let’s understand AUTH opcode and how it functions. It allows users to set authorised addresses. When a user calls AUTH opcode, it set’s a new address to validate & send transactions on behalf of the original address. This allows users to have multiple private keys for the same account. Note, however, that the ultimate account authority is still with the original address. The original address signer can at any point in time change authorised addresses.
Now that we know that AUTH opcode allows us to set authorised addresses, it still has the problem that the ultimate power is still with the original signer. For our use case, that is to move from EOA to SCW, we need to revoke the ultimate power from the original signer to the new SCW signer. This is where EIP-5003 comes into the picture.
EIP-5003 introduces a new opcode AUTHUSURP. The user will have to first use the AUTH code to set a new authorised address. Then we will have to call the AUTHUSURP code which will deploy the SCW at the authorised address defined by AUTH opcode above. Upon successful deployment, the opcode would return the newly deployed address. The new address would also be registered as one of the authorised addresses for the original address. Hence allowing the users to use the new signature & public key for all their previous assets and also interact with non-transferable assets (since the new address is listed as the authorised address for the original address)
How soon?
The above-pointed methods are still in the idea stages, I read about them from Ethereum’s planned road to account abstraction by Vitalik. The latest changes to the document were made a month ago as of 3rd Aug 2022. A lot of work has been put into making account abstraction a reality & improve the lives of all web3 users.
My recent search on Account Abstraction has been one of the key motivators for my today’s research. I see this as an opportunity for myself also to learn more about how EVM works, and how its opcodes work.
While transferring from EOA to SCW is one of the problems, high gas fees in SCW are also an emerging issue. I will also keep you updated on how Ethereum plans to solve that in my future blogs.
Until then, WAGMI!