Skip to content
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.

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

Docs: add new Mithril certification section in website #2324

Merged
merged 8 commits into from
Feb 24, 2025
Merged
Show file tree
Hide file tree
Changes from 7 commits
Commits
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
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
title: Mithril certification
---

import DocCardList from "@theme/DocCardList";

This section explains how Mithril certification works for different types of supported data, from computing the message signed by Mithril signers to authenticity verification by Mithril clients.

Under the hood, a certification framework leverages the Mithril protocol to provide a robust foundation for 'pluggable' custom modules that support the certification of specific data types:

- **Signers** compute messages using a specific module and broadcast them
- **Aggregators** receive signatures from signers and attempt to aggregate them into a **Mithril multi-signature** ultimately sealed in a **Mithril certificate**
- **Clients** download 'artifacts' and certificates in a **trustless way** and use them to verify authenticity.

[![Mithril certification design](./images/certification-framework.jpg)](./images/certification-framework.jpg)

<small>
<center>Certification process implemented in specific modules</center>
</small>

<p />

:::info

Implementing specific modules:

- Requires significant development effort
- Must be fully deployed on the signers (the majority of SPOs registered in the protocol), aggregators, and clients before end-to-end certification can occur.

:::

<DocCardList />
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
{
"label": "Mithril certification",
"collapsible": true,
"collapsed": false,
"position": 2
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
---
sidebar_position: 3
sidebar_label: Cardano node database
---

# Cardano node database

## Introduction

The Mithril protocol supports the certification of the **Cardano node internal database**, enabling fast bootstrapping of a Cardano node. This is particularly useful for full-node wallets, SPOs, and layer 2 protocols that need to operate full Cardano nodes.

To achieve this, Mithril signers and aggregators independently compute a message representing the immutable files of the Cardano node internal database and apply the Mithril protocol to jointly sign it.

:::info

The Cardano node internal database:

- Exceeds `150 GB` on the Cardano mainnet
- Can be bootstrapped in `~20 minutes` with Mithril
- Takes over `24 hours` without Mithril.

:::

## Mithril certification

[![Design of the certification of the Cardano node internal database](./images/cardano-node-database/end-to-end-process.jpg)](./images/cardano-node-database/end-to-end-process.jpg)
<small><center>End-to-end certification for Cardano transactions</center></small>

:::info

Learn about the Mithril certification steps [here](./README.mdx).

:::

### Message computation

The message is the hash of the concatenation of the immutable files in the Cardano node internal database:

- the hash of the immutable files is computed with `SHA256` of their binary content
- the message is computed with `SHA256` of the concatenation of the hashes of the immutable files
- the last immutable file, the ledger state and the volatile can not be signed as they are not deterministically computed by the Cardano node.

The message computation is the same on the signers and the aggregators.

[![Design of the certification of the Cardano node internal database](./images/cardano-node-database/message.jpg)](./images/cardano-node-database/message.jpg)
<small><center>Message creation on the signers and aggregators</center></small>

### Authenticity verification

The verification process operates on the full Cardano node internal database:

- the client downloads a compressed artifact from an untrusted source (e.g. an aggregator or a cloud service)
- the client computes the message from the downloaded artifact and verifies that it is signed by a valid Mithril certificate.

[![Design of the certification of the Cardano node internal database](./images/cardano-node-database/message.jpg)](./images/cardano-node-database/message.jpg)
<small><center>Message creation on the clients (same as on signers and aggregators)</center></small>
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
---
sidebar_position: 2
sidebar_label: Cardano stake distribution
---

# Cardano stake distribution

## Introduction

The Mithril protocol supports the certification of the **Cardano stake distribution**, allowing users to verify the actual stake held by one or more SPOs at a given Cardano epoch. This is particularly useful for bridges, sidechains, or other types of layer 2 protocols that need to rely on limited committees for their operations.

To achieve this, Mithril signers and aggregators independently compute a message representing the Cardano stake distribution and apply the Mithril protocol to jointly sign it.

A natural structure for the message is a **Merkle tree**, which is succinctly represented by its **Merkle root** (the actual signed message).

:::info

The stake distribution is:

- Composed of `~3,000` SPOs on the Cardano mainnet
- Computed at the epoch boundary with the following epoch (as it evolves during an epoch and is only final at the end of the epoch).

:::

[![Design of the certification of the Cardano stake distribution](./images/stake-distribution/cardano-snapshots.jpg)](./images/stake-distribution/cardano-snapshots.jpg)
<small><center>Stake distribution snapshots done by the Cardano node</center></small>

## Mithril certification

[![Design of the certification of the Cardano stake distribution](./images/stake-distribution/end-to-end-process.jpg)](./images/stake-distribution/end-to-end-process.jpg)
<small><center>End to end certification for Cardano transactions</center></small>

:::info

Learn about the Mithril certification steps [here](./README.mdx).

:::

### Message computation

The message is the Merkle root of the Merkle tree, where the leaves are the hashes of the tuple composed of:

- The **pool ID**, which is the unique identifier of an SPO in the Cardano network (computed as the hash of the Cardano pool's **cold verification key**, which is `bech32` encoded, eg, `pool1r0tln8nct3mpyvehgy6uu3cdlmjnmtr2fxjcqnfl6v0qg0we42e`)
- The **stake** delegated to the SPO at the given epoch in `lovelace` (`1 ada` = `1,000,000 lovelace`).

The message computation is the same for both signers and aggregators.

[![Design of the certification of the Cardano stake distribution](./images/stake-distribution/message.jpg)](./images/stake-distribution/message.jpg)
<small><center>Message creation on the signers and aggregators</center></small>

:::info

The Merkle tree inner nodes are computed with the `BLAKE2s-256` hash function: the child bytes are concatenated and hashed to compute the parent node.

:::

### Authenticity verification

Due to the relatively small size of the stake distribution, the computation of the Merkle tree is quick and can be performed on the client side:

- The client downloads the serialized Cardano stake distribution from an artifact delivered by an aggregator
- The client computes the Merkle root (the message) and verifies that it is signed by a valid Mithril certificate.

[![Design of the certification of the Cardano stake distribution](./images/stake-distribution/message.jpg)](./images/stake-distribution/message.jpg)
<small><center>Message creation on the clients (same as on signers and aggregators)</center></small>
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
sidebar_position: 1
sidebar_label: Cardano transactions
---

# Cardano transactions

## Introduction

The Mithril protocol supports the certification of the **full Cardano transactions set (since genesis)**. This allows users to verify a transaction's authenticity without downloading the entire Cardano blockchain.
This is particularly useful for lightweight clients, such as mobile wallets, which may lack the resources to store the entire blockchain.

To achieve this, Mithril signers and aggregators independently compute a message representing the **Cardano transaction set** and apply the Mithril protocol to jointly sign it. A proof of membership is then generated on demand for the subset of transactions a Mithril client attempts to verify. This proof can be validated against the signed message, which is included in the Mithril certificate.

A natural structure for the message is a **Merkle tree**, which:

- Can be succinctly represented by its **Merkle root** (the signed message)
- Allows for membership proof of a transaction in the set by providing the **Merkle path** from the transaction to the root.

This certification is conducted under high constraints when operating on the Cardano mainnet:

- The current Cardano transaction set exceeds `100 million` transactions
- The Mithril signer footprint must remain minimal (low memory, low CPU, low disk space)
- On-demand generation of the proof of membership must be fast and scalable to high throughput.

:::info

Another consideration is the finality of the Cardano chain itself: the closer we examine the tip of the chain, the more likely blocks can be rolled back, potentially invalidating transactions. However, the Mithril protocol is designed to offer certification with high guarantees. As an initial implementation, we have chosen to certify the transaction set at a **fixed offset from the tip of the chain** (currently `100` blocks on the Cardano mainnet). This balances finality guarantees and the latency required for Mithril to certify a transaction after submission.

The distance from the tip at which the transaction set is certified affects the Mithril protocol itself: the closer to the tip, the more likely some signers may operate on a temporary fork of the Cardano chain (which will later be rolled back), potentially preventing the quorum needed to create a valid multi-signature. The offset can be adjusted as a Mithril network parameter.

It is also worth noting that a new signature round is **triggered at a constant pace** (every `30` blocks on the Cardano mainnet).

:::

## Mithril certification

[![Design of the certification of the Cardano transactions](./images/cardano-transactions/end-to-end-process.jpg)](./images/cardano-transactions/end-to-end-process.jpg)
<small><center>End to end certification for Cardano transactions</center></small>

:::info

Learn about the Mithril certification steps [here](./README.mdx).

:::

### Message computation

Creating a Merkle tree with `100 million` leaves is impractical due to high memory usage and long computation times, which exceed the operational capacity of the signer. However, a **Merkle forest** offers a suitable solution. In this structure, the leaves of the signed Merkle tree are the roots of separate Merkle trees, each representing a contiguous block range. Each Merkle tree’s leaves are the transaction hashes within those blocks.

This structure is nearly append-only for transactions, allowing for some stored data compression when not used to create a membership proof. As a result, the volumes of information stored on signers and aggregators differ.

The blocks are divided into **block ranges** of `15` blocks. The leaves of the Merkle trees are the hashes of the transactions in the blocks within each range (`~150-1.5k` transactions per block range on the Cardano mainnet).
This reduces the number of leaves in the Merkle forest to approximately `1 million` on the Cardano mainnet – about `100` times fewer than the number of transactions in the blockchain.
This allows to create a Merkle forest of on an average `100` times less leaves than the number of transactions in the Cardano blockchain (`~1M` leaves instead on the Cardano mainnet).

[![Design of the certification of the Cardano transactions](./images/cardano-transactions/message-aggregator.jpg)](./images/cardano-transactions/message-aggregator.jpg)
<small><center>Message creation when aggregating on the aggregator</center></small>

The process is almost the same on the signer, except that the transactions of the block ranges are ephemerally stored and only their compressed representation is kept in the long run (the Merkle root of the block range Merkle tree) once the blocks are final (older than `k` blocks from the tip of the chain, `2160` on the Cardano mainnet). This allows drastic compression of the storage on the signers.

[![Design of the certification of the Cardano transactions](./images/cardano-transactions/message-signer.jpg)](./images/cardano-transactions/message-signer.jpg)
<small><center>Message creation when signing on the aggregator</center></small>

The Merkle tree inner nodes are computed with the `BLAKE2s-256` hash function. This involves concatenating the byte representations of the child nodes and then hashing them to compute the parent node.

:::

### Authenticity verification

The verification process operates on a subset of the Cardano set that can be certified (fully or partially):

- The client calls a prover route exposed by the aggregator, which computes a **Merkle proof of membership** for the transactions signed in the latest snapshot
- The client verifies that the proof of membership is valid and that its Merkle root (the message) is signed by a valid Mithril certificate.

[![Design of the certification of the Cardano transactions](./images/cardano-transactions/proof-client.jpg)](./images/cardano-transactions/proof-client.jpg)
<small><center>Proof creation done by the aggregator _(to verify 'Tx4' and `Tx62')_</center></small>
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
Expand Up @@ -2,5 +2,5 @@
"label": "Mithril network",
"collapsible": true,
"collapsed": false,
"position": 2
"position": 3
}
Loading