In the history of blockchain, we’ve had three major phases:
Blockchain 1.0: single chains, each designed for a single application (e.g., Bitcoin, Dash)
Blockchain 2.0: single chains designed to run multiple applications (e.g., Ethereum)
Blockchain 3.0: an evolution of 2.0 with improved scalability via sharding and sidechains, but that still applies single business logic (rules and standards) to all records and transactions
Insolar is blockchain 4.0 because it reinvents two key concepts in the industry: public/private chains and distributed applications (Dapps). Rather than being a single blockchain that applies single logic, Insolar creates distributed business networks, which support multiple applications according to all possible scenarios and standards (e.g., networks, consensus algorithms, and encryption models).
The underlying principle of this logic is the architecture of multiple domains.
Everything is in a domain
In our previous post, we mentioned that Insolar is designed according to the principle of “everything is a smart contract.” But there’s another principle at work too: “everything is in a domain.” Unlike other blockchain protocols, Insolar doesn’t deploy smart contracts across the Insolar network, it contains them to certain segments, which we call “domains.”
What’s a domain?
A domain is the set of rules and policies applied to the smart contracts within that domain. You can think of them as interoperable sub-networks or sidechains within the Insolar federation of clouds. At the same time, smart contracts from different domains can be executed on the same nodes, unless special domain-specific rules are applied.
Types of domains
The Insolar Public net contains one main domain, the Root domain, which is used to register all other domains. Every high-level domain is created as a new segment on the network and registered within the Root domain.
After the mainnet launch, there will be several preset domains that define the key elements of the Insolar Public net. These will include the Wallet domain, Node domain, and Member domain, which will contain wallet transactions, information on nodes, and network member management, respectively.
Any network user can register a new domain and manage it, setting own rules and policies to execute smart contracts and store data.
When setting a domain, users can define rules, restrictions, and policies, including:
- Who can call smart contracts
- Whether smart contract code can be changed (and by whom)
- How smart contracts are validated
- Data restrictions, which are especially pertinent for regulations such as GDPR
In the case of validation, domain owners can decide how many validators are required to approve the executed smart contract, what type of consensus should work between the validators, and what the requirements are for the validators themselves (e.g., whether their identities should be verified or they should be located in a certain jurisdiction).
Another example of domain policy is with data encryption. Since different countries have different encryption standards, the domain owner is free to set cryptography standards that are compliant with their local regulators.
Domain policy is applied before smart contracts are executed and domain policy determines the data privacy settings for the nodes that run the smart contracts.
Some business processes are better suited to run on public spaces, while others require strict privacy. That’s why Insolar gives companies the freedom to run businesses processes on either a public domain or on their own private domain, with customized settings that align with their unique needs.
Setting a private domain
A private domain is a domain where both smart contract execution and data storage is handled by company-owned nodes that aren’t visible to outside nodes, nor are they reachable by direct address.
There’s a key difference between Insolar’s solution and what private blockchain protocols typically offer: We don’t isolate private domains from other networks (and other private domains). A private domain owner is able to assign one (or more) nodes in a domain as a proxy node, so all the external communication is handled through it. Proxy nodes work like a gateway between a private domain and the publicnet.
The types of policies that can be set within domains (especially private domains) can be very specific. For example, the ability to erase private data is very important for GDPR compliance. Data erasure can be executed on the Insolar network, ensuring that no third party keeps any private data after their legitimate access to it has expired. If the data has to be erased in old blocks and all the nodes agree on the erasure, instead of the old records, a hash of the erased records appears with the message that the data has been erased according to GDPR or other regulatory requirements.
Another example: Companies may require blockchain solutions to establish interconnected processes with counterparties or within their own structure (among departments, employees), without sharing sensitive data. Moreover, within a single company there could be completely different requirements relating to different processes. For instance, handling thousands of typical records within a shared database is different from securing a contract worth a million dollars, and companies are willing to set different levels of data security for both cases.
Domains will accelerate business blockchain adoption
Blockchain technology is powerful, but it’s not one-size-fits-all. No two companies share the same demands, requirements, and security standards, so they require a degree of flexibility that’s not offered by blockchain 1.0, 2.0, or 3.0 platforms. With its unique domain capabilities, Insolar’s blockchain 4.0 architecture gives companies the unprecedented flexibility they demand, which will in turn dramatically hasten enterprise blockchain adoption.