Anonymous Block Proposers: How Logos Solves Leader Privacy in PoS
Every ten minutes, Bitcoin miners compete to produce the next block. They do it blindly — no one knows who will win until the proof-of-work solution is broadcast, and by then it’s too late to do anything about it. Ethereum works differently. Validators are assigned slots in advance, their leader schedule published at the start of each epoch. For roughly 6.4 minutes, the entire network knows exactly who is going to propose the next 32 blocks.
That advance disclosure is an attack surface. A known proposer can be censored before they get the chance to propose, DoS’d into missing their slot, or coerced — legally or physically — into excluding specific transactions. Over time, a patient adversary can observe the pattern of blocks and infer the proposer’s stake, turning anonymity into a target.
Logos takes a different approach. Block proposers in Logos are anonymous — not pseudonymous, not just unlinkable by one avenue, but unknown to the network until their block is already propagating. This is Private Proof of Stake (PPoS), and it is achieved through two interlocking systems: Cryptarchia, which runs the leadership lottery in zero-knowledge, and Blend, which anonymizes the broadcast.
This article explains how each works, how they compose, and why the design is meaningful in practice.
The Problem: What a Known Proposer Leaks
Before going into the solution, it’s worth being precise about the threat model.
Censorship. If an adversary knows slot N will be proposed by validator V, they can attempt to prevent V from seeing the transactions they want to include. By the time the block is supposed to be proposed, V’s mempool has been poisoned or their connection severed.
Coercion. A proposer who can be identified — by network triangulation, by long-run stake inference, or by a compromised leader schedule — can be pressured. Validators in regulated jurisdictions or those holding significant stake become targets for legal compulsion to comply with OFAC lists or other filtering requirements.
Denial of service. A known proposer is a known endpoint. Flooding their connection during their slot is trivial and effective — a missed slot means lost rewards and reduced liveness for the network.
Stake inference. This is subtler but important. Even if a proposer changes identity, the frequency with which they win the lottery reveals their relative stake. An adversary watching long enough can bucket validators as small, medium, or large — reducing the anonymity set and enabling targeting of high-value nodes.
Ethereum’s single secret leader election (SSLE) proposals address the first two by removing the public leader schedule, but they leave stake inference unaddressed. Logos aims to solve all four.
Cryptarchia: Private Leadership Election
Cryptarchia is the consensus protocol at the heart of Logos Blockchain. It is derived from Ouroboros Crypsinous — the first PoS protocol to prove security against adaptive adversaries in a privacy-preserving setting — but extends it with design changes that make it practical to deploy today.
How the Lottery Works
Time is divided into one-second slots. At each slot, every holder of a sufficiently aged note (Logos’ representation of stake) can check whether they have won the leadership lottery. The lottery is weighted by the value of the note — a larger note wins more often — but crucially, the check happens entirely inside the validator’s local state. Nothing is broadcast to the network at the time of checking.
The lottery threshold is computed as:
ticket := hash("LEAD_V1" || epoch_nonce || slot || noteID || sk)
threshold := stake × (t₀ + t₁ × stake)
If ticket < threshold, the note wins. The parameters t₀ and t₁ are public constants derived from the target block rate and the inferred total stake for the epoch. The note value and the secret key remain private. The slot activation coefficient f = 1/30 means roughly one in thirty slots contains a block — enough breathing room for the network to propagate each block before the next arrives.
This is a private coin flip. The validator knows they’ve won. No one else knows yet.
Proving the Win in Zero-Knowledge
The winner needs to convince the rest of the network that they legitimately won the lottery, without revealing which note they used, how much stake it holds, or any other identifying information.
They do this by constructing a Proof of Leadership (PoL) — a Groth16 zero-knowledge proof that attests to the following, without revealing any of the private inputs:
-
The note exists and is aged. The note’s identifier appears in the ledger commitment taken at the start of the previous epoch (
ledger_AGED), proving the note is old enough to participate. -
The note is unspent. The note identifier still appears in the most recent ledger snapshot (
ledger_LATEST). -
The note won the lottery. The hash of the note’s identifier, the epoch nonce, and the slot number falls below the threshold — meaning this note legitimately won this slot.
-
The proposer knows the slot secret. This is the adaptive adversary protection. The validator maintains a Merkle tree of one-time secrets, one per slot (derived via a hash chain from a random seed). To prove leadership in slot
sl, they must reveal a Merkle path to the secret for that slot, while erasing previous slot secrets. An adversary who compromises the validator after the fact cannot reconstruct past proofs.
The proof also binds a one-time leader public key (P_LEAD) that will be used to sign the block. The key is single-use by design — reusing it would let observers link multiple winning slots to the same proposer, enabling stake inference.
The output is a 128-byte Groth16 proof that any node in the network can verify in milliseconds.
Note Ageing and Epoch Structure
The requirement that winning notes be aged is not arbitrary. If fresh notes could win the lottery immediately, an adversary who knows the epoch nonce η could generate notes until they find one that wins many slots, gaining an outsized share of leadership — a grinding attack.
Notes must be on-chain before the start of the previous epoch to be eligible. The epoch itself is structured with a three-phase schedule: a stake snapshot phase, a buffer phase, and a lottery constants finalization phase. This cascade of delays ensures that by the time the epoch nonce is finalized, the notes eligible to win it have been committed long enough that no one could have chosen them with foreknowledge of η.
Blend: Anonymizing the Broadcast
A perfect zero-knowledge proof means the network can verify a block was proposed by a legitimate winner without learning which note won or how much stake it represented. But publishing the proof is not enough. The act of broadcasting a block to the network has a network-level signature: the block propagates outward from its source, and a well-resourced adversary watching traffic flows can triangulate the originating node.
The Blend Protocol addresses this.
How Blend Works
Blend is a mix network — a privacy overlay for block proposals. Block proposals don’t travel directly from the proposer to their peers. Instead, they are routed through a sequence of blend nodes (core Nomos nodes that have declared participation in the protocol), where they are cryptographically transformed and randomly delayed before being relayed onward.
The key properties:
Onion encryption. When a proposer creates a data message, they select a path through the blend network and encrypt the message in layers — each blend node on the path can only decrypt one layer, revealing the next hop. No node knows both the origin and the final destination.
Cover traffic. Every core node generates cover messages at a constant rate, in every round, independent of whether they have a block to propose. Cover messages are cryptographically indistinguishable from data messages. This is essential: a mix network that only generates traffic when there is something to hide provides no cover at all.
Timing delays. Each blend node holds messages for a random delay before forwarding. This disrupts traffic analysis that depends on correlating timing patterns across nodes.
The result is that by the time a block proposal reaches the gossip layer and begins propagating to all nodes, it has passed through enough hops — with enough delay and noise — that the originating node cannot be determined through network observation alone.
The Numbers
The Blend specification states that the protocol increases the time required to link a sender to a proposal by at least 300×, making stake inference highly impractical in practice. For an adversary controlling 10% of network stake, targeting a node with 0.1% stake, inferring that stake through timing analysis would take over 10 years.
Edge and Core Nodes
Not every Logos node participates in blending. Core nodes — those that have declared themselves as Blend participants via the Service Declaration Protocol — form the mix network and relay messages. Edge nodes connect to core nodes and inject their proposals into the blend network without running it themselves. The distinction allows lightweight nodes (e.g., validators running on consumer hardware) to benefit from the privacy of the mix without contributing to its bandwidth overhead.
Putting It Together: Private Proof of Stake
The combination of Cryptarchia and Blend achieves what neither does alone.
Cryptarchia ensures that the contents of a block provide no information about the proposer’s identity or stake. The PoL proof reveals only that some eligible note won this slot — nothing more. The leader public key is one-time, so no two winning blocks can be linked to the same proposer by inspecting the proofs themselves.
Blend ensures that the act of proposing a block provides no information about the proposer’s network position. The cascade of encrypted relays and cover traffic makes traffic analysis prohibitively expensive.
Together, they satisfy the core requirements of PPoS:
- Block proposals are not linkable to a leader — neither by inspecting the proof nor by watching the network.
- Proposer stake is not revealed — the ZK proof hides the note value, and the mix network prevents frequency analysis.
- Leaders are protected against network triangulation — Blend’s routing and cover traffic raise the cost of deanonymization to impractical levels.
This is not a theoretical construction. The Logos Blockchain devnet is live. The first Logos Blockchain release is running internally, with a faucet, Swagger API docs for node interaction, Prometheus metrics, and multiplatform Docker images.
Comparison: Ethereum’s Secret Leader Election
Ethereum’s validator community has proposed several approaches to secret leader election, motivated by the same concerns. The most developed is SSLE (EIP-7441 and related work), which uses shuffle-based cryptographic protocols to publish a slot’s leader only to that leader themselves in advance, while the network learns the identity only when the block is proposed.
SSLE removes the public leader schedule and addresses censorship and coercion risk. But it has limits:
- Stake inference remains possible. Even without a pre-announced schedule, an observer who watches which validator key proposes each block can, over time, infer the distribution of stake — especially if validator keys are reused across slots.
- Network triangulation is unaddressed. The block still propagates from a known originating node. An adversary controlling enough network vantage points can triangulate the source.
- The anonymity set is bounded by the validator set. SSLE hides which of the 1 million-ish Ethereum validators will propose next, but the validator set is public and staking amounts are linkable to deposit transactions.
Cryptarchia and Blend address all three gaps. Note values are hidden in the ZK proof, preventing on-chain stake inference. One-time leader keys prevent cross-slot linkage. Blend’s mix network severs the connection between block proposal and network position.
The cost is latency. Blend’s routing delays add seconds to block propagation compared to gossip-only protocols. The slot activation coefficient of 1/30 partially compensates for this — most slots are empty, giving the network time to settle before the next block is expected. But this is a real trade-off: Cryptarchia is not optimized for high throughput or low latency. It optimizes for resilience and proposer privacy.
Try It
The internal devnet is live. You can spin up a Logos node with the multiplatform Docker images, get test tokens from the faucet, and interact with the chain through the Swagger API docs. Prometheus metrics expose chain behavior in real time.
The devnet is the best place to observe Cryptarchia in operation — watch the slot timing, the PoL verification, and the block propagation through Blend. The specs referenced throughout this article (Cryptarchia PoL Spec, Cryptarchia v1 Protocol, Blend Protocol) are the normative sources for everything described here.
Proposer anonymity in PoS is a hard problem. Logos’ answer is to treat it as a first-class requirement, not an afterthought, and to build the cryptographic infrastructure needed to solve it end-to-end.
INSERT CTA LINKS HERE
Sources: Cryptarchia PoL Spec · Cryptarchia v1 Protocol · Blend Protocol Spec · Why Proposer Anonymity Matters