ethereum-optimism / ethereum-optimism/optimism
Sequencer: Derive L1 origin and attributes asynchronously
- Dominant language
- Go
- Stars
- 6.5k
- Forks
- 4k
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 145
Description
**Is your feature request related to a problem? Please describe.**
The sequencer synchronously determines the [next L1 origin](https://github.com/ethereum-optimism/optimism/blob/9179225da1e0b594686c16d5d8101fa7e03a013f/op-node/rollup/sequencing/sequencer.go#L490) and its associated [payload attributes](https://github.com/ethereum-optimism/optimism/blob/9179225da1e0b594686c16d5d8101fa7e03a013f/op-node/rollup/sequencing/sequencer.go#L509C30-L509C54) as part of the block production process even though this is not particularly time sensitive with a large max sequencer drift tolerance. This means that blocking L1 RPC calls may significantly slow down or prevent block production in the worst case, while still consuming some of the sequencer's block time (typically 2 seconds) even in the best case.
**Describe the solution you'd like**
The L1 origin should be derived asynchronously and concurrently with respect to L2 block production, and this origin should only be selected if the payload attributes for this origin have also been derived.
Practically speaking, we can attempt to derive both of these pairs of L1Origin and PayloadAttributes in parallel each time the fork choice is updated, and then select the "best" origin when we start building the next block. We will need to select the next origin if and only if the max sequencer drift has been exceeded. In all other cases, it should be fine to fall back to the existing origin in order to avoid delaying block production.
**Describe alternatives you've considered**
We may wish to implement the L1Origin and PayloadAttributes generation as a single [Deriver](https://github.com/ethereum-optimism/optimism/pull/11099) or even two Deriver's (AttributesWIthNextOrigin and AttributesWithCurrentOrigin), or perform these concurrent derivations as a subroutine within the sequencer.
**Additional context**
Add any other context or screenshots about the feature request here.
Contributor guide
Research direction
Start with op-node/rollup/sequencing/sequencer.go at the linked next-L1-origin and payload-attributes logic, then review the Deriver approach referenced in pull request 11099. Done means deriving both candidate origins and attributes asynchronously, selecting the next origin only when drift requires it and its attributes are ready, and otherwise preserving the current-origin fallback without delaying block production.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100