Let’s continue our part two of a brief introduction to some of Insolar’s main architectural features. In part 1, I explained how Insolar assigns roles to nodes and uses hot and cold storage for efficiency when processing and storing data. We also looked at how the platform introduces special smart contracts which allow for networks with different levels of permissioned access to communicate with one another and non-Insolar (even non-DLT) networks. In part two, we will delve a little deeper into what is a typical transaction within Insolar, how does it travel between nodes of Insolar Blockchain Platform, and what setup we consider practical for the usage of the platform.

Processing and Persistence: Expanded View

Broadly, existing blockchains and DLT offer two major approaches to processing data: the transaction is either validated by “miners” and recorded by all nodes, or there is some sort of a centralized processing involving only a subset of nodes. In the first approach, the data which is being validated is available to all nodes, and the decentralization here comes at the cost of low network throughput and high computation expenses. The second approach offers higher throughput rates but involves the network transferring potentially large objects and raises questions regarding centralization. Insolar extends the latter approach a little bit further: namely, there is no centralized authority per se (the validators are selected randomly and unpredictably), network exchange is limited to a handful of nodes, and frequently accessed data is cached.

To highlight this approach, let’s take a closer look at a typical transaction. What we have in mind is an arbitrarily complex object changing its state. A simple value transfer is a trivial example — more interesting would be a payment at some particular moment in the lifecycle of a commodity trade finance transaction (or trade, if you will). It would end up being a transfer of value between several counterparties within the trade — not necessarily only two of them. But, even before that, we have to check several conditions: that the commodity has arrived at a certain place, that it conforms to quality metrics, that the cargo is cleared for further movement by the authorities, and so on and so on.

Evidently, such a transaction would be pretty heavy in terms of both processing and storage space, and the costs of its replication to the whole network will be prohibitively high.

Processing cycle: a simplified case

Now let’s look schematically at how the simplest transfer of value from A to B looks in Insolar, without any complex business logic involved. Here’s the simplified sequence:

Executor requests the data from Light (and Heavy) Material node(s); Executor checks that A has enough units of value, and creates a transfer — subtracting from A and adding to B; The transfer is registered with the Light and Heavy Material nodes; When the current Pulse (network cycle) ends, the Light Material node creates blockchains from all records of action that it has been processing during the Pulse. (Those records of action are transfers or any other relevant results produced by smart contracts which are being executed); The Light Material node forms units of storage — called Jet Drops in Insolar — and sends them to the Heavy Material node; On the next Pulse, Validators — zero in a trivial case (not really different from what would happen in some traditional system) or several (according to some predefined policy) — perform essentially the same actions that the Executor was doing. But they also check that the Executor had enough rights to perform the transfer: that everything was legitimate from a security standpoint;

An important difference here is that, during a really complex transaction involving calls to various smart contracts, the Light Material node would use the already validated results of those calls — there would be no re-processing, just checking rights/validity. This saves a lot of processing power; Validators receive the data from the Light Material node. Not reading from the cold storage, but still a data transfer; The fact of successful validation is registered by Light and Heavy Material nodes (same as points 4 and 5); The transaction is finalized. All that involving several nodes — not every node on the network — and several read/write operations; Later, when somebody wants to check if the transfer was valid, they retrieve the information from the Heavy Material node, check the record and check if the nodes involved originally had the appropriate rights to conduct operations.

There wouldn’t necessarily be a full recalculation (although that’s technically possible), but — broadly speaking — all rights and credentials will be checked, as well as the sequence of events.

Node roles: Executors and Validators, Light and Heavy Material

Let’s diverge for a moment and briefly revisit the model of assigning node roles on Insolar (also see part 1).

It should be noted that this model is decoupled from any particular counterparty. Node role assignment is a part of the platform infrastructure, and roles change from Pulse to Pulse in such a way so the node can’t predict the specifics of its workload — this is done to exclude malicious node behavior. For example, imagine that somebody somehow is able to gain full access to a particular set of nodes. This would be disastrous for the network, and so we need to account for and remedy any such situation before it even arises. Insolar does this, not by endowing trust to any person; instead shifting that task to the infrastructure.

