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
Mithril Decentralised Network
Abstract
We propose to integrate Mithril Signer and Aggregator nodes in a non-intrusive way side by side Cardano node in order to be able to use the Cardano network layer for Mithril inter-node communications.
In this way, we can significantly reduce the cost and effort required to build a decentralised network for Mithril by using Cardano's established infrastucture, with negligible to no impact on the performance and no impact on the security of the Cardano network.
Motivation
Mithril is a protocol based on Stake-based Threshold Multisignatures scheme which efficiently produces certificates which can be used in a trustless way. There are several usecases envisaged for the Cardano ecosystem such as fast bootstrapping of full nodes, enabling secure light wallets, and decentralised voting.
There are several key components and requirements that need to be in place:
Such a network, 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. This is not guaranteed without a sustainable incentive scheme in place due to the additional maintenance and operational costs. Mithril is a lightweight protocol with respect to both computation and network communication overhead and has less strict network guarantees requirements than Cardano consensus. 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. The proposed solution is described in detail below.
Specification
Overview
This specification proposes to create
4
new mini-protocols in the Cardano network layer:node-2-node
mini-protocols:node-2-client
mini-protocols:Mithril Signer Registration Protocol
This is the protocol driving the diffusion of signers registration across the network. The purpose of this protocol is to ensure timely diffusion of each signer's registration for the next epoch.
How do we avoid last minute registrations from malicious players? Even if we have a time window for registering, we still need to allow for some marging so that messages reach the full network. But what stops adversaries from sending a registration request off-limits of the time-window? This is important, because if honest nodes have registrations with different users, their signatures will not be compatible for aggregation.
There's a need to limit the time range during which we allow for registration to be sent and to be received, as we want to avoid last minute flooding of registrations that would create discrepancy between signers that would prevent them from signing.
In order to achieve consensus on the signer registrations, a solution could be having the SPOs create a transaction on the main chain to register their Mithril verification keys (once every epoch or
k
epochs if a KES like mechanism is possible).Protocol Summary
We expect this protocol to guarantee that if a node has emitted a signer registration for a given epoch, it will reach all signers before the end of the epoch. Or in other words, the set of registered signers must be identical for each signer node.
The pull system should ensure convergence of state for all involved nodes within the timespan of an epoch.
Protocol Logic
There is a delicate topic regarding the collection of signers' registration:
There is a need to define
openWindow
andcloseWindow
, which corresponds to the time we allow for registration (or when we decide to stop accepting registrations). These values could be tied to epoch numbers, or the security parameterk
.This problem is not trivial, and by no means resolved. We should check with the rest of the team (consensus/ledger/network) whether it makes sense to treat registration requests in a similar way as blocks are treated (e.g. registration pool waiting to be included in a 'RegistrationBlock'). If we treat them as such, then the 'k' parameter is again relevant for agreeing on 'when' a fork can no longer happen.
Protocol Description
State Machine
Protocol messages:
Transition table:
Data Description / CDDL encoding specification
Mithril Signature Protocol
This is the protocol driving the diffusion of signers signatures across the network. The purpose of this protocol is to ensure timely diffusion of each signer's signature for the current signing round.
A signing round is an event that is defined as:
Protocol Summary
Protocol Description
State Machine
Protocol messages:
Transition table:
Data Description / CDDL encoding specification
Mithril Local Submission Protocol
This is the protocol used by signers to broadcast their registration and signatures. Note that this protocol allows a signer to send both their registration for a given epoch and their signature for a given signing round.
Summary
Protocol Description
State Machine
Protocol messages:
Transition table:
Data Description / CDDL encoding specification
Mithril Local Notification Protocol
This is the protocol used by signers and aggregators to be notified of registration and signatures of signers.
Summary
MsgNoSignature
if there aren't more signatures.Protocol Description
The following state machine does not represent the full semantics of the Mithril protocol, which requires to collect registrations for an epoch before collecting signatures for the next epoch.
State Machine
Protocol messages:
Transition table:
Data Description / CDDL encoding specification
Rationale
Why are we proposing this CIP?
Mithril requires strong network foundations to support interactions between its various nodes:
Why it would be great for Cardano to support Mithril within its network?
15-20x
faster with Mithril).What would be the overhead of operating a Mithril node on the Cardano network?
10 signing rounds
a day).3,500
) perepoch
(each less than10KB
): this means at most~35MB / epoch / Cardano node
.3,500
) persigning round
(each less than1KB
): this means at most~3.5MB / signing round / Cardano node
or~175MB / epoch / Cardano node
.10 signing rounds
a day).Path to Active
Acceptance Criteria
Implementation Plan
A hard-fork of the Cardano chain is not required during this implementation plan.
Further Reading
Copyright
This CIP is licensed under Apache-2.0