Skip to content

Commit

Permalink
eip: remove "increment nonce" clause (#353)
Browse files Browse the repository at this point in the history
nonce is managed by entrypoint. account doesn't have to increment it.
  • Loading branch information
drortirosh authored Oct 16, 2023
1 parent 5b7b971 commit 73a6769
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion eip/EIPS/eip-4337.md
Original file line number Diff line number Diff line change
Expand Up @@ -903,7 +903,7 @@ See `https://github.com/eth-infinitism/account-abstraction/tree/main/contracts`

## Security Considerations

The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ [ERC-4337](./eip-4337.md). In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _accounts_ have to do becomes much smaller (they need only verify the `validateUserOp` function and its "check signature, increment nonce and pay fees" logic) and check that other functions are `msg.sender == ENTRY_POINT` gated (perhaps also allowing `msg.sender == self`), but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust.
The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ [ERC-4337](./eip-4337.md). In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _accounts_ have to do becomes much smaller (they need only verify the `validateUserOp` function and its "check signature and pay fees" logic) and check that other functions are `msg.sender == ENTRY_POINT` gated (perhaps also allowing `msg.sender == self`), but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust.

Verification would need to cover two primary claims (not including claims needed to protect paymasters, and claims needed to establish p2p-level DoS resistance):

Expand Down

0 comments on commit 73a6769

Please sign in to comment.