[ Community Ramblings]About Decentralization

This article was translated from the LatticeX Forum, Author：alliswell original link:https://forum.latticex.foundation/t/topic/4606.

As one of the most frequently used words in the cryptographic economy, “decentralization” is often seen as the entire reason for a blockchain’s existence, and the degree of “decentralization” is often an important measurement for the evaluation of a public chain. People in blockchain technology especially “hate” centralization, and when a technology discussion comes to a deadlock, the strongest argument against a viewpoint is usually accusing it of causing “centralization”.

I believe people have their own ideas on the reasons for decentralization, and here is a brief summarization:

Transparent rules and broad participation

The disadvantages of a centralized system have been criticized for a long time. The bookkeeping rules (or rules of the game) of a system should be determined by all participants and never by a single individual or organization, and if the power is too centralized, it is difficult to ensure that the person or organization with the power will not make their own gains at the expense of others.

Fault tolerance

When there are a few malicious or faulty nodes, it will not affect the system’s smooth operation; after all, it is unlikely that all nodes will fail or go wrong at the same time.

Cannot be manipulated

Because of the lack of a sensitive central point, the cost to attack, disrupt or manipulate is high.

Those who have been following the news about Alaya or PlatON may have noticed that PlatON’s consensus mechanism has increased the number of candidate validators to 201 and the number of block producers per round to 43, which is two times more than the pilot network Alaya in terms of decentralization. Does it mean that the more validators participating in the consensus, the better? Imagine this, without considering hardware and bandwidth costs, what would happen if all 7 billion people on earth each running a node and participating in joint bookkeeping?

Inefficient consensus

For PlatON based on the BFT consensus mechanism, the confirmation of block or state has to go through at least 2 rounds of QC (Quorum Certificate), and each round of QC has to guarantee the signature of more than 2/3 (2f+1) nodes in the whole network, hence, too many nodes will lead to a serious decrease in consensus efficiency.

Security issues

According to the BFT consensus theory, the total number of nodes N equals 3F+1. With the proportion of bad nodes stay unchanged, the larger the total number of nodes means the bigger F, malicious or faulty nodes. For selecting nodes to participate in consensus, PlatON currently uses the mechanism of random selection. To avoid all block producers selected in the same round being bad nodes, we can improve the randomized algorithm by Slashing, forfeit bad nodes or other measures, but at present, it is still not appropriate to set the total number of alternative validators too large for security reasons.

Insufficient incentives for validators

Validators involved in consensus have to maintain network security and efficiency, but this is not selfless. Most public chains, including PlatON, incentivize validators by issuing additional Tokens, but if the number of validators is too large, the number of incentives needed will be tremendous, and the incentives allocated to individual validators will become very limited, which will affect the motivation of validators to maintain network efficiency and security.

Slow update and upscale

A large group is inevitably filled with a variety of voices, and moving forward with new proposals for improvement (such as PIP) is not an easy task, and the initiator of a proposal needs to strive for sufficient support to implement it.

Based on the above reasons, PlatON currently does not completely deregulate the total number of validators and block producers per round, but put preliminary limit based on the current technology, rigorous performance, and exception testing. There is no conclusion about the most appropriate amount of validators, but from the technical iteration and the perspective of long-term development, the current parameter of 201 + 43 needs to be expanded further. We can try to set a few small goals to promote decentralization while balancing security and performance:

Number of alternative validators

It is planned to support more than 10,000 validators and dynamically adjust the number of alternative validators according to the number of LAT staking, transactions, block generation rate, and other factors to increase validators’ cost to do evil and reduce the risk of being attacked.

Number of validators

We are considering how to optimize the BFT consensus algorithm to support more validators without significant performance loss. Due to the time window of DDoS attacks, the number of validators participating in BFT cannot be too large, and it is planned to support up to 200 validators.