distributed block building (and exploring the builder design space, broadly)

was chatting with @obadiaa and we wanted to open an issue here to serve as a place for discussion around distributed block building. I'm hoping this can serve to kickstart the conversation

---

there is a *large* design space here but the high-level idea follows:

the `mev-boost` architecture (cf. https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) suggests a healthy competitive landscape of many agents referred to as "builders" who produce valuable blocks for consensus proposers. these builders are able to produce more valuable blocks compared to other agents on the network because they specialize in extracting mev. this specialization implies an economy of scale that exerts a centralizing tendency on the protocol which threatens censorship-resistance and harms the overall resilience of the network.

to address this concern, we would like to research alternative builder designs beyond the monolithic, centralized builder design we will likely see at the start where a builder has a view of the public mempool (and possibly a separate private mempool for searchers) and tries to build the best block they can. a wealth of builder designs will hopefully ensure healthy competition amongst builders so that we get back pressure against any centralization risk.

one class of designs involves "distributing" the building task across many nodes. some orchestrating "scheduler" would be in charge of shipping updates to each subgroup of nodes who then work in parallel to build blocks. a clear subdivision here is to have a "cluster" for each leaf in the block tree so that a builder is responsive to any valid request a proposer may have for a block. an interesting refinement (and this is where some cool research could happen imo) is to pipe protocol data into this builder network so that building becomes an online, iterative process (refer to this article for context on the type of computing I mean: https://en.wikipedia.org/wiki/Stream_processing). For example, you could send each attestation a set of "sentry nodes" observes in real-time from the public network into the distributed builder set and compute the LMD-GHOST fork choice in real time -- using the output to load balance available building resources to one tip of the chain or the other.

another important note: this pattern can or cannot be "logically" distributed so that the group of nodes involved are under the control of a single entity wrt the protocol or not. if a single entity controls this distributed build process then it can be viewed as a scalability technique (hopefully to produce more profitable blocks) and if multiple distinct entities are involved then the build process can be seen as a substrate for a "decentralized" builder (imo the "holy grail" of this line of mev research).

I haven't thought too much about this topic beyond what I've put here but happy to chat more if anyone is interested; I'll come back to update with anything interesting I come across