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 -
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 https://github.com/zemse/sunflower. I have created a proposal here on Arbitrum forum so that trustless cross-chain applications would be able to build on Arbitrum too.
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 -
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 https://github.com/zemse/sunflower. I have created a proposal here on Arbitrum forum so that trustless cross-chain applications would be able to build on Arbitrum too.
It’s very odd that such huge L2 as Arbitrum still doesn’t support native blockhash oracle. This is essential point of entry for the whole mainnet storage and L2s may have it with no additional risks. We at Curve are forced to use our extra infrastructure to port data from L1.
I support this proposal. Allowing access to the L1 block hash on Arbitrum empowers developers with more robust tools for cross-chain verification and communication. This is a step towards deeper integration between L1 and L2 ecosystems. Support for research on this improvement!
Hey y'all
Following @peter's comment I've reposted this thread to research Arbitrum: https://research.arbitrum.io/t/access-to-l1-block-hash-on-arbitrum/9635
Hey y'all
Following @peter's comment I've reposted this thread to research Arbitrum: https://research.arbitrum.io/t/access-to-l1-block-hash-on-arbitrum/9635
Maybe this way can speed up the implementation of the proposed functionality. The access to L1 block hash is also crucial for us at vlayer Labs for multi-chain privacy and verifiability features. If it's still relevant for you I'd appreciate your feedback at Arbitrum research board.
This would be really useful, also the OP Stack already has such functionality, maybe there are some learnings already, probably worth looking at: https://docs.optimism.io/stack/protocol/smart-contracts#l2-contracts-predeploys
Agree with this proposal. it is easy to implement and important for self-trust data
Hey! Couple thoughts here
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.
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.
I think this proposal is better to post at https://research.arbitrum.io/ for technical discussion.
It’s very odd that such huge L2 as Arbitrum still doesn’t support native blockhash oracle. This is essential point of entry for the whole mainnet storage and L2s may have it with no additional risks. We at Curve are forced to use our extra infrastructure to port data from L1.
I support this proposal. Allowing access to the L1 block hash on Arbitrum empowers developers with more robust tools for cross-chain verification and communication. This is a step towards deeper integration between L1 and L2 ecosystems. Support for research on this improvement!
Hey y'all
Following @peter's comment I've reposted this thread to research Arbitrum: https://research.arbitrum.io/t/access-to-l1-block-hash-on-arbitrum/9635
Hey y'all
Following @peter's comment I've reposted this thread to research Arbitrum: https://research.arbitrum.io/t/access-to-l1-block-hash-on-arbitrum/9635
Maybe this way can speed up the implementation of the proposed functionality. The access to L1 block hash is also crucial for us at vlayer Labs for multi-chain privacy and verifiability features. If it's still relevant for you I'd appreciate your feedback at Arbitrum research board.
This would be really useful, also the OP Stack already has such functionality, maybe there are some learnings already, probably worth looking at: https://docs.optimism.io/stack/protocol/smart-contracts#l2-contracts-predeploys
Agree with this proposal. it is easy to implement and important for self-trust data
Hey! Couple thoughts here
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.
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.
I think this proposal is better to post at https://research.arbitrum.io/ for technical discussion.