Update EIP-7702: Prohibit nonce-changing opcodes

[Amxx]

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

• Lets say Alice has an EOA, and gave a signature so that Bob (or anyone) can temporarily place code at Alice's EOA's address.
• Lets say Alice submits a "normal" transaction, with the correct nonce
• Lets say before Alice transaction is mined, Bob (or anyone) uses Alice signature, invokes the code at under Alice's EOA's address, and execute any of these opcodes

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

[eth-bot]

File EIPS/eip-7702.md

Requires 1 more reviewers from @adietrichs, @lightclient, @SamWilsn, @vbuterin

[yoavw]

I'd say not cleared, but prevent SSTORE in the first place. Otherwise it might have unintended consequences to code that assumes the SSTORE was not implicitly a TSTORE. See my Safe example in the EM thread.

[Amxx]

This is what I originally proposed, both in EIP-5806 and here.

I see that #8539 is specifying that part, so I'll change this PR to be only about create/create2/selfdestruct

[AmadiMichael]

Resharing my comment from the 7702 eip...

Not so sure about the invariant because a contract that sets storage at initialization but also returns 0 bytes at initialization has no bytecode but has > 0 storage slots set.

E.g

PUSH1 0x01
PUSH0
SSTORE

PUSH0
PUSH0
RETURN

Returns no runtime code but definitely has something at storage slot 0 which if read via an rpc returns 0x01