One of the major shortcomings of @ethereum is the complicated UX.
Let's learn how EIP 4337, proposed by @nethermindeth & @opengsn in sep'21, tries to solve it with Account Abstraction.
A thread 🧵...
Let's learn how EIP 4337, proposed by @nethermindeth & @opengsn in sep'21, tries to solve it with Account Abstraction.
A thread 🧵...
1/ Well let's start with what account abstraction (AA) means.
Account abstraction provides users the ability to use accounts at a higher level with less knowledge of the processes going on underneath.
Like using a gmail account without knowing how it functions.
Account abstraction provides users the ability to use accounts at a higher level with less knowledge of the processes going on underneath.
Like using a gmail account without knowing how it functions.
2/ With AA, we have a chance to move away from the scary world of seed phrases.
We can enable different signing options, gas fees can be sponsored by Dapps or paid through fiat and much more.
Now that we know what AA is, let's understand how we can bring it to Ethereum.
We can enable different signing options, gas fees can be sponsored by Dapps or paid through fiat and much more.
Now that we know what AA is, let's understand how we can bring it to Ethereum.
3/ There are currently two types of accounts on Ethereum:
1. Externally owned account (EOA)
2. Smart contract accounts
1. Externally owned account (EOA)
2. Smart contract accounts
4/ Externally owned account (EOA):
These accounts are controlled by the user’s key pair (public key and private key). This is what most users use to interact with Ethereum.
Services like Metamask (wallet) act as an interface to interact with these accounts.
These accounts are controlled by the user’s key pair (public key and private key). This is what most users use to interact with Ethereum.
Services like Metamask (wallet) act as an interface to interact with these accounts.
5/ Smart contract accounts:
These accounts are not controlled by any private key, rather they are controlled by their code. For example, all the DeFi protocols are controlled by SC accounts.
These accounts are not controlled by any private key, rather they are controlled by their code. For example, all the DeFi protocols are controlled by SC accounts.
6/ The issue with Ethereum is that EOAs get special privileges that smart contract accounts do not.
The most notable example is the ability to initiate transactions. Currently, only EOAs can do that.
The most notable example is the ability to initiate transactions. Currently, only EOAs can do that.
7/ This is a problem because EOA functionalities are hardcoded into Ethereum protocol and there is no room for customization.
For example: Gmail provides you the option to enable 2FA on your account. Similar customizability can't be done on Ethereum today.
For example: Gmail provides you the option to enable 2FA on your account. Similar customizability can't be done on Ethereum today.
8/ EOAs on Ethereum have the following limitations:
1. Users can't use a custom signing scheme. ECDSA is a typical signing scheme that Ethereum uses to generate public-private key pairs.
2. Gas fees have to be paid in native cryptocurrency ($ETH).
1. Users can't use a custom signing scheme. ECDSA is a typical signing scheme that Ethereum uses to generate public-private key pairs.
2. Gas fees have to be paid in native cryptocurrency ($ETH).
9/
3. Because your private key is your account, losing your key means losing your account.
3. Because your private key is your account, losing your key means losing your account.
10/ All these problems can be easily solved by smart contract wallets as they allow the use of custom logic.
But as mentioned earlier, transactions on Ethereum can only be initiated through an ECDSA-secured externally-owned account (EOA) and not through smart contract wallets.
But as mentioned earlier, transactions on Ethereum can only be initiated through an ECDSA-secured externally-owned account (EOA) and not through smart contract wallets.
11/ Now you might ask - why don't we change that?
Well, EIP 2938 is one path toward fixing this. It introduces Ethereum protocol changes that allow transactions to start from a smart contract instead of an EOA.
But as mentioned, it requires significant protocol changes.
Well, EIP 2938 is one path toward fixing this. It introduces Ethereum protocol changes that allow transactions to start from a smart contract instead of an EOA.
But as mentioned, it requires significant protocol changes.
12/ Hence folks at @nethermindeth and @opengsn with help from @VitalikButerin proposed EIP 4337.
The proposal presents a workaround without any consensus-layer protocol changes.
It brings 'Account Abstraction' to Ethereum.
The proposal presents a workaround without any consensus-layer protocol changes.
It brings 'Account Abstraction' to Ethereum.
13/ Instead of modifying the logic of the consensus layer itself, it replicates the functionality of the current transaction mempool in a higher-level system.
The flow has a lot of moving parts, which include -
1. User operations
2. Bundler
3. Paymaster (optional)
The flow has a lot of moving parts, which include -
1. User operations
2. Bundler
3. Paymaster (optional)
14/ Let's understand them one by one.
15/ The proposal introduces the concept of 'user operations', these operations allow us to code custom functionalities into our SC wallets.
The user operation packages up the user’s intent along with signatures & other data for verification.
An image for context:
The user operation packages up the user’s intent along with signatures & other data for verification.
An image for context:
16/ This is what a general flow might look like for a transaction that gets initiated through an SC wallet:
1 - Alice (user) initiates a 'user operation' and includes the transaction(s) it wants to execute.
1 - Alice (user) initiates a 'user operation' and includes the transaction(s) it wants to execute.
17/
2 - She sends that operation to a high-level 'user operation mempool'.
3 - the operation is partially validated and broadcasted to the P2P mempool node network.
2 - She sends that operation to a high-level 'user operation mempool'.
3 - the operation is partially validated and broadcasted to the P2P mempool node network.
18/
4 - operations are picked up by a 'Bundler' who can be anyone - an MEV searcher, validator, you or me, etc.
5 - all the operations are then bundled by the bundler into one large transaction.
6 - Bundler includes the block in an Ethereum block along with other transactions.
4 - operations are picked up by a 'Bundler' who can be anyone - an MEV searcher, validator, you or me, etc.
5 - all the operations are then bundled by the bundler into one large transaction.
6 - Bundler includes the block in an Ethereum block along with other transactions.
19/ Now let's try to break down the functionalities of a bundler to understand how transactions will be executed and validated.
1 - Bundler routes the transactions to a global 'Entry Point' smart contract.
1 - Bundler routes the transactions to a global 'Entry Point' smart contract.
20/
2 - the global contract goes through each user operation and calls a 'validation function' in the SC wallet.
3 - the wallets run this function to verify the signature of the user operation and to compensate the bundler for bundling these transactions.
2 - the global contract goes through each user operation and calls a 'validation function' in the SC wallet.
3 - the wallets run this function to verify the signature of the user operation and to compensate the bundler for bundling these transactions.
21/
4 - the wallets run an execution operation to execute the transaction(s) that are specified in the operation.
5 - the wallet is then refunded with the gas left after the execution of the operation.
4 - the wallets run an execution operation to execute the transaction(s) that are specified in the operation.
5 - the wallet is then refunded with the gas left after the execution of the operation.
22/ The EIP also proposes the concept of a 'paymaster'.
Instead of relying on their wallet, users can now get their transaction fees sponsored by a paymaster.
Instead of relying on their wallet, users can now get their transaction fees sponsored by a paymaster.
23/ Sponsored transactions have a number of use cases. The most commonly cited use cases are:
- Allowing application developers to pay fees on behalf of their users
- Allowing users to pay fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s.
- Allowing application developers to pay fees on behalf of their users
- Allowing users to pay fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s.
24/ All of this is very exciting Nishil, but why should we care? well, there are multiple reasons.
1. The proposal allows us to use custom signature schemes. Users can now use the inbuilt schemes of iOS and Android devices and turn every phone into a hardware wallet.
1. The proposal allows us to use custom signature schemes. Users can now use the inbuilt schemes of iOS and Android devices and turn every phone into a hardware wallet.
25/
2. It allows native support on Ethereum for multiple signatories. Two or more users can now approve a single transaction, thus improving security.
2. It allows native support on Ethereum for multiple signatories. Two or more users can now approve a single transaction, thus improving security.
26/
3. Social recovery can be enabled. If a user misplaced his key somehow, then he can recover it by simply asking his friends and family to recover it for him.
3. Social recovery can be enabled. If a user misplaced his key somehow, then he can recover it by simply asking his friends and family to recover it for him.
27/ Well that's all folks, thanks for sticking with me.
This proposal introduces multiple avenues of innovation and I hope I did justice to it. It'll be exciting to see the usecases that teams build upon to enable an overall better UX for the users.
We shall cover that later.
This proposal introduces multiple avenues of innovation and I hope I did justice to it. It'll be exciting to see the usecases that teams build upon to enable an overall better UX for the users.
We shall cover that later.
Thanks to @yb_effect for helping with the magical final touches and @chapterone for providing me with this opportunity.
Make sure to check out the link below for some more stuff from Chapter One Research:
threadsby.me/its/chapteron
Make sure to check out the link below for some more stuff from Chapter One Research:
threadsby.me/its/chapteron
• • •
Missing some Tweet in this thread? You can try to
force a refresh
