Evaluate tracking historical L1 block attributes

[maurelian]

A second feature (after #110) requested here, is to make historical L1 Block attributes available.

This issue is for tracking purposes. Brief comments are welcome below, for long form discussions, please open a Discussion and link back to this issue.

[norswap]

Should be feasible.

Some questions:

• Predeploy or precompile (it's a helluva lot of blocks to store)
• L1 does not allow accessing arbitrarily old blockhashes (only the 256 last ones IIRC)... is there a design rationale behind that?

[protolambda]

Note that after The Merge, we'll have L1 beacon-state-root and beacon-block-root accumulators. Not directly accessible in EVM yet though, that will have to wait till the next L1 upgrade.

With these, you can get the authenticated root with an EVM opcode, and then do a binary merkle-proof (SSZ) through the whole state/history. Navigate to a historical batch, then into a block, then into an execution payload, and you'll get historical state-roots (history starting at the Merge, EVM opcode only available the next upgrade after).

---

Alternatively, we could build our own state-root accumulator (and very efficiently!):

• We already process every L1 block state-root in a L2 contract
• We just need to track the witness data to keep updating the binary tree accumulator. Similar to the 32-deep binary tree in the Eth2 deposit contract.
• It can be a predeploy, mostly copy-paste from the deposit contract, that "appends" a new piece of historical data (or even integrate it into the existing L1 info predeploy!), by updating the witness data and latest root, instead of storing additional data
• We can embed a pre-computed accumulator at genesis, so all L1 ethereum history is neatly authenticated.

Then users can supply a 1024 byte proof (= 32 * 32, if we do 32 levels binary tree deep like the deposit contract) to access any L1 state-root and/or block-root.

---

Above solutions would help authenticate the L1 data, but not worth it if we want to store it in the L2 state and directly provide it (avoid unbound storage with accumulator vs improve UX by storing it)