The Logos Networking Layer in Testnet v0.2: Everything Leaks Through Here
Component: Networking layer (discovery, peering, mix) / AnonComms + P2P Audience: Protocol engineers, privacy researchers, p2p developers Status: First draft, adversarially reviewed (2 rounds + 2-round fresh-eyes validation pass; see changelog)
Five articles into this series and I’ve been writing around a hole: the networking stack that sits between the Logos runtime and every module above it, the layer that decides whether anything upstack is actually private. Blockchain, storage, messaging, every piece so far borrowed from this layer without giving it the article. Discovery, peering, and mix. The plumbing.
Time to fix that, because the plumbing is where privacy actually lives or dies. Every stage of the transaction lifecycle this series keeps mapping (coordination, storage, settlement) eventually turns into packets leaving a machine, and packets are where observers do their best work. You can encrypt content all day; the network layer still leaks who talks to whom, who stores what, who offers which service, and when. This layer is designed to close those leaks for the whole stack at once. How much of that is running on testnet v0.2 versus specified for later is most of what this article is about, and the answer is messier than the design.
Why one shared layer
Start with what most p2p stacks actually do: the chat module does its thing over libp2p, storage rolls its own DHT, the blockchain runs its own gossip, and nobody buys network-level anonymity at all. Where anonymity does get built per-module, it gets built for the one traffic class that can’t live without it and nothing else; Logos’s own Blend Network, covered below, is exactly that case. So the real design question isn’t “shared mixnet versus five bespoke ones,” it’s “if the stack is going to buy network privacy for more than its most critical packets, where does that capability live so every module actually gets it?”
The Logos answer: one layer underneath everything, so modules inherit the properties by default instead of each team deciding whether privacy fits this quarter. A shared layer has a second draw, because anonymity is a crowd phenomenon: a mixnet carrying only chat traffic has a small crowd, and one carrying chat, storage lookups, and service discovery has a bigger one. Anonymity loves company, and a shared layer is how you throw the party. Whether you should throw your own party or crash someone else’s is a real question, and it gets its own section below.
One catch before the crowd argument gets too comfortable: a crowd only helps if you can’t tell its members apart. Chat messages, DHT lookups, and discovery queries have different sizes, timing, and shapes, and an observer who can classify traffic by type partitions your big crowd right back into small ones. Uniform packets (the Sphinx format the mix layer uses makes every packet look identical, more on it below) plus cover traffic are what turn co-tenancy into indistinguishability, and whether the cover traffic running on v0.2 actually buys that is an open measurement question, as we’ll get to. The shared layer is the precondition for a real anonymity set, not the property itself.
The other design commitment: everything is built as extensions to libp2p rather than a bespoke stack, and published as specs. The base libp2p mix protocol spec is already published; the DoS-protection extensions and the discovery spec (adapting published research to libp2p’s DHT) are on their way. Which makes the whole thing reviewable by people who’ve never heard of Logos. Reviewable is not reviewed; the closing section is about getting the review to actually happen.
One boundary to draw before going further, because I’ve watched people conflate these: the Blend Network from the blockchain article is not this mixnet. Blend is an anonymous broadcast layer purpose-built for block proposals; the mix layer is general-purpose sender anonymity for module traffic. Blend is also the pattern I flagged above, live in this stack: the most surveillance-sensitive traffic bought bespoke anonymity and sits outside the shared crowd, and my read of why, a reconstruction rather than a stated rationale, is that block-proposal timing can’t eat per-hop mix delays. The question to sit with is what else bails out. Chat is the obvious candidate, since users feel every millisecond, and chat is also the mixnet’s flagship demo (next section), which makes the shared crowd’s best current tenant its likeliest future defector. My read of the v0.2 demo, again a read and not a stated plan, is that chat lands on opt-in: direct path for ordinary messages, mix for the ones the sender flags as sensitive, which keeps chat in the crowd but shrinks the crowd to whatever opts in. If latency-sensitive traffic keeps peeling off into its own protocols instead, the shared mixnet carries whatever’s left. I don’t have a clean answer and I haven’t seen one in the roadmap; the delay-tuning work in the honesty section is the team wrestling with exactly this.
So what does the shared layer actually do? Three jobs.
The three jobs
Peering is the baseline: establishing and managing connections between nodes. In v0.2 this got a proper module surface: peerstore management, custom protocol registration, and stream notifications are exposed to any module, so your module can speak its own wire protocol over the shared connections without leaving the runtime. Unexciting, foundational, shipped.
Discovery is the interesting failure mode. Finding peers that offer a specific service in a decentralised network usually means random walks over a Kademlia DHT: visit nodes at random, ask each one what it runs, hope. For a common service that’s fine. For a sparse one, say the handful of nodes offering a niche storage capability in a network of thousands of chat nodes, it’s a needle-in-a-haystack search whose time and bandwidth blow up as the service gets rarer; the team’s own analysis puts numbers on how badly it scales.
Capability discovery flips the search around: services register what they offer in the DHT, and seekers look the capability up instead of stumbling into it. The protocol adapts DISC-NG from the research literature to libp2p’s Kad-DHT. Status, precisely: it ships in v0.2 as an alpha Logos Core module; client mode, so resource-restricted nodes can discover services without joining the DHT, is implemented with the PR approved but the deliverable not yet closed out; and integration into Logos Delivery to replace discv5 is a v0.2 deliverable currently in dogfooding. The benchmark targets (targets, not results): comparable to discv5 when everyone runs the same service, better than discv5 for sparse services. The docs on how discovery works today cover the mechanisms it would supersede.
And one tension I’d rather name than have pointed out to me: a capability registry is a public list of who offers which service, one of the exact leaks the intro complained about. Findability is what discovery is, so some leak is inherent, and Kademlia networks get enumerated today regardless; BitTorrent and IPFS crawlers do it by asking every node. What the registry changes is the price: the list concentrates at deterministic keys, readable at rest by anyone, a lookup instead of a crawl. The planned answer is anonymous service provision through the mix layer’s hidden services, and that work is open checkboxes. Until it lands, discovery makes providers easier to find, including by people they’d rather not be found by.
Mix is sender anonymity: route a message through relay hops with layered Sphinx encryption, each hop adding a randomized delay, so no single relay sees both sender and destination. Against whom, exactly, since this is where privacy projects usually go vague: three hops with randomized delays defend against a single curious relay and a local observer who can’t watch the whole path. The first hop knows your IP but not what you sent or where it lands. Not yet defended against: an observer wide enough to correlate traffic across the network, or colluding relays. The counters are cover traffic for K-anonymity (being indistinguishable among K possible senders) and a relay set large and independent enough that collusion is hard. Cover traffic is in fact running on v0.2; what nobody has is a measurement that it delivers meaningful K on a testnet whose real sender population is a handful of demo users, and the independent-relay-set condition is simply not yet true.
On testnet v0.2 the mechanism is real enough to touch: the Chat UI can send anonymised messages through a three-hop mixnet, and storage DHT lookups can ride the same protocol as a PoC. Same mix the storage article called “quieter to query.” But a testnet demo demonstrates the mechanism, not the anonymity: the relay fleet is five nodes, and with Sybil resistance still in demo mode (next section), an attacker could stand up enough relays to own whole paths. Route nothing sensitive through it yet. That’s what testnets are for.
What honesty requires here
The mix layer is the least finished thing this series has covered, and the roadmap doesn’t hide it. Work was still landing as I wrote this: LIONESS payload encryption, which stops a relay from marking a packet at one hop and recognizing it at another (any modification garbles the entire payload), was implemented in July. Cover traffic is further along than I expected to find: implemented, merged into nim-libp2p with a configurable cover-ratio option, and running on the v0.2 fleet, though the spec is still in-review PRs rather than published, and no measurement yet says whether the chosen ratio buys meaningful K-anonymity for a sender population that currently rounds to ten demo memberships. Hidden services are open checkboxes. And underneath it all sits the tradeoff the mixnet literature never resolved: per-hop delays are the main defense against timing correlation, and every millisecond is latency a chat user feels. The team has been tuning delay strategies toward practical limits, which is the polite way of saying this dial has no good setting, only chosen compromises. Where v0.2’s compromise sits is a question the demo lets you answer empirically: if the message arrives fast, ask how much mixing you really got.
DoS protection is the hard one, and I want to spend a paragraph on why. A mixnet’s whole point is that relays can’t tell who’s sending what. That same property makes it a spam cannon: if nobody can identify senders, nobody can rate-limit them by identity. The classical answers all compromise something (Tor-style guards, proof-of-work, Nym’s gateway rate limiting, Blend’s proof-of-quota), and the team has been working through that compromise space in their weekly notes, with a proper RLN-versus-alternatives write-up on their next list. The Logos direction is RLN (rate-limiting nullifiers), a zero-knowledge scheme where you prove you’re under your rate limit without revealing who you are, backed in v0.2 by a membership allocation module running in demo mode with pluggable authentication.
Demo mode’s flanks, stated plainly. Memberships are allocated off-chain, which means someone runs the allocator, and nothing I’ve found specifies who. Today’s testnet fleet shipped with pre-baked membership keystores, which reads like the project allocating for itself; the question is on my verify-before-publishing list. If that read is right, enrollment is a permissioned gate in front of the anonymous network, and a narrower one than Nym’s gateways, which are at least plural and open to anyone willing to bond stake. Decentralizing allocation is the obvious fix, and I haven’t seen the mechanism specified yet. RLN’s spam resistance reduces to the cost of acquiring memberships, and in demo mode that cost is undefined. The authentication is pluggable with a simple signature as the current floor (the team has been experimenting with Keycard device keys), so my inference, and I’d love to have it corrected, is that Sybil resistance on today’s testnet rounds to nothing. Rate-limiting anonymous senders without deanonymising them is a genuinely unsolved problem in the general case.
Build a crowd or borrow one?
The strongest objection to this whole layer: if anonymity loves company, the crowds already exist. Tor is the reflexive version of the objection and the weak one, not because onion routing can’t carry a DHT (I2P runs one), but because Tor specifically is a poor host for this workload: TCP streams only, exit semantics built for reaching the public web, and a project that actively discourages bulk p2p traffic. “Just use Tor” has opened rather than settled this argument for every p2p project of the last decade. The version with teeth is Nym: Sphinx packets, Loopix-style per-hop delays, cover traffic and credential-based DoS protection shipped, a paid relay set already running. That’s a more finished deployment of substantially this design, and “why rebuild it as libp2p extensions instead of speaking Nym as a transport?” is a question I can’t answer from the roadmap, because I haven’t found it argued there. Sizing it honestly in the other direction: a relay fleet is supply, not company, and Nym’s user-side crowd has stayed small, so borrowing buys mature machinery more than it buys an anonymity set. The componentization case below doubles as the implicit answer, and it’s noticeably less decisive against Nym than against a monolith. The upcoming RLN-versus-alternatives write-up is the nearest place I’d expect the comparison to happen; consider this a request that it does.
I2P is the closest prior art to what Logos is building: an integrated substrate where applications inherit anonymity by default, no exit boundary, discovery built in. It has shipped for two decades and its crowd stayed small. Integration depth did not, by itself, produce company. So the novelty claim needs honest sizing. The genuine difference from I2P is the componentization: mix, capability discovery, and RLN-based DoS protection as separately specified, separately adoptable libp2p extensions rather than one monolithic network, and a delay-based mixnet where I2P chose low-latency onion routing. The bet against borrowing is that integration compounds: module traffic never crosses an exit boundary, every module gets the properties by default, and a crowd that includes all of a stack’s traffic grows with the stack. That last clause assumes the stack gets adopted, which is the actual open question, and I2P is the standing evidence against assuming it. Whether this bet beats borrowing an existing crowd is unresolved, and I’d rather see it argued in public than assumed in either direction.
The compressed accounting for v0.2, then, design versus testnet. Designed: network-level privacy as a stack property, sender anonymity, quiet lookups, anonymous service provision, underneath every module at once, covering the hops of the lifecycle that content encryption can’t. Running: a peering module surface, an alpha discovery module in dogfooding, a three-hop Sphinx mixnet with cover traffic on a five-node fleet, chat messages and PoC DHT lookups riding it (chat with the defection asterisk above), and RLN membership in demo mode. The distance between those two lists is the work, and the roadmap is at least honest about the distance.
If you’re a p2p person: the specs are the contribution surface. The base mix spec is published, the DoS-protection extensions and the DISC-NG adaptation are on their way, and adversarial review of those documents is worth more to this layer than praise of the architecture. If you’ve got operational Tor/Nym/Loopix/I2P scars, the RLN-versus-alternatives comparison is the conversation to crash (the write-up is coming), and the build-versus-borrow question above, including whether “speak Nym” beats “rebuild in libp2p,” is yours to sharpen. Holler at me and I’ll route you to the right people.
Roadmap sources consulted (strip before publishing): context/roadmap/content/anoncomms/roadmap/mix.md (base spec published at rfc.vac.dev/vac/raw/mix), discovery.md, testnet_v0.2/mix_v0.2.md, discovery_v0.2.md, rln_v0.2.md, anoncomms/updates/2026-07-13.md (3-hop chat mixnet demo, LIONESS, RLN-alternatives research, Keycard auth experiments), 2026-04-13.md/2026-04-27.md (cover traffic spec + implementation PRs, merged into nim-libp2p with cover-ratio option), 2026-06-22.md/2026-06-29.md (cover traffic confirmed functional; five-node testnet-0.2 mix fleet deployed with pre-baked RLN keystores, 5 fleet + 10 demo-user memberships), 2026-04-06.md (discovery client mode implemented/PR approved; Delivery dogfooding), 2026-02-23.md/2026-03-30.md (delay strategy tuning), context/roadmap/content/testnets/v02.md, v02-release.md (P2P Module section).
Publish-time TODO: swap the blockchain-article wikilink for its published URL; the v0.2 chat-over-mix doc packet (docs/messaging/chat-module/send-anonymised-messages-over-the-mix-network) was in review per the 2026-07-13 update — link it once live on docs.logos.co. Do not link the mixnet demo-app getting-started page as the v0.2 demo; that doc targets testnet v0.1. Verify with the team before publishing: who operates the current testnet mix relays; who runs the RLN membership allocator (the “project allocating for itself” read above is an inference from the pre-baked fleet keystores); what auth the RLN membership module actually shipped with (simple signature vs Keycard); whether chat-over-mix is per-message opt-in as inferred; and whether latency is in fact the stated rationale for Blend living outside the mix layer.