RIP-7859: overhaul -> Expose L1 origin information inside L2 execution environment #57
Conversation
i-norden
force-pushed
the
ian/expose_l1_info
branch
from
33490cd to
494e520
Compare
i-norden
changed the title
i-norden
force-pushed
the
ian/expose_l1_info
branch
2 times, most recently
from
16608b6 to
258e3dd
Compare
i-norden
force-pushed
the
ian/expose_l1_info
branch
from
258e3dd to
ce781c8
Compare
| `[l1Origin.block.height, l1Origin.block.stateRoot, l1Origin.block.transactionRoot, l1Origin.block.receiptRoot]`. | ||
| This is smaller than the 708 byte preimage of a full execution header and smaller than an SSZ proof for a Merkle tree | ||
| with depth of 3 or greater (160+ bytes). | ||
| Taken together, we believe that it would be best to both support L1SLOAD and expose an `L1_ORIGIN` view inside the VM. |
There was a problem hiding this comment.
I agree. Once a rollup supports L1_ORIGIN, supporting L1SLOAD should not be too hard, since nodes already have a consistent view of L1.
| Correct `L1_ORIGIN` selection and storage in the contract underlying the `L1OriginSource` interface must be enforced at | ||
| rollup settlement time according to the invariant rules. This is accomplished by these rules being part of the |
There was a problem hiding this comment.
There's a subtle challenge here (though it's an implementation detail): If a rollup is not finalizing for a long time, it might lose its ability to read the L1 historical block hashes during settlement. EIP-2935 makes this unlikely but it can happen, so rollups need to devise a mechanism to "fill the gap" of L1 block hashes from the last known hash.
There was a problem hiding this comment.
Completely agree. In the original state of this RIP the goal was to make the EIP-2935 buffer size configurable, potentially extending it past the 8191 size, on a per-rollup-basis according to what the average settlement frequency is, but even then settlement could be delayed for various reasons like you say here.
|
Hey @i-norden, do you want to raise this for discussion on tomorrow's Rollcall? ethereum/pm#1216 |
…eaning inside the context of an L3
|
Thanks for the review @Thegaram! I added a link to the magicians thread for further discussion. I did not make it to the rollcall yesterday, but perhaps we can discuss it at the next one? I also added changes related to @edfelten's comments on the Jan 29th L2 Interop Working Group concerning the meaning in the context of an L3 and more careful use of "derivation/derive". |
This is an update to RIP-7859 that performs a major overhaul in light of @tynes' comment here. This RIP now defines the interface for accessing L1 info and rules for the meaning of L1 info, rather than stipulating a specific underling EIP-4788-like ring buffer implementation.
EIP-2935 portions of this RIP have largely been removed as I believe