Tech Update #2 recap: Mix, Sphinx, and anonymous storage
The second Logos tech update covered the mix protocol work happening in the Anonymous Communications team and how Logos Storage builds on it. KSR hosted, joined by Prem from AnonComms and Giuliano the Logos Storage lead.
What mix is in the Logos stack
Mix is not a single protocol but a parameterizable protocol framework built into libp2p. At the base sits a simple protocol for sending Sphinx packets peer to peer, with entry and exit abstractions layered on top. The same framework serves different applications across the stack, each with its own parameter needs: Logos Messaging is one consumer, Logos Storage another.
Sphinx, briefly
Prem walked through the Sphinx packet format, an older specification the team has integrated. It resembles onion routing (as in Tor) with a few properties Tor lacks:
-
Packet size stays constant across hops, so packets can’t be tracked by size changes from origin to destination. Current integration: roughly 4.5 KB packets with a 700–800 byte header, small enough to suit chat messaging.
-
Maximum path length is fixed at deployment (currently five hops), so any node can reject a malformed packet claiming, say, 100 hops.
-
A cryptographic tag lets each node deduplicate packets, which prevents both routing loops and replay attacks.
-
Single-use reply blocks (SURBs) allow anonymous replies. The destination can respond to the sender without ever learning its peer ID, IP, or port, something plain libp2p can’t do.
Nodes in the middle of a path don’t know their position in it. They know the path length, not whether their neighbor is the sender, the receiver, or another hop.
Mixifying protocols instead of a mix transport
An early design question: should mix be a libp2p transport or a protocol? The team chose protocol, and the stream spent time on why.
A mix transport would route all of a node’s traffic through mix. For a semi-broadcast protocol like gossipsub (used by Ethereum for block dissemination and by Logos Messaging), that multiplies hop counts and gets inefficient fast. It would also interfere with gossipsub’s peer scoring. A further constraint: libp2p currently allows only one transport connection between a pair of peers, so you couldn’t run mixed and unmixed traffic side by side.
Making mix a protocol lets developers “mixify” an existing protocol and choose, per message, what goes through mix. Daniel and Prem traced a full example with libp2p ping: instead of dialing the target directly, the client hands the ping packet to the mix protocol, which picks a random path (three hops in the example), routes it through, and the exit layer at the destination invokes the ping handler. The reply travels back along a SURB without the responder ever learning who asked. A mix transport may still come later as a default for protocols that want everything mixed.
Why storage is harder
Giiuliano gave a from-scratch explanation of mixnets: a single mix decorrelates traffic by re-encrypting messages and releasing them after exponentially distributed delays (memoryless, so entry time reveals nothing about exit time). But a single mix operator can be malicious, so you use a network of mixes and random paths. The catch is that there’s a fixed probability of sampling an all-malicious path, and that risk compounds with every packet you send.
Storage is file sharing, and the goal is stated plainly: sharing and downloading files without being identifiable for it. Sphinx packets are 4 KB; files can be a gigabyte. The more packets a transfer takes, the higher the odds of deanonymization. Capping served file sizes doesn’t fully help either, because an anonymous malicious downloader can just request the same file repeatedly. Mitigation strategies exist (guard and vanguard nodes as in Tor, stratified sampling as in Nym) and a team member is working on them, but the team was direct that this is a fundamental problem of open mixnets, mitigated rather than solved.
Current design choice: the downloader is anonymous, the provider is not. The provider can also rate-limit how many reply blocks it hands out, since forcing a downloader to mint huge numbers of SURBs would risk deanonymizing the other side.
A transport on top of mix
Out of the box, mix gives you one 4 KB packet forward and one reply back. A gigabyte transfer needs much more, so the team is building an application-level transport over mix: chunking data into Sphinx-sized pieces, maintaining a reply-header balance the downloader tops up on request, adding redundancy through replicated packets (erasure coding planned as the more efficient replacement), plus retransmission, ordering, and flow control. No congestion control yet. On top of this transport sits a BitTorrent-like block transfer protocol. The TCP-over-TCP trap came up; some of that stacking already exists today via Yamux windows and may ease with a move to QUIC.
Blend is not this mixnet
An audience question surfaced a useful distinction. Blend is a separate mix-like network for the Logos Blockchain, because consensus needs very specific parameters, and Blend bakes node incentivization and on-chain discovery into the protocol. What Blend provides that other chains don’t: private proof of stake, so the next block proposer isn’t known in advance and can’t be targeted for denial of service. The long-term aim is one mixing layer with different flavors; for now the two networks are separate.
Where this sits relative to other projects
Asked about Ethereum and Swarm: Ethereum is a blockchain, not a content distribution network, so it’s largely orthogonal. Swarm anonymizes queries with a forwarding DHT, which the team argued is a weaker mechanism than a mixnet: no cover traffic, and repeated identical queries tend to take the same path. Swarm offers persistence and paid storage today, which Logos Storage does not yet; the current focus is stronger privacy guarantees, with persistence on the roadmap. To the speakers’ knowledge, no other stack currently combines on-chain settlement, storage, messaging, and anonymity-preserving layers in one system.
Scope now, roadmap later
The privacy guarantees are currently bound to a threat model of smaller files. The first main application is the package manager: module downloads with Logos Storage as the backend, inheriting the privacy-preserving properties. The fully decentralized Dropbox (persistence, incentivization, efficient replication) is future roadmap, and the team was open that incentivization plus anonymity makes an already hard problem harder. One intermediate step under exploration: a set of nodes offering semi-altruistic storage up to a limited file size.