RIP-7859: Expose L1 origin information inside L2 execution environment

This proposal defines a contract interface for exposing inside the L2 execution environment information about the L1 block that the L2 most recently included bridge inputs from- the so-called “L1 origin”.

This view is useful to any contract on the L2 that needs to verify arbitrary L1 state, storage, transaction, or receipt data inside the L2. It can be used for verification in cross-L2 communication such as RIP-7755, for enforcing L2 consistency checks such as RIP-7789,
and for verifying reads from the L1 such as RIP-7728 and ERC-3668.

This proposal includes an interface for exposing L1 origin info and invariants rules on the meaning of that L1 origin but does not prescribe a specific underlying implementation. The goal is to be able to support a common interface across rollups with differences in implementations.

Link to the latest PR:

1 Like

I would absolutely love to see this adopted - nice job! Do you think there’s merit in generalizing the interface to reference a “parent chain” instead of specifying “L1”? As we end up with L3s and beyond, it would be useful to allow higher level chains to adopt this as well. Or if trying to also leave support for directly accessing L1 block data from within an L3, maybe a “layer” parameter could be worked into the interface to keep it simple.

Also, tiny nit but the interface has a return value with the wrong name

- function getL1OriginParentBeaconRoot() external view returns (bytes32 blockHash);
+ function getL1OriginParentBeaconRoot() external view returns (bytes32 beaconRoot);
1 Like

Yeah I think it is a good idea to generalize it to a parent-child relationship vs L1-L2! The intent is definitely for this to be supported at higher layers.

Directly supporting views of lower-than-parent layers is a good idea too, since it would make it cheaper to verify claims of those layers’ state vs the current approach where you need to e.g. use the L2 view inside the L3 to prove the L1 view inside the L2. This will complicate things a little bit for a L3+ sequencer as they will need to perform some introspection into their parent layer to (recursively, if we get to L4+) extract information about the lower layers’ “origins”.

Thanks for catching the interface typo. Will make a PR to fix that and switch to using the parent-child naming. I will give some more thought on how best to support lower layer views and I’m curious what your opinion is on the tradeoff there.

We have implemented PoC for this RIP in the rollup-geth project: Rip 7859: Store L1 Origin Information by dipkakwani · Pull Request #30 · NethermindEth/rollup-geth · GitHub Any feedback regarding the implementation is welcome :slight_smile:

More about rollup-geth here: Introducing rollup-geth

3 Likes

This is great! Can we reference this from the RIP as an example implementation?

2 Likes

Yes sure, please feel to reference the PR!

1 Like