- Insolar: The basics
- Relationships between users and service providers
- Configuring domains
- Application of different cryptography standards
- Interactions between companies and networks
- Support of complex network topology
- Synchronizing clouds and nodes
- Searching and calling services
Why did we create Insolar?
The idea of the Insolar blockchain platform emerged from the following observations:
- Increasing complexity and intensive diversification of business interactions;
- The emerging role of decentralization in decision-making;
- The inability to understand and embrace the complexity of business processes by the majority of DLT platforms developers, which discredits and undermines the potential of decentralized systems and leads to impractical solutions.
These observations led us to set the following goals for Insolar:
- Streamline the design, application and reuse of complex cross-enterprise processes;
- Automate cross-enterprise processes, enabling them to identify design flaws at an early stage and conduct thorough data monitoring in case of potential legal disputes;
- Create a platform that can be used in conjunction with existing solutions and systems;
- Create a platform that is compatible with existing corporate solutions and systems with similar properties, such as transnationality in data processing within different systems, horizontal scalability, processing XML documents, etc.;
- Introduce clear and unified generation and management procedures for different standards, whether global, state-level, business, including those between companies, etc.;
- Reduce susceptibility to vendor locks as a result of the usage of licensed technologies and centralized or centrally-managed systems and data exchange systems.
To reach these goals, Insolar is being designed as a unified platform where generic and tailored business solutions will be developed by Insolar and 3rd-party developers. Designing such solutions demands defining major data and process types, system policies for storage and computing power providers.
Compatibility with existing solutions
Compatibility with existing corporate solutions is vital for the development and success of Insolar.
Currently, there are two advanced platforms in terms of industrial application: Hyperledger Fabric and R3 Corda.
Compatibility with Hyperledger Fabric will be available via both API integration and native support of Fabric chaincode in Insolar. This way, companies already using Hyperledger Fabric solutions will find switching to Insolar easy.
Compatibility and/or integration with R3 Corda will be considered in the future. Compatibility with other blockchain platforms like Ethereum will be introduced via blockchain oracles.
Insolar: The basics
The Insolar platform is built on these key elements:
- Domains (manage contracts' lifecycle, data and security);
- Contracts (provide operability);
- Clouds (provide computing power and storage).
Domains play a key role in managing and adjusting Insolar capabilities to different applications. Domains have a wide range of features based on the declaration of policies that are imposed on every domain participant. Domains may be applied in the following ways:
- Definition of generic processes, standards, work rules, data formats, procedures for introducing changes into the standards and procedures for implementing changes (e.g. ITU standards or legal requirements for processing personal data);
- Initiating and managing objects such as market reference data, code dictionaries, company registers etc.;
- Provision and management of the storage and transfer policies of protected data (e.g. personal and biometric data, the history of clients' financial transactions);
- Establishing access policies to/from objects outside the domain, establishing the cryptography standards, establishing the terms for calculating computing power consumption and storage volume etc.
Insolar registers domains, enabling interaction between them, and does not intervene in the management of the domains. Management procedures are defined by each domain individually. For example, each domain can set up a vote to change its rules, policies and/or participants.
Additionally, a domain can permit changes by a court order if identification of court orders is implied in the domain's work logic. Rules and policies for managing domains determine the choice of the means and participants in the processing and storing of domain transactions and data. This implies the following implementation options:
- Application of Insolar generic blockchain solutions for storing and processing data, with imposing liability insurance on the providers of computation and storage power. Liability insurance can be represented in the form of legal obligations or cryptocurrencies.
- Application of traditional solutions (e.g. DBMS-based storage).
Insolar ensures interactions and cooperation between differently implemented domains and provides guaranteed message delivery and transactional integrity. At the same time, service users do not need to have in-depth knowledge of other domains to interact with them.
On Insolar, the term "contract" does not mean a bilateral, legally binding service agreement. The Insolar contract is a service or a microservice that unilaterally declares a set of functions and guarantees compliance with the rules related to these functions. A compact, stand-alone application (smart contract), a contract aggregator or an oracle providing access to an external system are contracts.
Insolar is designed according to the Everything-is-a-Contract principle. Every system element, including domains, is a contract. Basic platform features are represented by special system contracts, with the help of which a developer interacts with the core of the platform. The behavior in the system can be changed or extended through the creation of contracts.
Interaction of contracts
The majority of Insolar contracts interact only with each other on a domain or between domains, thus providing basic capabilities. However, people and systems from the outside must somehow interact with Insolar, and interactive contracts serve this purpose. They send, receive and process external calls. Interactive contracts act as mediators between outside systems and contracts inside the Insolar platform. Also, interactive contracts transform authentication/authorization data and rules for interacting between outside systems and Insolar domain formats.
Execution and safety
Insolar supports various contract designs, including GoLang, Java/JVM and C#/CLR. Different designs of the same logic will have the same functions. There can be a significant difference in the usability of this logic's implementation and in the accuracy of calculating computing power consumption.
A contract developer may focus solely on the contract logic and the calls of other contracts while such details as the location and implementation specifics of other contracts are managed transparently by the platform.
One of the important features of Insolar contracts is that they allow reusage of existing practices, tool libraries and environments. What's more, contracts can store and transfer large data objects with only a linear impact on performance due to storage capacity constraints on servicing modes and limited network throughput.
When implementing contracts in different languages within the recommended pattern, a generic Insolar storage solution guarantees the security and reliability of the platform. This is thanks to the following features:
- Domain-level managed rules that define which data can be submitted or received by domain participants;
- In addition to the logical rules, selected domains can also be isolated on network level with relevant network safety and data inspection instruments employed;
- Tight supervision of visibility and interactions among contracts and nodes, to prevent hijacking or brute-forcing identifiers, etc;
- Tracking of time and efforts spent on individual operations, with the option of a forced automatic stop;
- The guarantee of a contract's full execution ensuring duplicate calls will not emerge in case of hardware, system or network failure at any execution phase.
- Sequencing a chain of changes for each individual contract (object), with every change bearing the checksum of the previous state, thus enabling monitoring of ex-post changes in an individual contract;
- Based on the level of responsibility, appointing those in charge of processing node operations, such as operations with high value, can be executed only on the hardware, whose owners provided relevant financial and legal guarantees;
- Choosing the relationship level between productivity and risk, depending on transaction value;
- Splitting storage and execution functions between nodes:
- Execution nodes can only access operations within a limited time frame (about 10 seconds) and cannot read or write objects' histories;
- Storage nodes can access objects' histories but can introduce changes received from execution nodes only. Data on individual objects can be encrypted by execution nodes.
- Domain-level requirements for the number of validators (these nodes verify the
work of other nodes) allow the following:
- Balance control in favor of average operation cost against the risk of errors or deliberate distortions from individual nodes, e.g. forced fulfillment of less valuable operations;
- Balance control by changing the quantity of validator nodes in favor of operation costs against the risk of deliberate distortions;
- Manage the conditions of operation fulfillment and perform additional checks of attached operations' fulfillment when the latter is performed by third-party contracts;
- Solving disagreements between validator nodes, using strategies based on
the following models:
- Probability model, e.g. the majority is always right even if 2+2=5;
- Confluence model, meaning reappointing validators for extra rounds of validations until 100% matching results are reached;
- Higher level logic model, e.g. conventional voting among members of management committee or filing a court complaint;
- Combinations of the above.
In addition to these features, Insolar provides trust management during the execution of contracts:
Delegated functionality system
A unique delegate system allows new domains to complement the functions of existing domains and their contracts, without involving third-party developers of the existing solutions.
In the event that a pre-existing contract lacks the required service features, but already owns or can get the necessary data, relevant service features may be injected into the existing contract under certain security policies. Then the injected functionality will assist with (i) collection of data on behalf of the existing contract, (ii) preparation and storage of the required information, and (iii) implementation of the new functionality and behavior of the original contract.
Domains and clouds are elements for applying and structuring business logic, working on the nodes that are arranged into clouds. The Insolar cloud is a set of nodes represented by computing power and storage providers.
Providers work according to appointed computation and storage roles defined by the cloud rules. Different resources can be provided by attaching different roles to the servers, e.g. the provision of computing power, storage or network throughput.
The key task of a cloud is to ensure the storage and execution of contracts in the domains bound to the cloud. The cloud also ensures the delivery, submission and management of requests from/to contracts and domains on other domains.
A standard cloud implementation provided by the Insolar platform is based on blockchain technology. Alternatively, a cloud may be implemented differently: on a single node, DBMS, etc.
On the Insolar platform, storage and computing power providers will bear responsibility to companies using the platform for executing operations, and follow strict conditions for accessing them. This will be possible thanks to domains defining the clouds or server groups that can be used by the domain participants. Also, domains define the procedures that allow a provider to add more resources.
In terms of storage, the Insolar architecture implies a division of responsibilities between nodes based on roles (computing, storage, validation) and time (different operations are processed by different nodes at different times). The use of different providers makes it impossible to restore the complete state of the system or the history of individual objects, without obvious, traceable and time-consuming actions by perpetrators.
Consistency control mechanisms for individual requests, objects and large data objects, sequenced into event chains, prevent unauthorized and post factum changes to the Insolar platform.
Each fulfilled operation is checked by a set of validators that must come to a unanimous result. In case there is no full consensus, for enterprise use, more validators will do another round of validation, as the mismatch can be a hardware failure, for instance. If repeated rounds of validation do not fully match each other, the operation will be suspended or cancelled with the following outcomes:
- An extended processing of the operation will be performed by a domain's application logic;
- The operation will be referred to Insolar support service, if a domain allows that. The platform stores records related to application logic (states of accounts, agreements, etc.) and technical situations (e.g. disputes). The stored data serves to resolve complex situations and identify violations. After the data is processed separately, it is removed from the storage upon expiry.
Relationships between users and service providers
The Insolar platform offers several solutions for shaping and structuring dynamic market relations between users and computing power providers:
- Batch contracts for providing computing power at a fixed price;
- Spot deals for extra provision, ensured in accordance with the contract, in case of a power shortage;
- Lending computing power and storage;
- Support of low-load and open-source services with surplus or unclaimed capacities.
Verification of computing power capabilities stops fake power providers from joining the Insolar platform. The providers are verified based on the volume of completed and paid for work, unlike PoW with its insufficient costs.
Relationships between users and service providers
Insolar platform offers several solutions for shaping and structuring dynamic market relations between users and computing power providers:
- Batch contracts for providing computing power at a fixed price;
- Spot deals for extra provision, ensured in accordance with the contract, in case of power shortage;
- Lending of computing power and storage;
- Support of low-load and open-source services with surplus or unclaimed capacities.
Verification of computing power capabilities stops fake power providers from joining the Insolar platform. Unlike the insufficient costs generated by PoW, providers are verified based on the volume of work which is dompleted and paid for.
With the basic storage option, a ready-made solution can be used for different network types. Domains can be configured into the following networks types:
- Isolated (private or permissioned) network. A network of trusted participants with their own servers serving each participant individually. And by allocating additional servers, a participant can scale up related functions, but not a network.
- Controlled (permissioned) network. A compact network where participants do not own the hardware. The computing power is provided by relevant companies that are bound to financial and legal guarantees of liability and confidentiality.
- Open (public) network. A compact network where the participants can be computing power providers if they make a deposit in cryptocurrency. Unlike isolated and controlled networks that use conventional legal mechanisms, conflicts in public networks are solved using different consensus algorithms.
Developers should take the following steps to create a network:
- Configure an individual cloud;
- Set up rules for adding nodes and participants (these rules are defined by domain parameter values and policies).
- Creation of homogenous and hybrid networks;
- Integration with other blockchain networks (e.g. Ethereum, Hyperledger Fabric, Corda and others).
Regardless of the network types, various domains can interact with each other, allowing for:
The Insolar platform's high scalability is based on the following principles:
- Distribution of the computing power load between the objects. Redistribution is done when more execution nodes are added. Providers can be arranged based on the quality of service, e.g. some objects can be serviced by premium servers for a higher price, resulting in better throughput and low latency.
- Distribution of storage is based on traffic throughput (i) first and on storage volume (ii) second. If storage load increases, storage nodes are segmented. Stored data is divided between nodes according to demands for data liability and validation. Segmentation based on the quality of storage services can also be executed, though this can lead to manipulations by storage nodes.
- Running storage and execution on one node is not recommended due to the increased risk of unauthorized actions.
Storage volume can be optimized by merging existing blocks, excluding objects that were not bound to usage policies as defined by a domain. The legally binding limitation period provided for commercial contracts is an example of such a usage policy. Merging blocks does not make the platform less secure even if changes were made retrospectively or fraudulently. The history of each object is represented by a separate sequence that cannot be altered.
Data can be forcefully removed to comply with data security regulations such as the GDPR. If data was deleted, a record of the reason for its removal is stored in the system.
Application of different cryptography standards
Insolar is the only enterprise-grade platform providing the simultaneous application of different national cryptography standards. Besides using certified storage and management methods for keys through Windows and Linux mechanisms, this implies the creation and verification of the following elements:
- Hash sum of each operation;
- Hash sum of Pulse data block;
- Node signatures and network participants;
- Session keys for network interaction between nodes.
Group signatures in group operations can be replaced by the aggregation of individual signatures. In this case, the implementation and storage of individual signatures will generate extra costs.
Interactions between companies and networks
A global network for ultimate simplification of cross-business interactions will be built on the Insolar platform. Additionally, a group of companies will be able to create their own network tailored to specific tasks, with the option to connect with the global network.
Communicating with other companies on Insolar is as easy as using an e-mail or a messenger app. Having joined the network for the first time, a company can immediately start communicating with other businesses on the platform, allowing companies to build both generic and individual interactions quickly and efficiently.
Any network, like Ethereum, Corda or SWIFT, or a stand-alone installation, e.g. a Hyperledger solution, can be represented in the form of a specific domain. Access to and from this domain is serviced the same way as with other domains.
Support of complex network topology
Insolar provides support for complex network topology in network interaction between nodes:
- Support configurable network topology to handle complex corporate networks;
- Support of NAT traversal protocol;
- Ability to operate in multilevel corporate networks;
- Compatibility with traffic inspection systems and network-level security measures.
Synchronizing clouds and nodes
Synchronizing clouds and nodes according to time and entropy is important for the work of networks on the Insolar platform. Synchronization is based on the following principles:
- A time frame is called a Pulse;
- Time spent on the network is defined by the ID number of a current Pulse;
- The pulse number always increases but intervals between Pulses' numbers can differ;
- A Pulse spreads across the network when nodes interact with each other. Nodes can interact with each other only if their current Pulse numbers are the same.
- Extra data spreads across the network, e.g. a list of nodes or entropy. Entropy is a random or a pseudo-random number that cannot be predicted based on the network's current state.
How Pulsars work will be covered in detail in a separate document.
For domains on the Insolar global network, Pulses are generated, and d specifically elected set of Pulsars that provide high availability and guarantee that consistent synchronization data is distributed across the network.
Isolated networks can use their own sources of Pulses. To enable interaction between different networks on the Insolar platform, generation of Pulses must be synchronized. When previously disconnected networks are re-connected, the sequential number of the first Pulse generated for the interconnected networks will be larger than numbers of the Pulses of each network being connected.
Pulses in isolated networks will be produced slightly slower. This way, the networks will always be able to connect with the Insolar global network by catching up with the public sequence, since the tempo of creating a Pulse on the Insolar global network cannot be changed without the risk of exploitation.
Searching and calling services
The search and call of services on the Insolar platform are efficient, user-friendly and secure. The mechanics work as follows:
- The parent domain defines rules of access to contracts and subdomains;
- A domain or a subdomain receives a global address and becomes accessible from contracts in other domains and subdomains. The procedure is the same as the DNS, with the exception that open access can be granted only to first and second level domains. For example, insolar.io or client.insolar.io can be accessible, while lower level domains will be unavailable if not configured in advance.
Currently, the Insolar platform has technical identifiers only. Human-readable domain names may be added later.