The purpose of the EIP-4337 proposal is to avoid changes to the consensus layer protocol, and to achieve the goal of account abstraction, decentralization, no consensus changes, and payment of transaction fees.
Original title: “Account Abstraction: EIP-4337”
Written by: Yash Kamal Chaturvedi
Translation: ChinaDeFi
In this article we will get a complete concept of EIP-4337’s role in account abstraction.
introduce
The proposal includes some changes to avoid changes to the consensus layer protocol, rather than relying on higher-level infrastructure. It aims to achieve the following goals:
Account abstraction: Allow users to use smart contract wallets that contain arbitrary verification logic instead of EOA as their main account.
Decentralization: Allow any binding person to participate in the process of abstract user activities including account. The user does not need to know the direct communication address of any participant in order to process any activity that occurs across the public memory pool.
No consensus changes: For faster adoption, this proposal avoids consensus changes.
Pay transaction fees: Use ERC-20 tokens to pay transaction fees, enabling developers to pay for their users, as well as sponsored transaction use cases similar to EIP-3074.
The following are some of the new features in the proposal. All operations are performed in a peer-to-peer memory pool. Users do not have to worry about their wallet contract has been released, because the wallet exists in the deterministic CREATE2 address, if the wallet does not exist, UserOperation will automatically create it. Users will now be able to set a fixed fee premium and maximum total fee, and expect it to be included quickly and reasonably charged. The UserOperation that passes the simulation check is guaranteed to be inclusive until the sender has another state change, which will require the attacker to pay 7500+ gas for each sender.
Work
The user sends a UserOperation object, which encapsulates the user’s purpose and the signature and other data used for verification. Miners or binders using services such as Flashbots can combine UserOperation objects into a single bundled transaction, and then include them in the Ethereum block. The bonder pays the cost of the bundled transaction in ETH and compensates it with the fees paid by each individual execution of UserOperation. The binder will use cost priority logic to choose which UserOperation objects to include.
In order to simplify the logic of the wallet, most of the complex smart contract logic required to maintain security is executed outside the wallet, in a global contract called the entry point. The validateUserOp and execution functions are expected to be combined with the gated require(msg.sender == ENTRY POINT), so that only trusted entry points can trigger the wallet to perform operations or pay fees. After verifying the success of userop using UserOperation with calldata, the entry point makes arbitrary calls to the wallet. This is done to protect the wallet from attacks.
If the verification of UserOperation is successfully simulated, the UserOperation is guaranteed to be inclusive before the internal state of the sender’s account is changed.
Initiate transaction
We can allow application developers to pay fees on behalf of users, and allow users to pay fees with ERC20 tokens, collect ERC20 tokens through the contract as an intermediary and use ETH to pay.
The proposal can support the above use cases through the payment supervisor mechanism.
For use case 1: Paymaster verifies that the initiator’s signature is included in PaymasterData, indicating that the initiator is ready to pay for UserOperation. If the signature is valid, Paymaster accepts it, and the UserOperation fee is deducted from the initiator’s share.
For use case 2: Paymaster checks whether the initiator wallet has enough ERC20 balance to pay for UserOperation. If it is, Paymaster accepts and pays the ETH fee, and then applies for ERC20 tokens in postOp.
Advantage
Verification logic flexibility: validateUserOp function adds arbitrary signature and random number verification logic.
Execution logic flexibility: The wallet will be able to add custom logic for execution steps.
Wallet upgradeability: The wallet will be able to change its public key or upgrade its code.
shortcoming
Increase DoS vulnerability: The verification logic is more complicated than a single ECDSA verification.
One transaction at a time: The account cannot queue up and send multiple transactions to Mempool.
Gas overhead: Compared with normal transactions, more gas overhead.
Source link: medium.datadriveninvestor.com
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.
