Understanding Mithril

Mithril is live on the Cardano mainnet. Let's explain how Mithril works and what it is useful for.

Do not trust, verify

One of the basic principles of decentralization is the absence of a third party that you, as a participant in the system, must trust. Instead of trust, you have the opportunity to verify all information and thus get a single version of the truth. What is true for you at any given time is also true for all other participants in the system.

If you want to be a full participant in the blockchain network, you need to run your own full node that allows you to verify the history of all transactions. People are not willing to run their own full node and it is not even possible on mobile devices. Running a full node is resource intensive. Moreover, it requires time and certain technological skills.

The problem was partially solved by the so-called light nodes that store only headers of blocks (a kind of summary of each block’s transactions) instead of whole blocks. This has reduced storage, processing power, and bandwidth requirements. However, the disadvantage is that the light node cannot verify transactions independently of the full node. Light nodes also rely on full nodes to broadcast their transactions to the network and receive updates on the blockchain state.

Light nodes are able to verify transactions without full nodes only if they have a trusted source of information, such as a cryptographic proof or a trusted checkpoint. For example, some light nodes use the Simplified Payment Verification (SPV) protocol, which allows them to verify transactions by requesting proof of inclusion from full nodes. The proof of inclusion is a sequence of block headers that link the transaction to the most recent block. The light node can then check the proof against its own block headers and confirm that the transaction is valid and confirmed by the network.

There are some light wallets that are not light nodes and communicate only via proprietary protocols with servers. These are usually online wallets or custodial wallets that store your private keys on their servers and manage your transactions for you. These wallets do not interact with the blockchain directly but rely on their own servers to do so.

Even if you use Trezor or Ledger hardware wallets in the usual way, you are dependent on third-party servers that are connected to full nodes of individual blockchains.

Dependence on third parties is contrary to the ideals of decentralization, as it poses a potential risk of transaction censorship, data collection, leakage of private information, or even account freezing.

It is naive to expect people to run full nodes because of decentralization. It is necessary to create a technological solution that will offer them all the advantages of a full node and that they will be able to run conveniently on a mobile phone.

Mithril will enable the creation of trustless light clients and DeFi applications that are completely independent of third parties in terms of the ability to efficiently verify data on your own device. It also enables fast node bootstrapping and secure data synchronization, decentralized voting based on stake distribution (on-chain governance), efficient sidechain management, facilitates the development of a more scalable blockchain, etc.

Stake-based Threshold Multi-signature scheme (STM)

Mithril is essentially a signature scheme that allows the Cardano network to generate cryptographic certificates. These certificates are easily verifiable proof that it has been created (cryptographically signed) by participants owning the required amount of stake (coins).

You can think of a certificate as a message that multiple participants (ADA holders) agree to and actively validate the message with their (digital) signatures to publicly declare their agreement. Participants can essentially confirm any information with their signatures. One of the concrete uses can be the regular creation of snapshots with the state of the blockchain.

It is not necessary for all stakeholders to confirm the message. Instead, each time a new certificate is to be generated, a random set of participants is selected, and a sufficient subset of those participants are required to sign it. Similar to the slot leader who gets the right to produce a new block in a given slot, Mithril participants are randomly drawn.

Stake-based threshold multi-signature (STM) is a kind of threshold signature scheme (TSS) that respects the distribution of the stake (coins) in the blockchain network. TSS is a system that allows the generation of a single digital signature based on signatures from multiple signers.

This is a similar concept to the K-of-N multi-signature scheme. In this scheme, for example, 5 participants own a private key that can be used to sign a message. If a message is signed by only 3 participants, it is considered valid (3-of-5).

The STM scheme differs from the K-of-N scheme in that the number of participants who can sign the certificate is determined based on the number of registered participants (signers) and their stake.

If you know how a regular digital signature works, which you use, for example, when creating a blockchain transaction, you will easily understand the basic principles of how STM works.

STM is a type of digital signature protocol that allows a group of parties to collectively sign a message (create a certificate) without revealing their individual private keys. A digital signature is a way of proving the authenticity and integrity of a message. A digital signature is usually generated by applying a mathematical function to the message and the private key of the signer. The private key is a secret piece of information that only the signer knows, while the public key is a related piece of information that anyone can use to verify the signature.

Note: You will understand the image below better when you read about the roles of participants in the Mithril network in the next section.

STM works by splitting the private key into several shares and distributing them among different parties based on the stake (ADA coins). Each party can then use their share to generate a partial signature on the message, without knowing the full private key. The partial signatures can then be combined (by aggregator) to produce a valid signature that is indistinguishable from a signature generated by the full private key. The advantage of this approach is that it increases the security and resilience of the signing process, as no single party can sign or compromise the private key.

Since this is a threshold signature scheme, it is necessary that the required quorum of signers participate in the signing of the certificate. Otherwise, it is not possible to produce a new certificate, which is not a problem, as it can be done in the next round with a different set of randomly selected signers.

Signers act independently of each other and each individual signature can be verified. Individual signatures are aggregated and it is possible to produce a new certificate if the required threshold has been reached. The aggregated signature can be verified with respect to a global public key that represents the stakeholder set.

