Software, like many great works, is generally viewed as its result in isolation, and the journey to get there is often ignored despite being just as, if not more valuable than, the outcome. It feels slightly unfair to compare the process of writing software to more traditional engineering works such as bridge building. Still, there are a number of parallels, especially when it comes to software like Mintlayer, with its rigorous security requirements. When one first sits down to work out what needs to be done, it can seem somewhat daunting to approach a project such as Mintlayer; there are big questions about how the project should work, such as how the consensus system should look, smaller questions with deep security payoffs such as the cryptography that should be used, implementation choices that will influence the maintainability and performance of the software in the future, and even if it looks somewhat superficial on the surface even decisions like which programming language to use have deep repercussions for the future of the code base with certain languages having small numbers of users meaning it is challenging to increase participation in development and others having their limitations.
Proof of Work: Simplicity and Competition at its Core
When it comes to designing a blockchain project, a considerable amount of decisions have to be made. Should the project be a PoW, Proof of Work, blockchain? Should it be PoS, Proof of Stake? Should it be something else entirely? Many other options are floating around these days, and it’s not overly tricky to envisage something novel that nobody else has implemented yet, so should we go down that route? Is safety the most important aspect of the blockchain? Is it speed? Is it liveliness? Is it to have every possible feature and include everything except the kitchen sink? From its conception, Mintlayer was designed to be a Bitcoin sidechain that would enable DeFi features on Bitcoin in a way that would be simpler to use with a lower overhead to entry and without some of the limitations of some competing projects. Mintlayer wouldn’t be alone in its aims, but what design decisions could be made to make Mintlayer the best choice for a future user?
Before we delve into the specifics of Mintlayer and the design decisions that were made, we should first define a few terms that will come up repeatedly for completeness and to ensure we’re on the same page if nothing else. When Bitcoin introduced the idea of decentralized blockchains to the world, he utilized an older idea called PoW to help secure the network. The key idea is that to produce a block; you must solve a so-called crypto puzzle by finding a valid hash below some target. Producing a valid block is energy intensive and thus costs money, making it less viable to act maliciously. PoS is a more recent development from the blockchain world that chains, including Ethereum, have widely adopted. PoS intends to address some concerns with the PoW concept, including the energy-intensive nature of PoW mining. Rather than using energy to produce a block, PoS requires people to lock, or stake, coins to have the right to propose blocks to the network.
As we said before, Mintlayer was always proposed as a DeFi-focused Bitcoin sidechain; as a sidechain, we mean a chain that doesn’t act as a master or slave to Bitcoin but is interoperable, in some ways, with Bitcoin. We wanted tokens on Mintlayer to be usable, via atomic swaps, with the native Bitcoin mainchain without the need for a wrapped Bitcoin token like one would rely on in most existing DeFi ecosystems, or other Bitcoin sidechains. Mintlayer was proposed with a simple UTXO-based tokenization system without the complexity of requiring Solidity, or any other language, to create a token; and without the overhead and complexity of Turing-completeness as much as possible relying on Bitcoin-esque scripting. Perhaps most importantly of all, Mintlayer was designed with a security-first focus, a tradeoff that sacrificed some speed and flexibility, a tradeoff we were happy with not only because security was considered the most critical focus but because it’s possible and perhaps even preferable, for most transactions to happen off the chain on something akin to the Lightning Network or another rollup based solution and Mintlayer itself can be used primarily as a settlement layer.
Mintlayer was always meant to be a PoS system, but we started the code base with a PoW chain. Since we began the current implementation with a completely empty repository, we decided to start with a PoW consensus protocol, which would allow us to get started on the rest of the code base quicker. PoW is inherently simpler than PoS with far fewer security concerns meaning getting a working consensus protocol took a matter of days as opposed to months. Once it was in place, we could build the rest of the project around it since there wouldn’t be a gaping hole in the project. This code strictly continues to exist today, although it does not form part of the Mintlayer consensus.
From Liquid to Modern PoS
So what about PoS? We’ve spoken about Mintlayer’s PoW implementation but have somehow avoided discussing the PoS so far. The story of Mintlayer’s PoS consensus is far more convoluted, and the story begins several years ago when Mintlayer was first envisaged. When the Mintlayer concept was first born, as with most projects, the first step in the process was to spend a great deal of time studying existing solutions to Bitcoin DeFi to find out what worked and what didn’t. One such project was Blockstream’s Liquid. At its core, Liquid shared a lot of the functionality that Mintlayer aimed to have. Liquid operates as a pseudo-PoS chain where the ability to become a block producer, a functionary in Liquid terms, is based on an off-chain agreement directly with Blockstream instead of staking coins on-chain. This is a point of centralization at odds with Mintlayer’s core ethos. So how could this be improved?
In the following years, Mintlayer’s PoS consensus has been through a number of evolutions, eventually finishing with what we see today. However, it would be unfair to call that the final product since it is still being actively worked on, and we will endeavor to improve it for the foreseeable future. In one original conception of Mintlayer’s PoS consensus, NFTs were used to trade the right to produce a block. Whoever held the NFT had the right to create candidate blocks, whether for a given slot or not. This proposal was eventually discarded due to concerns around market liquidity which would likely have meant that block production rights would have ended up in the hands of a few with little recourse for those outside the chosen few.
The next step was to use ML, the fungible native Mintlayer coin; this avoided the potential liquidity concerns of the non-fungible approach and allowed Mintlayer to build on the work of the many modern PoS protocols out there who had been researching these problems for many years. This version of our PoS consensus used Bitcoin as a source of randomness to predict block producers in advance. Although an improvement, once again, the proposal was not without issues. Using Bitcoin block hashes as a source of randomness introduced two key potential weaknesses. First, the block producers would be known in advance, allowing DoS-style attacks against the nodes. Secondly, it raised the possibility of people being able to influence the randomness being used, although the risk of this is relatively low, to say the least. Staking in this iteration of PoS retained some degree of centralization, too, requiring 0.01% of the total initial supply to be a block producer without native support of pools or delegation.
Mintlayer’s PoS
This brings us finally to today. What we’re working on as we speak and what exists in the testnet. There are two key changes to the above, both of which have been hinted at already, so you might be able to guess what they are. They are, of course, dealing with randomness for block producer selection and the introduction of pools. To say they’re the only differences is a little unfair, however. Still, as a user, they’re the things that will stand out as most of the other changes are far subtler and part of the mechanics of what we’re doing and are significantly less exposed. The current version of our PoS has been worked on for well over a year at the point of writing. It represents the aggregation of knowledge from a number of sources, including other blockchains, research papers, and our own work and intuition. Some parts of what exists today look similar to what exists elsewhere, and this is because we believe it represents the best way for us to handle it, given our requirements and constraints. In order to reduce centralization, we introduced the idea of pools with the option for users to delegate to a pool to earn a portion of the pool’s stake rewards too. Although the original 0.01% of the total initial supply limit is retained, it now becomes the pledge required to start a pool. That is to say that if you want to run your own pool, you need the 40_000 ML. If you have fewer ML, you’re no longer locked out of the network’s consensus, though. Delegate your ML to an existing pool, and you’re good to go.
But how did we deal with randomness? We introduced Verifiable Random Functions, which I’ll shorten to VRFs to deal with randomness. Without wanting to get into the nitty-gritty of how they work too much, as this is neither the time nor the place they essentially work by allowing a node to generate a random number which is then compared to a threshold which is adjusted both to ensure block production averages at one block every two minutes and to take in to account the pool’s relative stake. A block can be produced if the random number, hashed with a timestamp pointing to the current time, is below the threshold. This trick also allows the time to tick in the blockchain. If it sounds a little familiar, it’s because it’s somewhat similar to how PoW works. One thing that we haven’t discussed yet but feels important enough to cover quickly is the chain selection rule introduced in our PoS protocol; it can essentially be seen as a superset of the chain selection rules in Cardano and Peercoin and selects the best chain by selecting the densest chain.
Potential Changes Under Discussion
We said before that the consensus is very much a work in progress, so what is it that is likely to change? There are a few ideas that have been percolating in our minds to improve the current PoS proposal. Some of those are ideas that will happen, and some of those ideas represent future research avenues. We will likely introduce a key evolving signature scheme for security purposes, and we are actively working on adding the concept of a saturated pool to the rewards mechanism to help limit centralization; this will likely come hand in hand with reward-based benefits for pools with a higher relative pledge. One thing that has been an area of some contention with Ethereum since their move to PoS has been the idea of slashing. As it stands, we lack a punishment mechanism for pools seen to be acting maliciously, but this is something that will likely be introduced in the future in an effort to secure the chain long-term. There are several ways this could be implemented, and it’s not necessarily clear yet which of those represents the best path. One last notable item is missing from earlier versions of our consensus, which is a direct link to Bitcoin. Although Mintlayer remains a Bitcoin sidechain that will be directly interoperable with the Bitcoin mainchain, the difficulties of safely linking the consensus to Bitcoin have been shelved for now. This isn’t because we don’t intend to do further work down that avenue but to ensure we could release a consensus protocol that is verifiably secure in a reasonable time. Now we’ve reached the point where the consensus is approaching a point of stability, and these more novel avenues can be investigated further.
