Skip to content

v0.4.0
Compare
Choose a tag to compare
@drortirosh drortirosh released this 27 Dec 16:28
· 242 commits to develop since this release
v0.4.0
6aeb396

ERC-4337 Contracts 0.4.0 Release Notes

  1. 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.

  2. 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.

  3. 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.

  4. 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

  1. 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.

  2. 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

Assets 2
Loading