Skip to content

v0.8.0

Latest
Latest
Compare
Choose a tag to compare
@drortirosh drortirosh released this 26 Mar 18:03
· 1 commit to develop since this release
v0.8.0
4cbc060
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Release v0.8

EntryPoint 0.8 address

0x4337084d9e255ff0702461cf8895ce9e3b5ff108

Summary

  • Native support for EIP-7702 authorizations in the EntryPoint contract

  • Native support for ERC-712 based UserOperation hash and signatures

  • The unused gas penalty no longer applies if unused gas is below 40,000 gas

  • Native Go implementation of ERC-7562 tracer for ERC-4337 bundlers (expected to be merged in Pectra mainnet)

  • Minor relaxations to ERC-7562 validation rules

  • Bug fixes for issues discovered as part of the AA Bug Bounty Program

    • Prevent initCode front-running
    • Fix errors in calculating Paymaster postOp actualGasUsed value
    • Prevent explicitly setting Paymaster as zero address

Contract changes

1. Native support for EIP-7702 authorizations in the EntryPoint contract (AA-521)

Native EIP-7702 support is added to the Entrypoint contract, reference bundler implementation and ERC-7562 validation rules.
See this document for full description of the EIP-7702 changes to ERC-4337.
Short summary:

a. The UserOperation hash includes the EIP-7702 delegation address
b. The EntryPoint contract checks the delegation address is set correctly
c. The eth_sendUserOperation API accepts the eip7702Auth parameter
d. ERC-7562 validation rules includes a new category called AUTH

2. Introducing the Simple7702Account contract (AA-525)

As part of the v0.8 focus on EIP-7702, we are adding the Simple7702Account contract to the core of the ERC-4337 smart contract distribution. This is a fully audited minimalist smart contract wallet that can be safely authorized by any Externally Owned Account (EOA) and adds full support for all the major features of SmartContract Accounts.

The following ERCs are supported:

  • ERC-165
  • ERC-721
  • ERC-1155
  • ERC-1271
  • ERC-4337 v0.8

3. Native support for ERC-712 based UserOperation hash and signatures (AA-508)

In order to better support signing with external signers, including hardware wallets, the UserOperation hash and signature calculation is now compatible with ERC-712.

4. Update contract licenses

In order to simplify the use of the framework contracts in commercial products, we changed the license of all interface and utility functions to use the MIT license. The core EntryPoint contract continues to use the GPL license.

5. Prevent initCode front-run (AA-466)

First reported by: @ICARUS as part of the AA Bug Bounty Program

In prior versions, the initCode from a UserOperation can be extracted from a UserOperation in the mempool and executed by front-running the actual UserOperation. The result is that the attacker pays for the account deployment, instead of the account owner. This is problematic because this will cause the already submitted UserOperation to fail
unexpectedly for the wallet, and because users will be required to re-sign and re-submit a new UserOperation. This issue is resolved by the following change in the EntryPoint contract:

Require use of EntryPoint in the SenderCreator helper function, which prevents an execution of initCode outside a context of a UserOperation.
In order to prevent a front-run, the Factory contract now SHOULD perform the following check: require(msg.sender == entryPoint.senderCreator());

6. Fix errors in calculating Paymaster postOp actualGasUsed value (AA-467)

First reported by: 0xdeadbeef and Elwin Chua from the OKX wallet team as part of the AA Bug Bounty Program

Reminder: the “unused gas penalty” mechanism was added in ERC-4337 v0.7 and includes a 10% of unused gas being charged for the UserOperation to avoid DoS attacks that are based on artificially high gas limits (AA-217).

The Paymaster’s postOp method allows a paymaster to calculate how much to charge a user, in case it wants to charge the user, either using ERC-20 tokens or in any other way. However, the value passed to postOp includes the gas used by execution, but neglected to take into account the gas penalty for unused gas.

As a result, the Paymaster doesn’t know the actual payment it will have to make back to the bundler, and will charge the user for less than the actual amount of gas used.

7. Don’t penalize unused gas below threshold (AA-507)

UserOp pays 10% of unused gas. With this change, the account (or paymaster) doesn’t pay below 40,000 gas. That is, if the account defines callGasLimit of 80,000, but end up using only 60,000.

8. Prevent explicitly setting Paymaster as zero address (AA-534)

First reported by: [email protected] as part of the AA Bug Bounty Program and taek from the ZeroDev team

Previously, it was sometimes possible to set the Paymaster address value in the UserOperation to zero address (0x0000000000000000000000000000000000000000) but still provide the paymasterData.
The EntryPoint contract treated zero address as “no paymaster” but a common way to check whether a Paymaster contract is being used is paymasterData.length > 0 and this presents a risk of undefined behaviour in some contracts, wallets and applications.

Now EntryPoint contract will not allow zero address as a Paymaster contract and will require paymasterData to be empty for UserOperations without a paymaster contract.

9. Update IAggregator interface by making validateSignatures function non-view (AA-518)

There is no need to require the aggregator’s validateSignatures method to be immutable.
The aggregator is required to be staked, and thus is “accountable” for any revert, regardless if it
uses its own state or not.

10. Make SenderCreator address public (AA-470)

The SenderCreator is a helper contract that is deployed from the EntryPoint constructor.
It was impossible to read this address as it was a private immutable field which made testing ERC-43337 deployment tedious.
Now this address is exposed by the senderCreator() function.

11. Use transient storage for reentrancy guard (AA-465)

This change makes the gas cost of reentrancy guards in the EntryPoint contract noticeably better. However, note that this requires the underlying network to have activated the EIP-1153 TSTOREand TLOAD opcodes.

12. Better handling of validateUserOp returning wrong data size (AA-527)

Previously, two common invalid states, undeployed sender and reverted validateUserOp function resulted in the same error code AA23 reverted. Now these two are split into AA20 account not deployed and AA23 reverted accordingly.

13. ERC-7562 validation rule changes

The purpose of the validation rules was always to prevent denial of service against the mempool by malicious entities, mainly by preventing inter-dependencies by different UserOperations.
We keep trying to find new ways to relax those rules to allow more use-cases, as long as they don’t open new attack vectors.

a. Allow CREATE/CREATE2 opcodes during sender deployment

We identified some scenarios during contract deployment that we can allow the use of CREATE/CREATE2 contracts

b. Allow storage access for all staked entities

Staked paymasters are allowed arbitrary storage read. We extend that rule to any staked entity.

c. EIP-7702 related rules added

14. Make BasePaymaster use "Ownable2Step" instead of "Ownable” (AA-541)

The BasePaymaster contract has been updated to use the Ownable2Step pattern rather than the Ownable implementation. With Ownable2Step, the current owner must first nominate a new owner. The nominated party then has to explicitly accept the ownership, which adds a confirmation step that prevents accidental transfers.

15. Remove legacy support for chains without "basefee"

This change removes complexity and allows for a consistent fee structure without having to handle alternative scenarios for networks without a base fee.

Assets 2
Loading