Many blockchain networks are restricted in their scalability, meaning that, as the network size increases, the speed at which the network can update, process transactions and synchronize the network global state lessens. Maintaining consistency across large networks takes time as each participating node should store copies of the data. However, Insolar has found a solution to improve network synchronization efficiency, without compromising security: Pulses.
Pulses are a sync-tool which serve to provide consistency throughout the network and are emitted by so-called “Pulsars” which are dedicated nodes. They serve as a logical function and are known as a utility consensus as their function is independent of the direct needs of platform users. As such, Pulses and the Pulsars that emit them represent a security layer that is separate from the blockchain network, yet responsible for ensuring that the network is synchronized. A Pulse indicates the beginning of the next time period in which transactions can be executed and validated, and provides for a source of randomness via a portion of data that it carries. The data holds information about the time and so-called entropy (randomness) of the Pulse.
Pulses are generated in accordance with the Pulsar Protocol, which enables the generation of entropy in such a random way that individual nodes are unable to predict which nodes will execute transactions and which will validate their calculations. The protocol, however, does not include conditions regarding Pulsar node network membership or the duration of Pulses. Instead, these parameters are agreed dynamically or preconfigured by the network participants.
While other configurations are also possible, the default setting for Pulse generation is based on Byzantine Fault Tolerance consensus among Pulsars, in which each network member contributes to entropy. The Pulses represent time intervals in which the network updates and every Pulse is identified by unique, increasing integers called Pulse Numbers.
A Pulse Number represents an approximate number of seconds since the network start and increases in the number are proportional to the number of seconds passed; this proportion must be less than or equal to 1. Pulse Numbers must be known to all nodes and these identifiers are unique, always-increasing whole numbers, while the increase Pulse Numbers should be proportional to the number of seconds passed in order to correlate with real time.
Configurable for flexibility
You may note that, throughout descriptions of the platform, that the features and structure of Insolar are tunable, and Pulsars are part of this flexibility. The configurable nature of the platform with regards to Pulsars generally caters to two different variables:
- The level of trust network that the participants have for each other
- The amount of nodes in the network and which will participate as Pulsars
In high-trust networks, as few as one business network node can be nominated to carry out network synchronization and entropy (of node choice), since malicious behavior is not expected. As such, private Insolar networks don’t need to deploy multiple Pulsars that are external to the network, instead just using a single node that is internal to the network. This sole Pulsar node can be seamlessly replaced with several others or external Pulsar nodes when the network is expanded to integrate other participants: i.e. lowering the level of trust and facilitating the need for Pulsars that are more independent.
The more public the network, the more participants, the less trust and, therefore, greater the need to run Pulsars on a separate protocol. For enterprise installations, a Pulsar can be just a single isolated or a shared server. This is also the case for private networks, which can implement a dedicated server; cross-enterprise and hybrid networks, which can use a shared network of Pulsars yet run individual installations of Insolar networks; and public networks, which can use trusted Pulsar nodes or run the Pulsar function on other nodes. Insolar, however, recommends deploying Pulsars to a separate network for all networks for security reasons, but this is not necessary.
In interconnected business networks on the Insolar Blockchain Platform, each network is known as a Cloud. In these Clouds, the rules for selecting Pulsar nodes can be defined and managed manually by the network participants and, therefore, can vary significantly. However, in the Insolar public MainNet, the Pulsar Protocol will be maintained by a random set of ten to fifty nodes which demonstrate reliability and stability.
While different configurations are possible for different network types, interoperability of nodes within a single Cloud is dependent on Pulses. This means that, for a single network on the Insolar Blockchain Platform, all the participating nodes must be on a single Pulse to process new requests or operations.
How it works
For each Pulse generation, there is a default algorithm in which each Pulsar nominates a Pulse candidate at random. This process takes place by the Pulsar sending a Pulse candidate packet (PulseData), which includes a hash code for the unencrypted Pulse and encrypted entropy. This candidate packet is distributed across all Pulsars.
After distribution of PulseData proposals, submissions with data mismatches are excluded, as are Pulsars for which fraudulent, erroneous or malicious activity has been proven by mismatches in proposals. The mutually matching PulseData proposal is then sent out as a hash along with the Pulsar’s encrypted entropy. The hash sum is divided by the number of approved Pulsars, with the remainder number selected as the Winning Pulsar. For example, if there are 5 Pulsars which submit matching PulseData proposals and the remainder from the calculation is 3, then Pulsar number 2 will be selected as the winner. This is since the first pulsar is Pulsar 0 and the fifth is Pulsar 4.
The winning Pulsar’s then provides the private key to its entropy value to the other Pulsars. The other Pulsars validate the PulseData from the winning Pulsar once more, if this is successful, the entropy is decrypted and the Winning Pulsar’s Pulse is distributed by the other Pulsars. The entropy ensures the randomness of the selection which improves security.
Data consistency across the network and Pulses distribution is handled by the network layer of Insolar. A Pulse carries randomness for the allocation of node roles and is a signal which acts as a trigger for the production of a new block.
The consistent view on the current entropy and the set of active nodes on the network are vital for Insolar’s OmniScaling approach to distribute work, and ensure that each transaction is executed by one node, yet validated by many. Nodes are designated roles in regards of whether to execute a calculation, validate it or just participate in network consensus. The roles are allocated to participants on the active node list, while entropy and consistency ensure behavioral consensus across all nodes. Moreover, nodes chosen to validate calculations are only elected on a new Pulse to ensure that the executors cannot collude with validators.
The Pulsar Protocol enables the generation of entropy in such a way that individual nodes are unable to predictably manipulate the entropy through vote withdrawals. This is the core function of Pulses: to enable a secure, unpredictable methodology to allocate functions across the network, without slowing operations. A key feature of Pulsars is that they can be run within or external to the network, in accordance with the level of trust amongst participants and the needs of the business network.
- Check our Github and leave feedback on the code.
Follow Insolar on social media: