At the Cardano Summit 2021, IOHK researchers Pyrros Chaidos and Roman Oliynykov presented the design and goals of Mithril – new research and engineering effort carried out by IOHK. Mithril will provide a stake-based threshold signature scheme that can be implemented as the protocol to solve chain synchronization, state bootstrapping, and trust issues in blockchain applications.

Mithril is the name used for a fictional metal in Middle-Earth – a malleable material, very light in weight but strong as 'triple steel', which does not tarnish or dim. Thus, the name symbolizes strength in terms of security and a lightweight approach with regard to the developed protocol.

Leveraging stake for signature aggregation

Let’s start with some background information to understand Mithril's benefits for the development of blockchain solutions.

Cardano is a proof-of-stake blockchain, so the consensus algorithm randomly selects nodes to become block producers according to the stake they hold. For certain messages or actions, it is important that a particular number of stakeholders provide their cryptographic signatures. The consensus protocol determines how individual nodes assess the current state of the ledger system and has three main responsibilities:

• perform a leader check and decide if a block should be produced
• handle chain selection
• verify produced blocks.

To achieve greater scalability in a blockchain setting, it is essential to address the complexity of critical operations that depend logarithmically on the number of participants. This means that the higher the number of participants (which are assumed to be numerous), the more complex it becomes to efficiently aggregate their signatures. In a base scenario, to presume a signature that talks for the majority of stakeholders, every stakeholder needs to sign the appropriate individual message. Although this is possible, it is inefficient in terms of scalability and speed.

Given 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 multi-signature aggregation fast and efficient without compromising security features.

Mithril protocol design

Mithril is a protocol designed to:

• leverage stake to obtain higher efficiency
• ensure transparent setup while not requiring increased trust settings
• leverage trade-offs between size and efficiency, which is guaranteed by the modular component design.

Mithril works in a public setting where signers don’t need to interact with other signers to produce a valid signature. The aggregator combines all the signatures into one, and this process is logarithmic with respect to the number of signatures, which results in a sublinear performance for Mithril aggregation. For example, when applied to full node clients like Daedalus, Mithril can boost full node data synchronization ensuring speed and decreasing resource consumption.

To represent a significant fraction of the total stake, Mithril uses the stake-based threshold setting. This behavior is different from the standard setting in which the given number of participants are required to validate a particular message. In the stake-based threshold setting, the protocol requires a fraction of the total stake to validate a given message to generate a correct signature.

Mithril also certifies consensus in a trustless setting. This means that it does not include any additional trust assumptions. It is possible to achieve consensus certification without including any additional assumptions, other than those already present in the proof of stake. For example, it can work within wallet-as-a-service, and the mobile client will use the certificate obtained from a Mithril node. With advanced security settings, such a procedure is potentially more efficient than SPO blockchain verification.

Finally, to ensure fast chain state bootstrapping, the signature scheme allows different stakeholders to validate only a given checkpoint of the chain. Stakeholders need not go through the whole transaction history of the given state – they simply need to go through the checkpoints to verify that the final stake is valid. This is beneficial for light client applications like light wallets that need to work fast without a full chain synchronization. Mithril signatures can be also useful for lightweight tally verification, or cryptocurrency governance decision making.

How it works

Mithril enables a multi-party signature by holding a number of individual lotteries (M) and considering a message to be valid if it has been signed by a number of different winners (K) over those lotteries. Each user, therefore, attempts to sign the message and then passes its signature through what is considered a lottery function. This function allows individual users to check if their signatures are eligible as lottery winners and output those without waiting. This is different from a standard setting, where slot leaders need to wait until their slot is active to participate. Once there are case signatures over different lotteries, they can be aggregated into a single Mithril signature.

Phases

The design of Mithril involves three phases:

Figure 1. Phases of Mithril operation

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.

It is also important to provide a reference string for the proof system. This is possible in a transparent manner and does not require any high trust assumptions.

Initialization

During this phase, users should update the state distribution. This lets every stakeholder know from what stake they are holding. Then, each stakeholder is responsible for registering their keys. This can happen either on or off the chain.

