External Block Production Sidecar

[dmarzzz]

Description

This document proposes a sidecar to op-node for requesting block production from an external party.

Tests

No tests have been added, but the Software Maintenance section details a path to incorporating in standard OP Stack e2e testing after an initial trial.

Additional context

By decoupling the block construction process from the Sequencer's Execution Engine, operators can tailor transaction sequencing rules without diverging from the standard Optimism Protocol Client. This flexibility allows individual chains to experiment on seqeuncing features, providing a means for differentiation. This minimum viable design also includes a local block production fallback as a training wheel to ensure liveness and network performance in the event of local Block Builder failure.

Metadata

• This work started with this PR in the spec repo but has been moved here as the work is experimental

[tynes]

Generally in favor of this approach. There is a thought that eventually we will want to embed the EL and CL in a single binary when we are trying to push the gas limits and block times. Using the proxy approach works great for now, enables teams to work in parallel without blocking each other on code review/merge

Would be super curious to see if you have a link to the proxy that you are working on. This would be really nice to include the proxy and config to spin up the system in the kurtosis OP Stack package so that people are aware that it exists and can play around with their own builders on a devnet

[ferranbt]

We have an experimental version in Go here and a more production-ready version in Rust here.

[dmarzzz]

Additionally our goal with the rust version is to migrate it to a reth module/extension so that should totally work in the single binary world in the event this isn't merged upstream by then

[odyslam]

Hey @dmarzzz @tynes we are building our solutions based on the experimental Local Builder API PR, assuming that it would get merged eventually.

Does that mean that the sidecar approach is the preferred method for now instead of the other spec? If yes, that means we should change our approach to interface with the proxy here and not expecting the API support, is that correct?