or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
Cardano Decentralized Message Queue
Questions
Abstract
We propose to create a decentralized message diffusion protocol leveraging the Cardano network layer. This protocol allows to follow a topic based publish-subscribe pattern to diffuse messages from publisher nodes to subscriber nodes in a decentralized way.
The messages can be sent and received by nodes running in a non intrusive way side by side to the Cardano node in order to enable inter-nodes communications.
In this way, we can significantly reduce the cost and effort required to build a decentralised network for message diffusion by using Cardano's established infrastructure, with limited impact on the performance and no impact on the security of the Cardano network.
Motivation
Mithril is a protocol based on a Stake-based Threshold Multi-signature scheme which leverages the Cardano SPOs to certify data from the Cardano chain in a trustless way. Mithril is currently used in the Cardano ecosystem in order to enable fast bootstrapping of full nodes and enabling secure light wallets.
The Mithril protocol coordinates the collection of individual signatures originating from the signers (run by SPOs) by the aggregators which combine them into Mithril multi-signatures and certificates. In order to be fully decentralized, the protocol needs to rely on a decentralized peer to peer network which, if built from the ground up, would require significant efforts and investment. Furthermore, the majority of SPO's, as the representatives of Cardano's active stake, will have to adopt and operate Mithril nodes alongside their Cardano node. Thus a natural solution is to use the Cardano network layer to significantly facilitate the development of Mithril protocol without a significant impact on the Cardano network or high maintenance efforts for the SPOs.
Other protocols in the Cardano ecosystem, such as Leios and Peras (and probably other protocols in the future), also need the capability to diffuse messages originating from block producers in a decentralized fashion. We have taken into consideration this need for a generic solution in the design proposed. However, at this stage, the impact on the performances have been established based on the needs for Mithril.
The proposed solution is described in detail below.
Specification
Overview
This specification proposes to create
3
new mini-protocols in the Cardano network layer:node-2-node
:node-2-client
:Message Submission mini-protocol
Description
The node to node message submission protocol is used to transfer messages between full nodes. It follows a pull-based strategy where the server asks for new messages and the client returns them back. This protocol is designed to guard both sides against resource consumption attacks from the other side in a trustless setting. There exists a local message submission protocol which is used when the server trusts a local client as described in the following section.
State machine
Protocol messages
Transition table
CDDL encoding specification
Client and server implementation
This mini-protocol is designed with two goals in mind:
The mini-protocol is based on two pull-based operations:
The client is responsible for initiating the mini-protocol with a peer node, but the server (i.e. the other node) is the one who asks for information.
The client maintains a limited size FIFO queue of outstanding messages for each of the servers it is connected to, so does the server with a mirror FIFO queue of message ids:
The protocol supports blocking and non-blocking requests:
Network load
The computation must apply a multiplicative factor based on the number of peers connected and/or the overall redundancy of messages transmitted with the diffusion mechanism. The current value is 1.
Message diffusion multiplicative factor
Mithril extra network usage
Some compression can be applied to the Mithril signatures which allows them to always be on the lower bound size, but it is not implemented yet.
For a total of 3,100 Cardano SPOs on the mainnet, on an average 50% of them will be eligible to send signatures (i.e. will win at least one lottery in the Mithril protocol). This means that if the full Cardano stake distribution is involved in the Mithril protocol, only 1550 signers will send signatures at each round.
The following tables gather figures about expected network load in the case of Mithril using the mini-protocol to diffuse the individual signatures:
For a total of 3,100 Cardano SPOs, there will be 1,550 messages sent per round of signature:
Infrastructure extra operating costs
Networking traffic cost
Mithril message diffusion extra networking cost
For a total of
3,000
SPOs sending messages, the extra networking cost incurred for a Cardano full node is:Protocol authentication
Message authentication mechanism
The message body is signed with the KES key of the SPO. This signature and the operational certificate of the SPO are appended to the message which is diffused.
Before being diffused to other peers, an incoming message must be verified by the receiving node. This is done with the following steps:
If any of these step fails, the message is considered as invalid, which is a protocol violation.
We also probably need to make sure that the KES key used to sign is from the latest rotation:
If the opcert number received is strictly lower than the previous one which has been seen, it should be considered as a protocol violation.
Cost of authentication
Computations are based on a 1ms verification delay per message on a CPU core which needs to be properly evaluated.
For a total of 3,100 Cardano SPOs, there will be 1,550 messages sent per round of signature:
Possible attacks
Sybil attack
In this attack, a malicious sender would attempt to create multiple identities impersonating SPOs. This attack is completely mitigated by the Message authentication mechanism as only active SPO on the Cardano chain can be authenticated and send messages. This would be considered as a protocol violation and the malicous peer would be disconnected.
Equivocation
In this attack, a malicious SPO would send different messages to different peers. This attack needs to be handled by the receiver of the message as the network layer does not verify the content of the message body by design.
In the specific case of Mithril, the individual signature is unique so there will be two cases:
Message flooding
In this attack, a malicous SPO would try to flood the network by sending many messages at once. In that case, the network layer could detect that the throughput of messages originating from a SPO is above a threshold and consider it as a protocol violation, thus disconnecting the malicous peer.
Local Message Submission mini-protocol
Description
The local message submission mini-protocol is used by local clients to submit message to a local node. This mini-protocol is not used to diffuse messages from a core node to another.
The protocol follows a simple request-response pattern:
State machine
Protocol messages
Transition table
Local Message Notification mini-protocol
Description
The local message notification mini-protocol is used by local clients to be notified about new message received by the core node.
The protocol follows a simple request-response pattern:
State machine
Protocol messages
Transition table
Rationale
Why are we proposing this CIP?
For Mithril
Mithril requires strong network foundations to support interactions between its various nodes:
For Leios
TBD
For Peras
TBD
For Cardano
Why would it be great for Cardano to support a decentralized message queue with its network?
Information Diffusion Architecture
In this section, we propose an architecture for
Cardano
andMithril
. Note,in this section,
Mithril
is used as a placeholder for a possibleMithril
application: we've seen many ideas about how
Mithril
can be used inCardano
and all of them can follow this design.
Any software included in
cardano-node
needs to undergo a rigorous developmentand review process to avoid catastrophic events. We think that merging
Cardano
, a mature software, with new technologies, should be a process, andthus we propose first to develop
Mithril
nodes as standalone processes whichcommunicate with
cardano-node
via its local interface (node-to-client
protocol). As we will see, this approach has advantages for the
Mithril
network and SPOs.
Ouroboros-Network
(ON) is, to a large extent, an agnostic network stack,which can be adapted to be used by both
Cardano
andMithril
. To constructan overlay network, the stack needs to access stake pool information registered
on chain. This can be done via the
node-to-client
protocol over a Unixsocket. Since
Mithril
nodes will have their own end-points, we'll either needto propose a modification to the SPO registration process, which includes
Mithril
nodes, or we could pass incomingmithril
connections fromcardano-node
to theMithril
node viaCMSG_DATA.
Ouroboros-Network
outbound governor component, which is responsible forcreating the overlay network has a built-in mechanism which churns connections
based on a defined metric. By developing a standalone
Mithril
node, we candesign metrics specific for the purpose. This way, the
Mithril
network willoptimise for its benefits rather than being stuck in a suboptimal solution from
its perspective - if
Mithril
andCardano
were tied more strongly (e.g. aspart
cardano-node
), then we wouldn't have that opportunity becauseCardano
must meet its deadlines, or the security of the system as a whole must be at
stake.
Eventually, there will be many
Mithril
applications, and all of them mighthave different network requirements and thus might require slightly different
configurations. We SHOULD aim to build something that can be used as
a scaffolding for such applications. This may also open future avenues for
delivering new functionalities that fit together well with existing
infrastructure while still mitigating the risk of catastrophic events at the
core of the system.
Please also note that any protocols and their instances that will be built as
part of the standalone
Mithril
node could be reused in future forPeras
andLeios
. It will give us even more confidence that the future core system willbe built from components that are used in production.
Cardano
andMithril
, as separate executables, can still be packagedtogether, lowering the barrier of participation. When run separately, the SPO
is also in better control of the resources dedicated to each process - this is
important for the health of both systems.
Another benefit of such a design is that
Mithril
can be developed on its ownpace, not affected by significant changes in other parts of the system like
ledger - the Cardano Core team restrains itself to not publishing new
cardano-node
versions with significant changes across many of its subsystems - just for the
sake of clarity of where to look if a bug is found.
In this design, a
Mithril
node runs alongside acardano-node
, which is connected toit via a UNIX socket (
node-to-client
) protocol. This means an SPO will runa
Mithril
node percardano-node
. TheMithril
node connected to BP canalso have access to necessary keys for signing purposes.
Mithril
might alsouse the KES agent, as
cardano-node
will in the near future, to securely accessthe KES key.
Path to Active
Acceptance Criteria
Implementation Plan
A hard-fork of the Cardano chain may be required.
Further Reading
Cardano network
Networking for Cardano Shelley: https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-design/network-design.pdf
Mithril
Leios
TBD
Peras
TBD
Copyright
This CIP is licensed under Apache-2.0