Hello folks,
Abstract:
It is proposed changes in Delegated Proof of State (DPoS) consensus protocol with the objective of increasing throughput of transactions per second after the establishment of rules, including security rules, to execute active delegate nodes in the cloud. The cloud offers several benefits to execute delegates node as security, computational resources on demand, metrics tools, and subnets. Also, DPoS offers reduced energy waste when compared with Proof of Work (PoW).
Current solution on Lisk:
Actually, in Lisk DPoS to propose a new block an active delegate node on its time slot should retrieve a list of connected peers, verify how much of them are in the same broadhash as itself, if it finds at least 51 peers in the same broadhash from itself then it will continue with forging steps as follows:
-
Collect transactions from its transaction pool
-
Verify each transaction
-
Fill the proposed block
-
Sign the block
-
Propagate the block to 25 random peers in the network.
Disadvantages of the current solution:
-
The peers involved in the broadhash consensus can be any type of peer and it can be even configured on a slow computer
-
Delay in the network can slow down the propagation of a proposed block and cause a fork if the next active delegate node on its time slot didn’t receive the block from previous time slot and it finds 51 other peers in the same broadhash of itself
-
Random peers can be anywhere, can be any type of peer, so as much the network grows the trends is have a slower block propagation. Similar concepts can be found on other blockchains like Bitcoin, Ethereum that have more than 10 thousands nodes
The peers in the network can be represented in a full graph where each vertex is a peer and the peers can be represented with the notation O(N²).
Contribution and proposed solution:
Broadhash consensus should be achieved between active delegate nodes. On each time slot of an active delegate that proposes a new block in the blockchain it will have access to a list of connected actives delegates, verify if at least a majority of them are in the same broadhash of itself then if it finds it will proceed with forging steps:
-
Collect transactions from its transaction pool
-
Validate each transaction
-
Fill the proposed block
-
Sign the proposed block
-
Multicast the proposed block to other active delegates for validation
The figure below represents the solution where the validation of a proposed block occurs on a subgraph of peers, only active delegates. This solution can be represented as O(1) as the proposed block should be validated between other active delegate nodes before been propagated to the network. Follows:
Also, all active delegate node should run on the cloud. Follow are security rules to run active delegate nodes:
-
Run on the cloud (recommended)
-
Use of elastic static IP
-
White list of peers (all active delegates and other peers)
-
Allow inbound data on Lisk port and from a white list of peers (Minimize Distributed Deny of Service (DDoS))
-
Establishment of better computational resource on demand (To be defined)
-
Redundancy between virtual machines (VM) in different datacenters
-
Subnets
-
After previous items were accomplished then the creation and use of Software as a Service is possible. A SaaS with already configured VM will provide easy for use for delegate accounts
Benefits of solution
-
Increase of throughput of transactions
-
Possibility to reduce latency
-
Minimizing distributed deny of service (DDoS) attack
-
Even if the quantity of peers grows in the network the throughput and latency are safe
-
Validation of a block will be performed by authenticated delegate nodes
-
Solution is self-sustainable as active delegate nodes are already incentivized for forging a block
-
Better computational resources for validators of a proposed block
Hypothesis
Is expected a higher transaction throughput and even lower latency when only active delegate nodes in the cloud validate a proposed block before propagating it to another type of peers.
The expectation is an improvement in transaction throughput higher than 500 tx/s, higher than 1000 tx/s, even higher than 3000 tx/s. Other private blockchains can achieve such transaction throughput.
My name is Davi and I am a master degree student in Computer Sciences focus on Distributed Systems.