Finally, users need to distribute stake and compress their test keys, which is done using the Merkle tree. This function allows Mithril signatures to be verified against a single hash that represents that Merkle tree. So, the size of the state needed to verify a signature can be kept low.

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.

For example, a single user can create a signature with Mithril as follows:

Figure 2. Mithril signature creation

First, a user will check the amount of stake they hold and pass it through a score function to obtain their score threshold T. Then, they will attempt to produce a candidate signature S. For each index, they will evaluate whether the candidate's signature they produced paired with the message they have just signed. The index number of the lottery they're checking against should also produce a score value that is less than their threshold T. If that is true, then the candidate signature they produced has actually won the lottery on that particular index number. If not, they will make the next attempt.

After trying all possible indexes, users will potentially have one or more indexes for which their signature S is valid. For each of those indexes, they can output an individual signature consisting of their candidate signature, the index number for which it is valid, and the proof that verifies that their score is consistent with the registered stake.

Network architecture

Implementing Mithril on Cardano, we can represent the software interaction as follows:

Figure 3. Mithril network architecture

A high-level representation of software around a stake pool operator (SPO) includes its connection to the Cardano peer-to-peer (P2P) network, the Mithril node’s P2P network, and the Mithril client connected to the node run by an SPO.

The Mithril node at the SPO platform accesses its verified blockchain at the local storage and runs the protocol to produce Mithril certificates that are kept at the Mithril storage. Produced Mithril certificates can be verifiably synchronized across the whole network. Thus, the SPO can share both the full Cardano blockchain and the list of valid Mithril certificates for it. When the Mithril client connects to the network, it requests a list of Mithril certificates and asks only for the longest chain of the Cardano blockchain.

Several SPOs can also participate in such a setting. The Mithril client will then verify that certificates fully confirm the obtained Cardano blockchain. The whole procedure is lightweight and will not require the involvement of significant network storage or computational resources. Moreover, Cardano full node sync and fast sync with Mithril procedures are not mutually exclusive – they can be run in parallel. Mithril fast sync will be later confirmed by the full node sync.

Use cases

Let’s take a look at the use cases where Mithril applicability is highly beneficial.

Mithril boosts the efficiency of full node clients or applications such as Daedalus. It ensures fast and secure synchronization of the full node data, significantly improving time and required resources including computation, network exchange, and local storage while keeping high-level security guarantees.

Mithril is also applicable to light clients and mobile applications, ensuring a trustless approach. Another significant advantage is using Mithril signatures for running sidechains. The main blockchain can connect to different sidechains that can even have different consensus protocols. Mithril has benefits in lightweight blockchain state verification, and thus, certificates can validate the current state of the specific blockchain as well as the correctness of forward and backward transfers in a secure way.

Finally, stake-based voting applications and governance solutions can use Mithril regardless of the voting protocol’s complexity. Mithril signatures can be utilized for secure and lightweight tally verification. This is also useful in governance when stakeholders go through a decentralized decision-making process and provide the final result in an easy and verifiable way.

Implementations

Several companies are already interested in Mithril implementation within their blockchain solutions. Galois, an advanced R&D firm focused on formal methods, cryptography, and hardware, will be implementing the first Mithril prototype based on the research done by IOHK. Galois will be implementing Mithril in the Rust programming language due to its fast prototyping features. They plan first to present smaller signatures with BulletProofs, then followed by production-ready implementations, and finally formal proofs of correctness.

Idyllic Vision is another company focused on building a self-sovereign identity protocol based on zero-knowledge proofs, a credential management system for organizations, and a mobile wallet for end users that supports interoperability between diverse society solutions. They are planning to implement the proof of concept of the Mithril node. In the following months, they will begin with creating a blueprint of solution architecture, defining a number of system components that should be developed and organically integrated into the existing infrastructure. This includes integration with the Mithril crypto library and the Cardano node, and a networking layer for communication between nodes. The result of this phase should be integrated into Cardano to enable fast bootstrapping of the node and support for extra functionality like lightweight clients as others.

