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.
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);
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.
But quick questions: Does RIP-7859 expose more data (state root, transaction root, receipt root) than needed? What are the tradeoffs? Verification will be cheaper but L2 nodes must store more data than needed.
