RIP-7728: L1SLOAD precompile

[thegaram33]

@wminshew

Is this still an issue w based rollups? [sorry if naive question … still learning]

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.

[thegaram33]

@SanLeo461

With static calling, an L3 could call to the L1 via a contract chain. L3 static calls the L2, L2 static calls the L1.

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.

[thegaram33]

@dror

My suggestion: Extend the accessList (EIP-2930) transaction field, to pre-fetch not only EVM state slots but also L1 slots.

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.