A new proposal for consensus mechanism. Cloud for DPoS active delegates and establisment of rules, including security rules for them

[davinet]

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.

[davinet]

Parameters, including, the number of transactions per block can be adjusted

[janhack]

Hi Davi,

thanks for the detailed analysis and sharing your proposal here!

It is correct that a low broadhash consensus can lead to missed block slots, which also was a problem at certain times in the past. Note that we have 2 LIPs that are currently being implemented that address this problem:

• LIP 0004 “Introduce robust peer selection and banning mechanism”
  This LIP defines a new implementation of the P2P layer of Lisk that further improves the block propagation. The LIP proposes a gossip-based flooding mechanism for broadcasting blocks to the network and to abolish the relay limit that is currently used. This way blocks automatically reach a node via the path that has the lowest overall latency (overall time that is necessary on that path to send block over the network and validate the block at every intermediate node).
• LIP 0014 “Introduce BFT consensus protocol”
  This LIP proposes to abolish the broadhash consensus so it is not necessary any more to be connected to a large number of peers that have the same block at the tip of the chain.

I think the solution you propose may be a good idea for a sidechain that mainly aims for huge throughput
(at the cost of centralization and demanding hardware requiremts), but not for the Lisk mainchain, which
aims to be decentralized and only require moderate hardware. More specifically, I would have the following concerns:

• We want to keep the peer-to-peer network of Lisk decentralized without a hierarchy of nodes that separates delegates and non-delegates (who is a delegate can also change often over time).
• Current benchmarks show that it would be possible increase the number of transactions per block to around 250. LIP 0002 “Change to byte based block size limit” proposes a byte based block size limit that allows for around 120 balance transactions per block and ensures that the blockchain increases by at most 50 GB/year. Currently, I don’t see the need for a higher number of transactions per block, in particular, as the transaction load on the Lisk mainchain is currently rather low. Note that 1000 tx/s for 1 year with 125 byte balance transfer transactions are 4 TB of data in one year. This would lead to centralization as it would not be possible to run Lisk Core on normal consumer hardware.
• What you propose can mostly not be enforced by the protocol (e.g., VM redundancy, elastic IP, better computational resource on demand), but would require to introduce some form of centralized bureaucracy checking if these requirements are satisfied. I believe that anybody should be able to run a delegate node with the hardware setup they choose as the possibility of missing blocks and the accountability to voters already creates enough incentive to choose sufficiently strong hardware.

Cheers,
Jan

[davinet]

Hi Jan,

Thanks for your reply, I really appreciate.

It was not very clear for me how many peers were included on Devnet for the benchmark presented in your answer. Also, there is any page that shows the steps to prepare the Devnet environment? Furthermore, It would be really good to see benchmarks in scientific articles when possible.

Comment: I think that blockchain is about, mainly, allowing pseudo-users to perform transactions between them. Basically, the main chain and Dapps have the purpose to include transactions in the ledger. After that, I raise a question: What is the main idea about having a full node in a blockchain? The Figure below shows the average number of nodes in Bitcoin and Ethereum:

Why there are so many nodes in Bitcoin and Ethereum?

• Incentive mechanism to mine a block?
• Smart contracts in Ethereum?
• Redundancy, fault tolerance, storage?
• Study and research?

One of the best features that I liked in DPoS consensus is delegate node and in special active delegate node.

Please, understand that I raised these questions because of my proposed solution to improve performance in the network and it is not a contradictory opinion about Lisk development direction.

My proposal considers a change in DPoS consensus protocol based on version 1.6 of Lisk in that time. The change is especially related to active delegate nodes interaction and after it, the block is propagated to others peers. Also, the establishment of delegate hardware specification would be mandatory to achieve higher performance. Even if the number of peers grows the latency of the generation of a block can be preserved. It’s preferable that active delegate node runs in a low latency network, that’s why I suggested cloud for them. The LIP 0004 seems to be interesting regarding the propagation of a block to peers.

• Regarding SaaS and white list, it’s possible to be done, cloud environments offer an interface to handle security groups

• Better computational resources, I understand the concern of storage and is great the idea of limiting the growth of the ledger to 50GB / year. However, it will continue to grow and a solution for it will be a necessity.

I understand that Lisk is designed for sidechains, and, if possible, I would like to understand in your perspective how the solution that I proposed is a good idea for sidechain that aims huge throughput. Finally, when I thought about the solution proposed I’ve realized that blockchain is about transactions and I just wanted to improve throughput using DPoS.

Regarding your comment about: “We want to keep the peer-to-peer network of Lisk decentralized without a hierarchy of nodes that separates delegates and non-delegates (who is a delegate can also change often over time).” Well, it’s great. In fact, I think that could be a trend in the future to bring any type of node to the cloud but I understand your point of view of having peers away from the cloud, I am one of those that wants to be an active delegate node in the mainnet network.

I will continue to think about new solutions and raise them when possible. Again, thanks for your answer.

Cheers,
Davi

[janhack]

Hi Davi,

if you have questions on how to reproduce the benchmark results, you can visit our Gitter room and one of the developers can help you there.

Cheers,
Jan