On Nomos, privacy for block proposers comes built-in with its Private Proof of Stake (PPoS) consensus protocol, Cryptarchia. It serves as a first line of defence against deanonymisation by using a private leadership election to protect block proposers. However, preventing adversaries from learning details about proposers by monitoring network activity requires even more robust obfuscation strategies.

Nomos’ Blend Protocol was designed to be exactly that: an anonymous broadcasting protocol for scarce communication patterns that makes it harder to link a block proposal with its proposer based on network analysis. It does this by introducing cryptographic and timing obfuscation to the proposal process, making it difficult to distinguish proposals from each other. The Blend Network - the Bedrock Service consisting of nodes participating in the Blend Protocol - is therefore an integral part of the Nomos architecture.

Why Blend?

Protection From Adversaries

Nomos’ privacy properties are intended to be robust in the face of malicious adversaries that may seek to gain information about Nomos proposers. The protocol was therefore designed with a variety of possible adversaries in mind, of varying ability to interact with the network. Active adversaries can modify the behaviour of nodes they control, while passive adversaries can only observe honest behaviour (”spying”). They may have a global view of the entire network and keep track of all its activity, or only have access to local information seen by nodes they’ve compromised. An adversary may be external to the protocol while monitoring its communications, or it may operate as a full-fledged participant. To provide substantial privacy to proposers, Nomos must protect against all these types of adversaries, with security analyses typically assuming worst-case behaviour - that is, so long as Nomos’ security assumption of a majority of honest stake is maintained.

Limitations of Private Leadership Elections

Private leadership elections are used in PPoS protocols such as Cryptarchia to confidentially select consensus leaders that have the right to propose a new block. In Cryptarchia, the election process is executed locally by each consensus participant, without the need to publish the schedule of leaders ahead of time. However, without additional protection, private leadership elections do not prevent a leader’s identity from being revealed after they propose a block. This property, known as unlinkability, provides neutrality for proposers who would otherwise find it prudent to engage in self-censorship when building a block.

Weak unlinkability is not only a major breach of privacy in its own right, but it also allows adversaries to learn a node’s relative stake. In Proof of Stake protocols, the likelihood of being chosen to propose a new block is dependent on each participant’s stake relative to the total. Therefore, an adversary observing the network over a prolonged period of time will be able to determine how often a particular node proposes a block. This rate can then be used to infer the node’s relative stake. According to calculations by the Nomos team, the time to infer (TTI) a given Nomos node’s stake without the Blend Network is about 24 days for a node with 0.1% stake. The property of ensuring that a proposer’s relative stake cannot be inferred is known as stake privacy.

Anonymity Properties of the Blend Network

The Nomos Blend Network serves to bolster unlinkability and, as a consequence, improve stake privacy. This is accomplished by passing block proposals between different nodes before being broadcast to the network, obscuring their origin. With various measures in place to make proposal messages look indistinguishable from each other, tracing any individual proposal becomes extremely difficult. Various ways to introduce anonymity by using a “hiding in the crowd” strategy are discussed in a previous blog article.

Using the Blend Network significantly improves Nomos’ privacy guarantees, as measured by the time it takes an adversarial observer to link (TTL) a proposal to its proposer and the time to infer (TTI) a proposer’s relative stake. For an adversary that controls 10% of the total stake and a message that is processed by three nodes before being broadcast, it takes more than 10 years to deanonymise a proposer and infer their stake with a probability of over 60% (for TTI) or 50% (for TTL). This estimate assumes that the node being observed has a relative stake of 0.1%.

Besides for its anonymisation properties, the Nomos Blend Network was designed to minimise bandwidth usage on the network compared to general-use mixnets, and to maximise decentralisation by involving all participating nodes in the obfuscation process. By doing so, the Blend Network increases the cost of attacking the network to deanonymise a block proposal without straining the network with high bandwidth usage.

Blend Network Overview

The Blend Network makes it difficult to link a proposer to their proposal by having the message travel between several nodes before being revealed. As a Nomos Bedrock Service, participation in the Blend Network requires staking and declaration using the Service Declaration Protocol (SDP). Participating core nodes must maintain a minimum number of connections with other nodes, and cannot exceed a maximum frequency of messages they can send - putting an upper bound on bandwidth usage.

While dedicated participation in the Blend Network is reserved for declared core nodes, proposals can also be sent to it from regular edge nodes. Such a proposer selects the Blend nodes that will form the Blend path for their data message, encrypts the message several times, and disseminates the encrypted message across the Blend Network. This dissemination involves a message being relayed to all nodes in the network in a peer-to-peer manner. Every node that receives a message attempts to decrypt it, only being able to do so if it is the first node in the proposal’s intended path.

Once the first node in the intended path receives the message, it decrypts one layer and disseminates the result for the second node to decrypt, and so on. Timing delays and artificial traffic are added to make it even more difficult to link a received message with the decrypted message. When the message reaches the last node in the path which finally decodes the message, this Blend node broadcasts the unlinked block proposal to the whole Nomos Network of validators, including edge nodes. An illustration of the dissemination process is shown in Figure 1.

