-
Notifications
You must be signed in to change notification settings - Fork 29
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
Comments
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. |
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 |
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. |
Maybe noob question but I still don't understand what is the needed infrastructure at the rollup level?
|
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? I'm still new to these considerations, thanks for bearing with me |
I would see it as enforced by L2 verifiers, which already necessarly have a read access to L1 to check the settlement contract. |
Could I ask:
|
At least all
Exactly right, using
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. |
Thanks! Who is using this in production today in Optimism or the Opstack in general? |
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? |
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.
Some features that this would enable are proving L1 oracle feeds into L2 or proving ERC20 balances into L2.
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? |
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. |
What can we do to move this issue forward? |
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.
The text was updated successfully, but these errors were encountered: