Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RIP Idea: L1 Blockhash Precompile #16

Open
tynes opened this issue Mar 4, 2024 · 16 comments
Open

RIP Idea: L1 Blockhash Precompile #16

tynes opened this issue Mar 4, 2024 · 16 comments

Comments

@tynes
Copy link

tynes commented Mar 4, 2024

Something that application developers continue to ask for is the ability to provide a witness that unwraps arbitrary L1 state into L2. This could be accomplished via a precompile on L2 that returns an L1 blockhash given a blocknumber. Using a precompile for this would help to standardize this flow. Before verkle, the witness size would be pretty large which isn't ideal and also having to verify MPT proofs in EVM also isn't ideal. It isn't immediately obvious what the semantics of this precompile should be given that different rollups have different architectures and we want to be mindful of L2 state bloat. This is related to EIP-2935 which I believe is a dependency of Verkle. We would want to be future compatible with using Verkle to unwrap L1 state in L2, which the Verkle proof precompile will be helpful for if L2s also adopt it.

@pegahcarter
Copy link

What if there was a pre-compiled ring buffer that stored a certain number of L1 block hashes, and at the point it restarts at the first index, it appends all block hashes to a merkle/verkle?

This would limit state bloat while providing all historical L1 block hashes on L2 at a central, trusted point.

@qizhou
Copy link

qizhou commented Apr 26, 2024

Providing a discussion on reading L1 RANDAO from L2 using L1 blockchain precompile here https://ethereum-magicians.org/t/expanding-eip-4399-prevrandao-with-randao-n/19741/6

@rdubois-crypto
Copy link
Contributor

Great suggestion.

It would be very good to be able to realize cheap Storage proofs in a standardized way on all L2s. This is the easiest way (just providing the root), maybe a precompile to directly prove the value of a slot would provide a better DX.

To solve the fragmentation of the onchain experience we need this and standardized L1<>L2 messenging.

@Eikix
Copy link

Eikix commented Jun 13, 2024

Maybe noob question but I still don't understand what is the needed infrastructure at the rollup level?
Is it:

  • a contract that stores L1 blockhashes like EIP-2935?
  • a precompile that gives L1 blockhash given a L1 block number?
  • a precompile to verify a storage proof?

@pegahcarter
Copy link

@Eikix Minimally, if we were to ignore state bloat all that required for an op-stack rollup would be to add a mapping to L1Block.sol like so. This is automatically synced through node software pushing txs within each block.

@Eikix
Copy link

Eikix commented Jun 14, 2024

@Eikix Minimally, if we were to ignore state bloat all that required for an op-stack rollup would be to add a mapping to L1Block.sol like so. This is automatically synced through node software pushing txs within each block.

Would this be trusted? You would probably need to add in the settlement system (fraud proof or proof scheme) the ability to check that the L1Block mapping matches the reality of the L1?
Or have a L1 lightclient on an L2?

I'm still new to these considerations, thanks for bearing with me

@rdubois-crypto
Copy link
Contributor

I would see it as enforced by L2 verifiers, which already necessarly have a read access to L1 to check the settlement contract.

@Eikix
Copy link

Eikix commented Jun 14, 2024

@rdubois-crypto

Could I ask:

  • Which rollup currently uses L1BlockHash as precompile / available?
  • What is the flow of using this feature for a user? (I imagine something like: verify L1 state?)
  • Which applications are made possible by this?

@pegahcarter
Copy link

@Eikix

Which rollup currently uses L1BlockHash as precompile / available?

At least all op-stack chains (link) (my experience is limited to op-stack).

What is the flow of using this feature for a user? (I imagine something like: verify L1 state?)

Exactly right, using eth_getProof. Here's an example that proves the storage behind a mapping on L1 onto L2. There are some additional helper scripts needed on the backend to fetch the proofs & run calculations- similar to proving a merkle proof.

Which applications are made possible by this?

Any app, really, because you have access to all L1 state at particular blocks. For example, you can send L1 oracle data to L2 or prove L1 token balances. One caveat, however, is the large proof size can lead to > $1 txs even on L2s.

@Eikix
Copy link

Eikix commented Jun 17, 2024

@Eikix

Which rollup currently uses L1BlockHash as precompile / available?

At least all op-stack chains (link) (my experience is limited to op-stack).

What is the flow of using this feature for a user? (I imagine something like: verify L1 state?)

Exactly right, using eth_getProof. Here's an example that proves the storage behind a mapping on L1 onto L2. There are some additional helper scripts needed on the backend to fetch the proofs & run calculations- similar to proving a merkle proof.

Which applications are made possible by this?

Any app, really, because you have access to all L1 state at particular blocks. For example, you can send L1 oracle data to L2 or prove L1 token balances. One caveat, however, is the large proof size can lead to > $1 txs even on L2s.

Any app, really

Thanks! Who is using this in production today in Optimism or the Opstack in general?

@pegahcarter
Copy link

I can only speak on my experience at Frax that we use this in prod across multiple L2s (Fraxtal, Arbitrum). Arbitrum we use to pass over chainlink values from L1.

@Eikix
Copy link

Eikix commented Jun 17, 2024

I can only speak on my experience at Frax that we use this in prod across multiple L2s (Fraxtal, Arbitrum). Arbitrum we use to pass over chainlink values from L1.

What is the most sensible way to go about it as RIP?
Unified API?

@tynes
Copy link
Author

tynes commented Jun 17, 2024

Which rollup currently uses L1BlockHash as precompile / available?

The standard config OP Stack that OP Mainnet/Base use do not have an L1 blockhash precompile. Many projects are asking for it to standardize on a single way to prove L1 state into L2.

Which applications are made possible by this?

Some features that this would enable are proving L1 oracle feeds into L2 or proving ERC20 balances into L2.

maybe a precompile to directly prove the value of a slot would provide a better DX.

I think composing together with EIP-7545 makes the most sense, this defines proof verification precompiles. So the developer would call the L1 blockhash precompile to get the blockhash and then call the proof verification precompile with the proof + the blockhash

@Eikix
Copy link

Eikix commented Jun 17, 2024

Which rollup currently uses L1BlockHash as precompile / available?

The standard config OP Stack that OP Mainnet/Base use do not have an L1 blockhash precompile. Many projects are asking for it to standardize on a single way to prove L1 state into L2.

Which applications are made possible by this?

Some features that this would enable are proving L1 oracle feeds into L2 or proving ERC20 balances into L2.

maybe a precompile to directly prove the value of a slot would provide a better DX.

I think composing together with EIP-7545 makes the most sense, this defines proof verification precompiles. So the developer would call the L1 blockhash precompile to get the blockhash and then call the proof verification precompile with the proof + the blockhash

Does that mean we should wait for verkle?

@tynes
Copy link
Author

tynes commented Jun 17, 2024

Does that mean we should wait for verkle?

No it does not mean we should wait for verkle, there are battle tested solidity libraries for proof verification that can be used in the short term, but a precompile would be much better in the long term.

@pegahcarter
Copy link

What can we do to move this issue forward?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants