Business-focused blockchain platforms, get ready, here comes Insolar.
Dear Corda and Hyperledger Fabric, get ready for some action.
There was a time when everyone was cursing about Javascript and the frontend ecosystem as every month a brand new Javascript framework appeared to solve all your existing app-related problems. This time was 2016. Now in 2019 we are suffering an analogous saturation phenomenon, but this time in the blockchain ecosystem. Do you remember the last time that you opened your Medium or Twitter and didn’t see a new post about a brand-new amazing post/tweet announcing a new blockchain project? Me neither. However, sometimes you come across a blockchain project you get a bit more excited about, and that you feel is worth your time and a deep look to see what is capable of.
And with this in mind, here I am, sharing with you my early interactions with Insolar, “a 4th generation blockchain platform for business aimed to enable seamless interactions between companies”. And you may be wondering, what is exactly Insolar, and why it got you more excited than any other existing 3rd (6th or 11th, who cares) generation blockchain platforms such as EOS, NEO, etc.? Well the answer is pretty easy, that it is business focused, its scalability feels amazing in paper, and I really loved their architecture and consensus approach. I usually do not trust blockchain projects that claim that they are better because they achieve better scalability with near-infinity transaction rates (as it is usually not remotely true), but after reading Insolar’s white paper I said “wait, maybe with this approach high transaction rates are possible”. And this is why I thought their technology was worth a deep dive (apart from the fact that Insolar is written in Go, and I love Go, so they earned my techie heart from start).
I think the best way of having a quick grasp of a new blockchain platform is comparing its main features to the ones of the the most well-known in the ecosystem (you can find a detailed comparison in their official site:
Governance model: Let’s start with the basics, is Insolar a public or private network? Well, the answer is both. The interesting part about this project is that it allows you to work with both approaches simultaneously. As I’ve always said, the future of blockchain is in Hybrid Networks not in exclusively public or private ones.
Smart Contracts: Insolar supports smart contracts, and they may be written in Java, Javascript or Golang (again Go? You guys know how to win a techie), and you can write different type of smart contracts over the network, including confidential contracts (an interesting feature for business use cases, definitely).
Performance-wise, Insolar claims to have achieved 10.000 tps on a 20 nodes test network, being able to reach even millions the more nodes there are participating in the network (I really need to try this sh* to see if it is actually true). Insolar block time is of between 1 and 10 seconds, and it uses two groups of nodes, storage and processing nodes, with each of them using 3 different validation layers (check their white paper for further details about this).
Consensus, here comes one of the things I liked the most about Insolar. Insolar uses defined by domain politics for the consensus, i.e. it has a dynamic consensus. They follow a consensus approach similar to Ethereum’s sharding. A transaction does not have to be validated by every node in the network any more (and this is why I feel the transaction rates they claim are actually possible).
Finally, they state to be interoperable with Hyperledger Fabric and Corda (the main business focused blockchain platforms). For my next posts I will try this, as if this is possible it would mean a significant breakthrough towards and interoperable catalogue of business blockchain platform alternatives, so that each company could choose its preferred blockchain technology and still communicate with other companies blockchain networks (now you are free to choose the DB you like for your application, right? Why shouldn’t you be able to choose the blockchain network that best suits your business needs?).
And how does Insolar achieve all of this? Their platform is built on these key elements:
Domains are responsible for managing contracts lifecycle, data and security. Domains establish governance of contracts and nodes, thus acting as “super contracts,” which can contain other Lifelines and can apply varying policies to the Lifelines contained within. Policy can differ with regards to rules for changing the Domain itself, access from/to other Domains for Lifelines, validation rules for logic (e.g., consensus, number of voters), mutability of code (is it possible for the code to change and what is the procedure to do so?), mutability of Lifeline history (e.g., to implement GDPR or legal action via authorization requirements defined by the Domain), and applicability of custom cryptography schemes.
Lifelines are individual chains in which each data object and all its states are stored. Objects are treated as individual chains (if you understand Hyperledger Fabric private channels you understand Insolar’s lifelines).
Contracts provide distributed code and operability. In Insolar a contract is a service or a microservice that unilaterally declares a set of functions and guarantees compliance with the rules related to these functions (like in any other blockchain platform). In Insolar every system element, including domains, is a contract. This is really interesting, as the system features will be extendable through new system contracts, and the platform functionality is run in a distributed manner ensuring its correct operation. Contracts may work intra-domain or inter-domain.
In line with the principle that everything is a contract on the Insolar platform, contracts can be considered as Lifelines and are based on general-purpose programming languages such as Golang or Java. As the platform already reduces determinism by using messaging, Insolar applies relatively relaxed requirements regarding the determinism of contracts. As such, invocation of a method on the same state, with the same parameters, and on the same Pulse should produce exactly the same results and consume roughly the same amount of CPU resources, while contract execution methods that run longer than one full Pulse must be explicitly declared with an “execution duration” policy.
A contract that does not produce the same results under the given conditions will not pass validation, and all efforts expended will be at the cost of the party that deploys the contract (as opposed to the caller). Insolar records information on spent effort as Sidelines and can track assigned limits, but actual billing and payment execution must be handled by governance logic (i.e., by other contracts). Although virtual machines are used to isolate contracts incompatible with security or governance rules, new code for a contract can only be introduced to Insolar as source code, with compilation and static inspection performed by nodes in accordance with an applicable governance model.
Sidelines are utility lifelines used to store temporary or auxiliary data such as indexes, pending operations, or debug logs. Lifelines can have several Sidelines to store information.
Validation The Insolar platform works on the principle of transactions executed by one node, validated by many. Therefore, processing power is used more efficiently since only a single node across the network serves a Lifeline to facilitate the execution of calls to an object, while multiple nodes validate transactions. In this process, a specific node is elected to become an Executor and receives calls, collects the results of outgoing calls, and provides updates for validation by other nodes. Validator Nodes are elected once an Executor’s status expires, meaning Executor Nodes cannot predict which nodes will validate transactions, thereby avoiding a scenario where nodes can collude. Furthermore, the number of nodes elected as Validators can be determined in accordance with the business process at hand and, since Validators in shared enterprise networks will have liability and legal guarantees, this works as insurance for transactions.
This structure provides for a balance in accordance with client needs. Processing costs are traded off against uninsured risks (suitable for situations where a cheaper transaction is executed, but fewer Validators verify said transaction, meaning greater risk of loss), or processing speed is increased to the detriment of operational risk (which would mean that frequent transactions could be processed without awaiting validation, or validations may be batched together and processed following some delay, leading to the possibility of resource-consuming rollbacks).
Consensus: Rules among Validators may vary with purpose on the Insolar platform (and this is something I love). Examples of this variation include Majority Voting consensus for public networks in which changes introduced by transactions are confirmed by a majority within a single round of voting, and All or Escalate consensus for cross-enterprise, hybrid, and private networks, in which all assigned Validators must agree or another round of voting will begin with a different set of Validators. This process is repeated until a decision is reached or the set number of rounds is exceeded, which in turn may trigger (internal or external) conflict resolution to provide a satisfactory outcome. And this is huge, why should we all use the same consensus algorithm in a network when there may be one that suits better our specific application?
Pulses: The consistency of the view of network nodes and the distribution of Pulses are dealt with by the network layer of Insolar. A Pulse is a signal carrying Entropy (randomness) which acts as a trigger for the production of a new block. The consistency of the Entropy and the set of active nodes on the network are vital for the previously mentioned methodology of executed by one node, validated by many. Nodes are elected from the active node list, while Entropy and consistency ensure behavioral consensus across all nodes. Validator Nodes are elected only on a new Pulse to ensure that Executor Nodes cannot collude with Validators.
The generation of Entropy and new Pulses occurs using Pulsars running on the Pulsar Protocol, which can either be run on the same network or an entirely separate one. Cases of the former include private networks, which can implement a dedicated server; cross-enterprise and hybrid networks, which can use a shared network of Pulsars yet run individual installations of Insolar networks; and public networks, which can use trusted Pulsar nodes or run the Pulsar function on other nodes.
Globulas: A network/domain of up to 1,000 nodes is called a Globula. It can run as a truly decentralized network with consistency established by a BFT-based consensus mechanism, implemented as the Globula Network Protocol (GNP). 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 leader-based consensus.
There are four categories of Primary role nodes:
- Virtual Node: performs calculations.
- Light Material Node: performs short-term data storage and network traffic.
- Heavy Material Node: performs long-term data storage.
- Neutral Node: participates in the network for consensus (not in the distribution of work) and has at least one Utility role.
The Primary role correlates to the type of resource the node can provide to the Cloud, and is a part of the OmniScale feature of the Insolar platform.
Clouds: provide computing power and storage. Clouds also establish governance of contracts, but although a Domain applies rules to logic, a Cloud manages the infrastructure, including nodes, network operations, and layout, storage, cryptography. Therefore, a Cloud is a dual entity. On one side, it is a special Domain that is stored by the Cloud itself and carries static configuration and rules such as procedures for registering and deregistering nodes, postexecution fraud detection procedures, compensation and penalization procedures, and processing Capacity Marketplace rules. Moreover, Clouds run the network and components deployed during node setup, such as bootstrap configuration, Globula discovery and split-protection protocols, node activation and deactivation protocols with the list of currently active nodes and blacklisted nodes, and real-time execution of fraud detection protocols.
And I think this is more than enough as a first introduction to Insolar. I hope you enjoyed and got as excited as me about this. Currently Insolar only has a private testnet with 20 nodes you can check out through their explorer.
One of my main criticism to Insolar right now is their lack of a clear documentation in their official site and Github repos. I tried to run my own Insolar network to try their technology, but I faced several errors I didn’t know how to work around. Nonetheless, I get it is a really young project with a lot of work ahead. In my next posts I will try to contact Insolar’s developing team see if they can help me understand their technology see if it as cool as it seems and share with you my findings so you can use my posts as preliminary documentation. Stay tuned, in my next post we will launch our own Insolar network!
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