Message Blending

Message blending is the primary way in which the Blend Network prevents observers from linking block proposers to their proposal messages. It involves hiding messages under several layers of encryption and randomly delaying their propagation at each stage. When a message is disseminated to all nodes, observers cannot determine which node was the intended receiver, even if they can identify the sender. Due to the layered encryption, observers also cannot determine which “hop” of the relay process the message is currently on. This decryption at each node in the path transforms messages, so the incoming and outgoing messages cannot be linked together based on their content.

A Blend Network message, in addition to the block data payload it is designed to transmit, includes additional cryptographic information that allows nodes in the path to decrypt and verify the correctness of the message. To construct a message, the sender uses shared secrets derived from the public keys assigned to every core node in the intended path to progressively encrypt the payload. Each step of this process also includes the transformation and progressive encryption of a constant set of blending headers, where blending header i will ultimately contain the decryption information required for the i-th node on the relay path. Together, the blending headers make up the encrypted private header. The public header consists of the plaintext information to be used by the first node in the path. The resulting structure of a Blend Network message is depicted in Figure 2.

When a core node receives a message, it will attempt to decrypt the private header based on a different shared secret it derives from the public header information. Once it verifies the validity of the header, the node will likewise decrypt the payload and transform the private header, reversing the transformation performed by the sender at this step. This involves “popping” the first blending header off the stack and moving much of its information into the public header, with the last header replaced with a deterministically-derived value. The resulting message is then ready to be decrypted by the next node in the path.

Random delays are the other component of message blending. If messages are rare (as in a low bandwidth network like the Blend Network), then an observer may be able to link even encrypted messages if they are disseminated in close succession. To prevent this, every message is assigned a random delay by the node processing it, with each message being released in the order it is received once its delay period has passed. This ensures that incoming and outgoing messages cannot be linked together based on their timing.

Cover Traffic

An important way that the Blend Network obscures network patterns is by producing indistinguishable messages within a “crowded” network. To increase this effect in an environment where proposals are relatively rare, the Blend Network also produces artificial cover messages. Cover messages do not contain any meaningful payload and are generated by core nodes to increase network noise and to blend in with data messages that contain real proposals.

Cover messages mimic the behavior of data messages, in that they are disseminated and processed by core nodes in the same manner. Core and edge nodes repeatedly encrypt random payload data to generate a cover message, which is then relayed to the next node in its selected path via dissemination. At each step in the transmission process, intended nodes decrypt, randomly delay, and disseminate cover messages without any indication that they may not be genuine. In fact, encrypted data and cover messages are completely indistinguishable even to adversary-controlled core nodes (a type of local observer). The hiding effect provided by cover traffic is illustrated in Figure 3.

To avoid the network getting congested with too much message traffic, the Blend Network places a quota limiting the number of cover messages produced by each node, as well as the number of nodes in the path of each cover and data message. Every message must therefore include a proof of quota in its public header, which is verified by the Blend nodes that process it to ensure that its creator did not generate too many messages. The Blend quota ensures that the Blend Network continues to operate with low bandwidth usage, and enforces a unique identifier for every message. This latter property makes sure that messages will be relayed without being viewed as duplicated and enables fair reward distribution.

Message Lifecycle

After discussing the different components of the Nomos Blend Network, it may be helpful to describe how it works from the perspective of an individual message. The following section will give a step-by-step overview of the path a data message takes from its creation until the block proposal is revealed to the network.

1. A node wins a consensus lottery and has a proof of leadership, which entitles the node to emit a data message. The payload of the message is a block proposal.
2. This node selects a path of Blend nodes through which to relay its message. The random and deterministic nature of the node selection process is verified by these nodes.
3. The node generates cryptographic keys and proofs, including proofs of quota, based on the nodes in its selected path.
4. The sender encrypts the payload and generates a message as described above.
5. The sender disseminates the message to its core node peers, which is relayed peer-to-peer until it reaches a node in the path that can decrypt its private header.
6. The Blend node verifies correctness of the decrypted header, including verifying the proof of quota.
7. The Blend node decrypts the message and assigns it a random delay. After this delay, the node sends the new message to its own peers.
8. Steps 5-7 repeat until the message reaches the final node in its path.
9. The final node extracts the block proposal from the message and broadcasts it to the entire Nomos network after a random delay.

Conclusion

By implementing layered encryption, random delays, and cover traffic, the Blend Network successfully obfuscates the connection between block proposers and their proposals. This solution not only ensures unlinkability but also makes inferring relative stake practically impossible, with a time to infer exceeding 10 years for a node with 0.1% relative stake. As a Nomos Bedrock Service, the Blend Network achieves these privacy benefits while maintaining low bandwidth usage and promoting decentralisation by involving all participating nodes in the anonymisation process. Through its carefully designed blending techniques, the Blend Network ensures that Nomos can deliver on its promise of truly private Proof of Stake blockchain technology.

Sources and Further Reading

• Stirring, Mixing, Blending: Different Approaches to Proposer Anonymity
• Blend Protocol