Add rollup config data to SystemConfig

[maurelian]

Background

Currently, critical rollup configuration values (block_time, seq_window_size, max_sequencer_drift) are only committed on-chain within the opaque absolute prestate hash.

This issue is the result of a request made by @lucadonnoh.

This makes these values difficult to access and verify onchain.

Proposal

Make the RollupConfig parameters directly available on-chain through the SystemConfig contract, rather than only existing in the prestate hash.

This would:

1. Improve transparency of critical chain parameters
2. Enable on-chain verification of these values
3. Support future proof systems by allowing the RollupConfig to be used as a local input to the Fault Proof Program (FPP)

Scope

Parameters to expose:

• block_time
• seq_window_size
• max_sequencer_drift

Key Considerations

• These values would remain static (not dynamically updatable) in this implementation
• The values would still be committed in the prestate hash for backward compatibility
• This approach aligns with existing implementations like op-succinct, which stores a hash of the serialized rollup config on L1

Non-Goals

• Making these parameters dynamically updateable (would require significant additional complexity)
• Removing these values from the prestate hash
• Changes to L1 info transactions

Open Questions

• Should we include any additional parameters beyond the three identified?
• What's the best way to verify these values match the prestate hash during deployment?

[tynes]

I am in favor of this and have attempted to propose this before. I would like to see the op-node fetch these values dynamically rather than having them hardcoded into the config. This does not imply that the values are mutable. That would break things without making the op-node be able to handle them changing.

[lucadonnoh]

For me one major advantage (other than better visibility) of op-program fetching the value from SystemConfig is that the absolute prestate would need to change less often. We review a ton of OP stack chains and we currently don’t assess op-program because it’s a lot of work, but we want to start doing so, and we would maintain a list of absolute prestates that we know and trust. If a new chain uses an absolute prestate that we’ve already assessed we don’t need to do any more work, and unknown prestates are by default untrusted. I know that this might sound like an L2BEAT specific issue, but it’s actually about self verification in general.