# op-rbuilder p2p network

## 1. Intro

An op-stack network may run multiple builders for a high-availability setup (see [rollup-boost-ha](https://github.com/flashbots/rollup-boost/blob/main/docs/rollup-boost-ha.md)). In this setup, op-conductor coordinates multiple sequencer instances such that only one is sequencing and proposing at a time, and failure of an instance is handled. A sequencer consists of op-node run in sequencer mode and rollup-boost for interfacing with op-rbuilder and the local execution client.

With flashblocks, intra-block HA is not guaranteed as flashblocks are not propagated between sequencers and thus builders. Flashblocks act as a micro-chain of blocks within one block, and should be built on top of each other. Currently, one builder builds all flashblocks for a block, and if that builder fails midway, there can be no more flashblocks created for that block. Other builders cannot take over, as they are unaware of the existence of the previous flashblocks for that block and don't have their state.

## 2. Goals and requirements

The main goal is to improve the availability of flashblocks in the case of a builder failure.

Assume:
- there are multiple builders on the network
- only one builds (flash)blocks at a time; this is coordinated by an external party (op-conductor)

## 3. Design

### devp2p vs libp2p

devp2p is a legacy p2p implementation made specifically for Ethereum execution clients. libp2p is a modular p2p library used by Ethereum consensus clients, as well as op-node for propagating softly-confirmed blocks.

### p2p protocol

Since there are only a few, known builders, we can directly connect the builders to each other and do not need a discovery protocol. In the future, if we connect to another network or wish to expand the network, we can add DHT discovery.

The builders will connect directly to each other and open a bidirectional stream upon connecting. When a builder builds a flashblock, it will send this block over the stream. When a builder receives a flashblock over this stream, it will execute it and store the resulting state in its cache.

A future extension could be to propagate state diffs as well as flashblocks, so the flashblock doesn't need to be re-executed. However, this will increase bandwidth required.

### Code structure

I plan to implement most of the core code into its own crate, which will have functionality for:
- starting a p2p node (with configuration for port, listen addresses, private key)
- connecting to known peers
- configuring stream protocols with their protocol ID and message type
- opening and handling streams, receiving outgoing messages from an external channel to broadcast, sending incoming messages to an external channel for handling by the consumer

This can be done in op-rbuilder first for ease of development, as its own crate. The crate can easily be moved to rblib later if desired.

The consumer/application logic of handling the messages can be implemented inside the existing op-rbuilder crate, as it's specific to op-rbuilder.

## Notes

- https://specs.optimism.io/protocol/rollup-node-p2p.html
- https://github.com/ethereum-optimism/optimism/tree/c813b04c9bd24a9b1088ec8a8e3a7598344633ff/op-node/p2p