BLEND-PROTOCOL

Timeline

• 2026-10-14 — 949faa9 — [RFC] Mantle: Bound operation data payloads (#467)
• 2026-09-29 — 96e9586 — [RFC] Blend: Bound connection traffic at the receiver (#421)
• 2026-09-11 — 7244d3b — [RFC] Blend: Failure Detection and Reaction (#412)
• 2026-09-11 — b7301a6 — [RFC] Mantle: Enable basic EmPoWering machinery (#400)
• 2026-09-03 — e2e9e0f — [RFC] The Epochs active and withdraw_at Record (#422)
• 2026-08-31 — 5587d1e — [RFC] Replace the BLAKE2b-based PRNG with ChaCha20 (ChaCha20Rng) (#425)
• 2026-08-31 — 5fa8ee4 — docs(blockchain): compress the block proposal with 16-byte transaction reference prefixes (#389)
• 2026-08-26 — 5e42374 — docs(blockchain): specify uint32 for epoch number (#420)
• 2026-08-25 — 796baaa — docs(blockchain): fix blend token evaluation and active message encoding (#405)
• 2026-08-24 — 7c70a38 — docs(blockchain): fix CSPBRG/CSPRBG typos in Blend Proof of Selection (#414)
• 2026-08-19 — a2a85cb — RFC Bedrock: Cryptarchia with uncle references (#385)
• 2026-07-03 — 709cf7f — Bedrock-RFC: Remove Concept of a Session (#365)
• 2026-05-29 — 67e498e — chore: fix math issues (#350)
• 2026-05-28 — 15f410b — chore: fix math issue (#349)
• 2026-05-28 — d45eed2 — Chore: mirror blochain specs into github/mdbook (#347)

Revision History

Introduction

The privacy of a Proof-of-Stake (PoS) system is defined by the inability of an adversary to learn:

1. Which node proposed a given block. This property is known as unlinkability.
2. How much stake a node has. This property is known as stake privacy.

While a node can be de-anonymized based on the content of its block proposals, this angle of attack is mitigated by Private Proof of Stake systems. However, a node can also be de-anonymized based on its network activity. An adversary can observe the node’s network behavior and link the node to the proposal it sends. Because a node’s relative stake correlates with its network activity in all PoS systems, observing a node’s behavior for some time enables the adversary to estimate the node’s stake. It is this network-based de-anonymization that is addressed by the Blend Protocol, allowing Logos Blockchain to achieve a truly Private PoS system.

The Blend Protocol is designed as a way to allow nodes to send block proposals that cannot be linked back to them. The idea is to make it very difficult and costly for someone trying to figure out who sent a proposal and what stake they hold. Because the protocol spreads messages out over many nodes, it becomes even harder to attack, which enhances network privacy. The Blend Protocol increases the time to link the sender to the proposal by at least times, which makes the stake inference highly impractical (Impact of the Blend Protocol on the Time to Link and Time to Infer the Stake).

The Blend Protocol targets a specific set of requirements that differentiate it from mixnets and other general-purpose anonymous communication systems. It achieves probabilistic unlinkability in a highly decentralized environment with low bandwidth cost but high latency. It hides the sender of a block proposal, making it costly for an adversary to learn its origin with high confidence. The cost of attacking the network is high due to decentralization and the economic value of stake needed to add a single node. The protocol works well even when many nodes are involved and not much data is being sent, but it may take longer for proposals to be delivered.

In this document, we present a succinct description of the Blend protocol, which is responsible for providing censorship resistance and network-level privacy for the block producers of the Logos Blockchain Bedrock ([Overview] Bedrock Architecture), the foundational layer of Logos Blockchain.

Privacy of Proof of Stake Systems

All Proof of Stake (PoS) systems have an inherent privacy problem — the stake of the node determines the node’s behavior. That is, by observing the node’s behavior (or impact of the node on the system), one can infer the node’s stake. More precisely, the stake that is discovered is relative to the stake involved in the PoS — stake that is used for the PoS purposes by the adversary. There are two things that can be observed:

• The content of the blocks.
• The network activity of the node.

Observing the content of the blocks makes it possible to execute a tagging attack. The consequence of a successful attack is that the stake of a node can be learned by controlling which transactions are included in the proposals built by the node. This is achieved by submitting a transaction only to the mempool of a targeted node — thus creating a difference in the transactions seen by this node compared to the other nodes — and observing the time when this transaction is included in the block.

The tagging attack can be addressed by designing a mempool in such a way that the node has an attestation that the transaction was seen by the majority of the network, which makes the adversary’s ability to manipulate the view of the node severely limited.

Observing the network activity of the node leads to an easier but still powerful attack that can also disclose the node stake even after the tagging attack is mitigated. That is, a node’s stake can be inferred by observing the frequency of the messages node emits during a particular portion of time — this attack is addressed by the Blend protocol.

The Blend protocol achieves network-level leader-proposal unlinkability with statistical indistinguishability. That is, a leader cannot be linked back to its proposal and cannot be distinguished from its peers based on its network behavior. This property translates into an increased difficulty of learning the node’s stake through the node’s network behavior.

To have a truly privacy-preserving system, we need to apply both techniques simultaneously. Solving one without the other will not suffice.

Terminology

Message Types

• Data message is a message whose payload carries content the network must act on. Two kinds are defined: a block proposal, generated by a consensus leader, and a Mantle transaction, generated by any participant. Any data message is indistinguishable from any other message until it is fully processed by the network. The privacy of the sender of a data message is what the protocol aims to protect.
• Cover message is a message that contains meaningless content, and its goal is to create noise (anonymity pool) in which data messages can hide. The cover message is indistinguishable, from the network perspective, from a data message.

Protocol Actors

• Logos Blockchain node is a node that is part of the Logos Blockchain network.
• Core node is a Logos Blockchain node that declared its willingness to participate in the Blend Network Service through the Service Declaration Protocol (SDP — Service Declaration Protocol). The core node is responsible for core protocol functions such as cover message generation, message relaying, message processing, and message broadcasting. Additionally, the core node generates data messages that are blended with the rest of the messages generated by the network.
• Edge node is a Logos Blockchain node that is not a core node. Edge nodes connect to core nodes through which they send messages (block proposals or transactions).
• Block proposer node is a core or edge node that is generating a new data message carrying a block proposal.
• Blend node is a core node that processes a data or cover message.

Node Types

• Honest node is a node that follows the protocol fully.
• Lazy node is a node that does not follow the protocol due to a lack of incentives and only takes part in the protocol when it is directly beneficial to the node.
• Malicious node is a node that does not follow the protocol regardless of incentives.
• Unresponsive node is a node that does not follow the protocol due to technical reasons, such as a lack of connectivity or malfunction.

Adversary Types

• Passive adversary is an adversary that cannot modify the behavior of a node, but can only observe.
• Active adversary is an adversary that can modify the behavior of a node in addition to observing the network.
• Local observer is an passive adversary with a limited view of the network and with the ability to observe the internals of a limited number of nodes.

Networking

• Blending is an operation of cryptographically transforming and randomly delaying messages. This shuffles the temporal order of incoming and outgoing messages so that they cannot be linked back to the sender based on the network statistical analysis or message content inspection. The key difference between blending and mixing (as defined in mixnets) is in the source of the anonymity. In mixing, the anonymity comes from processing multiple messages by the same node, while in blending the anonymity comes from processing the same message by multiple nodes.
• Broadcasting is the process of sending a block proposal extracted from a data message to all Logos Blockchain nodes.
• Disseminating is the process of relaying messages by core nodes through the network to edge and core nodes.
• Communication failure is an event when a message that is disseminated through the network is not finally broadcast. The communication failure might be due to lazy, malicious, or unresponsive nodes.
• Anonymity failure is an event when an adversary can link the sender to the broadcast message.

Time

• Epoch is a period that is defined by the consensus. It lasts for slots, each slot lasting 1 second. A new block is proposed for each slot with a probability of , which translates to blocks, as on average, every slots a single block is proposed.
• Round is the primitive measure of time in the protocol. It defines a period during which a node can emit a new message. The definition of a round is also important for defining the message releasing logic, which handles the randomized emission delay for processed messages. In this version of the protocol, the length of the round is 1 second (an equivalent of a single slot).

Overview

The Blend Protocol is a peer-to-peer anonymous broadcasting protocol with cryptographic and timing obfuscation capabilities. The main purpose of the Blend protocol is to increase the difficulty of linking any block proposal to the node that proposed it, maintaining privacy before and after the election, which increases the censorship resistance and privacy of the Logos Blockchain Bedrock. More precisely, the Blend protocol attempts to hide that the consensus leader is sending a leader message (a block proposal) by unlinking the sender from the message through cryptographic and timing patterns obfuscation mechanisms.

The Blend Protocol is one of the Logos Blockchain Bedrock Services. It consists of nodes that declare their intention to serve as core nodes through the Service Declaration Protocol (SDP, Service Declaration Protocol).

The protocol works as follows:

1. Core nodes form a network by establishing encrypted connections with other core nodes at random.
2. A block proposer node selects several core nodes and creates a data message (containing a block proposal) that can be processed only by the set of selected core nodes (according to the order given by the block proposer node).
3. The block proposer node sends the data message to its neighbors (core nodes). If the block proposer is an edge node, it connects to randomly selected core nodes to send the data message.
4. Core nodes disseminate (relay) the message to the rest of the network.
5. Core nodes generate new cover messages every round, which are blended with other messages.
6. When the data message reaches a blend node (designated core node), then it is processed by the node, that is:
   1. It is cryptographically transformed, so the incoming and outgoing messages cannot be linked together based on the content of the message.
   2. It is randomly delayed, so the outgoing message cannot be linked to the incoming message based on the timing observation of the message.
7. The blend node disseminates the processed message to the network so that the next selected blend node can process the message.
8. When the message reaches the last blend node, then:
   1. The blend node processes the message.
      1. Decrypts the message.
      2. Delays the message.
   2. It extracts the message payload (the block proposal).
   3. It broadcasts the block proposal to the Logos Blockchain network.

Below we present a simplified diagram of the protocol, which depicts how the protocol is evolving in time.

_{The sender is an edge node or a core node. The sender sends a data message to its neighbor (a core node). In addition to data message, core nodes send cover messages. The neighbor/relayer relays messages to other core nodes. The blend node relays all received messages immediately, but it also relays messages that it processed once every release window. There is no delay when disseminating/relaying a message due to the processing of messages.}

The current version of the protocol is optimized for the privacy of core nodes. The level of privacy that edge nodes gain is not as high as core nodes. The problem with maintaining a high level of privacy for edge nodes is that it would require increasing the delay of the network significantly (which is bad for the resilience of the consensus) or increasing the number of messages that an edge node emits (which is bad for the core nodes’ bandwidth). This is acceptable as we assume that edge nodes are mobile and do not have any static long-term network identifier. Therefore, they cannot be tracked easily. Moreover, edge nodes should have lower stake than the core nodes so they will connect to the network sporadically, which makes identifying them even harder.

Network

In this section, we briefly discuss the way the network is created and maintained.

Bootstrapping

The process of creating a network is called bootstrapping.

At the beginning of an epoch, all core nodes retrieve a fresh set of core nodes’ connectivity information from the SDP protocol. Then each core node selects at random a set of other core nodes and connects to them through fully encrypted connections. After some time, when all core nodes connect to other core nodes, a new network is formed.

Minimal Network Size

The minimal network size is . This is the minimum number of nodes (unique ProviderIds from declarations) that must be retrieved from the SDP to consider the Blend protocol safe to use.

Fallback

If the minimal network size is not reached, nodes must not use the Blend protocol. In such cases, nodes must broadcast data messages directly, bypassing the Blend network.

Maintenance

A core node reads at most a share of messages from each connection per round, sized to what the slowest node the protocol targets can process, sends at most the same share on each, and keeps a connection only while its neighbor delivers. It maintains its peering degree and blacklists a neighbor only for a fault the neighbor is answerable for (Connectivity Maintenance).

Messages

The protocol defines two types of messages: data, and cover.

• Data messages contain a meaningful payload, which is used by the Logos Blockchain network to advance the Bedrock consensus. The mechanisms that trigger data message generation are external to the Blend Protocol: the leader election process of the Bedrock consensus for a block proposal, and a participant submitting a transaction.

• Cover messages do not contain any meaningful payload and are generated by nodes to increase network noise and to blend with data messages. Cover messages mimic the behavior of data messages, meaning that they are disseminated and processed by core nodes in the same manner as data messages. Data and cover messages are indistinguishable, which means that a local observer cannot tell the difference between the data and cover message by looking at it.

  Cover messages make learning the communication patterns of core nodes harder, even from the perspective of a local observer.

Generation

A message is generated according to the following logic:

1. The node generates a message payload :
2. The payload is a block proposal or a transaction, then a data message is generated.
3. The payload is a random number, then a cover message is generated.

Both types of messages are created at random by independent processes.

2. The payload is cryptographically processed as follows:

3. core nodes are selected at random from the set retrieved by SDP,

4. The message is generated, which encapsulates the payload in layers of encryption. Each ’th layer can be decrypted by the ’th node from the selected set.

5. The message is relayed.

Relaying

A message is relayed according to the following logic.

• If the message is the outcome of the generation logic, then the message is sent to all neighbors (core nodes) of the node.

• If the message is the outcome of the processing logic, then:

  1. If the message is not unique, then the message is dropped;
  2. The message is randomly delayed;
  3. Then the message is sent to all neighbors (core nodes) of the node.

• If the message is received from the neighbor:

  1. If the message is not unique, then the message is dropped;
  2. Else, the message is sent out to the rest of the node's neighbors (core nodes) and concurrently is processed by the node.

Processing

1. A message is received by a node.

2. If the node is the ’th node, then:

3. The message is decapsulated from the message;

4. The message is relayed.

5. Else, the message is discarded as the node cannot process the message. Note that the message was previously relayed according to the Relaying logic.

6. After decryptions, the last node can determine the type of the message by examining the payload :

7. If the payload contains a block proposal, then it is broadcast to the entire Logos Blockchain network;

8. If the payload contains a transaction, then it is submitted to the node's mempool;

9. Otherwise, the message is discarded.

Broadcasting

Broadcasting is a process of delivering a block proposal extracted from a data message to the entire Logos Blockchain network by the core node that received it. Only content that is constructed correctly can be broadcast. Any badly constructed content must be rejected. The logic behind the verification of the content is out of the scope of the Blend protocol. It is defined by the Logos Blockchain Bedrock ([Overview] Bedrock Architecture).

A transaction extracted from a data message is not broadcast by this protocol. It is submitted to the mempool of the node that received it, and the mempool disseminates it as its own rules specify.

Failure Detection and Reaction

A payload the Blend network fails to deliver is broadcast directly by its sender, without the unlinkability the network provides.

Rewarding

A node must be encouraged to follow the protocol, which means that it must be rewarded for the contribution it is making. Otherwise, honest nodes might become lazy nodes, nodes that are not motivated to follow the protocol due to a lack of incentives. In simple terms, a lazy node will not work until it gets paid. Therefore, we motivate the following set of protocol actions:

1. Message generation: a node must be motivated to generate messages according to the protocol, where generation means that a new message is created that is not the outcome of the processing. This is especially important for cover messages. Data messages already incentivize the node that is generating them: a block proposal rewards its sender directly through the consensus-defined rewarding mechanism (Anonymous Leaders Reward Protocol), and a transaction is sent because its sender wants it included in a block.
2. Message relaying: a node must be motivated to relay every received message, where relaying means that a node forwards all messages it received to its neighbors to deliver messages to their next destinations (blend nodes).
3. Message processing: a node must be motivated to process every received message, where processing means that a node has decapsulated and delayed the message.
4. Message broadcasting: a node must be motivated to broadcast any data message it processed, where broadcasting means that a node sends the processed message to the Logos Blockchain network broadcasting channel.

Motivations

We address the above motivations in the following manner:

1. Cover message generation is motivated by the node’s individual need for privacy.

• The node must generate and emit cover messages to keep itself private. Otherwise, it will lose the protection given by the protocol.
• The node must also limit the number of cover messages to generate to be indistinguishable from all other nodes. That is, for every block proposal a node generates it must generate one less cover message; otherwise the node could be distinguished from other nodes based on the number of emitted messages.

2. Message relaying is motivated by monitoring the connection quality with the node by its neighbors.

• The node must relay messages according to a network-defined limit. Otherwise, the neighbors will close the connection with the node. This will lead to a network-level isolation of that node, and if the node is isolated, it will not receive any messages to process, so it will earn no rewards.
• The node must relay processed messages. If it does not, the node that generated the message will learn this fact and might stop addressing messages to the relaying node. This is possible because a node can select the recipients of the messages freely but from a random subset of all nodes.

3. Message processing is motivated by calculating a reward as a node’s activity function.

• The node collects message-unique information (blending tokens); the number of tokens collected increases the chances for a reward. The node receives a base reward after showing that it performed a minimal amount of work, which is verified by the step 3 of the Rewarding Mechanics.
• The node that collects more tokens increases its chances of winning a premium reward through a lottery mechanism. The node receives a premium reward after showing that it performed extra work, which is verified by the step 4 of the Rewarding Mechanics.
• The distinction between the base and premium reward is necessary to reward nodes for the work they perform and to continue to motivate them. The base reward provides a level of fairness, meaning every node should receive it if they were active enough. However, a lazy node might stop providing service after collecting just enough tokens to get the reward, which might be less than what an honest node collects. Therefore, the premium reward continues to motivate the lazy node to work more and collect more tokens. The premium reward is paid on a randomized competition basis, which cannot be biased by the node.

4. Message broadcasting is motivated by increasing the base reward.

• The node is motivated to broadcast the block proposal message as each block proposal that extends the chain directly increases the Blend Network Service income pool. That is, the block rewards and/or fees for each block are summed up and form the service income pool, which is then shared with active core nodes.

There is a subtle distinction between the broadcasting and relaying motivation logic:

• The broadcasting action is motivated by the fact that each broadcast block is contributing to the service income pool .
• The relaying action is motivated by a fear of losing a reward, which impacts the chances for winning a reward (node’s activity ).
• The reward is calculated as a multiplication of both .

Therefore, the nuance between such a distinction is with the “direction” of the motivation. For broadcasting, it is positive (earning), and for relaying, it is negative (losing).

1. Messaging abuse is limited by a quota construction.

• The quota limits message generation, which helps maintain network health and enables fair reward calculation.
• This is achieved by limiting the number of unique encryption keys that can be used for message generation. That is, processing a single message consumes a number of keys, which effectively limits the number of messages that can be processed by the network.

Mechanics

1. Every node during the epoch of the protocol collects some bits of information, which are called blending tokens, from processed messages.
2. After the epoch, every node selects a single blending token that has a certain property: it is most similar to the next Epoch Randomness. This token is registered on the ledger.
3. Every node that submitted a token receives a base reward if the token’s similarity to the next epoch randomness is above a certain (predefined) threshold (called the activity threshold).
4. Every node that submitted a token receives a premium reward if the token is in the set of the most similar tokens (as defined below) to the next epoch randomness.

Protocol

Network Maintenance

In this section, we present the part of the protocol responsible for maintaining the network connectivity.

_{A simple diagram representing the Blend Network, where core nodes (denoted as C) form a Core Network (bold connections) and edge nodes (denoted as E) form an Edge Network (thin connections).}

Since the network is built based on two types of nodes, we define two network types. The Core Network is built with core nodes, while the Edge Network is built with edge nodes that connect to the core nodes. This distinction is necessary as the process of bootstrapping and maintaining each network is different.

Core Network

Bootstrapping

The bootstrapping defines the process of creating the network, which happens at the beginning of each epoch.

1. A core node at the beginning of an epoch retrieves a set of core nodes’ information from the SDP protocol (Service Declaration Protocol).
2. If the number of core nodes is below the minimum number of nodes (Minimal Network Size), then stop and use regular broadcasting.
3. It starts opening new connections.

   1. It selects at random (without replacement) a node from the set of core nodes, excluding the identities that are on its blacklist (Connectivity Maintenance).

   2. It establishes a secure connection with the selected node, that is:

      1. It opens a TLS connection using ephemeral keys to the node according to the Connection Details.
      2. It identifies its neighbor using the Neighbor Distinction Process (NDP).
         1. The node learns that the neighbor is a core or an edge node.
         2. The neighbor learns that the node is a core node.
         3. The node stops connecting to selected peer after reaching the maximum number of tries ( parameter: Core Node Parameters). Then a new random peer is selected.

   3. It repeats the above steps while Connectivity Maintenance requires it to open a connection.

4. It maintains all connections as defined in Connectivity Maintenance.
5. If two nodes open two connections with each other, so that both have incoming and outgoing connections to the same neighbor (core node), then:
   1. The node with the lower public key value (provider_id from SDP) must close the outgoing connection to the node with the higher public key value.
   2. The node with the higher public key value (provider_id from SDP) must close the incoming connection from the node with the lower public key value.

Public key values are compared lexicographically. Specifically, we use the libp2p peer_id format of the provider_id and apply standard Base58 encoding (to_base58() libp2p function) for the comparison.

Maintenance

A core node maintains its connections during the epoch as defined in Connectivity Maintenance.

Edge Network

Bootstrapping

The edge network is maintained by core nodes because edge nodes can only establish connections with core nodes.

The bootstrapping logic of an edge node:

1. At the beginning of an epoch, the edge node retrieves a set of core nodes’ information from the SDP protocol.
2. If the number of core nodes is below the minimum number of nodes (Minimal Network Size), then stop and use regular broadcasting.
3. Whenever an edge node needs to send a message, it selects at random (without replacement) a node from that set.
4. It establishes a secure connection with the selected node.
   1. It opens a TLS connection using ephemeral keys to the node according to the Connection Details.
   2. It identifies itself and authenticates using the Neighbor Distinction Process.
      1. A core node learns that the neighbor is an edge node.
      2. An edge node confirms that the neighbor is a core node.
      3. An edge node must drop the connection if the neighbor is not the intended core node. Please note that technically it is done during TLS handshake, where the handshake will fail if the core node is using a different key than provided in the SDP declaration.
5. When the connection is established, it sends the message and closes the connection.
6. Concurrently to the above, it repeats steps 4 and 5 until it is sends the message to a number of nodes equal to the communication redundancy number defined by the edge node. It stops connecting to each node after a certain number of tries, which is defined by the edge node.

Message Lifecycle

Generation

Generation of a message is triggered by any of the following events:

1. A core or edge node won 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. A cover message is released at random by the core node, as described in Cover Message Schedule section. The payload of the message contains random data.
3. A node has a Mantle transaction to submit and holds an unused quota allowance. The payload of the message is the transaction.

When this happens, a number of messages (limited by the Quota) are generated as follows:

1. A number of keys are generated according to the Key Types and Generation.
   1. Each key uses a message-type-specific allowance as described in the Quota.
   2. The correct usage of the allowance is proven by Proof of Quota.
2. The payload of the message is formatted according to the Payload Formatting.
3. The above set of keys is used to encapsulate the payload of a message according to the Message Encapsulation Mechanism.
   1. Each key is used for a single encapsulation of a message, which can be processed (decapsulated) by a single node.
   2. The node selection is random and deterministic, and is provable by Proof of Selection. This restricts the possibility of targeting a specific node by an adversary. The adversary is limited only to a subset of keys that can be used to generate a message to a particular node.
   3. The message is formatted according to the Message Formatting.
   4. The message is released by the node to the Blend network according to the Releasing logic.
      1. Core nodes send the message to their neighbors.
      2. Edge nodes send the message to randomly selected core nodes.

For a complete description of the generation logic, refer to Generation.

Relaying

When a node receives a message from one of its neighbors, it does the following:

1. Checks the public header of the message, that is:
   1. The version of the message must be equal to 0x01; if not, then discard the message.
   2. The proof of quota nullifier must be unique; if not, then discard the message.
   3. The signature must be valid; if not, then discard the message.
   4. The proof of quota must be valid; if not, then discard the message and do not relay it.
2. The message is released to the network as defined in the Releasing section.
3. Concurrently to the above, the message is handled by the processing logic as defined in the Processing section.

For a complete description of the relaying logic, refer to Relaying.

Processing

Every message that passes Relaying verification is processed as follows:

1. The message is decapsulated as defined in the decapsulation section of the Message Encapsulation Mechanism. This means the node successfully decrypted the blending header and can now read and process it.
2. If decapsulation succeeds, the decrypted blending header is processed:
   1. If the proof of selection is invalid, discard the message.
   2. Information is extracted from the message and saved as proof of processing a blending token and is used to claim rewards.
   3. If the last flag of the decrypted blending header is turned on, the message is completely decapsulated. The payload can then be processed according to the Payload Formatting:
      1. If the type is a block proposal, add the payload to the broadcasting queue.
      2. If the type is a transaction, submit the payload to the mempool; a payload that does not parse as a transaction is discarded.
      3. If the type is a cover message, discard the payload.
   4. Otherwise, examine the decapsulated header:
      1. Verify the proof of quota is valid; if not, discard the message.
      2. Verify the signature is valid; if not, discard the message.
      3. Verify the public key is unique; if not, discard the message.
      4. Format the message according to the Message Formatting.
      5. Attempt a subsequent decapsulation to validate whether the node is the recipient (return to step 1). This must be done recursively to remove all consecutive encapsulation layers where the node is the intended recipient.
      6. If the decapsulation fails (meaning no more layers remain), randomly delay the message and release it to all neighbors.
3. If decapsulation fails, return the appropriate decapsulation failure message.

For a complete description of the processing logic, refer to Processing.

Broadcasting

Every payload that is added to the broadcasting queue is processed as follows:

1. The payload is checked to be structurally well formed: it must parse as a block proposal. A payload that fails this check is discarded. Whether the parsed proposal is valid is not evaluated here; that judgement belongs to the consensus logic the proposal is handed to in the next step.
2. The proposal is extracted from the payload and is broadcasted to the Logos Blockchain broadcasting channel after a random delay.

For a complete description of the processing logic, refer to Broadcasting.

Failure Detection and Reaction

This section defines how a node detects that the Blend network is not delivering its data messages and how it should react.

Detection

Delivery failure. The sender of a data message knows its payload: the identifier of the block it proposed, or the hash of the transaction it submitted. If the sender does not observe that payload on the broadcasting channel within the message traversal time (Transition Period), counted from the round in which the message was released, it must treat the message as lost.

Direct Broadcast

Nodes that value privacy above block rewards should disable this fallback and abstain from participation until Blend recovers.

When a sender detects a Blend network failure to broadcast, the sender broadcasts the payload directly to the Logos Blockchain broadcasting channel.

The deadline is the message traversal time, so a directly broadcast payload never reaches the network earlier than a delivered one. Block Proposal Reconstruction assumes that delay for the transactions a proposal references.

Rewarding

Every active core node receives a reward. The activity of a node is verified in a probabilistic manner, where a more active node has higher chances of getting a reward and a premium reward. To claim a reward, the node must do the following:

1. Generate a proof of its activity for a specific epoch as defined in Activity Proof. The proof confirms that the node was processing messages during the epoch. The node activity confirmation is probabilistic, and the odds increase with the number of collected blending tokens.
2. Use SDP active functionality (Active) to request a reward as described in Rewarding Distribution Logic, that is:
   1. Create an Active Message.
   2. Send it as an active message (Active Message).
3. The reward is calculated as defined in Reward Calculation, that is:
   1. The number of correct active messages is calculated.
   2. The number of correct and winning messages is calculated, where a winning message is defined by a lottery mechanism.
   3. Every node that sends a correct active message receives a base reward.
   4. Every node that sends a correct and winning message receives a premium reward.
4. The rewards are distributed by the mechanisms provided by the Service Reward Distribution Protocol.

Details

Notation

• denotes the peering degree of a core node;
• denotes a maximal delay time between two release rounds;
• denotes a maximum number of processing rounds for a single message;
• denotes a number of rounds in an epoch;
• denote the observation window expressed in the number of rounds;
• denote the number of messages a core connection carries per round;
• denote the number of messages per second the slowest node the protocol targets processes;
• denote the number of messages a node reads from a core connection in a round;
• denote the number of connections with edge nodes a node accepts in a round;
• denote a frequency at which cover messages are generated per round;
• denote a frequency at which block proposals are generated per round;
• denote a frequency at which messages carrying a transaction are generated per round;
• denote the expected number of cover messages that are generated during an epoch by the core nodes;
• denote a redundancy parameter for cover messages, defining the number of “replications” of the same message;
• denote a redundancy parameter for block proposals, defining the number of “replications” of the same message;
• denote a set of core nodes providing the Blend service for the epoch returned by the SDP protocol (Service Declaration Protocol);
• denote a number of core nodes providing the Blend service;
• is a cryptographically secure pseudo-random number generator, implemented as a ChaCha20-Based PRNG Construction;
• denotes the network absorption, the maximum time a message spends crossing the network on one hop;
• denotes the message traversal time, the time a message takes to cross the network;

Global Parameters

• , as defined in the Delaying section below.
• , the number of rounds per epoch.
• , the maximum number of blending operations of a single message.
• , the expected number of blending operations for each cover message;
• , the expected number of blending operations for each data message;
• rounds, the network absorption of one hop.
• rounds, the message traversal time, as derived in the Transition Period section.
• , the observation window is rounds.
• , the network generates one cover message per round on average.
• , the network generates one block proposal every rounds on average (Cryptarchia Protocol).
• , the network carries messages per slot of rounds, each carrying one transaction (Payload Formatting), whatever quota backs them: at (Expected Traffic).
• and : a cover message is not replicated, and a block proposal is replicated once. A transaction is not replicated.
• , the peering degree (Connectivity Maintenance). . Below a node opens no connection of its own; above nodes must open more connections than nodes can accept, and dials are refused.
• messages per second the slowest node the protocol targets processes, one below the measured on one core of a Raspberry Pi 5 (benchmark).
• messages a node reads from a core connection per round, and connections with edge nodes it accepts per round: and , so a node at its peering degree reads two thirds of , and at one above it (Expected Traffic).
• round, the time an edge node is given to send its message, as derived in Connectivity Maintenance.
• rounds, the time a core node handshake is given to complete, which covers the round trips of the transport handshake and of the Neighbor Distinction Process.

Core Node Parameters

A core node maintains the following set of parameters:

• denotes the maximum number of retries a core node will do to connect with another core node.
• denotes the maximum number of connections a core node holds with edge nodes at once. : a connection holds its slot for , one round, so the connections accepted in two rounds can be open at once, and a smaller value refuses edge connections before the share is spent.

Implementations should choose a default based on the deployment they operate in, and users can override these defaults before joining.

Edge Node Parameters

An edge node maintains the following parameters:

• denotes the connection redundancy number for the edge node. A node must send a single message that needs to be blended to this number of core nodes.
• denotes the maximum number of retries an edge node will do to establish a connection with a core node.

Implementations should choose a default based on the deployment they operate in, and users can override these defaults before joining.

Network Maintenance

Connection Details

The connections are established using libp2p with TLS version 1.3 (not older). The cryptographic scheme is Ed25519 with ephemeral keys**.** The libp2p protocol name is /logos-blockchain/blend/1.0.0 for mainnet and /logos-blockchain-testnet/blend/1.0.0 for testnet.

Neighbor Distinction Process

The Neighbor Distinction Process (NDP) enables the core node to distinguish between node types (core, edge) of its neighbors in the Blend Network. The process is straightforward:

1. A node extracts peer_id from the TLS metadata of the accepted connection.
2. If the peer_id is found in the set of provider_ids, then the neighbor is a core node; otherwise, the peer is an edge node.

Expected Traffic

A message is novel to a node when its proof of quota nullifier is not in the nullifier cache (Relaying).

The rate a core connection carries is:

Flooding delivers each message once per neighbor, so must be below ; at a backlog on a connection never drains. is sized so that a backlog of one round's share drains, at per round, within the time a message may spend at one hop, (Transition Period): . Messages backed by a proof of work count within , which is the reference load of Blend Difficulty.

A node reads at most messages in a round, which must not exceed , and verifies the public header of novel messages only (Relaying). At bytes per message (Message Formatting) that is MB/s.

Connectivity Maintenance

Admission

The shares keep the messages a node reads in a round within what the slowest node the protocol targets can verify, (Expected Traffic).

1. A node reads at most messages from a core connection in a round. A connection whose share is spent is not read until the next round.
2. A node sends at most messages on a core connection in a round. A message that has waited rounds to be sent on a connection is discarded for that connection.
3. The volume a neighbor sends is never a cause for closing a connection or for blacklisting.

Liveness

1. A connection with a core node is live when the neighbor has delivered a message, duplicate or not, within its last connected rounds, or has been connected for fewer than rounds in total.
2. Connected rounds and deliveries are counted per identity, for the epoch, over every connection the node has held with it.
3. A neighbor whose connection is not live is not blacklisted.

Degree

1. A core node holds between and connections with core nodes. It opens a connection while it holds fewer than live ones, or fewer than live ones that it opened. It accepts a connection while it holds fewer than connections and fewer than accepted ones, and closes a connection offered above either.
2. It draws the nodes it opens uniformly at random and without replacement from the set returned by the SDP protocol, excluding itself, blacklisted identities and its current neighbors.
3. A connection that is not live is closed.
4. A connection whose handshake is in progress counts towards once the Neighbor Distinction Process has identified the neighbor as a core node, and its peer is a current neighbor for rule 2. A handshake that has not completed within is abandoned and its slot released. At most handshakes are in progress at once, and one offered above that is closed.

Blacklist

A failure of the authenticated stream is a violation of the framing of the stream.

1. A connection with a core node whose authenticated stream fails, or that carries a message with a malformed header, an invalid signature, or an invalid proof of quota, is closed and its neighbor is added to the blacklist. A message discarded as a duplicate carries no reaction.
2. A blacklisted identity is refused on incoming and on outgoing connections. An entry expires after rounds.
3. The blacklist holds at most entries, and the oldest is discarded when it is full.

Edge Nodes

1. A core node holds at most connections with edge nodes at once, and accepts at most of them in a round. A connection offered above either is closed.
2. A connection with an edge node is closed once the edge node has sent its message, or once has elapsed from accepting it. covers one encapsulated message of bytes (Message Formatting), which takes s over a Mbit/s link; a further for framing and s of latency keep the total under one round.
3. An edge node whose message fails header verification has its connection closed. It is not blacklisted.

Logging

A node logs:

• every connection it closes, and every addition to and expiry from the blacklist;
• every round in which a connection's share was spent, and every round in which it discarded a message waiting for a connection;
• every period during which it holds fewer than live connections with core nodes, or fewer than that it opened.

Each entry carries the identity of the neighbor and the reason.

Transition Period

When a new epoch begins, the set of public information checked against proofs embedded in messages changes, which renders some messages invalid. However, these messages may still contain valid payloads that must reach their destination. Therefore, we implement a Transition Period (TP, ) during which the network can gracefully react to the change and allow these messages to safely exit the network.

A message crosses blend nodes, each holding it for at most and the network carrying it for :

where:

• defines the maximal blending delay;
• defines the network absorption of one hop (Global Parameters);
• defines maximum number of blending operations of a single message.

After rounds, all messages for the past epoch should have been processed and disseminated. To provide an additional safety buffer, we round the transition period up to rounds. After this period, all old connections can be safely terminated, and messages for the past epoch must not be processed anymore.

The transition period must not be shorter than the message traversal time. A node that stopped processing past-epoch messages before would discard messages that are still crossing the network, and their senders would wait for a delivery that can no longer happen (Detection).

When a new epoch begins:

• The node validates message proofs against both new and past epoch-related public input for the duration of TP. This allows past-epoch messages to safely transit through the network, as their validity is bound to the epoch in which they were generated.
• The Blend threshold is one of these public inputs: a proof is verified against the threshold of the epoch its public inputs belong to, so during the Transition Period messages meeting either epoch's threshold are accepted.
• The node must open new connections to process new messages for the new epoch.
• The node needs to maintain old connections and process all messages received from these connections for the duration of TP. A connection held for the past epoch does not count towards .

Quota

The quota limits the number of messages that can be generated during an epoch. This bound is necessary for the health of the network as it decreases the bandwidth usage and enables us to calculate rewards fairly.

Core Quota

The core quota () defines the messaging allowance that can be used by a core node during a single epoch. The purpose of is to limit the number of cover messages and the number of blending operations that can be used for a single message. We assume that the core quota is used for generating cover messages, but the core node is not limited by this assumption. We define it as follows:

Where:

• denotes an expected number of cover messages that are generated during an epoch by the core nodes;
• denotes the expected number of blending operations for each cover message;
• denotes a redundancy parameter for cover messages, increasing the number of core node messages a node can send;
• denote a number of core nodes providing the Blend service for the epoch returned by the SDP protocol (Service Declaration Protocol).

The division must be rounded up. Rounding down would collapse to as soon as — that is, as soon as the network outgrows the expected number of blending operations for cover messages. Every core node would then be issued an empty key pool and cover traffic would stop entirely, removing the protocol's anonymity guarantee exactly when the network is largest. Rounding up costs at most additional messages network-wide per epoch.

The parameters must additionally satisfy . Together with rounding up, this guarantees for every epoch.

Additionally, we introduce the total core quota, which defines the total number of generated cover messages that the whole network can emit (independently of the number of nodes):

The equality holds only when divides ; otherwise rounding up makes the total larger by at most messages. From it also follows that , which is relied upon by the Activity Proof and the Activity Threshold.

Leadership Quota

The leadership quota () defines the number of blending operations a block proposer (consensus leader) node can perform within the network. A single quota is used per single proof of leadership. Therefore, a single node can use multiple leadership quotas during a single epoch. We assume that the leader is interested in using most of its quota to generate data messages; however, the leader is not limited by this assumption. We define the leadership quota as follows:

where:

• denotes the expected number of blending operations for each data message;
• denotes a redundancy parameter for block proposals, defining the number of “replications” of the same message.

We can calculate an average data message number () which informs us about the average number of data messages generated per epoch:

where is the average number of leaders per epoch.

The depends on the consensus leader election algorithm, which at the time of writing can be estimated as follows:

where and are taken from the Cryptarchia Protocol. This is equivalent to the average rate of a slot having an elected leader.

Finally, let us define the leadership quota for node (), which can only be calculated by the node :

where is the exact number of leader elections won by the node in an epoch. The value of is known only to the node because its value is a function of the stake of a node , which is kept private.

Proof of Work Quota

The proof of work quota () defines the number of blending operations that a single proof of work solution entitles its holder to perform. A solution is attached to no node, so the quota is a per solution allowance:

where is the number of distinct solutions held by the node that satisfy the Blend threshold for the epoch. As with the leadership quota, is known only to the node.

: one solution pays for exactly one message, since a message consumes one blending operation per encapsulation.

Blend Difficulty

is the threshold a puzzle ticket must fall below to satisfy the proof of work branch of the Proof of Quota. It is a consensus value, fixed for each epoch at the same snapshot as the epoch's nonce, and is derived in Blend Difficulty.

Quota Application

We define a mechanism that applies the quota to the protocol and makes the messaging restriction effective. We start by modifying the mechanism that governs message generation, processing, and relaying. That is:

1. We require every message introduced to the network to be identified by a unique (ephemeral) key.
2. We restrict the number of messages a node can generate to the value of the quota.

For this to happen, a node creates a pool of keys that can be used for message generation and processing (the pool is epoch-specific):

which describes a collection of key pairs for a node with proofs of quota for the epoch , where is the -th public key, is its corresponding private key, and is its proof of quota. Additionally:

• is the sum of core quota, leadership quota and proof of work quota for the node .
• is a proof of quota which confirms that for every key from the key pool of a node, without disclosing the identity of the node .

Keys Generation

This protocol uses multiple types of keys that are described in the following specification: Key Types and Generation

Proof of Quota

One of the key ideas behind the Proof of Quota (PoQ — [Proof of Quota) is to guarantee that honestly generated messages are relayed and will be disseminated to the entire network. This is because an honestly generated message uses a unique identifier; otherwise, the network will eventually flag the message as duplicated and halt its dissemination.

If two messages use the same identifier, then the network does not guarantee that the message will be relayed. In such a case, any node that observes the second message with the same identifier will drop it.

This might lead to a situation where part of the network will see the first message and another part of the network will see the second. In this scenario, both messages are not disseminated to the whole network, as expected, due to spam limits in the network. However, this does not mean that either message has not reached its destination and was not processed.

The PoQ is constructed from three parts.

The first part of the PoQ is dedicated to the core quota. We define the proof of core quota () as true when all of the following conditions are met:

• : there exists a node that is part of the set of registered nodes , which is retrieved from the SDP protocol for the epoch . The value identifying the node must be hidden.
• : the public key is generated by the node for the epoch .
• : the number (index) of proof nullifiers that limits the number of proof of quotas a core node can generate in one epoch.

The proof of the core quota assumes:

• Public input: , , .
• Private input: , .
• Public output: .

Where is a PoQ nullifier and uniquely identifies the PoQ.

The second part of the PoQ is dedicated to the leadership quota. The proof of the leadership quota () is true when all of the following conditions are met:

• : there exists a valid proof of leadership for node valid for epoch .
• : the key is generated by the node for the epoch .
• : the number of key nullifiers that limits the number of proof of quotas a leader can generate per won slot.

The proof of the leadership quota assumes:

• Public input: , , .
• Private input: , , .
• Public output: .

Where is a PoQ nullifier and uniquely identifies the PoQ.

The third part of the PoQ is dedicated to the proof of work quota. The proof of the work quota () is true when all of the following conditions are met:

• : there exists a puzzle solution whose ticket is strictly below the Blend threshold for the epoch . The solution must be known to the prover, and the ticket is derived from it as specified in Proof of Quota.
• : the key is generated by the node for the epoch .
• : the number of key nullifiers that limits the number of proofs of quota that can be generated from a single solution.

The proof of the work quota assumes:

• Public input: , , , .
• Private input: , .
• Public output: .

Where is a PoQ nullifier and uniquely identifies the PoQ.

Finally, we use all three constrains and create a single proof of quota (). That is, the proof is true when any of the following conditions are met:

• constraints are true.
• constraints are true.
• constraints are true.

This means that the proof of quota is a logical sum of the proof of core quota, the proof of leadership quota and the proof of work quota, .

Please refer to the document below for more details.

The set of PoQ for leaders must be precomputed for each epoch to minimize the impact of proof generation on the proposal broadcast delay.

For more details see Proof of Quota.

Message Lifecycle

Proof of Selection

The proof of selection (PoSel, ) is a construction that makes the selection of nodes for message processing a random and verifiable process. The reasons behind such restrictions are:

• Due to random (unbiased) sampling of blend nodes, messages are distributed uniformly across the whole set of nodes. Therefore, we avoid creating communication hotspots, and through this, we make the rewarding process fair.
• The restriction on the selection of the blend node limits the possibility of targeting a specific node by an adversary. The adversary is limited only to a subset of keys that can be used to generate a message to a particular node.
• It limits the possibility of selfish behavior where a node “consumes” all of its keys and “sends” all messages to itself to increase its reward.

Note that the Proof of Selection alongside the Proof of Quota restricts the set of nodes that can be used for blending path construction. However, the selection of blend nodes from the set and the particular order they are used for path construction is not restricted. Therefore, a node can freely select nodes from the set of blending nodes defined by the PoSel and PoQ mechanisms to construct blending paths for any of the messages it wants to send.

The PoSel assumes:

• Public input: .
• Shared secret: .
• Public output: .

Where is the secret selection randomness generated by the and shared only with the recipient (node ), and is an index of the node on the list of core nodes.

The PoSel () is true when all of the following conditions are met:

• , where:

  • is secret selection randomness that is encoded using little-endian,
  • is the index of the recipient node (from the SDP list of core nodes) encoded as little-endian,
  • is the cryptographically secure pseudo-random number generator defined in Notation, whose output is restricted to bytes which is encoded using little-endian,
  • is a domain separated blake2b hash function,
  • and is the number of core nodes.

  This operation is statistically secure for relatively small that we assume to have in our system as analyzed in Statistical Analysis of Selection Bias of Modulo Operation.

• , where is the PoQ nullifier of the and is the PoQ nullifier derived from the secret and is the Posiedon2 hash function.

The PoSel must be used alongside the PoQ, as the PoSel is tightly coupled with the PoQ.

When performing modulo operation on the hash we do the following:

def modular_bytes(data: bytes, modulus: int) -> int:
    # Convert data into an unsigned big integer using little-endian.
    return int.from_bytes(data, byteorder='little') % modulus

Cover Message Schedule

Generation of cover messages is handled by each core node individually. The only protocol-enforced limitation is through the Core Quota (), which limits the number of messages a node can generate.

A core node draws its cover message schedule uniformly at random over the epoch.

Message Structure

For this document, we present a definition of the message structure as defined in the Message Encapsulation Mechanism. For simplicity, we omit the versioning of the message as defined in Message Formatting.

A node constructs a message according to the format presented below.

1. is a public header:

   1. , a public key from the set .
   2. , a corresponding proof of quota for the key from the and contains its PoQ nullifier .
   3. , a signature of the -th encapsulation of the payload , that can be verified by the public key .

2. is an encrypted private header , which contains:

   1. , a public key from the set .
   2. , a corresponding proof of quota for the key from the and contains its PoQ nullifier .
   3. , a signature of the -th encapsulation of the payload , that can be verified by the public key .
   4. , a proof of selection of the node index assuming a public key .
   5. , a flag that indicates that this is the last blending header.

3. is a payload.

Encapsulation Overhead Calculation: Assuming that we use Groth16 SNARKs as a proving system, we need bytes per PoQ ( for proof and for nullifier) quota. Which gives us bytes per hop (proof of quota bytes + proof of selection bytes + public key bytes + signature bytes + last flag byte) plus bytes for the public header. Which for hops gives us bytes in total. That is added to the payload being encapsulated, which is Max_Payload_Length = bytes (Message Formatting): the padded Max_Body_Length of Payload Formatting, set from the maximum size of the block proposal defined in Block Construction, Validation and Execution, plus the 3-byte payload header. The encapsulation therefore adds .

Formatting

The payload of the message must be formatted according to the following document: Message Formatting

The payload must be encapsulated according to the following document: Payload Formatting

Every encapsulated message must be formatted according to the following document: Message Encapsulation Mechanism

Generation

Generation of a message is triggered by any of the following events:

1. A core or edge node won a consensus lottery and has a proof of leadership, which entails a node to emit a data message. The payload of the message is a block proposal.
2. A node has a Mantle transaction to submit and holds an unused quota allowance. The payload of the message is the transaction.
3. A Cover Message Schedule. The payload of the message contains random data.

When this happens, a number of messages (limited by the Quota) are generated as follows:

1. A number of keys are generated according to the Key Types and Generation.
   1. Each key uses a message-type-specific allowance as described in the Quota.
   2. The correct usage of the allowance is proven by Proof of Quota.
2. The payload of the message is formatted according to the Payload Formatting.
3. The above set of keys is used to encapsulate the payload of a message according to the Message Encapsulation Mechanism.
   1. Each key is used for a single encapsulation of a message, which can be processed (decapsulated) by a single node.
   2. The node selection is random and deterministic, and is provable by Proof of Selection.
4. The message is formatted according to the Message Formatting.
5. The message is released according to the Releasing logic.

Relaying

The relaying logic is defined as follows:

1. The node checks the header of the message that was received from its neighbor, according to the Message Formatting.
   1. If the neighbor is a core node, then the message counts towards the liveness of the connection and towards its share (Connectivity Maintenance).
   2. If the neighbor is an edge node, then close the connection with the neighbor.
   3. If the header of the message is incorrect, then discard the message, close the connection and blacklist the neighbor (Connectivity Maintenance). We assume that an adversary cannot inject any spoofed message to the connection.
   4. If the PoQ nullifier from the public header of the message is already in the nullifier cache, then the message is a duplicate and must be discarded. Cached entries are retained for the duration of the current epoch and the Transition Period.
   5. If the signature from the public header of the message is invalid, then the message must be discarded, the connection closed and the neighbor blacklisted (Connectivity Maintenance).
   6. If the proof of quota from the public header is invalid, then the message must be discarded and must not be relayed. The connection is closed and the neighbor blacklisted, as defined in Connectivity Maintenance.
2. Release the message according to the Releasing logic.
3. Concurrently to the above step, add the message to the processing queue, where it is handled by the Processing logic.

The node must cache the PoQ nullifiers () for every message it relays for a duration of a single epoch plus the Transition Period (TP). Then the node can clear the cache. That means that the size of the cache must be at least:

At the rates above:

Processing

When a message has passed the Relaying checks, it is processed by this logic:

1. Decapsulate the message as defined in the decapsulation section of the Message Encapsulation Mechanism.

2. If the decapsulation is successful, then:

   1. If the proof of selection () is invalid, then the message is discarded. A valid proof of selection points to the index of the node in the list of nodes returned from the SDP.

   2. Store the blending token which is the collection of the proof of quota from the header (), and the proof of selection from the private header ():

   3. If the last flag is set () then examine the header type of the payload as defined in the Payload Formatting, then:

      1. If the payload is a block proposal, then the payload structure is verified and broadcast, as defined in the Broadcasting section.
      2. If the payload is a transaction, then the payload structure is verified and the transaction is submitted to the node's mempool, which disseminates it as its own rules specify. As with a block proposal, only the structure is checked here; whether the transaction is valid against the ledger is decided by Mantle and is out of scope for this protocol. A transaction must fit within the fixed payload body defined in Payload Formatting, so one that does not is not sendable over this protocol at all.
      3. If the payload is a cover message, then the payload is discarded.

   4. Else:

      1. Examine the decapsulated public header:
         1. If the PoQ nullifier from the public header of the message was already seen, then the node was not allowed to use the same PoQ nullifier and the message must be discarded. The cache is the one maintained by Relaying.
         2. If the signature from the public header of the message is invalid, then the message must be discarded.
         3. If the proof of quota from the public header of the message is not correct, then the message must be discarded.
      2. Format the message according to the Message Formatting.
      3. Attempt a subsequent decapsulation to validate whether the node is the recipient (return to step 1). This must be done recursively to remove all consecutive encapsulation layers where the node is the intended recipient.
      4. If the decapsulation fails (meaning no more layers remain), randomly delay the message and release the formatted message according to the Releasing logic.

3. If decapsulation fails, return the appropriate decapsulation failure message.

Blending tokens are stored by the node for rewarding purposes, as they prove that the node processed the message. The blending tokens are stored alongside context information such as the epoch number. We denote the set of blending tokens from an epoch stored by a node as .

Delaying

The purpose of message delaying is to hide timing correlations between incoming and outgoing messages from a node. That is, a message is delayed in a random manner, which makes it harder to link the incoming and outgoing messages based on the network timing observation.

The message anonymity pool is the total number of messages that have been seen by the node between two subsequent message release events. The set of seen messages does not necessarily include a message that the node is the recipient of.

The design assumes a maximum delay between two subsequent message release attempts, which defines the longest waiting time for message release. This also defines the maximal message anonymity pool (assuming a single message is released in a round by the network).

Now we can define the delaying logic:

1. Select at random a delay: .
2. Start counting rounds: is the starting round.
3. Every round check if the current round () is the delayed one , then:
   1. Release messages from the queue according to the Releasing logic.
   2. Select at random a delay: .
   3. Start counting rounds: is the starting round.

If the queue is empty, then we do not release any message.

However, the release round selection must work independently of the queue state. Otherwise, the maximal anonymity set is going to be , which must be scaled by the number of messages that are released in a single round.

Releasing

The process of releasing messages involves the following steps:

• Upon receiving a message, it is immediately released to all neighboring nodes, except the one it was received from.
• All processed messages are queued and released at the next release round determined by the Delaying logic.
• Every generated message is released at the beginning of the next round after its generation.
• As soon as a data message carrying a block proposal is generated, one random unreleased (future) cover message must be removed from the release schedule to maintain the node’s statistical indistinguishability. A data message carrying a transaction removes no cover message.
• If more than one message needs to be released for the same round, they must be randomly shuffled before release.

Broadcasting

Every payload that is added to the broadcasting queue is processed as follows:

1. The block proposal is extracted from the payload.
2. The block proposal is sent to a Logos Blockchain broadcasting channel after a random delay, as defined in the Releasing section.

The broadcasting happens through an independent protocol. All Logos Blockchain nodes form the broadcasting network, which means that it is larger than the blend network.

Rewarding

To better understand the context of the constructions defined in this section refer to the overview of the Mechanics, and for the motivation of the processing of messages in Motivations.

Epoch Randomness

The rewarding protocol requires a common and unbiased randomness. We assume that it is provided by the consensus once per epoch.

Activity Proof

The node activity proof () is a construction that attests in a probabilistic manner that a node was active during the epoch , by presenting a blending token .

In other words, the activity proof is when:

• A node has a blending token collected during epoch , and that:

  • Proof of Quota is true assuming epoch .
  • Proof of Selection is true assuming epoch .
  • , a public key from the set , that is used to verify the above proofs.

• The Hamming distance ( — returns the number of different bits between and binary strings) between the blending token and the next epoch randomness is not greater than the node activity threshold . That is:

Where:

• is a hash function (the implementation of the hash function is blake2b returning bits).
• is a number of bits that can represent an expected number of blending tokens generated during an epoch. The number is rounded up to full bytes as required by the blake2b hash algorithm:

The comparison is inclusive: a token whose distance equals satisfies the proof. The difficulty of the lottery is tuned through the sensitivity parameter of the Activity Threshold, not through the choice of comparison operator.

The requirement (see Core Quota) guarantees and therefore . It follows that and hence : the digest is always at least one byte wide, which the blake2b algorithm requires.

The Hamming distance verification prevents nodes from the grinding or pre-computation attacks due to the unpredictability of the randomness of the next epoch. Even if a node knows the value of the randomness in advance, it will not increase its chance for getting a reward as the node does not control the process of generating blending tokens. However, a dishonest node could use that knowledge to refrain from sending a message with a token that has a potential (probabilistic, not deterministic) of granting a premium reward for the recipient blend node.

The node activity proof construction is:

class ActivityProof:
    epoch_number: EpochNumber
    signing_key: SigningKey
    proof_of_quota: ProofOfQuota
    proof_of_selection: ProofOfSelection

Where:

• EpochNumber is the number of the epoch for which the activity proof is generated, as defined in Epoch.
• ProofOfQuota is defined as in Proof of Quota.
• ProofOfSelection is defined in Proof of Selection.
• SigningKey is the key used to sign the ProofOfQuota.

The serialized form of these fields, preceded by the one-byte metadata-type discriminant, is defined in Active Message.

Activity Threshold

The activity threshold defines the expected maximal Hamming distance from the epoch randomness to the blending token expressed as a non-negative integer smaller or equal .

We define the activity threshold as follows:

Where:

• represents the number of bits that are needed to express the number of nodes in the network , it makes the lottery difficulty a function of the network size;
• represents the number of bits needed to express all blending tokens generated during an epoch, where is the total number of cover messages generated by the network during an epoch (as defined here);
• represents a sensitivity parameter that controls the winning conditions of the lottery.

We assume that setting is enough to eliminate nodes that have not been active enough without too aggressively eliminating nodes that worked but had less luck with the lottery. However, we are going to revise this parameter in the future version of the protocol.

The difference is negative whenever , which happens when the total number of blending tokens is small relative to the network size. Because and , this regime is reached when the per-node quota is of the order of or smaller. A negative value is not a meaningful Hamming distance, so the threshold is clamped at : the lottery becomes maximally difficult instead of undefined. At an activity proof is still attainable, but only for a blending token whose -bit digest matches the digest of the epoch randomness exactly.

The clamped regime is not a target: at rewards are nearly unreachable. Parameters must be chosen so that .

Active Message

A node for every epoch must construct an active message, which must follow the Active Message and is carried on the wire by the SDP_ACTIVE operation (Mantle Transaction Encoding). The envelope fields (declaration_id, nonce) and their encoding are defined by those documents and are not restated here. This section defines only the service-specific metadata payload for the Blend service, which carries the Activity Proof for a blending token and an epoch .

The metadata field is the concatenation of the following fields, in order:

The total size of the metadata field is therefore bytes: the one-byte type discriminant followed directly by the 228-byte Activity Proof.

The metadata_type byte selects the activity-metadata variant according to Mantle Transaction Encoding; it is a discriminant, not a length prefix. The remaining fields follow the selected variant's encoding and validation rules.

For Blend activity metadata, metadata_type MUST be 0x01. Unknown activity-metadata discriminants MUST be rejected.

The active message is stored on the ledger.

The active message is used for calculating the node reward.

The active message is constructed after the current epoch, when the next epoch randomness is known.

The active message for epoch must be included in a block of epoch ; otherwise, it must be rejected.

The node selects the activity proof to include in the active message such that the Hamming distance between the proof and the new randomness is minimal.

The ledger must only accept a single active message per node per attested epoch. Any duplicate must be rejected.

Reward Calculation

The node rewards for epoch are calculated according to the following schema:

1. Rewards are not calculated if the number of nodes (unique ProviderIds from declarations) retrieved from the SDP protocol is lower than the Minimal Network Size.

2. Count the number of true activity proofs registered on the ledger:

   This value is used for calculating the base reward paid for all active nodes.

3. Count the number of true activity proofs registered on the ledger with the smallest Hamming distance—that is, calculate the number of nodes with the minimal distance among all submitted active messages:

   This value is used for calculating the premium reward, which is paid for all active nodes that have their activity proofs closest to the epoch randomness.

4. Calculate the base reward:

   where is the value of income for the Blend Network service for the epoch . For more details about the income calculation, refer to linked reference.

5. Calculate the reward of the node :

   That is, a base reward () is paid out to all nodes who have submitted a true activity proof, and the reward is doubled for nodes that submitted a true proof with a minimal Hamming distance.

Rewarding Distribution Logic

The reward is paid out to the node based on the node's activity declaration and the above reward calculation.

The rewards are distributed according to Service Reward Distribution Protocol. Here we are briefly sketching the main idea of the reward distribution protocol. For more details refer to the above document.

1. To receive a reward, a node must send an Active Message as described in the Active Message, where the metadata field is encoded as defined in Active Message. The node must point to a single declaration (declaration_id) and use a single provider identity (provider_id) for constructing the Active Message. Any reuse of the provider_id must make the Active Message invalid.
2. The Active Message must not be released before the epoch transition period of epoch has elapsed (Transition Period).
3. When the following epoch begins () Mantle distributes rewards (Service Reward Distribution Protocol). This delay is required to calculate the partition of rewards as defined in the above section.
4. If a node does not send the Active Message on time, then it will not receive a reward.

Analysis

Impact of the Blend Protocol on the Time to Link and Time to Infer the Stake

The main objective of the Blend protocol is to reduce the probability of linking a sender with the proposal, which also translates to increasing the time of learning the node’s (relative) stake.

The average latency penalty does not include the network delay.

The Blend Protocol increases the Time to Infer (TTI — Inference of relative stake) the stake times (assuming a network of a peering degree 4) in comparison to not using the Blend Protocol. This TTI increases times for every additional Blend node used, reaching more than years ( epochs) to infer a node stake.

When the peering degree is increased to 6 the time to infer the stake increases times that means that higher peering degree decreases the time as an adversary has more chances to observe traffic.

(*) Our TTI calculations are capped at more than epochs, which can be interpreted as more than years — a relatively safe threshold.

The time to infer the node stake depends on the confidence of the adversary. The confidence increases as the network observation time increases. Assuming node adversaries in the network and stake inference confidence of (which tells us about the confidence of the adversary when learning the node stake), we obtain the following values.

TTI — peering degree 4:

TTI — peering degree 6:

When the Blend protocol is applied, then the the Time to Link (TTL — The Unlinkability of Block Proposers) is non-instant, and it increases with the number of blend nodes used. For each additional blend used, the time increases times and the cost is of additional seconds of average latency.

Without the Blend protocol, the TTL is instant as the proposal is directly broadcast by the sender. Below we present a table where we show how long it takes to link a node to a single message with more than probability.

TTL — peering degree 4:

TTL — peering degree 6:

Statistical Analysis of Selection Bias of Modulo Operation

Applying a modulo operation to the output of a pseudorandom number generator (here the ChaCha20 keystream) with a large range (here from to , since the selection draws bytes), introduces a statistical bias when mapping to the smaller domain . This bias arises because is typically not divisible by , meaning that some residues modulo will occur slightly more often than others. Specifically, let , then with . The first values modulo will appear times, while the remaining values will appear times. Thus, the maximum bias between two values and in is:

Where is the probability that is the result of the modulo operation and the probability that is the result of the modulo operation.

The maximum per-value bias is exactly , regardless of , as long as . That means no single output differs from uniform by more than .

But now we consider total variation distance, a better global metric of distinguishability between the true distribution and uniform. This is:

We know then:

Reinjecting in the formula of :

So the distribution deviation is less than . Since the number of nodes participating in Blend is expected to be less than 10 million (less than ), the total variation distance is at most . Distinguishing the selection distribution from uniform then requires on the order of observed selections, far beyond what any observer collects in practice, so we can safely skip the rejection process necessary to draw random numbers uniformly in .