Proposal: Allow access to L1 block hash on Scroll

Gm Scrollers!

L1 block hash can be made available to a contract on Scroll via a precompile or opcode. This would allow the development of trustless cross-chain applications on top of Scroll.

Currently, applications that require access to data from L1 or other L2 chains have to use messaging bridges which usually derive security from a multisig. We have historically seen events where signers can be compromised and it can pose a threat to such applications. Having L1 block hash available on Scroll can enable opening a recent state on L1 as well as other L2s since their block hashes or state roots are also available on L1.

A recent L1 block hash can be included in the block headers on the Scroll chain. This value in the L2 block header can then be made available to the L2 execution context using a precompile or opcode (TBD).

Additional Information
If the user is generating a zk state proof, the generation time can be more (about 2-3 mins) and in the meanwhile L1 block hash value in the L2 execution context may change. One can still pin the available L1 block hash in a storage variable on L2 so that it can be accessed during proof verification. During EthGlobal Paris I’ve tried to build a cross-chain gnosis safe plugin GitHub - zemse/sunflower: 🌻 use L1 multisig owners to sign on L2 multisigs using zk proofs with help of L1 block hash precompile in Optimism and Axiom’s zk circuits.

If it is possible to access few historic L1 block hashes (upto 5 mins old), there will be no need to pin the L1 block hash on a temporary contract on Scroll, hereby improving the UX while reading cross-chain data.

1 Like