The consensus algorithm is an essential part of any blockchain protocol. It is basically what makes blockchain protocols what they are, and sets them apart from standard databases.
Consensus algorithms allow for network participants to agree on whether new records to be added to the network are valid. In some blockchain protocols, consensus mechanisms also define which nodes in the network are allowed to execute, validate and store records, transactions and smart contracts.
Best Consensus: A Myth?
Among blockchain industry thought leaders there has been much debate as to which is the best consensus algorithm. The discussion between Dan Larimer and Vitalik Buterin is the first that comes to mind. However, all consensus algorithms have their benefits and shortcomings, so none of them are able to be universal solutions for any business logic.
In our opinion, the use of blockchain in a live enterprise environment is not about applying just a single consensus algorithm for an entire network, but rather allowing users and businesses to decide which rules they want to apply to their own business processes. This approach was described in our previous blog post on Domains.
Time For A Structured Approach
At the same time, there are two categories of consensus protocols utilized by the Insolar platform by default. We call them Utility and Domain consensus protocols. Utility protocols are used for network maintenance procedures, whilst the others are for approving transactions.
Let’s take a closer look.
- Utility Protocols
The first category of consensus protocol that Insolar implements are Utility protocols that define not the way how the transactions are approved, but rather the overall network operations. Simply put, it is about how the nodes in the network discover each other and who is eligible to perform certain functions, such as execution, validation and storage.
We chose Byzantine Fault Tolerance (BFT) as a base, however Insolar offers certain scalability to traditional BFT. To understand how Insolar is able to provide linear scalability, first let’s explain what we consider to be good and bad in BFT.
Most enterprise-oriented blockchain networks (both public and private) use a Byzantine Fault Tolerance (BFT) consensus algorithm. Among them are Ripple, Stellar, Neo and Hyperledger.
BFT meets the enterprise requirements more than other consensus algorithms because the list of nodes is permissioned, pre-defined and all of them have equal rights.
All the nodes within this consensus need to communicate with each other in order to agree on each transaction, reaching a required majority of ⅔+1 votes.
However, the main advantage of BFT is at the same time its weakest point. Since all the nodes on the network need to agree on an operation which results in change across the network, transactional consensus can take time, with the time dependent on the amount of nodes. As such, adding a new node to the network means not linear, but exponential growth of the connections within the network. Sounds difficult? Well, it’s quite simple: if there are 100 nodes in the network, adding a new one (total: 101 nodes), means adding 100 more inquiries. As a result, the network works slower.
BFT could work perfectly within purely private networks because there is no need for more nodes than there are equal counterparties within the business process.
Hyperledger usually utilizes 30 nodes for transaction validation, which is probably enough to provide any business process with private chain solutions. Meanwhile, Ripple has recently expanded to 55 validator nodes, but since the network serves only its own products, there is also no need for further scalability.
Insolar’s Scalability Solution
Insolar proposes to make the traditional BFT scheme more scalable,we have formulated a concept in which each new node that joins the network increases network capacity almost linearly.
To solve thе limitation of BFT consensus becoming more complicated with more nodes, we have separated consistency (validity) of node participation from consistency (validity) of transactions. So, 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.
This still-limited-BFT approach is used for consensus of active nodes, thus limiting network size to ~1000 nodes. So we have added the concept of Globulas: virtual sub-networks of up to 1,000 nodes in each.
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 amongst Globulas (a smaller network of up to 1,000 nodes).
- InterGlobula Network Protocol — a dBFT-like protocol that extends the Globula Network Protocol and establishes consistency among globulas of a Insolar Cloud Network (up to 100 Globulas, or 100,000 nodes) using leader-based consensus.
Consensus for Pulsar nodes
Pulsar Protocol is a BFT-like protocol which generates Entropy (randomness) to prevent node collusion and indicates the beginning of time periods to nodes via Pulses. Insolar implements the principles of BFT not only to manage the list of active nodes, but also for the core process of network Pulse generation. As outlined in a previous post, Pulses are necessary to ensure the random nature of allocating executor and validator status to nodes for smart contracts, thereby ensuring network security.
Pulse nodes (Pulsars) generate Pulses using BFT consensus, to agree on the Entropy (randomness) of the next pulse.
2. Domain Consensus Protocols
The second type of consensus algorithm is the so-called Domain consensus protocols. They define the way in which smart contracts are validated within the network. And there are subcategories of consensuses here too. There is 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.
A Domain owner is able to choose how smart contracts are validated, while there are also two default scenarios:
- Majority Voting requires a majority of Validation nodes to confirm a transaction and is implemented by default for public networks.
- All or Escalate requires all Validation nodes to confirm transactions. Where 100% consensus across all nodes is not achieved, another round is initiated by the next Pulse, with different nodes being elected as validators until consensus is achieved. If consensus has not been achieved after a set number of rounds, the situation is escalated in accordance with conflict resolution procedures. This will probably be used within private domains, because the nature and size of public networks makes 100% practically impossible.
Skin in the game
On the Insolar platform, attacks by malicious nodes are prevented by three factors. The first is to use different consensuses over different sets of nodes for different functions (validating nodes, validating changes and validating permissions) the second uses time-isolation of different consensuses (e.g., voters to validate permissions are elected after transaction logic was processed). The third factor is the financial responsibility of each node. In order to run a node on the Insolar network, one must stake a certain amount of INS tokens. If there is a malicious (or technically unreliable) node in the network, it is penalized and the stake (partially or in whole) is burned.
Insolar’s approach to consensus mechanisms is set to provide near-linear scalability, with other features of the platform allowing transaction speeds which surpass those proposed by other blockchain platforms. Our upcoming private TestNet launch will demonstrate the transaction speeds capable.
- Check our Github and leave feedback on the code.
Follow Insolar on social media: