Add .exists() and .iscontract() on to the address type

[axic]

Not fully sure yet if .exists() can be implemented properly, but .iscontract() should be possible to be implemented via the extcodesize instruction.

With having .iscontract(), #4823 would not need to be implemented.

[frangio]

What would be the semantics of .exists()?

[axic]

.exists() probably should be postponed until there is a consensus on what that means in Ethereum, however when looking at the account cleanup rules during creation/selfdestruct/etc. should be a good indication.

I actually don't think this can be done properly without support form a new EVM opcode, because one could check for balance and code size, but cannot check for storage, which is possible to be non-empty if the account is only used through delegatecalls.

[wadealexc]

I would be cautious of any implementation of .iscontract() -- the whole idea of testing iscontract has led to lots of contracts vulnerable to exploits done by constructors

[axic]

Actually it seems that .iscontract() could be implemented by just using extcodehash.

[axic]

.exists() can be clearly implemented post Constantinople, because EIP-1052 for EXTCODEHASH clearly defines it:

In case the account does not exist or is empty (as defined by EIP-161) 0 is pushed to the stack.

From EIP-161:

An account is considered empty when it has no code and zero nonce and zero balance.

Similarly .iscontract() is clearly defined with EIP-1052:

In case the account does not have code the keccak256 hash of empty data (i.e. c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470) is pushed to the stack.

[axic]

@frangio @wadealexc any change of view since these are provided by opcodes now?

[wadealexc]

Since EXTCODEHASH returns a nonzero value during the constructor, this seems fine on the surface.

[frangio]

I don't think that really mitigates the vulnerabilities that can arise from using .isContract(), because an account can pass the EXTCODEHASH test but still become a contract in the future.

We do have an isContract function in OpenZeppelin though, because some ERCs require using it. So I think I would be okay with including it in Solidity. But it needs to be used carefully.

[chriseth]

Would calling it hasCode help in any way?

[axic]

I don't think that really mitigates the vulnerabilities that can arise from using .isContract(), because an account can pass the EXTCODEHASH test but still become a contract in the future.

Are we making commitments in the language that a property of an account in the state cannot ever change? 😉

@frangio Could you elaborate this sentence?

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

[axic]

This would become very useful in conjunction with ethereum/EIPs#8838

On non-EOF targets it could fallback to extcodesize/extcodehash.