RIP-7728: L1SLOAD precompile

A based rollup could automatically (implicitly) use the previous L1 block hash as the latest known L1 block hash. If the L1 and L2 block proposers are identical, then the previous L1 block hash is known to the block builder, and L2 block inclusion is guaranteed.

My concern would be in these two cases:

  1. Permissionless fallback: L1 proposer did not opt in to propose the next L2 block so someone else needs to propose it, inclusion in the next L1 block is not guaranteed.
  2. L1 reorgs automatically lead to L2 reorgs.

In these cases, the “latest known L1 block hash” is either not known in advance or might change, which can invalidate preconfs.

That makes sense, at first sight I don’t see any issue here.

And that shows that L1STATICCALL has better composability than L1SLOAD. With L1SLOAD on an L3, you might need different precompiles for reading from L1 and L2.

Great suggestion!

Indeed, the latency for each UserOp would add up which might lead to timeout.

The solution you suggested is backward-compatible in its format, but I assume we’d need different pricing / gas discounts for preloading L1 slots. That said, I don’t think it’s a very invasive change, we can consider adding it to the RIP.