Add back EIP-1052 isContract function with a different name

isContract has switched from extcodehash to extcodesize for less gas usage in this commit:

But as the important notes mentioned It is unsafe to assume that an address for which this function returns false is an externally-owned account (EOA) and not a contract. Therefore there would be cases that you would like a more secure check over gas usage. And I would propose to add back the EIP-1052 isContract function with a different name, maybe isSecureContract or something not sure.

2 Likes

What do you mean by “a more secure check” exactly? Using extcodehash doesn’t make isContract any more accurate or secure.

The only way to reliably check that an account is not a contract is to ask for a signed message and use ecrecover.

1 Like

You are right. The distinction made by EXTCODEHASH possible is between empty and uninstantiated accounts.

I’m not sure I understand the distinction you make between empty and uninstantiated accounts. AFAIK, the only thing we can check is the emptyness/hash of the code stored at this address … and this will be empty both for an EOA, or a smart contract before (and during) deployment.

Is there anything else the EVM tracks that we could use?

1 Like

@Amxx Take a look at the specification of EIP-1052. There are two possible values returned by extcodehash when an account doesn’t have code.

As ar as I can tell, though, this is not a distinction that would be relevant for a smart contract.

2 Likes

I was not expecting that form 1052. having extcodehash return 0 or keccak256("") depending on value/nonce/history feels wrong.

It allows some for of distinction between different “non contract” accounts, but I’m missing how this would help identify contracts.

1 Like

isContract() => haveDeployedContractRightNow()

2 Likes