To find out more, read the Mithril research paper and watch the Cardano Summit presentation.

You want to demonstrate a unique combination of blockchain functions, bringing real-world elements together with collectibles and smart contracts. Of course you’d like to have a massive cohort of willing creative participants just ready and waiting to develop it. 

It’s time to call in the guitar-playing bisons, obviously. 

Crypto Bisons, a blockchain-enabled NFT game unveiled at Cardano Summit 2021, is based on an original concept from Charles Hoskinson, who, as well as founding Cardano, is a long-time gamer and game designer. He is also the owner of a herd of 500 or so bison. Because, why not?

To see where the idea would go, Hoskinson enlisted the help of by six students at Enjmin*, the national digital game school of France in Angoulême. ‘We said to them, “Have some fun with it and see what you guys can do.” And it’s absolutely remarkable to see, month by month, the level of creativity and the convergence to something that actually has very practical gameplay mechanics,’ said Hoskinson. 

Karim Sellami, who managed the French team, said: ‘The first question that we had as students was not about gaming at all, but what happens in your field when you have so many bison! One day one of the bison had a fall and it made a noise and it was exciting, and then music is born. We thought about what will happen if all the bison discover music.’

But why a game? ‘Multiplayer games are a great use-case for blockchain,’ said Romain Pellerin, IOG technology chief. ‘You have the players, and they need to connect to a system and be logged in somewhere. With blockchain you have your log-in – it’s your wallet.’

Players form bands whose members are bison. Each bison has its own personality, which develops as the game world evolves. And a bison avatar is incomplete without a saxophone, right? Or a guitar. And if it’s a buffalo soldier, it’s going to need dreadlocks too. Well, there’s your collectibles. 

The music the bison bands play is another function of the digital world: it’s algorithmically generated. ‘The original design brief was that we wanted to do something where we combine NFTs, algorithmically generated music and blockchain together with a geolocation component,’ said Hoskinson. 

‘It's a great experiment to take NFTs to the next level. Until recently NFTs were considered static things. They were pictures, videos – it was like owning a letter or something like that. It didn’t change; it was just there and, you know, it could be traded and so forth.’

In Crypto Bisons, by contrast, the way the game object is used over time, from game to game, and even on to other platforms outside the game, affects its usability. ‘And so that's really a great experiment to conduct. You know, this also has very practical infrastructural implications on Cardano,’ said Hoskinson.

And where the bison go, others are sure to follow. ‘The bridging of the physical real world with the digital blockchain world – it hasn't really been done much before. Once that’s done, you can use it as a template for anything in the physical world. It can be artwork, it can be other types of animals, it can be people, places, these types of things.’

Pellerin added: ‘The game objects can be shared across games, not only within games. You could reuse them in different games but also in other entertainment support, your own music, other video games, platforms, and social networks. Finally, the logic and the scenario can be represented as a smart contract to evolve the scenario but also the game object. So we are very ambitious for this game. It’s going to bring great innovation that will lead to standards, because we have to design what is a game object on an NFT standard. And you can have many versions of the game standard, and that will lead to greater research.’

Another thing Hoskinson likes about the game is that players compete against each other in a creative, rather than a destructive, way. The bison just want to play their way into the musical hall of fame.

(* École nationale du jeu et des médias interactifs numériques)

Catch up on all the announcements from the Cardano Summit 2021 website and IOHK’s Twitter.

The Alonzo protocol upgrade introduced Plutus – a platform that provides a native smart contract language along with the necessary infrastructure and tools to support smart contracts on Cardano. The Plutus platform enables developers to write decentralized applications (DApps) with scripting capabilities that interact with distributed ledgers.

To understand Plutus, one has to recognize three concepts:

• The Extended Unspent Transaction Output (EUTXO) model
• Plutus Core ‒ the ‘on-chain’ part of Plutus
• The Plutus Application Framework (PAF) ‒ Plutus contracts consist of parts that run on the blockchain (on-chain code) and parts that run on a user’s machine (off-chain or client code)

Both the on-chain and off-chain code are written in Haskell, and Plutus smart contracts are effectively Haskell programs.

