Scalability is essential for a blockchain network to support an expanding user base and ensure growth without sacrificing performance.
Scaling a blockchain generally requires a combined approach with a diversity of solutions to suit each situation and project.
There are 2 main types of solutions to scale a blockchain:
- Layer 1 (L1) solutions: updates applied directly to the main chain protocol.
- Layer 2 solutions (L2): sidechains resources or ZK-rollups, which improve the performance of the main chain, diverting traffic to L2.
Among the L1 solutions, which will come to Cardano after those applied in the Vasil Hard Fork, will be the implementation of Input Endorsers, by Ouroboros Leios. This protocol will further improve block propagation times and performance as they will keep track of all submitted transactions and group these transactions into pre-built blocks. This means that there will be two sets of blocks, one that will contain the transactions and one that will achieve consensus. The blocks that will perform consensus will refer to the pre-built blocks, which will be constantly streamed without having to wait for consensus to be achieved.
If you want to read about the improvements implemented in Vasil, (the Babbage upgrade), you can read my article at the end (1).
Sidechains seek to solve the saturation problems that affect many blockchains (L1), allowing these new blockchains to be connected and interact with an existing blockchain. While these new chains contain different programming and features, they are compatible with the blockchain they join. Thanks to this, both chains can complement their capacities, serving a certain number of transactions in one or several sidechains, to later be transferred, in their final state, to L1 (which is unique).
The IOHK document, Proof-of-Stake Sidechains that was published in 2019, provides the first formal definition of what a sidechain system is in the PoS protocol, and how assets can be safely moved between sidechains.
In the Cardano blockchain there is a sidechain, called Milkomeda, and you can learn about it in the article that I leave you at the end (2). Soon the Isomorphic Multi-party State Channel solution will be applied, in the development called Hydra. I have written an article on the subject (3).
In L1, greater scalability can also be achieved, speeding up the speed and efficiency of data synchronization between applications (DeFi, wallets, etc). The IOHK research team published, in May 2021, the Mithril: Stake-based Threshold Multisignature document, which I will explain in this article.
Aiming to Be a Stronger and Lighter Structure
IOHK introduced Mithril during the Cardano Summit 2021, since then the team has made steady progress in development. It is part of the Basho Era.
I did not find official information on why that name was chosen, but on WikiWand says that Mithril is a fictional metal found in JRR Tolkien’s Middle-earth writings, and It is described as resembling silver, but being stronger and lighter than steel. I think I understand that this name was the right choice, let’s see.
Because each node has a complete copy of the blockchain, node synchronization takes time as each new node must download and verify each block. This requires specific software and storage requirements, which also means that it takes more time to synchronize the state of the chain.
Efficient chain validation is essential, to achieve higher scalability in a blockchain environment.
Mithril is a stake-based signature scheme that improves the speed and efficiency of syncing times for nodes joining the network.
Mithril addresses the complexity of critical operations, which depends on the number of participants, where the greater the number of participants, the complexity increases geometrically (rather than proportionally).
Considering the time it takes to validate a particular message, and the resource usage during the validation phase of chain synchronization, Mithril will provide a solution that makes the aggregation of multiple signatures fast and efficient without compromising security features.
The main problem is to extract only part of the information from the network, for a thin client, since it does not download the entire blockchain. Blockchain synchronization is an intensive operation, because it is a very large information base, currently over 81GB, and it is constantly growing.
Mithril is the cryptographic construct that allows thin clients (such as non-node wallets) to obtain data from the blockchain, without downloading all of its content. Synchronizing the blockchain is an intensive operation, because it is a constantly growing information base. It is a protocol, which acts as a threshold signature scheme based on participation, being transparent, secure and light.
For certain messages or actions, it is important that a certain number of participants provide their cryptographic signatures. The consensus protocol determines how the individual nodes evaluate the current state of the accounting system.
The greater the number of participants, the more complex it will be to efficiently add their signatures.
Considering the time it takes to validate a particular message, and the resource usage during chain synchronization, it is vital to provide a solution that makes aggregation of multiple signatures fast and efficient, without compromising security features.
The following properties are crucial for the scheme:
- It must contain the threshold behavior of a cryptographic signature, which means that it is possible to produce a valid signature, only if a certain list of fund holders is read, expressed in terms of delegation
- As Multisignature , the pre-signature fragments can be verified independently, and then publicly added to the final signature.
- The final signature, of constant size, is verifiable logarithmically, based on the total number of coin holders.
Mithril’s Research Paper reflects on how to maintain a strong security configuration in multi-signature aggregation. As a result, Mithril can be applied for fast, efficient and secure chain synchronization protocol.
Use cases can be for secure voting, data exchange between sidechains, and data synchronization within light wallets.
Holders will include the Mithril keys along with the basic crypto keys in their wallets. The blockchain will contain the UTxOs information, registered account information, and Mithril keys.
At regular intervals, the full nodes will collect the UTxOs and test where they can produce a pre-signature. This test is critical as not all holders are eligible to issue the signature on a given message, only a random set will be chosen. Only when there is a sufficient number of presignature fragments, which are issued by the chosen ones, will it be possible to add these fragments to the final “Sigma” signature.
This will improve chain synchronization while maintaining trust, with multi-signature aggregation, which is a fast and efficient way to log in, without compromising security features.
Mithril’s goal is to leverage the existing network to provide certified snapshots of all, or part, of the state of the blockchain. These snapshots can be useful in different ways. The IOHK team has been working on a first use case to leverage Mithril to quickly and efficiently boot up a full Cardano node.
Mithril operates on top of the main ledger, ensuring that it does not interfere with main network operations, and since the signatures created are condensed, it requires minimal additional resources and low bandwidth usage for the signature nodes.
The peculiarity of Mithril certificates is that they have the same security properties as Ouroboros, the underlying protocol of Cardano.
Mithril’s design involves three phases:
— Parameter setup. To set up a Mithril protocol, users need to:
- fix the group setting where the cryptography will take place
- select the index range M, which is the number of elections they will be holding
- set the quorum size K, which is the number of election winners that need to sign a signature for it to be accepted.
—Initialization. During this phase, users should update the state distribution.
—Operation. While working with the chain, users can produce, aggregate, and verify Mithril signatures. Producing signatures involves users’ attempts to check if the signature they produced is actually a winner on one of the lotteries held in parallel. If true, the users will broadcast their signatures. If there are enough signatures supporting a particular message over different lotteries, they can be aggregated into a single Mithril signature. It can then be broadcast and verified by anyone using only the reference string for the proof system and the very short Merkle tree hash of stake distribution.
Development Update
The team has been working on the development of the Mithril Core library, which implements the full-featured cryptographic primitives of the Mithril protocol.
He also worked on the creation of the Mithril Network, which is implemented on top of the Mithril Core library.
The current structure of Proof of Concept (PoC, the incomplete implementation of a method or an idea, carried out with the purpose of verifying its viability), has the following components:
- The Mithril Signer: the node that works transparently on top of the stake pool operator Cardano nodes and individually signs the ledger state.
- The Mithril Aggregator: the trusted node run by IOHK 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 ledger state snapshot archive.
- The Mithril Client: the node used to restore a full Cardano node by retrieving a remote snapshot and its certificate chain from a Mithril Aggregator, and by verifying snapshots validity thanks to the Mithril cryptographic primitives.
The team is currently in the final stages of optimizing and testing the Mithril Network in its first centralized version (i.e. running with a Mithril aggregator operated by IOHK). This phase will allow company engineers and researchers to work on launching a more decentralized version of the Mithril Network on the Cardano mainnet, where stakepool operators will also be able to run Mithril Aggregators on their own.
New use cases will be added, such as the implementation of Mithril in thin clients and wallets.
The Mithril repository is now open source.
For more information check out the Mithril proof of concept documentation and the Discord channel for further discussion.
. . .
(1) Basho Era Progresses with ‘Vasil’ Hard Fork
