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

[ralexstokes]

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

[ralexstokes]

may be worth another issue but also would be keen to explore, research, discuss advanced algorithms for block building along the lines of hardware acceleration w/ GPUs, FPGAs, ASICs, etc.

[ralexstokes]

as far as this issue is becoming wiki/documentation, there are likely a lot of interesting builder designs involving threshold cryptography or MPCs for distributed building.

we can take an analogy to distributed (validator) staking pool designs: https://github.com/ethereum/distributed-validator-specs

and wonder if we can apply this technique to building.

open research question bc this implies you immediately have a large state (literally the ethereum execution state) inside the shielded context which harms performance but one of you reading this may have some mathematical magic up your sleeve :)

[ralexstokes]

I may start organizing this somewhere else so this issue isn't just meandering brain dump but:

was talking with @pkopparla and we came to a nice technique that could facilitate building: access lists a la EIP-2930.

this may make sense to do extra-protocol, i.e. in a private mempool like the flashbots auction product, but essentially you want to demand the read/write sets for a given transaction to come with the transaction. this greatly simplifies parallelization when working to simulate/execution EVM effects.

you could imagine an "ingestion" tier of nodes that just verify the access lists and then handing this off to an inner tier of nodes that handles execution (over disjoint combinations of state access) when trying to find the most profitable block