Remove ban of EXTCODESIZE

[pdobacz]

Starting the move tentatively decided on during EOF implementers call.

Will proceed to EIPs/EEST/evmone next.

EXTCODEHASH unbanning was also discussed, but the decision was to start small and possibly expand in the next step.

[gumb0]

Main argument against would be: this breaks code unobservability guarantees.

In particular the danger can be in some contracts implementing logic conditional on code size (if EXCTODESIZE(addr)=...) and then this code being broken in case addr code is translated to a different version. (here in particular, if legacy code is ever translated to anything else)

And with EIP-7702 even legacy translation is not neeed: result of EXTCODESIZE changes when EOA is delegated to a contract or when delegation is updated. From the point of view of 7702 this is desired behavior.

All other considered solutions (EXT*CALL status codes, IS_CONTRACT etc.) introduce some level of observability, too (some logic depending on whether the contract is EOA or not may break if code assumes this is immutable). But EXTCODESIZE method raises this level up a notch, with more potential scenarios of breakage.

[gumb0]

Also general aesthetics / elegance argument: having to explain why with all the measures to prevent code observability. there was one exception for EXTCODESIZE. And why EOF can read legacy code size but not EOF code size.

[pdobacz]

Agreed to both comments, The only reason why this has been (tentatively) chosen is that it doesn't introduce yet another opcode.

I only have doubts whether this

some contracts implementing logic conditional on code size (if EXCTODESIZE(addr)=...)

pattern (with exact equality, and to a RHS not being zero) is worthwhile. To me the elegance and abstraction-based arguments are much more important.

If we can at this point have an IS_CONTRACT opcode, this would be definitely cleaner.

[pdobacz]

Per last EOF implementers call this is unlikely to happen, the EXTCODESIZE remaining banned has momentum. Will reopen if anything changes.