The Insolar case: Why using a single consensus may not make sense anymore?
Also published at: https://adlrocha.substack.com
A while ago I wrote an article discussing the different types of consensus algorithms out there, what they consisted in, and its virtues and vices. One of the points I wanted to stress in the publication is the importance of choosing an optimal consensus algorithm while developing your blockchain use case. Of course, there are many other design decisions you need to take into account while developing your brand new Dapp, but choosing a good consensus algorithm in your design may make your developers lives way better. It is not the same to develop a Dapp for a use case with high-throughput and more relaxed trust requirements over a Proof-of-work consensus than over a BFT-based network.
Let’s try to choose one.
A lot of work is being done around the design and development of new and better consensus algorithms every day. So what should you look for when choosing a consensus algorithm? The first thing you need to determine is the specific requirements of your use case. Do you need a high transaction throughput? Is there some kind of trust between entities in the network allowing us to relax the security and trust requirements? Are we targeting a private, public or permissioned network? How many nodes will there be in the network, and how will my Dapp coexist with other applications deployed? Do I need finality to be fast?
With our application requirements settled, is time to look at at all of our potential candidates. Along with other design decisions (such as the need of smart contracts, for instance), the selection of the consensus algorithm to use for our application may condition the specific platform and network over which we are going to develop and deploy it. What kind of features should we have a look at when choosing our perfect consensus?
- Transaction throughput: This is one of the metrics that worry developers the most when talking about performance. The more transactions per seconds a network can accommodate, the more users in parallel it will support. However, in current existing consensus algorithms there is a trade-off between performance and level of trust that you will have to maneuver with.
- Finality: The time required to be able to consider the data stored in the ledger final may be critical for certain use cases, so bear finality in mind while you are design it.
- Scalability: This is one I really like. How well does our target consensus accommodate new applications, new nodes, or higher transaction throughputs. These may seem like “easy” maintenance tasks, but in certain consensus algorithms adding a new validating node is not that easy, and the coexistence with other applications may break yours, so do not overlook this.
- Trust / Centralization: How is the consensus reached? Every node in the system has the same power in the reaching of the consensus, or there are “higher rank” nodes? This definitely conditions the use case design, network topology and governance. If we can trust a small number of nodes we may go for more relaxed trust requirements and go with validator nodes and a PBFT consensus. However, if trust is an issue and you can trust no one, you may have to sacrifice a bit of performance for the increased trust.
- Interoperability: And the most discussed feature along with performance discussed these days. People do not realize it, but choosing the wrong consensus may condition the future interoperability of your use case. Is not the same to deploy your Dapp over a Cosmos-based network, or a Polkadot-compatible chain, than going for a simple PBFT without interoperability in its roadmap.
The following image does not include all of the aforementioned features, but it gives a good baseline guide to help you choose the perfect consensus for your use case.
But why choosing one when you can choose them all?
I thought that once you chose your preferred consensus algorithm, you were marrying that consensus (and its corresponding platform) for all the lifecycle of your application (as long as you didn’t make the decision to migrate to an equivalent or completely different). That was until I met Insolar. Insolar is a brand new blockchain platform with really cool features that enhance in several ways current blockchain platforms. And one of them is the use of dynamic consensus (If you want to learn a bit more about Insolar, I wrote another article with a brief overview of their technology).
Insolar implements currently two type of consensus protocols: Utility protocols (for network maintenance procedures), and transaction-validating protocols. Insolar has this approach to enhance the scalability and performance of current blockchain designs. Instead of forcing all nodes to agree on all transactions, Insolar nodes first agree (using BFT) on who are active (valid nodes) and what is a new entropy (randomness), then, by using a set of active nodes and entropy, nodes are assigned to process transactions within smaller groups of nodes by using Domain consensus protocols.
For the utility protocols, Insolar uses the concept of Globula Networks (virtual sub-networks). This means that the list of active nodes is maintained not within the whole network, but within each Globula. Globulas then agree with each other about active nodes. This separation into Globulas is only applied to network consensus, while the smaller groups are composed with nodes of different Globulas to process transactions. This results in two consensus protocols that define interaction within the Globula and among different Globulas:
- Globula Network Protocol: A BFT-like protocol that establishes data consistency among Globulas
- InterGlobula Network Protocol: A dBFT-like protocol that extends the Globula Network Protocol and establishes consistency among globulas.
To orchestrate all this network architecture, Insolar uses the Pulsar Protocol. This protocol is like the “clock” of the network (if you allow me the electronic analogy). It generates a periodic pulse to indicate the beginning of validation times for nodes (globula network conensus). Pulses include an increasing sequence number, a timestamp and a source of entropy to avoid the collusion of nodes. As outlined in this post, Pulses are necessary to ensure the random nature of allocating executor and validator status to nodes for smart contracts, thereby ensuring network security.
And apart from this elegant approach for the consensus, here comes the reason for my love for Insolar (and the reason for this article), Domain Consensus Protocols. They define the way in which smart contracts and their corresponding transaction will be validated within the network. We have a consensus to validate (1) the execution of contract logic; (2) the finality/completeness of distributed transactions; and (3) node permissions and records to be added into ledger. This gives us the flexibility to fine-tune the consensus algorithm for our specific use case and application requirements. Even more, through the life of our application we are able to configure these features to evolve with our application. How cool is that?
Layering the protocols already works in the Internet
So in the end, we may not need to choose a specific consensus for our application. Insolar follows a layered consensus approach to ensure the honesty of nodes and the validation of transactions while offering a lot of flexibility and scalability for the design and coexistence of any type of use case. With Insolar you can completely fine-tune the network to the needs of your applications. For me, they follow a similar approach to the one we are using in the “traditional” Internet, with different layers of protocols and networks (LAN, etc.), each with a specific role, and fine-tunable according to the application. Insolar’s technology offers some fresh air to the blockchain technical discussion, and we will have to stay tuned for their adoption and future developments.
