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 Message Blending Module (MBM) is a mechanism that enables message unlinkability. It is constructed of the following components.

• First is the Cryptographic Processor (CP), responsible for performing cryptographic operation on the message. The result of this operation is a bitwise message indistinguishability. In other words, the input message cannot be linked back to the output message based on the examination of their binary representations.
• Second is the Temporal Processor (TP), responsible for randomly delaying the release of the message. The goal of the TP is to remove statistical dependencies between the fact that the message arrived to the node and the action of the node. In other words, it aims at unlinking the event of receiving a message and the event of sending the processed message based on time analysis.
• Third is the Message Router (MR), which decides where the message outputted by the CP must be transferred. The MR is a mechanism responsible for deciding where the message should be moved internally in the system, that is, it can be transferred to the TP, or another module, or even to other parts of the system.

Design

Overview

The Message Blending Module (MBM) is constructed from three building blocks.

• Cryptographic Processor (CP) is responsible for cryptographic operations performed on messages.
• Message Router (MR) is responsible for relaying the message to the correct part of the system according to the message content.
• Temporal Processor (TP) is responsible for introducing a random delay before the message is sent out.

The workings of the MBM module is straightforward.

1. A message is delivered to the Cryptographic Processor (CP). The message may come from:
   1. An abstract input which is not defined in this document. In practice, when implemented, it will be a block proposal or block selection.
   2. The Persistent Transmission Module, then the message is received from the network which is cover or data message that must be processed.
   3. The Cover Traffic Module, then the message is cover traffic.
2. The message is processed by the CP, where:
   1. If the message is coming from the network (received through the PTM) then it is decrypted.
   2. If the message is generated internally (received from the Input or CTM) then it is encrypted.
3. The CP transfers the message to the Message Router (MR), who then forwards the message according to the context of the message. That is:
   1. If the message is originating in the node then it is forwarded directly to the PTM.
   2. Otherwise:
      1. If the message is encrypted then it is sent to the TP.
      2. Else, if the message is not encrypted then:
         1. If it contains a block proposal, then send it to the TP and later release to the Broadcast Network for the consensus-wide propagation.
         2. If it contains information that are important for the logic of a different module, then the message is forwarded to the appropriate module (for example, for incentivization purposes it may be routed to the Tier 4). We are leaving it undefined at the moment.