Path to decentralization

Insolar plans to grow and support a decentralized infrastructure with a plethora of participants.

Insolar’s path to decentralization is straightforward and can be illustrated as follows:

_images/path-to-decentralization.svg

Figure 1: Path to decentralization

An eagle view of the MainNet maturity roadmap that leads to decentralization is in the following table:

MainNet 1

MainNet 2

MainNet 3

Execution nodes

Permissioned,
provided by Insolar Foundation

Permissioned,
provided by trusted parties

Permissionless,
provided by anybody

Observer nodes

Permissioned,
deployed and used
by trusted parties

Permissionless,
deployed and used
by anybody

Permissionless,
deployed and used
by anybody

Governance

Managed by Insolar Foundation

Basic governance

Advanced on-chain
governance

Staking

Delegated Proof-of-Stake
(DPoS)

Delegated Proof-of-Stake
(DPoS)

Delegated Proof-of-Stake
(DPoS)

What infrastructure powers Insolar MainNet?

Let’s consider Insolar MainNet as an ever-growing galaxy that consists of multiple nodes:

_images/mainnet-nodes.svg

Figure 2: MainNet 1—a little galaxy of nodes

Important

All nodes (except Observers) on the network exchange data, and all are subject to the BFT-like consensus.

In figure 2, Insolar runs all the nodes except the light-colored Observer ones. Insolar nodes have several static roles:

compute Compute—virtual nodes (compute) with powerful CPUs for smart contract execution.

throughput Throughput—light material nodes (LMN) with lots of RAM for block building and caching.

storage Storage—heavy material nodes (HMN) with fast SSDs for quick access to long-term storage.

Note

observer Observer nodes do not participate in consensus, they replicate the finalized MainNet data and rebuild the data in a relational form. In particular, this allows to check data consistency and immutability over time. Read more on Observer nodes below.

For more information on node roles, see the Multi-role nodes section.

In addition to the static roles, all nodes have dynamic ones: executor and validator. During each pulse, nodes are assigned dynamic roles for object processing. Dynamic role allocation is the basis of the platform’s security and scalability. For more information, see the Dynamic roles section.

So, to decentralize an Insolar network, third parties only need to run more executor and validator (dynamic) nodes of all the static roles. For more information, see the Execution and validation section.

Observer nodes

Moreover, Observer nodes (dark and light yellow in figure 1) complement the network. These nodes implement important functions:

  • Replicate all the data stored by heavy nodes. This data is by definition finalized.

  • Transform a mesh of custom smart contracts and their interactions into business objects and transactions between them. You can easily query these objects and transactions to build fast and efficient analytics applications with excellent UX.

  • Provide a fast report service that offloads read requests from the blockchain.

  • Allow every participant to check data consistency and immutability over time.

Currently, Observer nodes can only be run by trusted third parties: top-tier universities, enterprises, and exchanges.

Run your own Observer node

If you are an exchange developer, deploy a node that replicates MainNet data

The next step towards decentralization

As Insolar moves along its path to decentralization:

  • Observer nodes become permissionless.

  • Executor and validator nodes of all roles can be run by trusted third parties.

  • “Galaxy” arms increase in number and grow.

_images/mainnet2-nodes.svg

Figure 3: MainNet 2—an expanded galaxy of nodes

In figure 3 above:

  • Dark-colored nodes are run by Insolar.

  • Light-colored nodes are run by selected third-parties: top-tier universities, enterprises, and exchanges.

  • Yellow Observer nodes are permissionless.

  • Dotted “+” nodes designate increasing numbers of nodes of different roles: Observers, Compute, Throughput, Storage.

Becoming fully decentralized

Further along the path to decentralization, all the nodes of the main network become permissionless. However, this does not hurt the desire of enterprises for a way to restrict access to sensitive data.

Enterprises can deploy private networks with complex permissioning schemes. In turn, private networks seamlessly integrate in a hybrid manner with the Insolar’s public network. A single on-chain governance model manages the resulting decentralized network.

Initially, Insolar Association sets up a governance framework with rules for managing the network nodes and applications.

Note

The Insolar Association will be made up of a group of 100 diverse organizations from around the world. The association members each will be running up to 10 executor nodes on the Insolar Network.

The MainNet users can later modify the rules in accordance with a collective decision.

The general governance framework defines procedures and policies for:

  • Joining new nodes to the network. Anybody can submit their nodes for joining.

  • Creating new applications. Any developer can submit their application to the MainNet as a set of new smart contracts that adhere to predefined governance rules.

  • Uploading and updating custom contracts.

As a result, the “galactic” growth culminates in a merger with other “galaxies”, public and private, to give birth to an Insolar “Universe”.

_images/mainnet3-nodes.svg

Figure 4: MainNet 3—merger of public and private galaxies

In figure 4 above, “clusters” at the end of “galactic” arms are growing private networks run by various enterprises.

Bridging to other DLTs

Furthermore, as discrete blockchain networks grow and expand, they will increasingly need to interact with one another. Insolar’s global network bridges to other blockchain networks and becomes a “constellation”.

_images/constellation.svg

Figure 5: Constellation of networks

Bridges facilitate seamless, trusted, low-friction interactions between enterprises.