I wonder if a race is possible when performing a check of a return value of a call similar to eth.getCode(greeter.contractAddress) for being zero. That is, is it possible that the contract was alive during the check, but self-destructed right afterwards? I am lost with the causality rules of Ethereum.
The example call was copied from the Contract Tutorial.
2 cases: outside and inside the Ethereum Virtual Machine (EVM).
Yes, race is possible if eth.getCode is used. eth.getCode is Javascript and is outside of a contract and the EVM. So after eth.getCode, the next block that your Ethereum client receives, could have a transaction that invoked selfdestruct on the (greeter) contract.
No, if within the EVM in a single transaction, because statements are sequential and there's currently no parallelism (as @Sebi mentions). The EVM equivalent would be to use extcodesize or extcodecopy. Control flow within the EVM is deterministic.
Yes, race is possible if more than one transaction is used. Within the EVM, it is important to be aware that miners have full control of how transactions are ordered within a block. Transaction Ordering Dependence (TOD) is mentioned in this paper and TOD contracts will usually have a security issue. If a contract C performs extcodesize for contract D in one transaction, and then performs some action in another transaction (assuming that contract D still exists), then C is vulnerable to an attack: a transaction that does selfdestruct on D, could be inserted between the 2 transactions of C.
No, each call to the contract is serialized (there is (currently) no parallelism in Ethereum); each node executes a call (transaction) to the contract sequentially and then relays the result (the block containing the contract with the updated state) back to the network.
