EVM: Return 0 from EXTCODESIZE when called for accounts and inexistent addresses

[raulk]

A user has reported this with an ERC-721 token contract:

https://fvm-forum.filecoin.io/t/cannot-invoke-extcodesize-for-non-evm-actor/115

The same error was reported with OpenZeppelin's ERC-1155 contract. In this case it was coming from a Solidity call to isContract(), which under the hood calls EXTCODESIZE to determine if the address has any code associated with it. I'm pretty sure the ERC-721 failure has the same root cause.

NB. There are security advisories related to this usage of Solidity.

Our implementation of EXTCODESIZE errors if the supplied address is not an EVM smart contract. Instead, we should behave this way:

• If the address is an EVM smart contract, return the length of its EVM bytecode (already implemented).
• If the address is an EVM EOA, return 0.
• If the address doesn't exist, return 0.
• If the address is a secp256k1 or BLS account, return 0 (they are accounts with no associated code -- although this might change with account abstraction!).
• If the address is an f2 actor or a built-in singleton => ?

The last case is hairier, as it's an interoperability rough edge. An f2 address or a singleton built-in is a contract, and for all intents and purposes we want an addr.isContract() call to return true, so the value needs to be non-zero.

However, EXTCODESIZE can also be used to size a buffer ahead of a call to EXTCODECOPY. If that's what the contract wants, if we return a non-zero, the caller may proceed with calling EXTCODECOPY and would receive an unexpected error. This is probably fine as the usage of EXTCODECOPY is very limited, and returning EVM code is absolutely impossible here.

[mriise]

they are accounts with no associated code -- although this might change with account abstraction

this wont be the case for a while likely, for now abstract accounts will be either f2 or f4 (and ofc f0).