Insolar’s Pulsar Protocol
A backbone of Insolar’s Blockchain 4.0
In this article we would like to touch upon Insolar’s nodes interaction layer, so-called Pulsar Protocol, described in details in recently published tech paper. The main purpose of this layer is to facilitate the network
synchronization and to provide a source of randomness within a ledger. It utilities Byzantine Fault Tolerance (BFT) consensus model, similar to Hyperledger. With more detailed description of the general purpose consensus available here, let us to briefly review how BFT consensus of Pulsars’ network is functioning and estimate robustness and scalability of the protocol.
Timeline is split into fixed time intervals, called Pulses (or more conventionally Views). At each Pulse the node goes through several phases:
Phase 1: Node prepares, signs and broadcasts PulseData payload to all nodes.
Phase 2: Node receives PulseData payloads with signatures from all other nodes within the cluster, called Globula. Node validates signatures and removes malicious nodes from the send/receive list. The valid Pulsars ID and signatures are broadcasted to all nodes.
Phase 3: Node reaches consensus on PulseData with 2/3 majority, then the Winning Pulsar is selected based on hash of proposed set of PulseDatas. Winning Pulsar provides encryption key to decrypt its PulseData payload.
Phase 4: Node validates Winning Pulsar encryption key, broadcasts another signature to nodes to confirm the validation. Afterwards it receives similar signatures and after successful validation of 2/3 majority the PulseData payload is finalized and persisted.
The tech paper does not discuss possible attack vectors or bottlenecks, however there are a few:
34% attack: This is known issue of any BFT based distributed ledger. A way to mitigate the attack is to setup rules for selecting Pulsars and apply the permission restriction on obtaining Pulsar ID.
Silent Bob attack: At Phase 3 the Winning Pulsar is expected to provide signing key. Given some malicious omnipotence one could try to jam the consensus. This can be mitigated by banning Winning Pulsar for such misbehavior from the nodes send/receive list and restarting Phase 3.
Now lets check all bottlenecks: at Phase 1 nodes propagate PulseData payload along with signatures to every other node. At Phase 2 nodes need to validate two signatures from every other node, then broadcast Pulsar ID to nodes. At Phase 4 they need again to broadcast Winning Pulsar’s validation signatures. Each time node communicates to all other nodes in Globula cluster, which can be up to 1000 nodes. Since the tech paper does not mention any specifics on what will be the encryption scheme I’ll assume RSA-2048.
Let’s do some fast estimations:
Signature validation overhead: RSA-2048 signature validation with optimized C++ library, ran on Intel Core 2 1.83 GHz processor(source) takes about 0.16 msec/sig. Since the node would need to do about 2000 + 2/3*1000 validations per Pulse, it is 0.42 sec per Pulse, which is a negligibly small number to cause any network delay or nodes desynchronization.
Bandwidth requirements: 64B(PulseData) + 128B(NodeStateProof) + 256B(Pulsar signature S1)+ 256B(Pulsar signature S2) + 64B(Pulsar ID) + 256B(Winning Pulsar’s validation signature S3) + assume 1024B(payload bytes) = 2kB per node per Pulse, which tells that any node with a reasonable bandwidth can participate in Pulsars’ consensus.
In conclusion, one can clearly observe that in the current setup Pulsar Protocol does not impede the scaling of the upper layers of Insolar Business Network Platform.
