Introduction EIPs (Ethereum Improvement Proposals) are protocol/application-level upgrade proposals for the Ethereum platform.EIPs broadly contain proposals for protocol/consensus/application layer upgrades, whereas ERCs are application-level upgrades. EIP - - ERCs (Ethereum Request for Comment) are token/contract standards (application level standards) that start out as EIPs. EIP becomes ERC only when the core Ethereum devs and committee agree and vote on it. ERC Some of the most popular EIP turned ERC standards are: which defined the standard to create a fungible token , EIP-20 which defined the standard to create a non-fungible token , EIP-721 which defined a standard to create a hybrid of fungible and non-fungible tokens , EIP-1155 One such standard recently proposed by along with some others, is a standard called also simplified as Vitalik Buterin, , ERC-4337 Account Abstraction Using Alt Mempool. #WhatTheFork is ERC-4337 ? Technical Explanation is a standard that aims to solve the UX problems with traditional wallets without any modification to the protocol/consensus layer. ERC-4337 Traditional wallets are generated using the (Elliptic Curve Digital Signature Algorithm) to generate a public & private key pair, and the public address is derived from the public key. These wallets can only sign and broadcast a transaction to the chain and cannot perform smart contract-like functionalities. ECDSA Account Abstraction, as it is popularly known, is a way of bringing contract-like functionality to EOAs (Externally Owned Accounts) without having to manage an EOA and Smart Contract separately. brings AA (Account Abstraction) by moving the validity conditions of a transaction, like the signature verification, replay protection, etc., from the consensus layer to the smart contract layer (execution layer). ERC-4337 introduces a standard interface for the Ethereum network’s deposit contracts, which allows different applications and wallets to interact with smart contracts in a standardized way. ERC-4337 Layman Explanation Normal Ethereum wallets are very standard and can only perform tasks like signing and sending transactions. A good metaphor is to look at Account Abstraction as having a chip planted into the Ethereum wallets, which makes it smart. The chip is analogous to the code in the wallets, which makes it smarter. Programmers can write code to do many other tasks, which can extend the functionality of normal wallets beyond just transaction signing. The additional functionality can include performing any type of logic ranging from batch transactions and time-locked wallets to performing social recovery, multisig wallets, and gas payments using ERC-20 tokens. Under the hood Components of AA — A higher-level transaction object which gets sent to a separate mempool UserOperation — A contract to pay for transactions on behalf of the wallet Paymasters — Nodes that can bundle transactions from the UserOperation mempool Bundlers — The EntryPoint contract is a singleton (global) contract that verifies and executes the bundles of UserOperations sent to it. EntryPoint Wallet — A user account in the form of a contract Wallet Contract — A factory contract that creates individual wallet contract Wallet Deployer — Application/User Interface to perform transactions Wallet Software UserOperation A looks like a transaction; it’s an ABI-encoded struct that includes fields such as : UserOperation struct UserOperation { uint256 nonce; bytes callData; uint256 callGasLimit; uint256 maxFeePerGas; uint256 maxPriorityFeePerGas; bytes signature; address sender; bytes initCode; uint256 verificationGasLimit; uint256 preVerificationGas; bytes paymasterAndData; } : This is the wallet making the operation sender : The data to call the wallet with for the actual execution step callData : To prevent replay attacks. Also used as salt for first-time wallet creation nonce : The amount of gas to allocate the main execution call callGasLimit : Maximum fee per gas (similar to EIP 1559) maxFeePerGas : Maximum priority fee per gas (similar to EIP 1559) maxPriorityFeePerGas : Data passed into the wallet along with the nonce during the verification step signature : The of the wallet (only needed if the wallet is not yet on-chain and needs to be created) initCode initCode : The amount of gas to allocate for the verification step verificationGasLimit : The amount of gas to pay for to compensate the bundler for pre-verification execution and calldata preVerificationGasLimit : Address sponsoring the transaction (or zero for regular self-sponsored transactions) and any additional data paymasterAndData Paymaster Paymasters allows developers to sponsor the fees of a transaction on behalf of the users. Paymasters allows users to pay their fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s and pay in ETH Bundler A Bundler is a node that listens to the mempool, bundles multiple together, and sends that bundle to the EntryPoint contract for execution. UserOperation UserOperations Bundlers choose which objects to include in their bundle transaction based on similar fee-prioritization logic used by block builders on Ethereum today. UserOperation Because the Bundler acts as the “from” address when getting the bundle transaction on-chain, the Bundler will pay the gas fee for the bundle transaction in ETH. Bundlers are compensated through fees paid as part of all individual executions. UserOperation EntryPoint The EntryPoint contract is a singleton contract that verifies and executes the bundles of sent to it. It is a global entry point that everyone using ERC-4337 compliant smart contract wallets will use to transact on the EVM. This concept is comparable to the single staking deposit contract. UserOperations The use of an EntryPoint simplifies the logic used by smart contract wallets, pushing the more complicated smart contract functions needed to ensure safety to the entry point rather than in the wallet itself. Offchain Architecture The dApp initiates a signature request from the user’s wallet The wallet signs and broadcasts the transaction to the chain using an RPC call. The UserOperations calls go into a separate mempool which runs parallel to the traditional transaction mempool. From this point, the on-chain flow starts… OnChain Flow There is a method in the EntryPoint contract called . handleOps() The transaction now goes through 4 steps: If the wallet is not yet on chain, then the transaction goes through the phase where the factory contract will deploy the wallet contract. initCode The function performs the validation to check if the nonce and signature are valid. validateUserOp() Checks if there is a paymaster to pay the user’s transaction fees and accordingly invokes the function in the Paymaster contract. validatePaymasterUserOp() The final step is to execute the transaction in the wallet contract What’s in it for users ? No more worry about seed phrases and the hassle of storing them, making it easier for non-techy users to get onboarded to the web3 ecosystem No need to worry about having native coins to pay for fees. Fees can be paid using ERC-20 tokens Improved security. Since the validation layer is taken care of by the contract, users can have their trusted devices manage the authentication of payments making their mobile devices similar to hardware wallets Enable multisig functionalities What’s in it for devs? Easy user onboarding by having a paymaster pay for the user’s transaction fees Enhanced privacy and security: With account abstraction, developers can implement custom privacy and security measures tailored to the specific needs of their applications. This can include advanced cryptographic techniques, such as zero-knowledge proofs, to ensure transaction privacy or multi-signature wallets to enhance security. …among many more Folks, this is just a high-level introduction to ERC-4337. I will be writing about this extensively, along with some technical guides to creating an ERC-4337 compatible wallet. Stay tuned.. Also Published Here
