optimistic-specs
optimistic-specs copied to clipboard
ethereum-optimism
Make L1 block headers available in the execution context
It would be useful it Optimism provided access to L1 block headers similar to L1 Block Number. https://github.com/ethereum-optimism/optimism/blob/f4cf99e34b9d06f20335eece5dc84e10fdbeb8cc/packages/contracts/contracts/L2/predeploys/iOVM_L1BlockNumber.sol#L12
In particular, making the last n state roots available on optimism would enable contracts to easily prove and operate on layer 1 state without any interaction from the base chain.
So in contrast to getL1BlockNumber(), an optimal solution would probably support getL1Header(uint256 n) so it is possible for a client to generate a storage proof that interacts with a particular recent layer 1 block header.
Optimism v1.0 will have the block hash, which would enable proving a state root: https://github.com/ethereum-optimism/optimistic-specs/blob/701b494896469a0cf31835bb422528caa93d3683/packages/contracts/contracts/L2/L1Block.sol#L18
Optimism v1.0 will have this: https://github.com/ethereum-optimism/optimistic-specs/blob/701b494896469a0cf31835bb422528caa93d3683/packages/contracts/contracts/L2/L1Block.sol#L18
Nice! Would it be possible to make the state root available? Then storage proofs are super simple. With just the blockhash, we'd need to submit the block header rlp onchain to trustlessly extract + verify the state root.
Looking more closely at the OP, you're also looking to access historical state roots, not just the latest, is that right?
Looking more closely at the OP, you're also looking to access historical state roots, not just the latest, is that right?
Yeah thats correct. Since otherwise it would be hard to coordinate a storage proof for a particular state root, since the current L1 block could change under us if not explicitly provided. I think it could be similar to how blockhashes work on mainnet.
We've been thinking about adding a history accumulator to merkleize all past L1 data together that was posted to L2. See discussion https://github.com/ethereum-optimism/optimistic-specs/discussions/235 That would enable an efficient proof to L1 activity that was previously confirmed on L2.
This is an advanced feature that may come only after initial bedrock deployment though. Block-hash will definitely be available, and latest L1 state-root probably too (if not already the case).
I think we should maybe strive to include more than the latest blockhash (e.g. last 256 or even just last 16), at least to avoid the situation where we include a proof and it becomes invalid because the latest L1 block hash changed by the time the transaction lands on L2.
