Enable all EXTCODE* opcodes

[frangio]

As discussed before, ERC-721 and ERC-1155 need some form of a "HASCODE" operation, which has so far been implemented with EXTCODESIZE. In current EOF there's no way to implement it without invoking a Legacy contract as an escape hatch.

There's a proposal to add a HASCODE opcode for EOF that would fix this particular issue.

However, I believe it's simpler and compatible with all EOF goals to just enable EXTCODE* opcodes.

The opcodes would have the same semantics they have in Legacy code:

• If the target account of EXTCODECOPY is an EOF contract, then it will copy up to 2 bytes from EF00, as if that would be the code.
• If the target account of EXTCODEHASH is an EOF contract, then it will return 0x9dbf3648db8210552e9c4f75c6a1c3057c0ca432043bd648be15fe7be05646f5 (the hash of EF00, as if that would be the code).
• If the target account of EXTCODESIZE is an EOF contract, then it will return 2.

Common concerns

Code introspection

This change does not introduce code introspection. EOF contracts remain opaque, it's not possible to read their code from within the EVM, and they retain strict separation between code and data. An EVM implementation doesn't need to keep the EOF bytecode if it compiles it to some other form (machine code, SNARK circuit, etc.).

There's no point in disabling code introspection of Legacy contracts because it can always be recovered by escaping to the Legacy EVM. If this has an efficiency impact for EOF EVM implementations, I think it would be better addressed by pricing (e.g., crossing from EOF to Legacy could have an additional cost).

Data contracts

It's possible developers may use Legacy contracts as data storage via EXTCODECOPY. If this is a problem to the network I believe it should be addressed by more accurately pricing the opcode.

Account Abstraction

There's an argument that these opcodes enable "discrimination", either deliberate or unintentional, against smart contract accounts (SCAs). I think this is a bad argument in both cases:

Unintentional: In my experience, unintentional incompatibility with SCAs arises from the assumption that the account can produce ECDSA signatures. This happens when a protocol requests a signature and assumes it can authenticate it via ECRECOVER, which only works for EOAs. The removal of EXTCODE* doesn't change this. If we want to do something impactful for the AA roadmap we should work to ensure widespread adoption of ERC-1271 and ERC-6492, or alternative standards.

Deliberate: Some developers have tried to deliberately restrict smart contracts from accessing an application as some form of protection from batching or reentrancy. See example here. This has always been a terrible idea, and it has been extensively documented as such for a long time. Most notably, there are alternative and more reliable ways to do this that won't be stopped by the removal of EXTCODE*, like requiring an ECDSA signature or (until EIP-7702) checking tx.origin == msg.sender.

Additional benefits

• Less divergence between Legacy and EOF
• Avoids adding yet another opcode (HASCODE)
• DELEGATECALL guard: Delegation from an EOF to a Legacy contract currently causes a revert and this risks breaking proxies unless it's possible to detect that an address contains Legacy code, which EXTCODECOPY enables.
• Future migration of Legacy contracts: It seems impossible to eventually migrate Legacy code to EOF code without these opcodes. (However, there are larger unsolved issues for migration, mostly lack of gas introspection.)