Owner: @Marcin Pawlowski

Reviewers: 🟢@Youngjoon Lee 🔺@Alexander Mozeika 🔺@Álvaro Castro-Castilla

Background

Please refer to Nomos Blend Network: Introduction [WIP Design] for more information about the Nomos Blend Network design.

Introduction

The Cover Traffic Module (CTM) mechanism is necessary to address an obvious shortcoming that every message in the system (that is not a drop message) is de facto a data message. Therefore, an internal observer learns about every data message, as every message that must be relayed is a data message by definition. This is the reason behind emitting cover messages, which we use to increase the anonymity set of messages and create additional confusion for the observer. In other words, by adding cover traffic for each round of the protocol we force the observer to guess if the message is a cover or data message.

The probability of guessing is described as a ratio of the number of data messages to the total number of messages $P(m=d)= {|d| \over |d|+|c|}$, where $|d|$ is the number of data messages in circulation, and $|c|$ is the number of cover message in circulation.

For simplicity and to limit bandwidth consumption we aim to add a single cover message for every consensus defined time slot during which a real data message can be generated. However, this is not a hardcoded assumption and can be changed at will.

Please note that data messages are generated at a rate that is noticeably lower than the rate of cover messages. We expect that the number of cover messages that are disseminated through the network must be high enough to add up to the anonymity set of messages for every single data message. Therefore the cover traffic is the primary source of the messages that are constituting the anonymity set.

Design

The design of the Cover Traffic Module is straightforward. It is a module that is connected to the Message Blending Module and generates cover messages that are interleaved with data messages on the network. The release of cover traffic messages is done according to the release schedule. The node performs a private lottery which outcome indicates at which time slot the node must release a cover message.

Below we present the Optimistic Cover Traffic design. We name this version optimistic as it does not implement any logic that is responsible for motivation and verification of the participation in the protocol.

<aside> 💡

Please note, that a more sophisticated design requires additional accountability mechanics. This mechanics is going to be provided by the Nomos Blend Network: Tier 4 — Economic Incentives [WIP Design]. Due to the fact that we aim at introducing complexity in a gradual manner, we focus on presenting the most simple mechanism that provides core functionality.

</aside>

Assumptions

1. There is a global list of nodes $N$.
2. The list $N$ is fixed for duration of an epoch $E$.
3. Each epoch $E$ is constructed of $S$ time slots.
4. For each time slot $s \in S$ a cover message is generated with probability $\pi_{C}$.
5. There is a parameter $\mathcal k$, that defines expected number of hops that should be used by cover message. Please note, that $\mathcal k$ can also be seen as a cover traffic multiplier, which multiplies the number of messages that are transmitted through the network and add up to the anonymity set.
   1. $k = 1$, has the minimal impact on the bandwidth.
   2. $k = 2$ can be seen as better choice for the anonymity as successful unwrapping of a cover message does not immediately inform the node about the fact that the message is cover traffic. Therefore, we might consider dropping the $\pi_{C} \approx 1/2$ and setting $k = 2$ to have better anonymity (however the same message anonymity set) at the cost of the same bandwidth.
   3. $k = \dot k$, where $\dot k$ parameter defines the number of hops that are most commonly used, can be considered as even better from the perspective of the anonymity as the cover traffic transmission pattern will follow the most common message data transmission pattern. Then $\pi_{C} \approx 1/k$ could be use to have the same bandwidth consumption and message anonymity.
   4. $k \gt \dot k$ improves the anonymity of the messages that are using more hops than the most commonly used number of hops. In other words, in order to cover messages that require more hops than expected, we need to increase the number of hops for cover messages.
   5. We also note that there is $\widehat k \ge k$ parameter that defines the maximal number of hops that are supported by the protocol. We currently assume that $\widehat k = 3$. The $k = \widehat k$ as the best choice for the anonymity which also requires reduction of the cover message generation probability to $\pi_{C} \approx 1/{\widehat k}=1/3$, to uphold the same bandwidth consumption.