Account Abstraction (EIP 4337) contracts
GPL-3.0 License
Bot releases are hidden (Show)
delegateAndRevert()
helper in EntryPoint to accommodate nodes without state overrides in eth_call and eth_estimateGasexecuteUserOp()
.Separated validation rules into its own separate doc, instead of having a section in the EIP, clearly marking each validation rule <RULE_TYPE>-<RULE_NUMBER>.
where RULE_TYPE is one of:
OP - opcode rules
COD - code rules
STO - storage rules
SREP - staked entity reputation rules
UREP - unstaked entity reputation rules
EREP - entity-specific reputation rules
ALT - alternative mempools rules
Validation rules changes from 0.6.0:
OP-013 Banning unassigned opcodes to prevent future vulnerabilities via new opcodes.
OP-051 Allow calling EXTCODESIZE ISZERO
to allow calling depositTo()
.
OP-054 Forbidding calls to EntryPoint besides depositTo()
.
STO-033 Allowing staked entity reading storage on non-entity contracts.
This relaxation simplifies and extends the usability of paymasters.
EREP-020 Staked factory is accountable for account breaking validation rules.
UREP-* Unstaked reputation rules.
These rules prevent unstaked paymasters from invalidating many user operations at once.
ALT-* Alt mempools/canonical mempool interactions rules.
OP-070 Transient storage rules.
Published by drortirosh over 1 year ago
Following feedback from the community, we have pushed and deployed a new version of the EntryPoint contract, with a few modifications. The latest address is 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789
Together, they guarantee that now there is a consistent view of the UserOperation :
This is primarily relevant to external entities (block explorers, wallets, and anyone processing events).
We also asked OpenZeppelin to update the audit to include these changes
If a bundler has an "off-chain" calculation of the hash, it should be updated to the new implementation of the getUserOpHash() helper method in the EntryPoint.
Block explorers are not affected directly. They can now safely assume that userOpHash has a unique value.
Even though these changes were not critical, as there were no security implications, we felt that it is better to push such changes now, before wallets get widespread adoption.
Published by drortirosh over 1 year ago
This version contains several important changes to the account and entrypoint.
It is also audited by OpenZeppelin (see the audits in the audits
folder)
Below are the Major Changes:
IAccount.validateUserOp
changes:
IPaymaster.validateUserOp
changes:
simulateHandleOp
, to simulate a full UserOperation execution (not only validation)Published by drortirosh almost 2 years ago
Simulated execution indistinguishable from on-chain execution for contracts (AA-92)
EntryPoint security improvement. Previously, the 'simulateExection' was defined as a view call to ‘validateUserOperation’ method with 'from' address set to 'address(0)'. This meant that contracts (Account, Paymaster, Aggregator, Factory) could check if their code is running in a simulation or not and behave differently in simulation and execution. It was also impossible to simulate the target call within the context of account-abstraction call, for instance we could not estimate gas for a call on an undeployed wallet. This is solved by adding a separate 'estimateExecution' method to the EntryPoint.
Default SimpleAccount now deployed as an upgradeable proxy (AA-74)
While ERC-4337 does not have a "canonical" wallet, we aim to provide the best-practices example as part of the contracts package. SimpleAccount is now deployed as an ERC-1967 Proxy, making accounts both upgradeable and cheaper to deploy out-of-the-box.
Use standard proxy factories or Create2Factory for Gnosis Safe deployments (AA-91)
Used a non-standard approach previously. Now the only difference in a Gnosis Safe deployed by ERC-4337 is the added ‘Eip4337Manager’ module.
Enforce 'verificationGasLimit' and revert with meaningful error messages(AA-85)
Previously, the 'verificationGasLimit' was not enforced on-chain.
Note: the following changes were made in version 0.3.1 but were not published
Implement optional staking and reputation for all contract types - Accounts, Paymasters, Aggregators, Factories (AA-73)
As each contract in the UserOperation's life cycle has an opportunity to revert, causing the Bundler to have wasted the computation resources spent on verification, without a reputation system the Bundlers become susceptible to denial-of-service and sybil attacks. Requiring some stake to be locked first to create a new contract in the ERC-4337 system prevents that and allows the Bundlers to track these contracts' reputation.
Note that If a contract does not need to access any storage slots at all it does not need to have a stake.
Relax storage rules in opcode banning (AA-67)
Previously it was forbidden for contracts to access any external contracts' storage slots. This, however, prevented many important use-cases. For instance, a Paymaster that uses an ERC-20 token to pay for UserOperation gas was not feasible. With this new set of rules, the contracts can access the storage slots that are a mapping of the UserOperation Account address or a 'msg.sender' value. Thanks to zkSync for their contribution. They explain this change here: https://v2-docs.zksync.io/dev/developer-guides/aa.html#extending-eip4337