Initial Test Suggestion

<aside> ⚠️ Please note that some of the current Nomos design is subject to change substantially. Especially, the Nomos team is considering the new Mixnet design that is much simpler and aligns well with the vision of Nomos. Therefore, this document tries to focus on only generic metrics that are likely to be useful for both the current and the future designs.

</aside>

Goals

This is a summary of goals that we want to achieve by the collaboration with DST. The details can be found in the following sections.

The first collaboration will focus on the network layer of the Nomos Base Layer.

• Maximum bandwidth that a node can handle
• Similarity of ingress/egress between nodes
• Latency for messages to be propagated to the (entire) network

Detailed Expected Outputs

Bandwidth

• Purpose

  • By checking how much bandwidth that a node can handle, we expect to find the optimal amount of cover traffic in terms of performance (not from the perspective of privacy) and the optimal number of mix nodes in each mix layer.

  <aside> 💡 Please note that a nomos-node binary acts as both a mix node (if selected) and a gossipsub node. That is, a node that is selected as a mix node will handle more packets than nodes that are not selected as mix and only participate in gossipsub. That is, the maximum bandwidth of the network may be bounded to the maximum bandwidth of a node that participates in both mix and gossipsub.

  </aside>

• Metrics

  • Bandwidth (KB/s) that a node can handle as the amount of traffic increases
    • There are two ways to increase traffic.
      • Increasing real traffic (block proposals)
        • By adjusting slot length and active slot coefficient: TODO @Youngjoon Lee
      • Increasing cover traffic (but this affects only mix nodes because cover traffic is not broadcasted via gossipsub in the current design)
        • By adjusting packet emission rate: TODO @Youngjoon Lee

Ingress/Egress Similarity

• Purpose

  • The current Mixnet design aims to continuously make all nodes have the similar amount of network ingress/egress for sender online unobservability, receiver online unobservability, and sender-receiver unlinkability to disturb observations from global passive adversaries (aka. GPA). Every node always emit real or cover messages according to the rate configured. It is not a constant rate, but a Poisson rate. In other words, if we observe the network for a long time, we expect to see all nodes emit the similar amount of messages. If some nodes handle more ingress/egress significantly than others, it may indicates that our Mixnet design/implementation has any flaw.

  <aside> 💡 Nodes that are selected by a mix node will have more ingress/egress than nodes that are not selected (that participate only in gossipsub) because all traffic is gathered to mix nodes before being broadcasted via gossipsub. But still, all nodes selected as a mix node should have the similar amount of ingress/egress.

  </aside>

• Metrics

  • Ingress and Egress (KB/s) of each node in the network over time
    • Check whether there is any node that has different patterns

Latency

• Purpose
  • To check if there is any unexpected factor in Mixnet that delays the message propagation.
  • To check how the number of nodes in the network affects the latency of gossipsub after Mixnet
  • To find the optimal parameter for Mixnet: packet emission rate, packet delay, and route length
    • This is a low priority for now because the Nomos team is designing the new Mixnet architecture that will probably have different parameters.
• Metrics
  • Latency for a message to arrive in the exit mix layer since it is sent by a mix client
    • Each message has a unique message ID that is encapsulated in Sphinx packets by a mix client (a message sender). Intermediate mix nodes can’t see the message ID because it’s encapsulated. Only the final mix node in the exit layer can see the message ID. We need to figure out how to measure the latency between the mix client and the final mix node. For example, they can print the message ID in the logs, but I’m not sure if these logs can be used to measure latency.
  • Latency for a message to arrive in all (or a certain threshold of) nodes in the network via libp2p gossipsub since it is broadcasted by the exit mix layer.
    • I would like to ask if DST team has a know-how to measure the latency until a message is disseminated to the certain threshold number of nodes in the gossipsub network.

Notes