Insolar Architecture Basics (1/2)

I recently had a conversation about Insolar with a senior software engineer and blockchain architect for one of the world’s largest software providers. The engineer raised some good points about decentralization and blockchain platforms of previous generations. Our conversation allowed me to explain some basic architectural aspects of Insolar Blockchain Platform and clarify how we achieve scalability, transparency and permissioning within one system. Let’s take a look at some of the main topics that engineers often ask me about Insolar architecture.

Processing and Persistence

The basic large-scale unit of our network is a Globula, which may consist of up to 1,000 nodes belonging to different participants. Presently, we are developing the MainNet and the EnterpriseNet, and the nodes there will be cloud based, provided by Insolar or its partners. In the future, the nodes could be placed either on premises or in a cloud — e.g. Insolar MainNet/EnterpriseNet or AWS or the like.

Consensus

A Globula lives in cycles — or, in our terms, Pulses. Pulses synchronize the network and are a set time in which an object must be processed for execution or validation. Their duration may be adjusted, being around 10 seconds at the moment of writing. At each Pulse, the BFT-based consensus algorithm makes sure that the network state is consistent: new nodes are plugged into the shared view on the network, while faulty/suspicious nodes are removed, etc. This ensures that all nodes behave consistently, according to the rules of the consensus. After each consensus, all ‘good’ nodes in the Globula are assigned to perform different roles for different objects (chains). As a result of the completed consensus, all nodes have a similar view on the network configuration, hence such assignments are exact and non-disputable.

Node roles

There are Virtual Executors that process a transaction, Virtual Validators that validate, and Light Material Executors and Light Material Validators that persist the result of processing and validate the storage operation. The consensus protocol ensures that no Executor can validate its own output, and no node can reliably predict its role during the next Pulse.

OmniScaling

There can be only one Executor for each particular transaction, but many Validators. If the transaction takes longer than one Pulse, the Executor node receives permission to continue execution (from the would-be Executor on the next Pulse). The amount of Validators can be tuned according to the perceived value at risk of the transaction. Again, that’s the very core of OmniScaling: allowing a potentially-linear increase in capacity upon adding more nodes. Insolar plans to further extend this feature by pooling Executors.

Hot & cold storage

The persistence layer is made of Light and Heavy Material nodes. Light nodes are responsible for building blocks and connecting them into chains, as well as forming units of physical storage (called Jet Drops in Insolar). Light Material nodes act effectively as a cache over a predefined (configurable) amount of Pulses, while Heavy Material nodes provide the cold, long-term storage. This allows to avoid tapping into the cold storage for frequently accessed objects. Only Material nodes can access the stored data — Virtual nodes have no direct access to it.

Access frequency

One would argue that to process an object, it must be eventually brought up from cold storage, which is expensive. But on Insolar Blockchain Platform it is done in a very limited number of cases, and only from the Heavy to Light Material nodes. Following this, the object is cached. There’s still the need to pass the data between nodes, but again: only for the nodes which are directly involved in the processing of said data object (i.e. not all of the network nodes in case of a single Globula). Conversely, in common-style blockchain platforms like Ethereum, the full network processes and exchanges data; on Insolar this takes place on just several (a configurable number) nodes.

Public/Private and Permissioned/Permissionless

Domains as a governance tool

On top of what was described above, there are logical business-oriented foundations via the introduction of Domains as units of governance. Technically, a Domain is a special smart contract that defines a framework (policies and settings), within which other smart contracts are executed. The framework could include a plethora of things: a business domain (e.g. trade finance); access rules (permissioned or permissionless); a location (e.g. geographical) in which smart contracts can be executed and their results stored; consensus rules for validation (e.g. number of validation nodes and/or algorithms versus value at risk); and so on.

Insolar networks

We believe that any practical setup for enterprise will be permissioned, as enterprise needs to keep valuable data safeguarded. However, Insolar is currently developing its MainNet that will require a joining procedure, but once a participant has joined, all data will be available to all participants. To ensure stability of the network and safety of users, the initial setup of the MainNet will utilize nodes from Insolar and Insolar partners. At later stages, any nodes can join openly through a staking procedure. Afterwards, we will be launching the EnterpriseNet, where the Domains will be implemented for different business cases and with appropriate data access policies.

Interoperability

Late in the Insolar development roadmap is the integration between different Insolar networks (Clouds), as well as connectivity to other blockchains and distributed ledgers (DLTs). Everything is a contract within Insolar Blockchain Platform, which means that there are technically similar communications inside as well as outside — via remote calls and API invocations.

The platform code is available on Github, and we plan on providing the OEM package, so anyone could extend the functionality themselves in a completely private (or, on the contrary, public) setup.

Tidbits about Insolar Blockchain Platform

• Nothing is ‘mined’ on Insolar.
• Nodes have to be authorized in any setup (be it public or private, regardless of permissioning), there are several mechanisms and protocols to ensure they act in the interest of the network.
• Insolar employs scalability mechanisms based on node role separation (executor/validators) and sharding at both hot and cold persistence.
• The number of communications and data transfers is highly optimized, owing to the above-mentioned role model, and is orders of magnitude less than in common-style blockchain platforms like Ethereum.
• Working with Insolar does not mean migrating all data and all processing onto Insolar Blockchain Platform — the platform can be a part of a heterogeneous setup involving existing systems.
• Insolar can facilitate different cases of permissioned or permissionless, as well as public or private, or combination thereof.

The above covers the essential architectural points and significant features of Insolar Blockchain Platform. However, it is by no means exhaustive. Moreover, I have decided to make this into a two-part series to give further insight into Insolar’s architecture. In the next article, we will dig deeper into the processing and persistence, and private/public and permissioned/permissionless aspects of the platform. In addition I will clarify some aspects about the architecture in comparison to earlier generations of DLT.