Nodes are an integral part of any network, functioning as a point of signal reception and redistribution. As in all networks, nodes are essential in blockchain, distributed in terms of location and control and tasked with performing a variety of functions. Here the idea that each node is controlled by different parties is important in blockchain and the distributed ledger technology behind it.
Since theoretically a node can be any device connected to a network via the internet and controlled by the device’s owner, the owner can interfere with operations conducting on their node. However, in blockchain, there is no need to blindly trust node operators to act altruistically for the benefit of the network. Instead, consensus algorithms are used for the network to agree on which data will be written to the distributed storage.
Although theoretically a node can be any device with an internet connection, in practice, blockchain nodes require high computing power and memory and can therefore come at some expense, not to mention the energy consumption and space that they can take up.
So what if enterprise could be part of a network in which they wouldn’t need to deploy their own node to be part of the network? At Insolar, we think this is key to the development and implementation of blockchain and so with our platform, businesses do not need to set up their own node to join and work within the blockchain network. This, however, does not mean that business entrust their sensitive data to those which house the nodes on which the data is kept.
How it works
Unlike on other blockchain platforms, not all nodes are tasked with verifying or holding all the data, with only a limited set of nodes for a limited amount of time granted access to an exact version of the data needed to update the network. These nodes are known as executors and validators, with the workload shared between them. As such, transactions are executed by one random node and validated by a few other random ones, but not all nodes have to fall into one of the two categories, with other nodes handing someone else’s data, being idle and participating in consensus.
As such, the validators approve amendments to the storage, with network consensus defining which nodes will execute particular actions for a particular set of data at a particular time, and which nodes will validate the work of the executors, with the resulting changes updating the network state. Which nodes are tasked with each action is documented, meaning data cannot be received by a node without this fact being recorded to the ledger.
Since nodes which handle transactions (executors and validators) are known, they take on a certain liability for their actions. This enables the introduction of service level agreements (SLA) for nodes which are identifiable in the event of data leaks or malicious actions taking place. Meanwhile, the Pulsar Protocol provides for Entropy (randomness), making allocation of roles to nodes hard to predict. This makes collusion in the network difficult and limited by duration of block time, whilst any nodes found to be colluding to the detriment of the network can be discovered by checking in the ledger which nodes were responsible for a particular action on particular data.
Ability to audit
The ledger, therefore, indicates which actions were carried out, when this took place and by whom, whilst it also indicates why they had the right to access or modify data. Meanwhile, the data itself can be encrypted and stored separately and therefore not shown within the ledger.
Here we can draw a clear comparison with a notary. A notary is licensed by the state to perform legal verification of documents to indicate that they are valid. The state places responsibility on the notary who validates a document and the notary takes on liability for validating such a document. If the notary asserts that a document is valid and it turns out to be falsified, then they have to answer for why they validated it and, if found to be at fault, have their status as notary stripped from them.
In the Insolar blockchain network, liability falls principally on the executor node which computes a transaction and then passes it on for validation. Subsequently, secondarily liability resides with the validator node who see the unencrypted data. Should the unencrypted data be leaked or should a malicious update of the network take place the executor that handled the transaction, in addition to the validator that verified it, can be easily discovered and held to account.
Since validators only have right to approve/deny transactions, in a situation where a malicious action takes place legal recourse will be taken against the executor with the view that there was some kind of collusion with validators to validate or deny a transaction: i.e. liability for the validator node(s).
Breakdown of the process
Let’s take a look at how this works in practice:
- A transaction takes place.
2. A virtual node is assigned as the executor for the action on a particular Pulse and this node sees the unencrypted data (other virtual nodes do not see the unencrypted data).
3. On the next Pulse other virtual nodes are selected at random to be assigned as validators. They see the unencrypted data and validate it, whilst the remaining nodes do not see the data, just which nodes are working on a particular computation.
4. The data is validated and encrypted, and then passed to light material nodes for storage.
5. The ledger records who did what with a hash for the transaction.
If something is wrong or a malicious action has taken place:
6. Liability falls on the nodes that processed the transaction — the executors and validators.
7. Legal action can then be taken against provider(s) of these nodes.
This system makes data for transactions hidden, with only nodes who took part in actions indicated within the ledger, not the data which they handled. Transactions can thus be audited via the ledger in this way but balances (like on the bitcoin ledger) aren’t shown.
As such, sensitive data is kept secure whether it is on nodes that you deploy or whether on others’ nodes.
Virtual Nodes are calculation nodes and do the processing and are able to introduce changes and new data into storage.
Light Material Nodes are block-building nodes and serve as storage for Virtual Nodes, forming new blocks and acting as short-term (hours or days) storage.
- Check our Github and leave feedback on the code.
Follow Insolar on social media: