Distributed ledger technology (DLT) networks are usually split into camps: public and private, permissionless and permissioned. The degree of network openness often depends on the utility of the DLT, with more closed networks said to be more suitable for business in order to keep their data secure. But what happens when enterprise needs to hold some parts of its data secure, yet share other parts with other counterparties or the public at large? Insolar Blockchain Platform is able to segregate data and link different networks with different utility to bring about the much needed network effect blockchain has been waiting for.
Different Shades of DLT Networks
DLT networks are usually split into four different types: public or private and permissioned or permissionless. At Insolar, we split these networks into three distinct types: private, public and enterprise. On Insolar Blockchain Platform, private blockchains operate on private Clouds or within private Domains that have special security settings. This allows certain nodes to execute transactions, in addition to storing the ledger. This type of blockchain keeps the ledger private and doesn’t allow just anyone to join. Public blockchains on Insolar are ones which operate on a public Cloud with public Domain settings. These networks also allow certain nodes to execute transactions and store the ledger too, but the ledger is public and anyone can join.
Insolar Blockchain Platform is made up of Clouds: networks that are formed from an isolated set of nodes. Insolar introduces an underlying protocol which defines the node role (executor, validator) for each object during the current computation and validation period, known as a Pulse. Meanwhile, inside Clouds, there are Domains which are special smart contracts running complex logic on Cloud nodes.
A Domain is essentially a smart contract which defines policies such as business scope, validation, data location, etc. All participants of a Domain obey these policies by default. An example of Domain-based rules within a network could be a large permissioned network with 100 users in which there are three members which want to have hidden data sharing between them only (e.g. a particular instance of business transaction). So they set up permissioned access to their smart contract within the Domain. Domains make it possible to set different levels of privacy within each network. Domains can communicate with one another based on sharing their Merkle proofs, and so Clouds are able to interoperate. These proofs are only exposed and validated where calls happen and these are verified via Merkle Trees.
Network members do not set up an additional network or Cloud instead of a Domain because, if they did, they cannot make direct calls back to the larger network where they want to share some data with the other participants. This means that the Domain makes granular permissioned access possible to a certain set of data for a certain set of participants from a larger network.
Set data can be distributed amongst set nodes using a smart contract which is able to specify which logical location it wants its data to be stored on. Actual mapping takes place via the combination of smart contract settings with Domain policies. The mapping is done by the network layer, which underpins material (storage) nodes. The network layer then resolves all logical settings into physical addresses and performs all the actual heavy lifting of moving data over the wires. This is what allows smart contracts (that is, each object) to specify the location it wants to be stored in. Put another way, a contract in the Domain can specify the location for where its data shall be stored in said Domain, but not on a particular node within such Domain.
Blockchain Platform for Enterprise
Enterprise blockchains, however, operate on a permissioned Cloud with both public and private Domain settings. It is these enterprise blockchains that can vary in the level of permission offered, depending on how secret or secure the data needs to be stored. In enterprise blockchain networks, more secure and less secure data can be mixed within a single Cloud via the use of Domains. This is possible since, in Insolar Clouds, nodes do not replicate all the same data network-wide, and so not all nodes store the same data. This means that nodes can be allocated set data which needs to be restricted.
How it Works
Communication between different Clouds takes place by exposing their existence to one another via special contracts; without doing so, there is no way they can know about each other. Those contracts provide discovery and integration mechanisms, and without them the Clouds are hidden from one another. It is through these contracts that participants of large consortia networks will be able to communicate among themselves via API calls.
For pure public networks, there is an addressing feature to help users find other members of the network. The public network is for consumers and so is a resource like the internet: just as the internet has the IP addressing system using a sequence of numbers to navigate, the Insolar MainNet will have specific hashes to find data. This means that, provided that users have access to the addressing, they can find each other.
With that being said, let’s take a look at the different types of network in action.
Examples of Networks with Varying Privacy
1) A fully private network based on Insolar is a completely isolated setup where data is accessible only to a number of participants via their internal system. This type of network would generally be for teams working with highly sensitive information, such as trade secrets.
2) A lighter shade of a private network would be one in which permissioned access is provided to users in a secure environment, yet at portion of the data is publicly visible. A good example of this kind of network would be a corporate voting system with anonymized results.
3) Even lighter would be a network in which all the details of a supply chain for an avocado are placed on a DLT and the purchaser of said fruit can see all of the dates and locations (events) where the fruit changed hands. However, the data shown to the purchaser is limited in that it hides the personal data of the people who partake in the supply chain. Although, this data can be with permissioned access to relevant parties of the chain to provide for further accountability.
4) Another shade could be considered a university database where all students are provided with permissioned write access, meanwhile, the DLT is open access to the public. This could be a system where the students upload their work to the public for transparency.
5) Full public access can be considered an internet-like database of online documents with no need to sign up to participate in the network because, by design, there’s no requirement to provide any sign up credentials. Anyone is free to access and contribute (write data) to this database, just as they are free to read data from it.
Hybridization of blockchains via interoperability will facilitate real-world business use cases of DLT. Without this ability to interact and share data, blockchains will become private silos in themselves. As demonstrated, this can be overcome by following a structure of network interoperability in which each network is a blockchain and Domain-based policies can operate for certain data between specific users in each network.
- Check our Github and leave feedback on the code.
Follow Insolar on social media: