-
Notifications
You must be signed in to change notification settings - Fork 87
Decentralized Message Queue (DMQ) Implementation Overview
This document serves as an extension to CIP-137, providing technical insights and implementation guidance for the proposed Decentralized Message Queue (DMQ), primarily supporting Mithril protocol operations.
Significant progress toward enabling Mithril has already been achieved.
Notably, an initial implementation step was
merged into the
ouroboros-network repository, and a document highlighting decisions and
goals
demonstrates ongoing progress. Current development progress is actively
tracked in this
issue.
This document is divided into two parts. The first section outlines the network team's interpretation of CIP-137 requirements, discussing both implementation considerations and expected business logic. This will form the basis for collaboration with the Mithril team. The second section will provide a more detailed implementation plan.
The objective is to leverage Cardano's Network Diffusion layer to distribute various types of information—in this case, signatures—by creating multiple overlay networks. Achieving this goal involves:
- Ensuring Cardano's Network Diffusion layer is reusable;
- Implementing CIP-137.
The first requirement has already been met, with more information available here. The second requirement necessitates implementing three mini-protocols:
- Message Submission Protocol: Node-to-node communication employing a pull-based model for efficient and secure diffusion.
- Local Message Submission Protocol: Enables local clients (e.g., Mithril Signers) to submit messages securely.
- Local Message Notification Protocol: Allows clients to receive notifications of new messages via the network node.
This section captures the sequence diagram of signatures through the Mithril network architecture.
flowchart RL
subgraph MPA[Mithril Processes A]
MSA1[Mithril Signer A1]
MSA2[Mithril Signer A2]
MAA1[Mithril Aggregator A1]
MAA2[Mithril Aggregator A2]
end
subgraph MN[Mithril Diffusion Network]
DMQN1[DMQ Node 1]
DMQN2[DMQ Node 2]
DMQN3[DMQ Node 3]
DMQN1 <-- "N2N Signature Submission Protocol" --> DMQN2
DMQN1 <-- "N2N Signature Submission Protocol" --> DMQN3
DMQN2 <-- "N2N Signature Submission Protocol" --> DMQN3
end
subgraph MPB[Mithril Processes B]
MSB1[Mithril Signer B1]
MSB2[Mithril Signer B2]
MAB1[Mithril Aggregator B1]
MAB2[Mithril Aggregator B2]
end
MSA1 -- "N2C Local Message Submission Protocol" --> DMQN1
MSA2 -- "N2C Local Message Submission Protocol" --> DMQN1
MAA1 <-- "N2C Local Message Notification Protocol" --> DMQN1
MAA2 <-- "N2C Local Message Notification Protocol" --> DMQN1
DMQN3 -- "N2C Local Message Submission Protocol" --> MSB1
DMQN3 -- "N2C Local Message Submission Protocol" --> MSB2
DMQN3 <-- "N2C Local Message Notification Protocol" --> MAB1
DMQN3 <-- "N2C Local Message Notification Protocol" --> MAB2
Signatures in the above diagram, flow from Signers to Aggregators. Starting from Mithril Signers that submit messages to local DMQ nodes via the N2C Local Message Submission Protocol, these messages are then diffused to other nodes through the N2N Signature Diffusion Protocol. Mithril Aggregators, connected via the N2C Message Notification Protocol, then receive notifications of new signatures.
The Local Message Submission mini-protocol allows local clients, such as Mithril Signers, to submit messages directly to network nodes. Due to mutual trust between local processes, risks like malformed messages, excessive message sizes, or invalid contents are minimal.
Connections are short-lived, reducing complexity in resource management and connection handling. Thus, the protocol remains simple and efficient without additional constraints like TTL enforcement.
This protocol enables local clients (e.g., Mithril Aggregators) to receive timely notifications from network nodes regarding newly received messages.
Here's an improved and clearer version of your section:
As currently specified, the protocol involves short-lived connections where the Aggregator node queries the DMQ node for a single message at a time. This design limitation can result in inefficiencies when multiple messages are available, forcing the Aggregator node to continuously poll the DMQ node. To avoid unnecessary polling, the protocol could instead be enhanced by allowing the DMQ node to indicate, within its response, whether additional messages are available and, if so, how many. This adjustment would streamline communication, reduce redundant connection attempts, and improve overall efficiency with minimal protocol complexity.
This protocol facilitates message diffusion between DMQ nodes, utilizing a pull-based strategy. The inbound side explicitly requests new messages from peers, thereby efficiently managing resource consumption and safeguarding against potential DoS attacks.
This protocol closely mirrors the Cardano Transaction Submission Protocol,
leveraging existing logic from the ouroboros-network library.
Before being diffused to other peers, an incoming message must be verified by the receiving node. The message contains almost all the information required to validate a message (as explained in the CIP), the only external piece of information needed is a snapshot of the stake distribution that can be cached once every couple of epochs since it doesn't change too often.
It is possible to perform concurrent/parallel verification of multiple messages since there's no dependency between individual messages.
The TTL of a message should be at least the time that each signature round takes (e.g. 10minutes). The CIP offers some data assuming that the TTL of each message is around 30 minutes.
Currently, no specialized network parameters are required beyond the standard
NodeToNodeVersionData.
Protocol message size limits as defined by CIP-137 are:
| Message part | Lower bound | Upper bound |
|---|---|---|
| messageBody | 360 B | 2,000 B |
| blockNumber | 4 B | 4 B |
| kesSignature | 448 B | 448 B |
| operationalCertificate | 304 B | 304 B |
| message part totals | 1,148 B | 2,788 B |
These limits should guide the sizing of protocol tokens.