Store historical block hashes in a contract, and modify the BLOCKHASH (0x40) opcode to read this contract.
1 Like
Big fan personally, because it would make it so https://github.com/Keydonix/uniswap-oracle/ could work over longer periods of time than 1 hour.
While itâs probably ok to have this list be ever increasing in size, given we currently have a 256 block limit on block hash it seems sensible to put an upper bound on the history stored. That should be as simple as using sstore(HISTORRY_STORAGE_ADDRESS, block.number - 1 % 256, block.prevhash) for storage and sload(HISTORY_STORAGE_ADDRESS, arg % 256) to load, preserving the current checks that arg < 256.
We could still increase the limit from 256 if desired but avoiding the assumption that history will be available indefinitely seems wise, especially since the ETH2 history only preserves a limited range and itâs unlikely that ETH1 will be moved into ETH2 within that timeframe (~13 hours). Otherwise we risk it becoming a backwards incompatible change when moving to ETH2 or being stuck storing unlimited block history forever.
This EIP doesnât mention any repricing of BLOCKHASH. Seems to me that the current 20(?) will be far too low, seeing as this will have to traverse a (with time) pretty large trie.
After this I had a few discussions and it seems having the blockhash in state, but not in a contract/account, is what would work the best with witnesses and transaction packaging. If it is part of an accountâs state, then witnesses have to have a special case for this account or it would not be easy for ârelayersâ to batch and update witnesses for the blockhash.
By having it in the state I mean to store its root in the block header and keep it separate to the account trie, similar to historical hashes on the beacon chain.
Interesting. It would definitely reduce the âwitness-churnâ, and one could imagine having a BLOCKROOT opcode to retrieve the cht-root. That type of solution could, if given a (number,hash) check if itâs in the history, whereas the proposed 2935 is more powerful; given a number, it could look up the hash.
Dunno enough about the indended usecases to know whether thatâs sufficient or not.
Actually that is a good question, what are the intended use cases:
-
I would think many still use it as a terrible source of randomness. Which is discouraged.
-
For creating proofs, one can definitely expect the sender to provide their expected root hash (supposedly they compare that against what
BLOCKHASHreturns) and it would not be unheard of to ask for the appropriate block number too. So I think a system likeBLOCKROOTwould not hinder the use cases where a proof is validated.
Is there any other use case out there?
Although⌠this would also suffer from the same churn. Say you provide hashes 15 root elements, and a few more hashes along the way to prove your BLOCKHASH. And ship that off in a transaction⌠Well, whether it goes into block N or N+1 will make all the difference whether your proof is valid or not.
Btw, sidenode: geth uses chts, both hardcoded (we update the cht when we make new releases) and in contract-form (which we submit new cht signatures into around the time of releases). Those cht:s are in certain section sizes, of 32768 blocks. See https://github.com/ethereum/go-ethereum/blob/master/contracts/checkpointoracle/contract/oracle.sol
One use case to consider is an âintrospection engineâ that allows contracts to consider assertions about any past state. Similar to verifying a fraud proof against optimistic rollup data, but more generalized. It becomes possible to trustlessly look at any blockchain data from inside EVM.
For this use case, the block number and block hash are known when making the transaction, so it would work fine even if the block hash can only be verified in EVM rather than queried. Itâs just proof validation.
One use Iâm exploring for such introspection engine is trustless blockchain read access through a network of staked nodes. A client would be able to query the history (at cost), get a signed reply, and be able to verify it with other staked nodes who would be able to slash any node that provided clients with bogus history. That makes ultra-light clients quite easy to implement.
1 Like
By having it in the state I mean to store its root in the block header and keep it separate to the account trie, similar to historical hashes on the beacon chain.
This is indeed how itâs done on eth2. The challenge I see is just that on eth1 this would be more challenging to implement, requiring a whole new data structure etc etc. Whereas the storage-based solution is much more surgical and non-intrusive. Any opcodes would just seamlessly migrate from being based off of the eth1 blockhash store to being based off of the eth2 blockhash store.
Suggested minor fix:
Implementation in Nethermind:
I am suggesting the cost of SLOAD (800) instead of the cost of BLOCKHASH (20) when searching.
Interesting case is - > shall we always charge 20 for the last 256 blocks or start charging 800 for everything after the FORK_BLKNUM + 256.
I suggest 800 always as we wanted to raise the BLOCKHASH cost anyway.
And the last thing -> I suggest creating an account with the bytecode of [âSTOPâ] at the BlockhashStorage address at FORK_BLKNUM to avoid the strange case where we have an account with no code but with storage. This could lead to various problems with existing behaviours.
Iâd like to argue for adding all block hashes since genesis to the history contract and not only the ones since the HF block. Otherwise if we want to build a light-client sync protocol on top of this EIP, the HF block becomes sort of a new hard-coded genesis. It should also be useful for the L2 networks stated in the motivations of the EIP.
Iâd like to argue for adding all block hashes since genesis to the history contract and not only the ones since the HF block.
Unfortunately doing large one-time state changes like that would require machinery that we donât yet have.
Iâd recommend that we just have an âuntrusted setup ceremonyâ where people run a script to generate a Merkle root of the first FORK_BLKNUM block hashes, and that gets hardcoded into all the wallets and anything else that needs to access history; anyone can run the script to check the root themselves later if they wish.
can this be done without the storage trie write? Couldnât BLOCKHASH simply be re-written to say âeither 256 blocks or since the forkâ and let the clients choose their own storage mechanism? Perhaps Kate Commitments instead? I really donât like the idea of adding an unbound merkle trie update to every block. With the miner reward and other contracts at least the trie is not mandated to grow for each block, whereas this requires one storage trie to always update.
I agree the BLOCKHASH opcode and history contract are not dependent on each other as you say, but most of the use-cases become feasible with the history contract. So ideally weâd have that even if without the BLOCKHASH opcode modification (since you can prove old blocks in EVM when you have the commitment).
whereas this requires one storage trie to always update.
If the concern is the cost of this update, canât the tx base fee be increased to account for it?
Good talk by @tkstanczak.
Regarding the comment about not feeding prehistory (block hashes from before the fork) I think thatâs fine although I intend to (rarely) access prehistory in one of my contracts.
I intend to solve by running a script, after the fork, which generates a merkle tree of all prehistorical hashes, and stores the root in a contract that has a verification function. Caller would provide block number, block hash, and merkle path to prove it. The script itself will be published so anyone would be able to run it independently to verify the merkle root before trusting that contract. Since prehistory never changes after the fork, you only need to run it once.
Storage is O(1), at the cost of merkle verification on every access. Probably a reasonable trade-off for those rare cases where a contract needs to access ancient blocks.