What is the Plutus Application Backend?

In a previous blog post, we discussed the on- and off-chain functionality of core components of Plutus in greater detail. Here, let’s dive deeper into Plutus off-chain capabilities and take a look at the Plutus Application Backend (PAB).

In the UTXO model, we have off-chain infrastructure that builds the transactions that move the apps along. This off-chain infrastructure is quite complicated because it needs to look at the ledger state, pick some information from the ledger, and put it all together to build a transaction with the right pieces of data in the right place. The PAB is a single Haskell library that makes it easier to write this off-chain infrastructure and the on-chain scripts.

The PAB helps with building the UTXO transactions in two ways:

• The read path - That is, getting information from the chain, and reacting to events that happen on the blockchain. The read path is currently working on the testnet
• The write path - This is where we actually construct the transactions that run the Plutus scripts

The role of the PAB

The PAB is a key component of the Plutus Application Framework (PAF) that enables developers to create and test DApps locally, before deploying them to a live production environment. A little like the Marlowe Playground provides a sandbox for devs to create and test financial smart contracts, the PAB offers a similar environment for devs to create and test full DApps.

The PAB is an off-chain, backend service for managing and handling the requirements of the application instance throughout its lifecycle. This includes interaction with external clients (such as wallet frontends) and acts as an intermediary between Plutus Applications, the node, the wallet backend, and end-users. Such interaction is made possible by PAB commands and mock components that enable convenient simulations and integration of DApps.

While not a prerequisite for DApp creation or implementation – some developers are creating their own tools and indeed API-based alternatives are being worked on by the community – the PAB removes the need for developers to create their own infrastructure from scratch (including chain index, etc.) reducing development time and resources needed. It allows developers to simulate how an application would behave on-chain for prior testing and error elimination, to ensure a flawless transition for launch.

The purpose of the PAB is to:

• provide a standardized environment for Plutus applications to run in
• present discoverable interfaces to the external clients
• track on-chain information for smart contract uses
• allow the developer to work in an emulated or non-emulated environment

The PAB can switch between emulated and non-emulated (real network) environments seamlessly. This makes it easier to write all kinds of different tests – unit tests, integration tests, property based tests, etc. The PAB allows DApps to easily communicate with it as the backend can receive and deliver messages. Thus, the DApp can send usual requests to endpoints that the PAB has exposed, and which correspond to actions and operations that any particular smart contract is capable of handling.

Applications deployed using the framework’s libraries can run on the PAB, which provides runtime support for access to the blockchain to further perform smart contract operations triggering transactions based on the EUTXO model. Additionally, PAB features functionality for persistence, logging, and monitoring.

Where are we right now?

Earlier this summer, we deployed the first in a series of color-coded testnets to bring core Plutus smart contract capability to Cardano. This was deployed on mainnet via the ‘Alonzo’ hard fork. Smart contract capability is currently accessible using a Command Line Interface (CLI). While the first simple smart contracts were enabled on mainnet in early September, this was always the first stage in the road to DApp deployment on mainnet.

Developers have meanwhile been working on their DApps (many via the PAB) locally while testing any core smart contract functionality on the testnet. These elements need to come together before an DApp hits mainnet and this takes time. Once the PAB is integrated with the node and other core components such as the wallet back end (WBE) connector, developers will be able to move their DApps into a state of readiness and bring them to the Cardano testnet prior to mainnet launch.

These early applications built locally will then be able to interact with the mainnet as intended. The ‘mockchain’ approach to development to date means that for DApp creators, it will be a smooth transition from testnet to mainnet. All it takes is a change in the configuration files to start the PAB, it requires no changes to the actual code or to the Haskell code. This integration work is complex and a critical part of Cardano infrastructure so we need to ensure it is done correctly. We’re continuing to work on the final integrations and based on the current trajectory, we plan to deliver the integration in November, assuming we don’t encounter any critical issues.

Looking ahead

