Insolar Blockchain Platform: Network Layer
Insolar Network and how it solves Blockchain limitations
Insolar is a blockchain platform that enables distributed business networks. It allows users to build enterprise applications on top of its blockchain and the platform has a multilayered architecture. One of the most important layers in this architecture is the network layer. Before taking a look at the Network layer, it is important to understand how a transaction is created and validated in the platform. Also, it is to be noted that Insolar Blockchain allows for interoperability between public and private networks.
Insolar follows an “executed by one validated by many” convention. That means the execution of the transaction will be done by a single node and this transaction will be validated by many nodes. An executor node is selected, which can receive calls, collects the results of outgoing calls and provide the updates that need to be validated by other nodes. It is to be noted that the Validator nodes are elected only once the Executor’s status expires.
This structure has many advantages. By providing such a method the processing costs are traded off against many uninsured risks. The transactions can be insured by adding more nodes to validate it. Frequent small transactions can also be configured to execute without waiting for validation. This design will surely increase the throughput and allowing large scale transactions. So for such a structure to exist we need a very consistent network. This consistency is the main goal of the network layer of Insolar.
Let’s look at the various components of the network layer.
Entropy, Pulse, and Pulsars
In order for producing a new block, some randomness is required. This randomness is known as Entropy. The entropy is carried on a signal called Pulse. The Pulses are generated by Pulsar Nodes or Pulsars. The Pulses and Pulsars together form a separate logical layer that is responsible for network synchronization along with providing randomness. For the “executed by one validated by many” system to work, the consistency of the entropy and the set of active nodes on the network are vital. The validator node election happens on the next Pulse after execution, so that collusion can be avoided. In order for multiple nodes to work together (process new requests and operations) in a single cloud, all of the must be on the same Pulse.
Generation of the Pulse
The generation of the Pulses in Insolar is done based on a protocol known as the Pulsar Protocol. The rules for selecting the Pulsar vary for different clouds. The selections are made by dedicated servers which perform no other operations. In the case of the public network, selections will be performed by a random subset of 10 to 50 nodes which have high uptime. Along with this, other configurations are also possible depending upon the network types.
The default Pulse generation is based on BFT (Byzantine Fault Tolerance) consensus among Pulsars. So what is BFT? Simply speaking, all the involved nodes have to agree upon every message that is transmitted between them. If a group of nodes is corrupt then the network as a whole should not be affected by it.
In such a consensus, each member can contribute to the entropy but are unable to predict it through vote withdrawals.
So what makes the Insolar’s BFT consensus different?
In traditional BFT consensus, all the nodes in a network need to validate or agree on all the transaction in the network. This is effective but can create issues by slowing down the network and hindering the scalability. As noted earlier, this issue is solved in Insolar by Pulsars and active node list. Instead of making all nodes to agree on all transactions, Insolar nodes first agree on the active node list and entropy. This results in a consensus that does not trade off scalability.
Globulas and Globula Network Protocol
Globulas is another important concept in Insolar Blockchain. Globulas are networks of up to 1000 nodes. This can run as a truly decentralized network with consistency established by a BFT-based consensus mechanism, implemented as the Globula Network Protocol.
The previously mentioned node election for execution and validation are not based on voting, instead, they are part of the feature based on the active node list. The importance of the Globulas is that by separating the whole network into multiple Globulas, the active nodes don’t need to be maintained in the entire network, instead, they can be maintained in each Globulas. These Globulas then come to an agreement about the active nodes.
The design of GNP is based on pure datagram protocol. To ensure the efficient use of network datagrams, the GNP implements a set of primary and secondary features related to the inner workings of Globulas. GNP distributes the new Pulse across a Globula’s active nodes. Also, GNP collects Node State Proofs (NSP) of the active node to lock down Node State. It detects fraudulent node behavior and suspends and exclude nodes that are unable to provide their NSP to a threshold number of nodes. NSP is the most critical element to build a shared state across all nodes of the Globula.
Another important concept related to Globulas is the Globula State Hash. It is a Merkle tree root built of NSPs and other information such as node indexes. In case you are wondering what a Merkle tree is: it is a tree structure widely used in Blockchain with every leaf node labeled with the hash of a data block, and every non-leaf node is labeled with the cryptographic hash of the labels of its child nodes. A Merkle root is the root of this tree. Globula State Hash make it possible to verify past transactions without reading the entire ledger. Also, the integrity and completeness of the platform are maintained by the Global State Hash (GSH). Even though there is no difference in using a simple hash of node list other than the Merkle root for GSH, Merkle roots are preferred for larger networks.
InterGlobula Network Protocol
Insolar also supports larger node networks of up to 100 Globulas (a total of 100,000 nodes), which behave transparently across such networks in accordance with whichever contract logic is in place. Such networks rely on the InterGlobula Network Protocol, which implements a leader-based consensus.
The higher number of nodes are received in exchange for additional phases of Network Consensus and additional synchronization requests among Globulas, thereby increasing the minimum block (Pulse) time to 10 seconds.
InterGlobula make uses leader-based consensus among Globulas to build a higher level Merkle tree over GSH. This enables to set up large scale networks, also while using Merkle proofs for consistency checks.
By looking at the architecture of Insolar’s network, I feel that Insolar is providing a network with high transaction speed without trading off any security. The innovative modifications over the traditional consensus mechanisms allow the network to be scalable which is key for any business ready blockchain. All these features will allow Insolar to reach its goal of providing a simple low cost scalable and secure blockchain platform for business enterprises.
