Flashnet Anonymous Block Building

Summary

Flashnet is an anonymous communication system designed by Mark Simkin (Flashbots) for BuilderNet Phase 2: distributed block building where any builder can submit a block bid or broadcast a complete block without their identity being linked to the block they published. The system uses a DC-Net variant (dining cryptographers network) with stacked invertible bloom filters for collision resolution, homomorphic authentication tags for aggregator load reduction, and TEEs only for liveness (not anonymity). The anonymity guarantee comes from classical non-colluding server assumptions.

Motivation: Distributed Building Without Attribution

In BuilderNet Phase 1, multiple operators run the same block building code in TEEs, but it’s publicly known which operator’s enclave produced which block (via attestations). For BuilderNet Phase 2, the goal is:

Multiple builders can bid for the right to produce a block
The winning builder publishes their block
No party learns which builder won without the block being published (anonymous bidding)
Even after publication, the builder’s identity is not necessarily revealed

Why this matters: if it’s known that Builder X submitted the highest bid before the block is published, adversaries can extract Builder X’s block construction strategy. Anonymous bidding prevents reverse-engineering of block construction logic.

DC-Net: The Core Primitive

A DC-Net (Dining Cryptographers Network) enables anonymous communication: N users each want to send one message; the system delivers all messages without revealing who sent which.

Basic DC-Net:

Users are arranged in a ring; each pair shares a random key
Each user XORs their message with their two shared keys and broadcasts the result
Any subset of broadcasts that covers all key pairs XORs to the original messages
No individual broadcast reveals the sender

Problem: classical DC-Nets require N rounds of interaction and cannot handle collisions (two users sending simultaneously produce XOR of both messages, unrecoverable).

Flashnet’s Solution: Stacked Invertible Bloom Filters

Invertible Bloom Filters (IBF)

An IBF is a data structure that stores key-value pairs and supports:

Insertion: add (key, value) to the filter
Deletion: remove (key, value) from the filter
Decoding: recover all stored pairs if the filter is not too full (<50% load)

IBFs are “invertible” because you can XOR two IBFs together and decode the symmetric difference — all pairs in one but not the other.

Collision Resolution via Stacking

When multiple users send simultaneously in a DC-Net, their messages XOR together unrecoverably. Flashnet replaces messages with IBF entries:

Each user’s message is placed in a random slot in an IBF array (chosen by the user pseudorandomly based on a shared secret)
Each user secret-shares their IBF contribution among K servers
Each server sums all shares it receives (additive combination, not XOR)
All K servers broadcast their aggregate
Aggregators combine server outputs to recover the full IBF
The IBF is decoded to extract all individual messages

Collision handling: if two users choose the same slot, they collide. The IBF’s “stacking” (multiple hash functions per entry) handles this: a collision at one hash position is resolved by checking other hash positions. The system succeeds with high probability if the collision rate is below the IBF’s load threshold.

Overhead: approximately <2× communication overhead vs. the optimal (sending messages directly). This is near-optimal for anonymous communication.

Homomorphic Authentication Tags

Problem: malicious servers could inject false messages or modify shares they relay. This would compromise the anonymity guarantee.

Solution: homomorphic authentication tags (based on linear hash functions):

Each user attaches a tag to their share: tag = H(share) where H is a linear hash function
When a server sums N shares, it also sums their N tags: sum(tags) = H(sum(shares)) (linearity)
Aggregators verify that the tag of the summed output matches the sum of tags
Any modification to a share changes the tag, causing verification failure

Aggregator role: a lightweight aggregator node (not required to be honest) can verify server outputs without learning their contents, and route aggregated outputs to the decoder. This reduces direct load on servers by a factor of K (the number of aggregators).

TEEs: Liveness Only

Flashnet’s anonymity comes from the non-colluding server assumption (classical). TEEs are used only for liveness:

Liveness problem: a malicious user could fill all IBF slots with garbage, preventing other users’ messages from being decoded. The user does this because garbage is indistinguishable from legitimate content before decoding.

TEE solution: users submit their messages to a TEE-attested gateway. The gateway verifies that the message is well-formed (a valid block bid, a valid block, etc.) before inserting it into the DC-Net. Malformed messages are rejected before they enter the system.

The TEE does not learn the user’s identity (it only verifies message validity, not origin). If the TEE is compromised, anonymity still holds (the anonymity proof depends on the non-colluding server assumption, not on TEE security). TEE compromise can only affect liveness (an attacker controlling the TEE can reject valid messages, causing delays but not deanonymization).

Security Model

Property	Mechanism	Trust Assumption
Anonymity	DC-Net + IBF	Non-colluding servers (classical)
Integrity	Homomorphic tags	Computational hardness of forging tags
Liveness	TEE gateway	TEE hardware not compromised
Collision resistance	IBF stacking	IBF load < threshold (probabilistic)

BuilderNet Phase 2 Integration

Use case: anonymous block building bids

Flow:

