AlertSourceDiscuss
Skip to content

EIP-210: Blockhash refactoring

🚧 StagnantCore

Stagnant

This EIP has had no recent activity for at least 6 months, and has automatically been marked as stagnant. This EIP should not be used in production.

If you are interested in helping move this EIP to final, create a PR to move this EIP back to Draft and add yourself as an author, and an EIP editor will help guide you through the process. Thank you!

AuthorsVitalik Buterin (@vbuterin)
Created2017-02-10

Summary ​

Stores blockhashes in the state, reducing the protocol complexity and the need for client implementation complexity in order to process the BLOCKHASH opcode. Also extends the range of how far back blockhash checking can go, with the side effect of creating direct links between blocks with very distant block numbers, facilitating much more efficient initial light client syncing.

Parameters ​

  • CONSTANTINOPLE_FORK_BLKNUM: TBD
  • SUPER_USER: 2**160 - 2
  • BLOCKHASH_CONTRACT_ADDR: 0xf0 (ie. 240)
  • BLOCKHASH_CONTRACT_CODE: see below

Specification ​

If block.number == CONSTANTINOPLE_FORK_BLKNUM, then when processing the block, before processing any transactions set the code of BLOCKHASH_CONTRACT_ADDR to BLOCKHASH_CONTRACT_CODE.

If block.number >= CONSTANTINOPLE_FORK_BLKNUM, then when processing a block, before processing any transactions execute a call with the parameters:

  • SENDER: SUPER_USER
  • GAS: 1000000
  • TO: BLOCKHASH_CONTRACT_ADDR
  • VALUE: 0
  • DATA: <32 bytes corresponding to the block's prevhash>

If block.number >= CONSTANTINOPLE_FORK_BLKNUM + 256, then the BLOCKHASH opcode instead returns the result of executing a call (NOT a transaction) with the parameters:

  • SENDER: <account from which the opcode was called>
  • GAS: 1000000
  • TO: BLOCKHASH_CONTRACT_ADDR
  • VALUE: 0
  • DATA: 32 byte zero-byte-leftpadded integer representing the stack argument with which the opcode was called

Also, for blocks where block.number >= CONSTANTINOPLE_FORK_BLKNUM, the gas cost is increased from 20 to 800 to reflect the higher costs of processing the algorithm in the contract code.

BLOCKHASH_CONTRACT_CODE ​

The Serpent source code is:

python
with offset = 0:
    if msg.sender == 0xfffffffffffffffffffffffffffffffffffffffe:
        with bn = block.number - 1:
            while bn:
                ~sstore(offset + ~mod(bn, 256), ~calldataload(0))
                if ~mod(bn, 256):
                    ~stop()
                bn = ~div(bn, 256)
                offset += 256
    elif ~calldataload(0) >= 0 and ~calldataload(0) < block.number:
        with tbn = ~calldataload(0):
            with dist_minus_one = block.number - tbn - 1:
                while dist_minus_one >= 256 && ~mod(tbn, 256) == 0:
                    offset += 256
                    tbn = ~div(tbn, 256) 
                    dist_minus_one = ~div(dist_minus_one, 256)
                if dist_minus_one >= 256:
                    return(0)
                return(~sload(offset + ~mod(tbn, 256)))
    else:
        return(0)

The EVM init code is:

0x6100f58061000e60003961010356600073fffffffffffffffffffffffffffffffffffffffe33141561005857600143035b801561005257600035610100820683015561010081061561003f57005b6101008104905061010082019150610022565b506100f3565b600060003512151561006e574360003512610071565b60005b156100e7576000356001814303035b6101008112151561009857600061010083061461009b565b60005b156100ba57610100830192506101008204915061010081049050610080565b610100811215156100d057600060a052602060a0f35b610100820683015460c052602060c0f350506100f2565b600060e052602060e0f35b5b505b6000f3

The EVM bytecode that the contract code should be set to is:

0x600073fffffffffffffffffffffffffffffffffffffffe33141561005857600143035b801561005257600035610100820683015561010081061561003f57005b6101008104905061010082019150610022565b506100f3565b600060003512151561006e574360003512610071565b60005b156100e7576000356001814303035b6101008112151561009857600061010083061461009b565b60005b156100ba57610100830192506101008204915061010081049050610080565b610100811215156100d057600060a052602060a0f35b610100820683015460c052602060c0f350506100f2565b600060e052602060e0f35b5b50

Rationale ​

This removes the need for implementations to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols.

Citation

Please cite this document as:

Vitalik Buterin, "EIP-210: Blockhash refactoring[DRAFT]," Ethereum Improvement Proposals, no. 210, 2017. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-210.