Distributed Block Building

Block building in Ethereum is transitioning from a single centralized block builder per slot toward a distributed network of specialized nodes operating inside Trusted Execution Environments (TEEs). Flashbots’ BuilderNET is the first production implementation. The core challenge: achieving censorship resistance and privacy at the network layer even after TEE integrity is established. (→ NoConsensus.wtf 2025 — Overview)

The Problem with Today’s Block Building (dmarz / Flashbots)

Current state (single block builder per relay):

  • Single point of failure: if the block builder or relay goes offline, order flow is lost.
  • Exclusive order flow deals: builders pay for exclusivity, locking out competitors and reducing market efficiency.
  • Geographic centralization: two relays produce >90% of Ethereum blocks, located in two geographies.
  • No user privacy: block builders see all transactions in plaintext before inclusion.

BuilderNET: Distributed Block Building in Production

BuilderNET (Flashbots) is a live production system (as of August 2025) implementing distributed block building:

Current state:

  • 3 builder nodes, each run by a separate independent entity.
  • 3 searcher nodes (not covered in detail here).
  • All nodes replicate full computation (no work partitioning yet).
  • Fully permissioned — adding nodes is an open R&D challenge.
  • Communication: flooding (all nodes send everything to all other nodes).

TEE architecture:

  • Every node runs inside a TEE (currently TDX/SGX).
  • All inter-node communication encrypted to keys generated inside the TEE.
  • Properties: confidentiality (messages readable only inside TEE) + integrity (verifiable protocol compliance).
  • Fail-stop assumption: TEE failures are detectable (loud), not silent. If a TEE is compromised and misbehaves, cryptographic evidence is produced.

Production measurements (August 2025, 8-hour sample):

  • Concurrent user sessions: peaks at ~1,000.
  • Inbound transaction throughput: peaks at ~4,000 TPS.
  • Inter-node requests: ~2,000 requests/second (batching reduces this below inbound TPS).
  • Design target for mature system: ~500 nodes, thousands of TPS maintained.

Flooding bottleneck: cannot add more nodes without smarter routing — current flood topology means each new node multiplies network traffic linearly.

TEEs for Spam Elimination (Quintus Kilbourn / Flashbots)

The spam problem: encrypted mempools (transactions encrypted to block builder) introduce a new incentive: searchers can’t target user transactions directly, so they spam many transactions to probabilistically land behind their target. Spam can reach very high fractions of total Ethereum transaction volume.

TEE solution: arbitrage logic runs inside the TEE, detecting and handling economic opportunities before block space is consumed. The searcher has no incentive to spam because the TEE will already handle the opportunity optimally.

  • Deployed in BuilderNET (Flashbots) — as of August 2025; effectiveness data not yet available in this wiki.
  • Independently deployed in Jito (Solana) — TEE-based block building emerging across multiple chains.

Status note: The spam-elimination claim is as of NoConsensus 2025 (August 2025). No follow-up data on measured spam reduction post-deployment has been ingested.

Open question: using TEEs to mitigate P2P-layer attacks (Eclipse attacks, DHT poisoning, Sybil attacks) — bounding the number of peers a node can communicate with, or limiting DHT views. No concrete design yet, but framed as promising research direction.

The Residual Problem: Network-Layer Censorship

Even with full TEE integrity, a network adversary can:

  • Observe which IPs send transactions to which builder nodes.
  • Identify market makers by traffic patterns and selectively delay their packets.
  • Reconstruct information content from metadata (timing, flow size, source patterns) without reading encrypted payloads.

This is why BuilderNET’s roadmap includes anonymous broadcast (see Anonymous Broadcast): TEE compliance + anonymous P2P gossip together close both the application-layer and network-layer attack surfaces.

Future Architecture (dmarz)

Target state for “Ethereum tomorrow” block building:

  • Hundreds of specialized nodes: some focused on ERC-4337 account aggregation, some on ZK proof aggregation, others on specific order flow.
  • Geographically distributed across multiple countries (≥2 per country + satellite/edge deployments).
  • Permissionless entry: any node that can prove TEE compliance can join.
  • Anonymous broadcast between nodes: hides inter-node metadata from network observers.
  • Work partitioned across nodes (not replicated): true horizontal scaling.
  • Privacy zones: subsets of nodes operate with isolated information environments for different order flow types.

Connections

Open Questions

  • How do you make BuilderNET permissionless without a trusted TEE attestation registry becoming centralized?
  • What is the right fallback when the distributed block building network goes offline — should it degrade gracefully to single-builder mode?
  • Can anonymous broadcast protocols handle 500 nodes at 4,000 TPS within block time constraints?
  • What happens when a TEE is hardware-compromised silently (not the assumed fail-stop case)?