Really cool to see this written up.
My immediate reaction is that MPBC feels very close to the collaborative block building direction State Lock Auctions was trying to point at in early 2024, but starting from the more deployable side of the design space.
The question I was trying to ask in the state lock post was not only “how do multiple parties contribute to a block?” It was more like: what synchronization primitive lets them safely collaborate at all?
My biased read at the time was that builders were pipeline stalled by uncertainty around top-of-block state. If you do not know which state is about to be consumed by the highest-value opportunity, then building the rest of the block is unnecessarily hard. So the crude idea was to expose the contentious state boundary, preserve some searcher privacy / updateability, and let other builders build around it.
I think Phil’s decentralized building phases are a useful way to place both designs. Today’s PBS market is still mostly Phase 0: monolithic actors with private views of the world. BuilderNet / TEE replicated privacy moves the system toward Phase 1: more parties can share sensitive data without trusting one operator (but only one monothlic merging algo). MPBC feels like a Phase 1.5 / early Phase 2 interface. It starts with the existing single-party block market, but adds a co-building surface around it.
State Lock Auctions were more like a rough sketch of a Phase 2 primitive. Not an endgame, and definitely not something I would defend in its exact form, but an attempt to ask what it means for multiple parties to jointly build a block while having stable assumptions about contested state.
This is where I think MPBC is directionally right but still incomplete. Append-only merging gives us multiple inclusion lanes. That is very useful for missing transactions, proposer commitments, simple transfers, and self-contained bundles. But the highest-value part of the block is usually the part where state is contentious. If co-building only works for transactions that do not touch the important conflicts, then we have improved inclusion at the edges of the block, but not yet decentralized the part of block building that matters most economically.
Maybe the simple framing is:
- MPBC gives us contribution lanes.
- State locks give us conflict boundaries.
- TEEs / commitments give us a way to make those boundaries credible.
From this POV, the operator eventually becomes less of an append-only merger and more of a temporary concurrency-control layer for the slot. Some state is reserved, some state is safe to build against, some state is contested, and builders can submit partial payloads with clearer assumptions about what will survive merging.
The part that can still go comically wrong is pricing and attribution. If a contributor adds value, who gets paid? If someone constrains state, what do they pay? If multiple builders have the same transaction, who gets credit? My old post punted with a naive cost-per-storage-slot rule, which is obviously not sufficient. The long-term shape probably needs to be contention-aware pricing: the cost of consuming coordination capacity should scale with demand for the state being constrained. In BuilderNet we tried to advance the value attribution R&D space by introducing a rules based value attribution system known as the Flat Tax Rule, which has had positive reception from some actors in the supplychain, and less positive than others. Ultimately value attribution in the presence of sybil is hard, in fact, from joint research from Flashbots and Offchain labs, the “only non-wasteful, symmetric, incentive compatible and sybil-proof mechanism is a second price auction with symmetric tie-breaking.”
Overall, I like MPBC as a serious step away from “one monolithic builder’s private view of the world.” My main push would be to treat append-only merging as phase one. The real Phase 2 target is multiple parties safely collaborating around contested state.