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.
Tech Update recap: Logos Messaging
This session went deep on Logos Messaging with contributors from Logos Delivery, Logos Chat and Research, and previewed what messaging ships in Testnet v0.3.
Two layers
Logos Delivery is the transport: gossip routing over libp2p, wrapped in a Messaging API where you subscribe to a content topic and send. Logos Chat sits on top and adds encryption, users, multi-device installations and group chat. Build against the raw protocols, the Messaging API or Logos Chat, whichever fits.
Reliability lives in the encryption layer
Delivery already abstracts RLN for anonymous spam protection, Mixnet for anonymous publishing and service discovery for finding capable peers. What it cannot provide is end-to-end reliability, because only the encryption layer knows whether the intended recipients received a message. That is where SDS (Scalable Data Sync) runs.
SDS avoids the ack storm a broadcast transport would cause. Each message references the messages that caused it, forming a causality tree, so every member can tell what they are missing and request repair. Reliability is probabilistic and tunable, periodic sync traffic covers quiet groups, and the mechanism improves as groups grow.
de-MLS: group keys without a server
MLS assumes an always-available delivery service and a central authentication service. de-MLS replaces the first with a rotating steward plus a voting layer. A member proposes an add, remove or key rotation, the group votes over gossip, and a yes converts the proposal into a standard MLS commit that advances the epoch. A steward who ignores you rotates out, own-key updates skip the vote, and the current design needs no on-chain component.
Forward secrecy and post-compromise security require everyone to apply the same commits in the same order, so a fork breaks the group. Commit messages therefore need near-total reliability while conversation messages can run looser. SDS keeps separate causality trees and parameters for each stream. Invitations, sent once with no follow-up, still need their own approach.
The offline-epoch problem
Miss an epoch and you lack its keys. Forward secrecy forbids reading backwards, yet SDS recovery depends on causal history. The proposal under review derives SDS header keys from the epoch key with a lag, so a member a few epochs behind can still read the reliability header, learn what they missed and rebuild forward without decrypting any content. Removals and key access while lagging are open corner cases.
Identity
Account logs answer the second MLS assumption: append-only, signed records of account updates. Each app and device installation gets its own key bound to the account, so losing a phone means revoking one installation rather than the whole identity. Social recovery and richer evaluation rules are planned, with the logs moving onto LEZ later. Profiles with display names are live.
Testnet v0.3 messaging
-
RLN enabled in Logos Delivery through a pluggable RLN module; Delivery itself neither generates nor validates proofs. Soft rollout: the first release generates proofs without validating them, validation follows.
-
RLN membership Merkle tree backed by LEZ for the first time, with the required transactions mined in the background so users never hit a wallet step.
-
History backfill through the Store protocol, delivered over the same Messaging API.
-
An anonymityLevel flag: full (Mixnet only), preferred (falls back without mix peers) or none.
-
Service discovery becomes the default peer discovery for Delivery, extending later to blockchain, storage and Mixnet.
-
Logos Chat: revocable installations and multi-device, delivery acknowledgements, group names and descriptions, a default message database, basic content types, post-quantum encryption for groups and DMs, and a conversation-types plugin system for shipping protocol updates without breaking existing apps.
-
Not yet: Mixnet with RLN, and Mixnet for storage. The plumbing is in place; rollout is staged.
The first Logos Delivery module release candidate was cut the day before the stream and release notes will follow shortly.
Next session: the SQLite Zone, a decentralised database on Logos Blockchain.