Spotting Blockchain Innovation — Building Blockchains w/ Insolar
Spotting Blockchain Innovation — Building Blockchains w/ Insolar
Recently, while looking for my blockchain innovation series, I came across Maxim Safronov, who is the project manager at Insolar. After a brief introduction to the project, it seemed interesting to me to write down what they are doing.
The main goal of the project is to become the most business-oriented DLT solution in the market. However, under the hood, we can find a lot of hidden innovation.
The main item we will discuss is the combination of node role allocation and sharding which allows the Insolar blockchain to reach a performance of over 19,500 transactions per second (proof at Insolar explorer). Added to that, the usage of these different roles in the network allows Insolar to process business documents on-chain which is a huge benefit for businesses and giving them legal rights on-chain.
However, scaling up a blockchain often has consequences. Decentralized systems become more centralized when scaling up, the most well-known example is miner centralization which plagues many projects.
According to the DCS Theorem, only two properties can be simultaneously achieved out of Decentralization, Consensus, and Scale. The DCS theorem is actually a triangle that defines the relationships between the three properties. Although the triangle states that only two properties are possible, the theorem can be “cheated” by properly structuring the problem. Let’s find out!
- Pseudo-random node selection. triggered by signals called “Pulse”. Pulse also carries a source of randomness/entropy and is generated every 5–15 seconds by Pulsar nodes.
- GDPR compliant within permission or private network (search some info)
Block Storage and Node Role Allocation
The first interesting aspect is the way Insolar organizes its network. The network consists of Storage and Processing nodes whereas the Storage nodes can be divided into “Heavy” and “Light” material.
Heavy nodes are in charge of storing the blocks consisting of the ledger, however, none of the nodes stores the full ledger. This decision has been made in regards to security but also storage capacity.
The Light material nodes keep only the recent history of the ledger and are used for internal network traffic.
Processing nodes are responsible for computational tasks and verifying transactions. Normally, with other chains like Ethereum, every node is aware of the smart contracts in the network and they can all process its transactions.
Insolar decided to opt for asynchronous processing to increase performance even further. Each smart contract is delegated to a single node whereas other randomly selected nodes are in charge of verifying the results from the processing node (“Validators”).
By separating responsibilities the way Insolar does, they are able to process business contracts on-chain which is an important criterion for mass adoption by businesses.
Also, this separation allows for increased data security as only certain nodes hold a set of data for a limited amount of time. As such, transactions are executed by one random node and validated by a few other random ones.
The innovative thing here is that each action a node carries out is documented (verification, which data they received, etc.), meaning that full transparency exists over who has received your potentially sensitive data. (More info in ‘Data Security’).
Embedded contracts
Enterprise business logic requires the ability to create complicated smart contracts with heavy ledgers inside them. In the Ethereum contract model, all data is stored inside the contracts. Thus, popular contract ledgers continually grow, which makes working with them expensive for users (source: section 3 Smart Contracts Insolar).
Alternatively, Insolar decided to use key-value storage for their smart contracts as it’s the most simple and lightweight form of data storage. Whenever storage is needed, the contract calls the needed data and not the full state like the case is for Ethereum smart contracts who store all data inside the contract.
Using Insolar’s approach, neither user or contract creator need to pay excessive fees for working with large smart contracts. Again, this predictable cost of smart contract usage is a great benefit for businesses.
Contracts itself can be developed using Golang (Java and other languages will be added soon) as the language is very efficient while processing logic.
Shredded BFT
At last, let’s take a look at the alternative Byzantine Fault Tolerant (BFT) implementation Insolar has embedded. The current problem with BFT is that whenever the number of nodes increases in the network, reaching BFT consensus becomes more complicated, mostly because reaching finality takes much longer and the risk of more inactive/idle nodes.
Therefore, 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.
As this approach still limits the network to grow to only up to ~1000 nodes to maintain its efficiency, Insolar came up with an interesting approach of creating multiple domains with each up to 1000 nodes. More information about this concept of “Globula” and “Globulas” can be found in their blog post about scalability.
Other Innovative Approaches
This is just an excerpt of what Insolar is doing differently. Other interesting reads include:
Spotting Blockchain Innovation — Building Blockchains w/ Insolar was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.