This is just the start. As always, this will be an iterative process. With the evolution of the Plutus platform, we will be inviting the developer community to deploy their own tooling and create off-chain code for their DApps running on Cardano. We have already seen a hive of activity in this area, through both the Alonzo testnet program and Project Catalyst. So while we test the platform with our engineers/QA and the developer community, we’ll be making gradual improvements and adding more capabilities and functionality. The goal? From the Alonzo hardfork and the arrival of Plutus smart contracts, a rapid scaling of the developer experience, with new tools, APIs and environments to support an already burgeoning ecosystem of talent.

For regular updates make sure you follow us on Twitter and subscribe to our YouTube channel. For an overview of projects #BuildingOnCardano be sure to check out the Essential Cardano repo.

The 100 Cardano stake pools to benefit from the third IOG delegation have been announced. They were chosen from 520 nominations made by stake pool operators, based on contributions to the Cardano community.

All the pools chosen will receive delegated stake of about 3m ada from IOG, in a strategy to encourage a vibrant pool ecosystem. By delegating this large stake to a pool for several months, IOG increases that pool's chances of minting the latest block of data on the blockchain. When a block is produced, the pool earns rewards that are split between the pool’s operators and every ada holder who has delegated to the pool.

Most of the pool operators who got involved – 84% – nominated another pool, and 7% entered just to promote another pool and didn't apply for delegation for themselves. All the pools that received delegation were nominated by other operators.

‘The selection process, although driven by the nominations of all 520 pools that took part, was discretionary,' said Ben O’Hanlon, IOG’s head of community, insights and engagement. 'But we’re clear that the 100 chosen reflect the voice of the community.’

He added: ‘A key difference between proof-of-work and proof-of-stake is that POW extracts value from the network. In POS, stake pool operators have to attract delegation, so they have a stronger relationship with other stakeholders in the ecosystem. This is why nominations are so interesting.’

Participation with others to build, create and educate is one of the salient characteristics of those selected. More than 30 tools and resources created or being developed by SPOs have been added to the Essential Cardano page on GitHub. This makes it easier for people to find their way around the ecosystem, and GitHub users can add their suggestions.

Here is the table of the 100 successful pools.

Whereas the first two rounds of delegation were about giving a leg-up to mission-driven and smaller, or ‘incubator’, pools, in this round pools were asked to nominate contributions by operators that they considered outstanding. Stake pool operators (SPOs) were also asked questions about environmental matters such as green energy use. (Their answers will be published in a follow-up post.)

‘Something that the first two delegation rounds revealed was that SPOs wanted all the good work they saw being done silently to be recognized,’ said O’Hanlon. ‘This is the feedback we heard, and so we acted on it and gave SPOs the opportunity to nominate.’

Although not everyone will agree on every delegation decision, it's important to remember how much progress has been made since the start of the year and what a success the strategy has been. When the staking process was set up, IOG ran 20 public pools to which it delegated the stake from its own ada. All but one of these were retired in December last year and part of the stake was moved to private pools through the delegation process. The first ‘call for delegation’ was on December 10 (Ada Lovelace’s birthday).

In the second round, more emphasis was placed on mission-driven pools, geographical distribution (to minimize connectivity failure), social and community activity (to keep ‘telling the story’ of the Cardano blockchain), and support for the lower-middle-sized ‘core’ of the network.

This third round opened as Cardano achieved one of its key goals – 100% of block production in the hands of the pools. Running a stake pool is a competitive business, and there are no guaranteed outcomes, but IOG has directly supported pools with 300 delegations so far as part of this strategy!

You can discover more about the latest 100 successful pools, and all the 3,000-odd active pools, at Adapools or Pooltool. On these community-built platforms, you can search on each ticker-like name for more information. Their search functions work differently and it's worth spending a bit of time looking at the differences.

Global time synchronization across any distributed network is essential to ensure its resilience.

From ensuring up-to-date information between all participants, maintaining accurate transaction processing and block creation, time synchronization is especially important in terms of smart contract deployment.

