Mark Tyneway

Looks like a flake in the e2e tests ``` === FAIL: op-e2e/system/altda TestBatcherConcurrentAltDARequests (18.09s) concurrent_test.go:76: Expected at least 10 transactions from the batcher setup.go:424: CLOSING service.go:289: INFO [10-18|17:10:21.002] Stopping Proposer...

> > Looks like something is wrong with the `op-deployer-integration` > > ``` > > Caused by: Error response from daemon: Conflict. The container name "/kurtosis-fluentbit-configurator" is already in use...

Some additional notes on the problem: - https://hackmd.io/@clabby/HkbN4CBkke - https://gist.github.com/protolambda/4269a1c54ccccf77580e5fc03c8099a4

Allowing the sequencer to control the timestamp will mean the timestamp will need to be batch submitted. This could be optimized by submitting a timestamp diff rather than the full...

Another consideration here is "lazy block production". It should be possible for a sequencer to build blocks more slowly if they are not seeing a lot of throughput. Decoupling the...

Some thoughts on the design can be found here: https://www.notion.so/oplabs/Interop-Reasoning-about-Cross-Safety-Management-and-Reorgs-65f2d84c663947e88acfdb7a3023e91b

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...

/ci authorize https://github.com/ethereum-optimism/optimism/pull/16397/commits/3fb21804dbeb3f73ee5158f2f01f3afa6785d0d2

> Likely need to rebase this on latest develop as the naming of ci jobs changed. Just rebased this

/ci authorize [5b93847](https://github.com/ethereum-optimism/optimism/pull/16397/commits/5b93847bbf64367ee4a64eea1e112137aee49dd5)