Eip 210

Issue A: BLOCKHASH semantics

@vbuterin’s intent when writing the EIP was that the BLOCKHASH operation would still only return the most recent 256 blockhashes, and nothing older than that.

For fetching older stuff, a contract would need to CALL the contract.

Alternative one:

Modify the EIP to make it clear that BLOCKHASH retains the earlier semantics.

Consequences:

• If so, clients do not necessarily need to modify anything regarding BLOCKHASH, except raising gasCost.
• Since contracts will CALL the contract, perhaps it should be made ABI-compatible.
  • Either via ignoring the first 4 bytes, allowing any signature
  • Or explicity expecting signature blockhash(uint256)

Alternative two:

Don’t modify the EIP, use it as written.

Consequences:

• Changes blockhash semantics (but more useful)
• Makes actually CALLing the contract totally unnecessary (why would anyone ever do that?)
• Forces clients to modify BLOCKHASH

Issue B: Genesis lookup

Should we add support for the contract to return the genesis hash?

Consequences:

1. Would complicate contract creation a bit

• Either via stuffing the genesis hash into the contract code
• Or via setting genesis hash in storage

2. Would increase runtime cost a bit