User:Crypto Jesus/sandbox
Account Abstraction
[edit]Account abstraction is a proposal that seeks to reduce the number of account types and push functionality such as signature verification, gas payment, and replay protection out of the core protocol and into the EVM.[1] This proposal is designed to enable a greater diversity of wallet and protocol design, as well as improve the user experience of private key storage and recovery. Additionally, account abstraction allows for natively paying gas fees in tokens other than ETH, and for accounts to change public and private keys.
Account abstraction enables wallet designs to incorporate features such as multi-signature, social recovery, more efficient and simpler signature algorithms (eg. Schnorr, BLS) and post-quantum safe signature algorithms (eg. Lamport, Winternitz). It also reduces the overhead of transactions by eliminating the need for externally owned account (EOA) transactions, making it easier to manage user balances.[2]
This technology is being developed and standardized currently as EIP-4337.
History
[edit]Account abstraction has been a topic of conversation in the Ethereum ecosystem for many years. The concept of account abstraction was first proposed in EIP-86 in 2017, it sought to create a system of account abstraction using a single address to represent multiple accounts. This proposal was designed to reduce the complexity of interacting with multiple accounts on the Ethereum blockchain, as well as to reduce the costs associated with operating multiple accounts.[3]
In the following years, there were numerous other proposals relating to account abstraction, including EIP-1706 and EIP-1776, which proposed a system of account abstraction that would enable users to create their own account-based smart contracts. Other proposals included EIP-2156 and EIP-2470, which sought to implement a system of account abstraction that would enable users to create their own wallet contracts.
EIP-2938 was proposed in June 2019 and sought to improve the scalability of Ethereum's mempool by allowing users to bundle multiple transactions into a single transaction. This would reduce the size of the mempool and also reduce the amount of time it takes for transactions to be processed by the network. The proposal also sought to address the issue of transaction fees, by allowing users to pay a fixed fee for their transactions, instead of the current system of paying a fee for each transaction.[4]
The concept of account abstraction was further refined with the introduction of EIP-4337 in June 2020. Prior proposals required consensus layer changes making them impractical to implement. This proposal created an implementation of account abstraction that enables users to create their own custom wallet contracts, which can be used to interact with the Ethereum blockchain without the need for consensus layer change. This proposal also drastically reduced concerns surrounding scalability, security, and cost.[5]
Today, account abstraction is a major focus of the Ethereum community, as developers continue to seek solutions to improve scalability, security, and transaction fees.
EIP-4337
[edit]EIP-4337 is a universal standard that enables developers to build applications using account abstraction without requiring consensus-layer protocol changes. It introduces the concept of a pseudo-transaction object called a UserOperation which can be used to execute actions through a smart contract wallet. This UserOperation object contains intent, signatures, fees, and other data which can then be bundled with other UserOperations by validators or bundlers into a single “bundle transaction”. This bundle transaction is then included in an Ethereum block, with the bundler paying the fee for the bundle transaction in ETH and getting compensated through fees paid as part of all individual UserOperation executions.[6] EIP-4337 provides a simple, secure, flexible, and potentially discounted way to interact with smart contracts. It eliminates the need for users to interact directly with the blockchain removing the complexity of gas and the requirement to hold native blockchain tokens.
User Wallets
[edit]User wallets are used to validate UserOperations which are used to execute actions through a smart contract wallet. The user wallet is responsible for verifying the signature and nonce on the UserOperation, paying the fee and incrementing the nonce if the verification succeeds, and throwing an exception if the verification fails. The wallet also contains an op execution function that interprets calldata as an instruction for the wallet to execute actions.[7] By verifying UserOperations, the user wallet ensures that only approved transactions can be executed.
Entry Point Contract
[edit]To ensure safety, the complicated logic is done not in the wallet itself, but in a global contract called the entry point. The entry point is responsible for verifying the UserOperation with a call to validateUserOp, creating the wallet using the provided initCode if the wallet does not exist already, and then making an arbitrary call to the wallet with a UserOperation carrying the calldata. It also introduces a class of actors called Bundlers which are responsible for packaging UserOperations from a mempool and sending them to the EntryPoint contract on the blockchain.[8] The EntryPoint contract acts as a central entity for all EIP-4337 wallets and paymasters, coordinating the verification and execution of a UserOperation.
Paymaster Contracts
[edit]Paymaster contracts are optional smart contract accounts that can sponsor transactions for wallet contracts.[9] Paymaster contracts can be used to drastically improve the user experience on non-financial applications (i.e. a decentralized social media platform utilizing account abstraction could use a paymaster contact to make posts free for users).
Contributors
[edit]Vitalik Buterin, Ansgar Dietrichs, Kristof Gazso, Tjaden Hess, Shahaf Nacson, Namra Patel, Dror Tirosh, Will Villanueva, Yoav Weiss, and Sam Wilson.
Projects Utilizing Account Abstraction
[edit]Existing implementations:
- Biconomy - SDK for account abstraction
- ETH Inifitism - EIP-4337 implementation
- Stackup - SDK for account abstraction
Future implementations:
- Candide Wallet - Ethereum social recovery wallet
- Solon Gateway - Decentralized interface for web3
References
[edit]- ^ https://matterlabs.medium.com/introducing-account-abstraction-l2-l1-messaging-and-more-760282cb31a7
- ^ https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a
- ^ https://github.com/ethereum/EIPs/blob/master/EIPS/eip-86.md
- ^ https://eips.ethereum.org/EIPS/eip-2938
- ^ https://eips.ethereum.org/EIPS/eip-4337
- ^ https://eips.ethereum.org/EIPS/eip-4337
- ^ https://eips.ethereum.org/EIPS/eip-4337
- ^ https://eips.ethereum.org/EIPS/eip-4337
- ^ https://eips.ethereum.org/EIPS/eip-4337