Skip to content

Release v0.6
Compare
Choose a tag to compare
@drortirosh drortirosh released this 24 Apr 21:56
· 155 commits to develop since this release
v0.6.0
abff2ac
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

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

The changes are:

  • new userOpHash algorithm (#245)
  • nonce managed by EntryPoint (#247)
  • prevent recursion of handleOps (#257)

Together, they guarantee that now there is a consistent view of the UserOperation :

  • The UserOperation hash is always unique
  • Events emitted by the execution of a UserOperation are now uniquely mapped to a 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

The announcement

Effect on Bundlers

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.

Effect on Wallets

  • Existing account contracts can use the new EntryPoint as is, but they can improve their performance by REMOVING the nonce check, as EntryPoint already verifies the nonce uniqueness.
  • BaseAccount was updated, so accounts should be recompiled against it.
  • the nonce() method was renamed to getNonce(). This is in part for reflecting the new mechanism (it references EntryPoint to read the nonce), but also since in a "[Gnosis] Safe" account we can no longer use the nonce method, as Safe uses nonce for non-AA transactions, and getNonce (and EntryPoint) for AA-based transactions. There is no conflict between the two.
  • In order to verify the account is working with a new EntryPoint, it can actively call the entryPoint.getNonce() method (this method is already called from the BaseAccount.
  • Wallets should read the next nonce to use in a UserOperation using the getNonce() method, instead of nonce.
  • Wallets should also decide if they want to use the "two-dimensional" nonce, by using different values for the key part. (Note that the default GnosisSafeAccount currently enforces sequential nonces, just like a normal safe)

Effect on Block Explorers

Block explorers are not affected directly. They can now safely assume that userOpHash has a unique value.

In conclusion

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.

Assets 2
Loading