historic-blockhashes

EIPS/eip-2427.md

@@ -0,0 +1,61 @@
+---
+lang: en
+eip: 2427
+title: BLOCKHASH2
+author: Zac Mitton (@zmitton)
+status: DRAFT
+type: Standards Track
+category: Core
+created: 2019-12-04
+discussions-to: https://github.com/ethereumclassic/ECIPs/issues/242
+replaces: 210
+---
+
+## Summary
+
+A separate `BLOCKHASH` opcode (`BLOCKHASH2`) that actually returns the blockhash no matter how old it is. The current one only allows you to specify the latest 256 blocks (or returns `0`).
+
+## Abstract
+
+There are plenty of arguments online for having access to blockhashes within the EVM. I will only quote a handful of them here. 
+
+This proposal simply it as an opcode (not a special contract type).
+
+## Motivation and Rational
+
+Layer 2 systems need this data badly. Why?
+
+There have multiple attempts to implement it (see [EIP-210](https://github.com/ethereum/EIPs/pull/210), and [multiple](https://github.com/ethereum/EIPs/issues/1218), [multiple](https://github.com/ethereum/EIPs/issues/96), [other](https://github.com/ethereum/EIPs/pull/1094), [discussions](https://github.com/ethereum/EIPs/pull/641)), but they stopped short mostly because they were attempting to do it as a contract in the EVM. This had some benefits, but the drawback was the requirement to "stuff" this contract with hashes (from before the fork).
+
+By implementing this without a special "SYSTEM" contract, we avoid the stuffing problem, and the other benefits we can have separately by adding merkle-mountain-ranges to the headers ([FlyClient](https://github.com/ethereumclassic/ECIPs/pull/145)).
+
+#### Low Level Abilities
+
+ - Accessing the blockhash within the EVM allows validation of ALL data, because literally *all* blockchain data is committed in it. 
+ - Automatic access to the 15 other elements of the header, for instance.
+ - This means provable logs (so implementers can use them instead of storage and everybody wins).
+ - Access to _historical state_. We can prove not only the current storage values, but any particular value at any particular time. Since this is inside the EVM, they can act as variables, allowing developers to optimize/reduce data structures held in storage.
+ - Interoperability becomes much more robust
+
+#### A Few Quotes
+
+>  ...[accessing] blocks with very distant block numbers, facilitate[s] much more efficient initial light client syncing.. --Vitalik Buterin
+
+> The application of verifiable off-chain computation networks such as true-bit. The on-chain verification process would in many cases rely on a specific "snapshot of state". It would not be possible to verify against a moving target. I would imagine the registration of a job in true-bit might require a specific block number, or the ability to lock in a block number once certain conditions are met. That block number would include a state-root to provide merkle proofs against during the interactive verification process. -- me
+
+> I have considered cases where logs are nearly sufficient over expensive storage. However maybe the log needs to be read in very rare cases(1 out of every million for instance). If block headers are available, it would be possible to "escalate" a log into something that can be read by a contract by presenting a merkle proof verification of its existence. - me again
+
+#### A Few Specific Applications That Would Benefit
+
+ - Relay systems between blockchains
+   - Relays like BTC relay may no longer require "constant pinging"
+ - Allows for efficient Light clients
+   - Especially when combined with FlyCLient
+ - L2 systems that have longer lock times than 256 blocks
+   - i.e. Truebit, Plasma, Raiden
+ - Systems relying on blockhashes for pseudo-random numbers, i.e. to print assets randomly (will no longer have severe time restrictions).
+
+## Specification
+
+An opcode is added (`0x46`) called `BLOCKHASH2` with the exact same functionality as `BLOCKHASH`, except that when the `blocknumber` specified is old than `256` blocks it still returns the relevant `blockhash`
+