We all want to know what is next in the web3 world. Today we will deep-diving into the future of Ethereum wallets & how it will change the experience for both developers & users.
One word answer for what is coming next to Ethereum is Account Abstraction. It will change how we authorize transactions & interact with blockchains. The change will open the possibilities of having recovery wallets, username-passwords wallets, paying gas fees in tokens other than ETH, or getting gas fees sponsored and having a gassless experience.
Let us dive into how all of this is possible?
So you might have come across this word already. Vitalik has been asking for it since Feb ’20, you can see its birth here.
But Why account abstraction? What is account abstraction? How account abstraction works?
Why account abstraction?
Currently, in Ethereum every transaction has to be signed by an externally owned account (EOA, like metamask, trust wallet, etc.). This signature acts as the authorization mechanism. Miners are looking for transactions in the public mempool. These miners first verify the signature of each and every transaction before picking it up for execution.
The process of signing every transaction have the following problems:
Let's dive into each one of the above-listed problems in detail.
A single way to verify a transaction’s authenticity
One of the biggest problems with the currect architecture of Ethereum is that there is only a single way to verify a transaction’s authenticity. All transactions must be signed with an ECDSA to prove their authenticity. What if we get some vulnerability in the current algorithm (ECDSA) in the future? What about quantum computers, we know quantum computers are coming and can break ECDSA.
The problem is that if we ever have to change the algorithm to authorize transactions in the future, we will have to send an update to all the ETH nodes. For context, the current process of pushing updates to ETH nodes is through voting. The majority of the nodes have to vote in favour and pass the change. Once voted on, the change has to be planned and rolled out with proper tests. What if this takes 6 months? If there was a vulnerability in our authorization layer then all our accounts will be exposed to attacks & hacks until the change has been passed, tested & deployed to all the eth nodes.
A single point of failure, your private key/mnemonic
Another problem in the current architecture is the single point of failure, i.e EOAs. You get a mnemonic when you create your account. That mnemonic is the access to all your crypto funds forever. There is no way to change the mnemonic, what if you forget the mnemonic? The funds are lost forever!! What if someone steals your mnemonic?? Well, write a script to transfer all your funds ASAP! (ps: the hacker already has that script and your funds are already gone). You see the problem, everything boils down to your mnemonic. Once your mnemonic is compromised, your funds are not secure anymore.
Stuck with the blockchain’s native token
The current consensus layer also forces everyone to pay gas fees in ETH. While I love ETH & would love to hodl it for long. I would want some predictability in my wallet & have most of my liquid funds in some sort of stablecoins. There is no way for me to pay gas fees in stable coins with EOAs. The flexibility of paying fees in any other coin or method except for the native blockchain coin is impossible. This inflexibility will lead to problems in scaling Ethereum to billions of people.
What is account abstraction?
Account abstraction is an initiative toward solving the above problems. The latest initiative is drafted in EIP-4337. The protocol allows users to have smart contract wallets without any change to the current consensus layer. This will allow users to have their preferred way of authenticity, allow users to recover or change their proof of authenticity, and also allow users to pay gas or let others pay gas on their behalf.
How account abstraction works?
After multiple attempts from the Eth community, they have settled on EIP 4337. This protocol was the preferred choice because it did not need any change to the current consensus layer.
I will try and briefly explain how this EIP works and how it will abstract accounts for us. Let us first list down the components of this EIP:
The journey starts with a user’s intention to execute an operation on the chain. The user then will bundle their intention of the execution in an object called, User Operation. A user operation describes the following
What is the difference between a transaction versus a user operation? Transactions are fully signed (according to ECDSA) instructions from the account (EOA). While user operations are not signed but do contain proof of their authenticity & instructions that are to be executed. The proof though may not be according to ECDSA standards. The proof’s authenticity has to be decided by the smart contract wallet where the account is hosted and the consensus layer has no say on the user operation’s proof.
Once the user has created the User Operation, they send it to the public network for Bundlers to pick this operation & execute it on the chain. Bundlers are nodes who are ready to process these user operations. Bundlers can sort these user operations based on their gas fees and the reward they can earn by processing the operation successfully.
How are bundlers different from miners? Miners pick transactions that reward them and execute them, while bundlers pick user operations that reward them and execute them. In theory, a miner could become a bundler as well. But before Account Abstraction becomes mainstream, we expect there to be a smaller set of bundlers in the ecosystem than miners.
Bundlers then route each and every user’s operations through an Entry Point Contract. The role of the Entry Point Contract is to route the user operation through its wallet’s smart contract and get it authenticated from the contract. Along with the operation’s authenticity, the Entry Point contract also verifies if the wallet has enough balance to pay for the gas fees & reward for the bundler.
If the wallet’s contract is not deployed Entry Point will also deploy the wallet and then verify the operation.
Once the operation is verified, it will also verify the paymaster (if specified) & verify if the paymaster has enough balance to pay for the user’s operation.
In the above verification process itself, either the wallet or the paymaster has to transfer the maximum amount of gas required for the successful execution of the operation.
Coming back to our verification, upon successful verification of operation & paymaster, the Entry Point will then pass the complete user operation to the Wallet contract for it to execute.
Post the execution of the operation, Entry Point will refund the extra unutilized gas left back to the wallet/paymaster (depending on who paid earlier). If a paymaster was involved Entry Point will also call its postOp function to inform it about the exact amount of gas used for this operation. This will allow the paymaster to keep a track of the payments it is sponsoring.
This is how we will be able to in future solve the three problems stated above. The architecture allows users to
I did not get a lot of time to go in deep into each and every component of the EIP. Keep an eye out for future blogs for them. I will also be writing soon about how the complete system is secure and DDOS proof!
Until then, WAGMI!