From 73a676999999843f5086ee546e192cbef25c0c4a Mon Sep 17 00:00:00 2001 From: Dror Tirosh Date: Mon, 16 Oct 2023 19:19:17 +0300 Subject: [PATCH] eip: remove "increment nonce" clause (#353) nonce is managed by entrypoint. account doesn't have to increment it. --- eip/EIPS/eip-4337.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eip/EIPS/eip-4337.md b/eip/EIPS/eip-4337.md index 78afb46e..1e3b8170 100644 --- a/eip/EIPS/eip-4337.md +++ b/eip/EIPS/eip-4337.md @@ -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):