Update EIP-7702: Prohibit nonce-changing opcodes #8538
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rational for this change is explained in the PR, but might deserve some discussion. All these are a transposition of a discussion that already happened on EIP-5806 (alghouth without all the attention/participation that EIP-7702 is getting today)
Restricting nonce-changing operation
Then Alice's nonce would increase, and the "normal" transaction would no longer be valid. This could DoS Alice's ability to use her EOA. It would also mess up with the mempool. Therefore, I strongly believe that these opcode MUST be restrited.
Restricting SSTORE
EDIT: The SSTORE part is the subject of #8539, no longer in this PR.
I understand people want to use SSTORE. I'm one of them, and I was very reluctant to add this restriction to EIP-5806. However, there is an invariant formulated somewhere (maybe @gballet can find the refenrence) that accounts without code SHOULD NOT have storage slot set. I believe this has to do with the transition to Verkle, or with safety assumption if permanent code is ever placed at this address. This restriction was recognised during the AA breakout session n°2.
I guess the proposed behavior is similar to what happens today if you use SSTORE in a contract that is selfdestructed within its construction transaction.
If you need persistent storage, you can use a third party contract that holds it for you