Simplify get_block_hash() method by returning null hash

[chfast]

Continuation of changes in #154.

Reverts #73.

[chfast]

@gumb0 @axic, this one is up to discussion. For me both variants are ok. We can treat this as an experiment.

[gumb0]

I'm fine with this, I think it's nice to be consistent with functions in #154 and it might simplify calling code in VM.

[gumb0]

These names bytes32 & uint256be look too much as type names, it confuses me a bit every time.

[chfast]

That's the intention. I have to do hard-core function pointer casts in Go, because cgo (Go's C tool) does not support const types. Then whenever I change the EVMC part there is no error in Go bindings.

In this "fake" function I'm using the function pointer before case and the one after with exactly the same arguments and return types so this detect almost all mismatches (because non-const types bind to const ones).

[gumb0]

"for which", "in which" maybe? Or maybe just call it "null bytes" for get_block_hash, too

[gumb0]

"signalled" and comma before "then"

[chfast]

This has been rebased. Any comments about the design?

[chfast]

Use cases

1. Contract asks about "recent" block hash (default use case). The VM can pass the request to the Host safely and put the result on the stack.
2. Contract asks about a future block hash. The VM can pass the request to the Host safely and will get the null hash and/or an error.
3. Contract asks about an old block hash. The VM cannot pass the request to the Host because the block might be available but BLOCKHASH instructions should put null hash on the stack anyway.

Possible VM implementations

1. The VM checks if the requested block is in the safe range (256 recent blocks). Only then asks the Host. VM does not expect to get the error / null hash in return.

• https://github.com/ethereum/aleth/blob/master/libaleth-interpreter/VM.cpp#L1092-L1099
• https://github.com/ethereum/go-ethereum/blob/master/core/vm/instructions.go#L547-L552

2. The VM asks the Host first. When error is received it puts null hash on the stack. If the requests is successful it check it that's not an old block and nulls it if it is.
   This variant at least does requests when they are not needed.

Conclusions

• The first implementation is better.
• In the first implementation is slightly better when the Host returns null hash instead of an error.

// Variant with error:
bytes32 hash;
bool success = host->get_block_hash(&hash, number);
assert(success);
if (!success)
    hash = {};  // Make is deterministic.
stack[0] = hash;

// Variant with null hash:
bytes32 hash = host->get_block_hash(number);
assert(hash != {});
stack[0] = hash;

[axic]

I'm still strictly against this change. Would have preferred not merging it.

[axic]

Contract asks about an old block hash. The VM cannot pass the request to the Host because the block might be available but BLOCKHASH instructions should put null hash on the stack anyway.

This applies to EVM, but nothing else. The main point of the #73 change was that hera wouldn't need to do black magic (checking if get_block_hash returns the null hash) to exhibit special behaviour.

I think this change makes sense if EVMC guarantees that in case of an error the null hash is returned. Which it currently doesn't do.

[chfast]

in case of an error

What kind of error?