The generation of Mithril certificates is governed by several parameters. The 'm' parameter defines the number of lotteries that a single participant can sign. The 'k' parameter defines how many signatures are required to produce a valid certificate. The 'φ' parameter defines the randomness in the system that affects the chance of winning the lottery and signing the certificate.

Creating a Mithril certificate

Several roles are defined that participate in the creation of a Mithril certificate.

The Mithril signer is a node that operates transparently on top of the SPO Cardano nodes. It works in conjunction with the Mithril aggregator. The Mithril signer generates a new pair of Mithril keys for each epoch and signs them with KES keys. The verification keys (public keys) are then broadcast to all other signers within the Mithril network. The signer node regularly verifies snapshots of the full state of the Cardano blockchain and signs these snapshots by using the Mithril private key.

The Mithril aggregator is a trustless node responsible for orchestrating the activities of the Mithril signer nodes. The aggregator node controls the creation of a new Mithril certificate. To do this, the aggregator needs to cooperate with signer nodes and coordinate them. All signers in a given round sign the full state of the Cardano blockchain (snapshot) and send the signatures to the aggregator. Some signers may not be able to send a signature (outage, attack, etc.). Once the aggregator receives a sufficient number of signatures, it can create a Mithril certificate based on combining all the signatures together (combining the partial signatures creates an equivalent signature as if it were a certificate signed with a private key).

The node aggregator archives all snapshots and associated certificates. Clients can get this information from the aggregator node and work with it, for example quickly bootstrap and node.

The client can obtain snapshots and verify them through certificates, as it uses the same Mithril cryptographic primitives as signers and aggregators. The client can quickly verify the authenticity of the data, i.e. the integrity of the blockchain.

In the image below you can see the individual steps that lead to the creation of a Mithril certificate. This is a simplified form, as the process is somewhat more complex and involves more steps for all participants. There is only one signer in the picture for clarity, but in reality, there are more of them.

It is necessary to realize that the entire process of generating certificates takes place in individual phases.

In the first, so-called establishment phase, nodes agree on Mithil parameters and a group of signers.

In the second phase, keys are registered across all signer nodes. An aggregation verification key is created based on all registrations at a given time.

The third phase is called operational and takes place in cycles. The start of each new cycle is signaled through a message. A snapshot of the UTXO set will occur and signers are expected to sign the message. Each signer individually checks whether it is eligible to sign the message. For every valid signature, it creates a proof containing a signature of the message, verification key, stake, and paths of the party in the Merkle tree.

The aggregator node verifies signatures from all signers. Multiple signatures can be aggregated together to form a certificate. If a quorum is reached, it is possible to produce an aggregate signature from all individual signatures. The node produces a proof using the aggregate keys, the message, and the vector of individual proofs from each party.

Individual signatures are broadcast to all parties in the network. It is important since each party can independently produce the certificates. In particular, the party that performs aggregation is not required to have any specific knowledge, nor it is assumed to be honest. It can be said that any third party that has access to the individual signatures can perform the signature aggregation. In other words, all signers, or any other node, can become the aggregator node.

The potential of Mithril technology

Mithril represents a very useful primitive that is potentially interesting for all existing blockchains. By associating STM keys with individual cryptocurrency accounts, it is possible for coin owners to participate in the certification of any message collectively in a completely decentralized manner.

Through the parameters, it is possible to easily define a threshold (1/2 or 2/3) that must be reached in order to cryptographically prove that the required group (stake) endorses the message. Signers can sign the message individually and publish the signature through the blockchain. This is very useful for on-chain governance. Even in the case of Bitcoin, it would be possible for BTC holders to ratify, for example, a software upgrade.

Mithril can be used to regularly produce snapshots, i.e. archiving the state of the Cardano blockchain. This will enable very fast bootstrapping of a node, as it is not necessary to download the entire blockchain and verify all individual transactions in the history. It is enough for the client to download all the snapshots together with the certificates and verify them. This is possible in a relatively short time (minutes) and right after that the node can verify the latest transactions and blocks. In other words, to be a light client that does not depend on communication with a full node. Thanks to Mithril, a light client can have the same security as a full node, and the resource requirements will be so low that it will be possible to run a light client on a mobile phone.

Another important use of Mithril cryptographic primitives is for sidechains, as the transfer of assets between networks will be significantly easier through the ability to quickly verify the latest global state.

As we mentioned above, Mithril is a suitable technology for on-chain governance, as it is easy to organize voting based on coin ownership. Voting cannot be manipulated in any way by a third party and no one can be prevented from voting, as each light client will be completely independent of the third party. All voting results will be transparently stored on the blockchain and everybody can validate it.

Mithril will be an important building block for Ouroboros Leios (Input endorsers), as through certificates it will be possible to pre-prepare (pre-validate) blocks before their final inclusion in the blockchain.

Conclusion

Mithril can be seen as a big step forward for decentralization, as a large part of users still rely on third parties. People want to have fast and cheap transactions on their mobile phone and this is not possible in most cases without interaction with a full node running on another device. Most people don't want and will never be willing to run their own full node. Mithril will enable trustless Peer-to-Peer communication from your mobile phone. In other words, your phone can only communicate with the Cardano network and have the security of a full node.