Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
Why are contracts limited to only the previous 256 block hashes using the BLOCKHASH opcode (and corresponding functions in Solidity and Serpent)?
Why does another contract, such as this, need to be used to get block hashes more than 256 blocks ago? Also, how was the 256 limit determined and are there any plans on adjusting it? (Increasing it would still preserve backwards compatibility.)
According to Vitalik Buterin here:
The constraint is to preserve a property that history is irrelevant past a certain point and state is all that matters; it improves efficiency and code simplicity for many kinds of nodes.
The 256 block limit is also mentioned in the Ethereum Yellow Paper by Gavin Wood at page 25.
I would argue that an on-chain service via a contract to perform this task, such as the one you linked to, is sufficient for getting block hashes beyond the previous 256. Ethereum's vision as a platform is to be general and enable building decentralized services, so many of the aspects of the design may not cater to features such as complete block hash history. This may be because doing so would open the door to less generalization and more complications/bugs, besides setting a precedent of adding features to facilitate certain needs or use cases.
I want to share one scalable solution to accessing historical block hashes on-chain that we’re using in Relic Protocol. We store Merkle roots of chunks of historical block hashes in storage, and use zk-SNARKs to prove their validity.
For reference, see https://github.com/Relic-Protocol/relic-contracts/blob/2ecb2ffdd3a450a8eb7c352628c2ef51ed038c42/contracts/BlockHistory.sol
This is already deployed on mainnet, and we'll be releasing a developer SDK for integrations shortly.
