Skip to content

ECS-3077 Apply style guide, tighten some sentences. #1130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 8, 2023
Merged

ECS-3077 Apply style guide, tighten some sentences. #1130

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
efed76d
ECS-3077 Apply style guide, tighten some sentences.
NeilBurgess42 Aug 3, 2023
ab49fe2
Final editing tweaks
olgahryniuk Aug 3, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
115 changes: 54 additions & 61 deletions docs/root/mithril/mithril-protocol/protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,126 +3,119 @@ sidebar_position: 1
sidebar_label: Protocol in depth
---

# Mithril Protocol in depth
# Mithril protocol in depth

:::info

The research paper `Mithril: Stake-based Threshold Multisignatures` is downloadable [here](https://iohk.io/en/research/library/papers/mithril-stake-based-threshold-multisignatures/).
Mithril is based on the research paper [Mithril: Stake-based Threshold Multisignatures](https://iohk.io/en/research/library/papers/mithril-stake-based-threshold-multisignatures/).

:::

:::info New

:new: Interact with the **Mithril Protocol** by experiencing with our [protocol simulation](./simulation.md). This will help you understand how the participants interact to create a multi signature and what's the impact of the protocol parameters.
:new: You can interact with the **Mithril protocol** through the [protocol simulation](./simulation.md). This will help you understand participants' interactions, multi-signature creation, and the influence of protocol parameters.

:::

:::tip

For more information about the **Mithril Network**, please refer to the [Architecture](../mithril-network/architecture.md) page.
For more information about the **Mithril network**, please see [architecture](../mithril-network/architecture.md) overview.

:::

## Introduction

The full details of the Mithril protocol are provided in the published paper. This section is high-level description of
the protocol in layman’s terms.
The full details of the Mithril protocol are provided in the published paper. This section is a high-level description of
the protocol.

In a nutshell, Mithril is a signature scheme that generates a certificate that convinces
the verifiers that a portion of the stake of a system has signed a message.
In a nutshell, Mithril is a signature scheme that generates a certificate to convince verifiers that a portion of the stake of a system has signed a message.

However, rather than taking the whole set of
stake holders, Mithril
"randomly selects" a subset of them, and requires a portion of that subset to provide a signature.
However, rather than taking the whole set of stakeholders, Mithril
'randomly' selects a subset of them, and requires a portion of that subset to provide a signature.

An analogy would be
that Mithril signers participate in a lottery which defines if they are entitled to sign a particular message. In case
they win this lottery, then they can go ahead and sign the message. Whenever a sufficient number of parties have won the
lottery (and submitted their respective signatures), a certificate can be computed.
Mithril signers participate in a lottery that defines if they are entitled to sign a particular message.
The lottery winners can then sign the message. When there are enough signatures, a certificate can be computed.

## The phases of the protocol
## Protocol phases

The protocol has 3 different phases:
The protocol has three phases:

1. **Protocol Establishment phase** which determines the parameters that will be used by Mithril participants. Also,
during this phase, the set of "allowed signers" is defined.
2. **Initialization phase** during which Mithril nodes generate and exchange keys,
1. **Protocol establishment phase** during which parameters are defined for Mithril participants and a set of *allowed signers* is defined
2. **Initialization phase** during which Mithril nodes generate and exchange keys
3. **Operations phase** during which nodes sign and aggregate signatures of messages to produce certificates.

:::note Note

Note that all 3 phases require the set of parties (`P` in the paper) to be fixed. During the protocol establishment phase
Note that all three phases require a set of parties (`P` in the paper) to be fixed. During the protocol establishment phase
three important parameters are generated:

* `m`, defines the number of "lotteries" that a single user can participate in to sign a message.
* `k`, defines the required number of single signatures to produce a valid certificate.
* `phi_f` (as denoted in the library) which can be interpreted as the chance of a signer to win a lottery.
* `m`: defines the number of lotteries that a single user can participate in to sign a message
* `k`: defines the required number of signatures for a valid certificate
* `phi_f` (as denoted in the library): defines the chance of a signer to win a lottery.

:::

Now, let's assume that we want to generate a valid signature for message `msg` using a mithril signature. Then we need `k` valid signatures from the subset of signers.
To generate a valid signature for message `msg` using a Mithril signature, `k` valid signatures from the subset of signers are needed.

To this end, each player is allowed to participate in `m` "lotteries" to see if it "wins" the right to sign the message.
To this end, each player can participate in `m` lotteries to see if they win the right to sign the message.

If none of this lotteries are won by this particular signer, then it will not be able to submit a signature.
If the player does not win a lottery, they cannot submit a signature.

If, contrarily, the signer wins one of the lotteries (or more than one), then it
can submit the corresponding signature (or all of the corresponding signatures respectively) to produce the valid certificate. The chance of winning the lottery is defined by a function over `phi_f`. The closer `phi_f` is to one, the higher the chances of winning a lottery are.
If the player wins at least one of the lotteries, then they
can submit the corresponding signature/s to produce a valid certificate. The chance of winning the lottery is defined by a function over `phi_f`. The closer `phi_f` is to one, the higher the chance of winning.

This means that there exists the possibility that a particular message cannot be certified using Mithril under a given set of parameters. There could be a scenario where not enough signers have won the allowed lotteries to produce a valid certificate. In which case the parameters can be adapted.
Under specific parameters, a message may fail to get certified using Mithril. In such cases, when an insufficient number of signers win lotteries to create a valid certificate, adjustments can be made to the parameters.

### 1. Protocol Establishment Phase
### 1. Protocol establishment phase

* Select/fix a prime order group to be used as basis for multi-signature scheme
* _When using bulletproof_: Generate a "random" string, for example by taking some unpredictable data from the net (hash
of latest block, stockmarket quotes) and hash it
* When requested by a party, return the parameters and random string
* Choose/establish a prime order group to serve as the foundation for the multi-signature scheme
* _When implementing bulletproof_: generate a pseudo-random string, such as hashing unpredictable data from the net (eg, latest block's hash, stock market quotes)
* Upon request from a party, provide the parameters and a random string.

This setup phase must be done only once and is valid for as long as the same proof system, e.g the parameters can very well be statically baked into the various systems producing and consuming Mithril proofs.
This setup phase must be done only once and is valid for as long as the same proof system (eg, the parameters might be statically baked into the various systems producing and consuming Mithril proofs).

Similarly, during the protocol establishment phase, the parameters `k`, `m` and `phi_f` are defined, as well as the set of allowed signers.

### 2. Initialisation Phase
### 2. Initialisation phase

This phase includes both the actual initialisation phase of each party, and the registration of keys.
This phase includes both the actual initialization phase of each party and the registration of keys.

* Party retrieves the protocol parameters
* It uses the parameters to generate a new key pair of a verification key and a signing key, plus a Proof-of-possession
`κ`. The verification key and PoP are broadcast to all other parties for registration, which is expected to last for
some limited period of time. An important difference with the paper is that registration is not centralised in the "
idealised" manner described in the paper. Instead, all signers will register against all other signers. Meaning that
each signer will trace it's own registration procedure. Together with other participants' keys, the stake of each
party is stored.
* Then an aggregate verification key (`AVK` in the paper) is created from the registration material, in the form of a
Merkle-tree.
Firstly, the party retrieves the protocol parameters.

The key dissemination process can also happen on-chain, which makes sense as the parties need to have some guarantees about the validity of keys and stakes of each other party.
Next, they use the parameters to generate a new key pair of a verification key and a signing key, plus a proof of possession (PoP)
`κ`. The verification key and PoP are broadcast to all other parties for registration, which is expected to last for a limited period. An important difference between the implementation and the paper is that registration is not centralized in the 'idealized' manner described in the paper. Instead, all signers will register against all other signers. Thus
each signer will trace its own registration procedure. Together with other participants' keys, the stake of each
party is stored.

Then an aggregate verification key (`AVK` in the paper) is created from the registration material, in the form of a Merkle tree.

This phase happens once for each _instance_ of the protocol running.
The key dissemination process can also occur on-chain, which is logical as it provides parties with assurances about the validity of keys and stake held by each participant.

### 3. Operations Phase
This phase happens once for each _instance_ of the running protocol.

Operations run in cycles, where each cycle is triggered by a message (eg. a snapshot of the UTxO set) to sign for which
### 3. Operations phase

Operations run in cycles, where each cycle is triggered by a message (eg, a snapshot of the UTXO set) to sign for which
a quorum of `k` valid signatures must be submitted.

* Each party needs to check for eligibility to sign the message. It may be eligible to sign the same message more than once. This check is performed for `m` distinct indices. For every index, the signer evaluates a function (parameterized with `phi_f`) that takes its stake as input. If the result of the function is `SUCCESS`, then the signer is eligible to sign this message for the given index.
* Each party needs to check for eligibility to sign the message. They may be eligible to sign the same message more than once. This check is performed for `m` distinct indices. For every index, the signer evaluates a function (parameterized with `phi_f`) that takes its stake as input. If the result of the function is `SUCCESS`, then the signer is eligible to sign this message for the given index.

* For every valid signature, it creates a proof (`π`) containing a signature of the message, verification key, stake and paths of party in the Merkle-tree.
* For every valid signature, the party creates a proof (`π`) containing a signature of the message, verification key, stake, and paths of the party in the Merkle tree.

* Then, multiple signatures can be aggregated together to form a certificate (`τ`) by:
* Verifying signatures from each party:
* Checking the party is authorized to sign for the given index (using the same procedure as the signing)
* Checking the party is authorized to sign for the given index (using the same procedure as signing)
* Checking the proof is valid which means:
* Check the evaluation threshold is correct for party’s stake given the message, index and signature
* Check the provided path exists in the aggregate keys' Merkle-tree
* Verify the signature of the message is valid w.r.t to verification key
* Checking the evaluation threshold is correct for the party’s stake given the message, index, and signature
* Checking the provided path exists in the aggregate keys' Merkle tree
* Verifying the signature of the message is valid with respect to the verification key
* Producing an aggregation key from all verification keys
* Producing an aggregate signature from all signatures `μ`
* Producing a proof using the aggregate keys, the message and the vector of individual proofs from each party:
* In the concatenation proof system all these values are simply packed together to form the proof,
* Producing a proof using the aggregate keys, the message, and the vector of individual proofs from each party:
* In the concatenation proof system, all these values are simply packed together to form the proof
* In the case of _bulletproof_ system, a more compact proof is generated.

* Each certificate `τ` can be verified to be valid for some message, using the known setup parameters to verify the certificate’s proof and then verifying the aggregate signatures and verification keys.
* Each certificate `τ` can be verified as valid for some message, using the known setup parameters to verify the certificate’s proof and then verifying the aggregate signatures and verification keys.

:::note Note

Expand All @@ -132,6 +125,6 @@ Note that if the individual signatures are broadcast to all parties, then each p

:::tip

For more information about the **Mithril Network**, please refer to the [Architecture](../mithril-network/architecture.md) page.
For more information about the **Mithril network**, see [architecture](../mithril-network/architecture.md) overview.

:::