Heavy Material nodes are interconnected in a separate (from blockchain per se) network, thus strengthening reliability and availability. As such, Insolar solves the technical distributed storage/processing task with a predictable/configurable SLA.

There is no one size fits all

What we’ve gone through above is pretty low level in terms of the details of how processing takes place in Insolar, and for a very simple case. A complex transaction would involve lots of cycles like this one, and moreover — different objects (smart contracts) would call each other. In this, more complex case, the logical centralization and caching mechanisms offered by the platform would confine network exchanges to a minimum, while still keeping the process decentralized and scalable.

Now, in the case of Ethereum, for example, at least all full nodes are involved in computing a block. At present, that involves a Proof-of-Work consensus mechanism, and there has to be communication between nodes, which is expensive even when very little data is exchanged.

But there is no such thing as a “universal transaction”. Depending on the business case at hand, there is actually a valid trade-off: localized processing with potentially heavy data flying over the wire versus distributed processing of data stored locally with heavy block construction and exchange to reach consensus. There is no one size fits all. No doubt there are cases where Ethereum (or Bitcoin, for that matter) will be more efficient in terms of the data transfer. But all things considered, we say that Insolar favors complex transactions, while the other platforms are more suited for simple stuff, i.e. A gives 5 units to B. The question is: how many cases are like that in the enterprise world?

Public/Private and Permissioned/Permissionless

Given that Insolar positions itself as a platform best suited to serve complex business transactions, let’s take a look at other aspects of a typical setup within which any medium-to-large enterprise operates. Blockchain or DLT-wise, there are several things to consider:

1. Joining the network

In the context of point-to-point payments, virtually any human being should have straightforward access, so zero permissioning makes sense. On the contrary, when dealing with financial markets, supply chains or any non-trivial network of participants in a complex business transaction, a counterparty has to undergo some KYC procedure, which is largely defined by a certain set of regulations. For enterprise cases it is more of the latter than the former.

2. Access rights to relevant information after the participant has joined

Not all counterparties to, for example, a derivative trade or trade finance will be happy if significant conditions (which are usually kept secret in the context of a trade) are accessible to anybody in the open. Direct counterparties — ok, regulation body — fine, but (for example) competitors? That’s why there is a need for permissioned access to certain objects.

3. Validation given that all actors underwent KYC

Of course, business validations and legally binding documents are ensured by cryptography. But we also need to make sure that all conditions have been met and the sequence of events has been justified — much like any enterprise needs operations departments to check, validate and settle everything.

4. Centralized vs decentralized processing

There is an immense body of research regarding why is it hard for any actor (however big and reliable) to convince its counterparties that they (the actor) should hold a centralized database and define the rules of processing. There are also technical challenges for this actor when maintaining such a database, while, additionally, they should be responsible for all business processes and their automation. That’s why blockchain, or more strictly DLT, is the right option: it effectively shifts away those responsibilities from one single actor to a decentralized setup, while ensuring the consistency and behavior of both the infrastructure and all actors involved (however trusted or malicious).

5. On-chain vs off-chain storage

If we want to track a complex transaction in its entirety, then, with regards to storage, nothing is really out of scope. The information comes from the outside world, but all of the data pertaining to a transaction are relevant and, ideally, should be stored together. This includes, if need be, the incoming documents which trigger transactions. A common approach (e.g. in Quorum) is to store the heavy documents off-chain, referencing them with a hash. Insolar can store any documents on-chain — that of course makes storage more expensive, but provides additional guarantees for contexts where that might be important.

The bottom line

In simple cases, conventional blockchains such as that of Ethereum may be faster, while in complex, business-oriented cases — they are not suitable.

Insolar is building a platform that would ultimately facilitate the tracking of the complete lifecycle of an arbitrary complex transaction.

First and foremost, Insolar appeals to relevant business cases and demonstrates how Insolar Blockchain Platform can help.

Wrapping up

Insolar in particular aims to be politically and architecturally decentralized, but there is a logical centralization in some sense. We are developing a platform which facilitates enterprise-oriented solutions, not just another set of low-level APIs. This platform would give enterprises an opportunity to operate on a business level, using business logic.