1

In https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol the function detecting contract 

function isContract(address account) internal view returns (bool) {
    // According to EIP-1052, 0x0 is the value returned for not-yet created accounts
    // and 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 is returned
    // for accounts without code, i.e. `keccak256('')`
    bytes32 codehash;
    bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;
    // solhint-disable-next-line no-inline-assembly
    assembly { codehash := extcodehash(account) }
    return (codehash != accountHash && codehash != 0x0);
}

The comment says that there is a distinction between not-yet created accounts and account without code. I don't understand it, I thought all the possible accounts are already technically created just their balance and code are 0, resp. empty in the beginning.

Improve this question
3
  • 1
    I tend to agree. It's actually more of a matter of terminology whether you call it "already technically created" or "already technically exists" (which is what I would use). Also, I wouldn't use the word "empty", because even when an account "has code and/or balance", it's not exactly "in the account", but rather "ascribed to the account" (again, a matter of terminology). Obviously, EIP-1052 implies something that you and me are both unaware of, so I suggest reading it (and perhaps even pasting the relevant section of it here). – goodvibration May 12 '20 at 13:37
  • I wasn't even aware of extcodehash. It could be a new feature, added in solc 0.6.x. – goodvibration May 12 '20 at 13:39
  • 1
    Checked; it was added in solc 0.5.0. – goodvibration May 12 '20 at 13:59
1

Although from a theoretical point there are similarities between non-existent accounts and an account without bytecode, both behave similarly when they are the recipient of a transfer. From a practical point of view there are important differences.

A non-existent accounts cost nothing, it doesn't exist yet. On the other hand a non-empty account without bytecode requires allocation in the Ethereum World State and it has the be kept around forever.

Another place where it is useful to distinguish between a non-existent account and an empty account is during a contract's constructor execution. Contract exists and can make calls to others but its bytecode will not be assigned until the constructor finishes.

Improve this answer
1

The answer is in the specification of eip-1052:

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

And if we follow to the of specification of eip-161, then we find out that:

  • The nonce of a non-existent account is set to the "normal" value (typically 0)
  • The nonce of an existent (possibly empty) account is higher than the "normal" value

So in short, my understanding is that once you make the very first transaction to or from an account, it changes from non-existent to empty.

Improve this answer
3
  • thanks, but the nonce is only the number of sent transactions, so if an account didn't send any transaction, hence nonce 0, but received a positive value (or zero value, does it make a difference?) transaction, would this account still be considered non-existant? I did try to read EIP-161 but couldn't find the information to answer this. – Anh Dũng Lê May 12 '20 at 14:03
  • @AnhDũngLê: I don't feel that this answer is correct, because: – goodvibration May 13 '20 at 6:20
  • 1. The specification of eip-161 linked above states that an account is considered empty when it has no code and zero nonce and zero balance, so my interpretation of empty is not correct. 2. This specification states that an account is considered dead when it is either non-existent or empty, but it doesn't really bother to explain the meaning of non-existent anywhere. 3. This related discussion states that "there is no longer a meaningful difference between emptiness and nonexistence from the point of view of EVM execution". – goodvibration May 13 '20 at 6:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.