Proposal: Allow access to L1 block hash

Proposals
1

Title – Proposal: Allow access to L1 block hash on Arbitrum

Constitutional / Non-Constitutional - Constitutional

Abstract - Allow access to L1 block hash using precompile or opcode on Arbitrum. The L1 block hash can be included in the Arbitrum block’s header similar to L1 block and timestamp.

Motivation - L1 block hash can enable accessing data on L1 or other L2s. Ability to have L1 block hash on Arbitrum in a trustless way can enable novel cross-chain use cases with improved security.

Rationale - Currently applications that require access to data from L1 or other L2 chains have to use oracles which usually derive security from 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 Arbiturm can help with this.

Key Terms (optional) - N/A

Specifications -
The ArbSys contract should accept calls using getL1BlockHash() and returns back a recent L1 block hash which is present in the block header of the arbitrum block.

function getL1BlockHash() external returns (bytes32);

Steps to Implement -

  1. Include a recent L1 block hash on arbitrum’s block header
  2. Add a function to ArbSys to retrieve L1 block hash

Timeline - TBD
Overall Cost - TBD

Additional Information - I’ve recently worked on a PoC of reading L1 data on L2 at EthGlobal Paris. The problem statement is that gnosis safe has to be deployed and managed on all the chains independently. Hence, this project keeps the source of truths of gnosis safe signers on L1 and on L2 it uses the state of L1 without using a trusted bridge. Here is the GitHub link GitHub - zemse/sunflower: 🌻 use L1 multisig owners to sign on L2 multisigs using zk proofs. I have created a proposal here on Arbitrum forum so that trustless cross-chain applications would be able to build on Arbitrum too.

2

Hey! Couple thoughts here

  1. It would be good to discuss what API here would be ideal. For example, the API you suggested that would just return the latest block hash would lead to transactions carrying state proofs potentially regularly being invalidated when the latest l1 block hash is updated or require an extra pre-commit tx vs for example vs an API that allowed access to a number of recent block hashes. Generally speaking once an API is committed to it’ll be locked in permanently so it’d be good to think through what’s optimal here.

  2. At a user application level the L1 block hash (or rather the previous block’s hash) can be sent up via an L1 contract to the L2 chain trustlessly over the generalized messaging bridge if desired. This approach is push based rather than automatic so would lead to block hashes that would be more out of date than a natively integrated bridge and have some increased cost, but would avoid the need to lock in a particular design at the system level. This pattern could be deployed as a public good that any contract on Arbitrum One could trust without the need for oracles.

1 Like
3

Agree with this proposal. it is easy to implement and important for self-trust data

4

I think this proposal is better to post at https://research.arbitrum.io/ for technical discussion.

1 Like
5

This would be really useful, also the OP Stack already has such functionality, maybe there are some learnings already, probably worth looking at: Smart Contract Overview | Optimism Docs