Multiple builders each construct a block and compute its value (MEV)
Each builder submits their block (or a hash commitment to the block) anonymously via Flashnet
The relay or validator receives all block bids without knowing which builder submitted which bid
The highest-value bid is selected; the winning builder reveals their block
After revelation, the builder’s block is verified against the commitment

Privacy before revelation: the losing builders’ blocks are never revealed. Their block construction strategies remain private.

Privacy after revelation: the winning block is public, but the losing blocks (and their builders) remain anonymous. The relay learns only that one of the N builders submitted the winning block, not which one.

Relationship to Other Anonymous Communication Systems

System	Use Case	Overhead	Anonymity
Mixnets	Email, messaging	2-5×	Statistical
Tor	Web browsing	3-7×	Probabilistic
DC-Net (classical)	Small N, no collisions	2×	Perfect (classical)
Flashnet (stacked IBF)	Block building, variable N	<2×	Classical
Signal (sealed sender)	Messaging	~0%	Heuristic

Flashnet achieves near-optimal overhead with classical anonymity guarantees — stronger than Tor/mixnets but requiring non-colluding servers rather than honest routing paths.

Open Questions

❓ What is the concrete message throughput of Flashnet at BuilderNet Phase 2 scale (tens of builders, 12-second slot times)?

❓ How many non-colluding servers are needed for the anonymity guarantee to hold in practice? (2 non-colluding servers provide information-theoretic anonymity; in practice, more servers improve robustness.)

❓ Can Flashnet be extended to handle continuous bidding (real-time bid updates) rather than one-shot block submission?

❓ Does the TEE gateway create a centralization point? (Potentially yes if only one TEE gateway operates; multiple gateways would be needed for decentralization.)

User-Facing Mempool: NAMP (Feb 2026)

The Flashbots “Network Anonymized Mempools” post (2026-02-17) generalizes Flashnet beyond block-bid coordination to a user-facing anonymous broadcast protocol for transaction submission, complementing FOCIL and onchain privacy tools (Railgun, Privacy Pools, stealth addresses).

Why network anonymity is the missing layer

Onchain privacy hides content but operators of OFAs / TEEs / relays still learn metadata: IP, account-correlated traffic patterns, location. Flashbots cites NY Fed selective-censorship paper and Propellerheads “EV intent” work.
Existing alternatives force a binary: TOR/Nym = weak anonymity or high latency; FOCIL = censorship resistance only via the public mempool, inviting frontrunning. Both impractical for time-sensitive DeFi where ms-level price moves mean P&L.
For DeFi specifically: drives down latency overhead so the same primitive that protects a Railgun user from deanonymization also prevents intermediaries from filtering or disadvantaging participants by network identity.

ZipNet inheritance

Flashnet is descended from ZipNet (Asharov et al., ePrint 2024/1227). ZipNet’s insight: most computational/bandwidth overhead in anonymous broadcast comes from ensuring liveness, not anonymity. Use TEEs for liveness, classical crypto for anonymity. ZipNet’s weakness: dies if a single server drops. Flashnet’s improvement: stays live as long as a majority of servers are honest and online; provides strongest sender-anonymity (no broadcast attributable to any client) at moderate bandwidth.

Three-role architecture

Clients run a TEE locally (or delegate, with extra trust). Each client locally prepares an empty array and places its message at a pseudorandom slot, then secret-shares the array among servers.
Servers (≥½ honest assumed): receive shares, locally sum into share-of-sum, forward to leader.
Leader: combines shares, recovers the final array (which is the union of all clients’ messages), gossips to a public mempool. Tolerates some unresponsive/malicious servers.
Homomorphic vector commitments authenticate the addition step — the binding property keeps each server honest.
Client-side TEE prevents a malicious client from filling all slots with garbage (a liveness DoS, not an anonymity break).

Anonymity-Latency-Bandwidth Trilemma (Flashbots framing)

Onion routing (TOR): low bandwidth, async, low latency in practice — but weak anonymity vs. global passive observers.
Mix-Nets (Nym): strong anonymity vs. global passive adversaries via cover traffic + batching/reordering — high latency and high bandwidth.
DC-Nets: strong synchronous anonymity, moderate latency — high bandwidth/compute. Anonymity scales with cover traffic (analogous to PoW security scaling with hashrate).
Flashnet: maximizes anonymity, low latency, moderate bandwidth — leverages TEEs for liveness only.

Two deployment vectors

User-facing anonymity + censorship-resistance tool for tx submission (and AA mempools), complementing FOCIL.
Coordination primitive for permissionless block building — slots into BuilderNet Phase 2 (Distributed Building). Lets anyone run a node, scaling BuilderNet beyond reputation/trust limits (today: only Flashbots, beaverbuild, Nethermind run BuilderNet enclaves).

Flashbots positions Flashnet variants as eventually integrable into MCP-style designs (FOCIL etc.), but stresses deployment is possible today without protocol changes.

Timeline

2025-08-08 — Flashnet presented by Mark Simkin (Flashbots) at MEV-SBC 2025
2026-02-17 — “Network Anonymized Mempools” Flashbots Writings post: announces user-facing NAMP variant for tx submission