Glossary
Below is a comprehensive list of definitions for some common terms used in the Mithril guide.
Beacon
A beacon represents a point of the blockchain for which a Mithril certificate is created. It embeds at least the version of the Cardano network that is targeted, the associated epoch, and the immutable file number.
Cardano network
The Cardano network is a proof-of-stake blockchain platform that supports the ada cryptocurrency.
More information is available on the introduction page.
Cardano node
A Cardano node is a node that runs in a Cardano network. There are several types of nodes, among them Cardano full nodes that hold a copy of the whole blockchain. They can be used by wallets, stake pool operators, exchanges or DApps. One of the uses of the Mithril network is to rapidly bootstrap a Cardano full node.
Cardano key pair
A Cardano key pair is an asymmetric key pair used to identify a stake pool operator on the Cardano network.
Cardano transaction
A Cardano transaction proof is a cryptographic proof that a sub-set of Cardano transactions is included in the Cardano transactions set. It is generated upon request from a Mithril client and is signed by a certificate.
A Cardano transactions set snapshot represents, in a succinct way, the Cardano transactions set that was signed by Mithril at a given Beacon.
Certificate
The Mithril aggregator combines the produced multi-signature and some metadata into a Mithril certificate that will be later used by the Mithril client to verify the authenticity of a snapshot. The certificates are chained so that the stake distribution used to create the signatures is verifiably genuine.
More information is available on the certificates page.
Epoch
The Cardano network uses epochs to group blocks computed in a certain amount of time (approximately five days). It is part of the design of its proof-of-stake consensus Ouroboros. At the end of each epoch, the stake distribution of the ending epoch is computed.
Immutable file number
Inside the database of a Cardano node, the blockchain state is stored in immutable files which never change once committed. These immutable files are designed so that they are deterministically produced and thus are the same on any Cardano node. These files are created by following an incremental number, the immutable file number, and there are three different immutable files for each number (ie, chunk, primary, and secondary). Only the files up to the penultimate immutable file number are considered as committed and final, the last immutable file number files are constantly evolving. The snapshots produced by the Mithril network rely on these immutable files.
Individual signature
For each beacon, the Mithril signers will compute on their end a message representing the blockchain state, and sign it with their verification keys to create an individual signature. Upon winning one or more lotteries, the Mithril signer will be able to use this individual signature to participate in the creation of a multi-signature.
More information is available on the protocol page.
Mithril aggregator
The Mithril aggregator is a trustless node of the Mithril network that orchestrates the work of the Mithril signer nodes and gathers their individual signatures to produce Mithril multi-signatures and their associated certificates.
It is also in charge of creating and storing the snapshot archive.
More information is available on the aggregator page.
Mithril client
The Mithril client node within the Mithril network is used to restore a Cardano full node by retrieving, from a Mithril aggregator, a remote snapshot and its certificate chain. Finally, it is used to verify snapshot and certificate validity using the Mithril cryptographic primitives.
More information is available on the client page.
Mithril network
In its current version, the Mithril network is a network of nodes responsible for creating snapshots and certificates that enable fast bootstrap of a Cardano node. It runs on top of the Cardano network.
More information is available on the architecture page.
Mithril protocol
The Mithril protocol allows stakeholders in a proof-of-stake blockchain network to individually sign messages that are aggregated into a multi-signature which guarantees that they represent a minimum share of the total stake.
More information is on the protocol page.
Mithril signer
The Mithril signer is a node of the Mithril network that works transparently on top of the stake pool operator Cardano nodes and which individually signs the ledger state.
More information is available on the signer page.
Multi-signature
The Mithril multi-signature is an aggregate of individual signatures, which guarantees that a minimum share of the total stake has participated in its creation.
More information is available on the protocol page.
Snapshot
A Mithril snapshot is a signed archive of the blockchain state that can be used by Mithril clients to restore a Cardano full node. It is uniquely identified by its fingerprint or digest which is part of the message signed by the Mithril network.
Stake distribution
The Cardano stake distribution is the list of all the stake pool operators' pool Id addresses and their associated share of the total stake of the Cardano network.
The Mithril stake distribution is the list of all the stake pool operators' (that are running a Mithril signer) pool Id addresses, their associated share of the total stake of the Cardano network, and their signing verification key.
Stake pool operator (SPO)
A stake pool operator, also known as an SPO, represents a party that holds (via delegation) stake in the Cardano network. The stake entitles it to participate in block production thanks to the Cardano consensus mechanism.
Verification key
To create individual signatures, Mithril signers must register their signing public key: the verification key. To guarantee their genuineness, they are signed by the associated Cardano key pair. It is worth mentioning that a Mithril signer must be aware of the verification keys of all the other Mithril signers to produce valid individual signatures.
More information is available on the protocol page.