In collaboration with scientists from the Universities of Edinburgh, Purdue, and Connecticut, Input Output found a way to globally synchronize clocks across a blockchain to provide a more secure and tamper-proof global time source. This includes synchronization of time from internet of things (IoT) devices, like measurement tools in supply chains, and general distributed systems, particularly where the disruption of a central clock represents a security risk. The research is realized by Ouroboros Chronos, the Greek word for time, which is the latest iteration of Ouroboros – the consensus algorithm that underpins the Cardano blockchain.

Time matters

Time is an indispensable concept within computer programs and applications. Without this concept, we would not be able to access any transport layer security (TLS) based websites, exchange data, or utilize various cryptographic algorithms.

Yet, time tracking is a difficult problem to solve. Accurate time synchronization presumes data transmission across the whole internet, and this, in turn, takes time too. It is also hard to predict how much time would be required for certain data transmission – the network state constantly changes and relies on such factors as congestion and the actual size of data among others. Thus, inconsistencies often occur and it is important to provide the tools and solutions for accurate timekeeping.

Real time

With common computers, we take timekeeping for granted. However, there is a rigorous mechanism that works behind the scenes. The Network Time Protocol (NTP), for instance, addresses the timekeeping issue using a hierarchy of servers distributed globally. This includes up to 15 Stratums the routing paths of which are developed to synchronize in the most optimized manner. This is also enabled by the construction of a Bellman-Ford shortest-path spanning tree that decreases both latency and transmission time inconsistencies.

The UK Government’s Satellite-derived time and position: Blackett review recently highlighted the need for more resilient timing data and the dangerous dependence of critical sectors from smart grids to autonomous vehicles on Global Navigation Satellite Systems (GNSS) that are vulnerable to jamming, cyber attacks, and space weather. Additionally, the world’s first National Timing Centre, led by the National Physical Laboratory, was recently created to investigate alternative and more resilient timing services for everything from telecommunications to smart transport. International metrology centers currently have to compare clocks operating at different frequencies and in multiple locations for accuracy.

Blockchain time synchronization

The concept of timekeeping is different for distributed ledger technology. Without an accurate and valid timestamp, the network cannot verify if the transaction that is being processed is valid and does not revert the previous one. There are different timestamping techniques used across a range of blockchain ledgers, however, they aren’t necessarily very accurate. For example, Bitcoin uses timestamps for consensus security reasons, but not primarily for timekeeping; and in Ethereum, on-chain timestamps are determined by miners whereas the consensus won’t technically block or verify those for validity.

Timekeeping is essential for smart contract execution as well. Inaccuracy poses a risk for decentralized finance (DeFi) smart contract attacks. Smart contract vulnerabilities aren’t always conditioned by poor code, time inconsistencies should be resolved to block any possible attacks within the ledger.

Ouroboros Chronos: designed to boost communication and timing resilience

The new research on Ouroboros Chronos enables blockchain technology to synchronize clocks more securely. Chronos is itself a cryptographically secure blockchain protocol that additionally provides an accurate source of time via a novel time synchronization mechanism, eliminating the vulnerabilities of externally hosted clocks. This also enables blockchain to accurately time-stamp transactions making the ledger more resistant to attacks that target time information.

The new protocol can dramatically boost the resilience of critical telecommunications, transport, trading systems, and infrastructures by synchronizing local time to a unified network clock that has no single point of failure.

Professor Aggelos Kiayias, director of the Blockchain Technology Laboratory at the University of Edinburgh and Chief Scientist at Input Output, who led the research, says:

The problem of synchronizing clocks without a central time-keeper is essential in creating a truly robust decentralized financial system. For the first time, we have developed a blockchain mechanism that enables a dynamically evolving group of parties to calibrate their local clocks so they are consistent – even if they come and go following arbitrary participation patterns. By creating a blockchain-based global clock, we have also paved the way to a more secure, tamper-resistant time source with many possible external applications.

By enabling accurate timing and thus full traceability of all transactions, the scientific breakthrough also marks a major step towards creating fully auditable and fraud-proof financial systems.

To find out more, see the published research here.

Thanks to Rachel Bruce, Jenny Corlett, Rod Alexander, and Christian Badertscher for their input and support in writing this post.