Avalanche data is incorrect

[alfredonodo]

Hi,
the consensus of Avalanche called Snowflake requires 51% of stake. So the Nakamoto coefficient is incorrect as it is based on 33% of stake instead of 51%; it should be 45 instead 24.
Thank you

[xenowits]

Hey @alfredonodo ,

NC doesn't directly depend on the consensus threshold. Though, we use a standard 33.3% as the standard PoS-network operative threshold.

See this report for more details: https://messari.io/report/evaluating-validator-decentralization-geographic-and-infrastructure-distribution-in-proof-of-stake-networks

[alfredonodo]

@xenowits
Thank you for your answer.
Nakamoto consensus depends exactly on consensus threshold. As you wrote here "the Nakamoto Coefficient is a measure of the smallest number of independent entities that can act collectively to shut down a blockchain".
I read the report and found it excellent, but it does not address the problem properly. In a nutshell, a blockchain is a decentralised database that must respond to the CAP theorem. There are two main families of blockchains: AP blockchains which are based on Nakamoto-style consensus, the finality is probabilistic and the longest chain wins, and they favour liveness over safety, and CP blockchains which are based on BFT consensus, the finality is absolute there are no forks, and they favour safety over liveness.
Nakamoto style consensus blockchains of the PoW type like Bitcoin or PoS like Cardano need 50% of the votes (hashes or stakes) to reach consensus and add new blocks while blockchains with BFT style consensus of the PoS type like Algorand, Cosmos, TON and others need 66.6%. Other blockchains, such as Ethereum, Polkadot, Solana and others, have a mixed consensus, i.e. they use both the Nakamoto consensus and the BFT finality and therefore allow for forks, but fall within the 66.6% value.
The thresholds indicated in Messari's report liveness=finality=33.33, safety=66.6% are valid for blockchains with BFT and BFT finality type consensus (33.3% of malicious nodes are sufficient to stop consensus and block generation while 66.6% are needed for attack the network), while for those with Nakamoto type consensus they are all 50%.
I am now investigating Avalanche: according to the article above, the majority consensus should be at 50%, while according to what I read from the whitepaper it should be 33.3%. As soon as I have clarified, I will let you know.

[xenowits]

Thanks for the detailed answer @alfredonodo !

I myself want to understand this better, so appreciate the research. Keep me posted!

You can also DM me on discord (username: xenowits)

[kopeboy]

What a delusional service.. I will be looking around for better sources of NC cause this seems misinformation.

[alfredonodo]

What a delusional service.. I will be looking around for better sources of NC cause it's clear now this is spreading misinformation.

Actually, in this case it is the opposite. In fact, the problem is on the Avalanche side which lacks clarity as the whitepaper does not clearly specify many implementation details. I tried asking on their forum, but I am still waiting for a reply.
This is an open source project and everyone can analyse it and propose corrections, as the topic is very complex and marketing is often more important than technology. I haven't found better projects than this and that's why I'm trying to improve it, complaining is useless.

[alfredonodo]

I myself want to understand this better, so appreciate the research. Keep me posted!

You can also DM me on discord (username: xenowits)

Hi, thanks for the invitation, but fortunately I do not have discord, but I think I found you on telegram.

I found the answer which is unusual, I think even for you @kopeboy. If you want to read the detailed answer, you can read here.
The short version is that Avalanche is a synchronous (weak hypothesis compared to the general case) BFT protocol that uses a probabilistic threshold to achieve 75% safety and 25% liveness and thus 25% fault tolerance which corresponds to Nakamoto coefficient (you can change the code accordingly).

Probably the comparison paper above made the mistake of specifying 50% because of this sentence in the whitepaper which caused me to have doubts.

Once the querying node collects k responses, it checks if a fraction ≥ α are for the same color, where α > k/2 is a protocol parameter.

[kopeboy]

Thank you for investigating and clarifing! Apologies for being unnecessarily harsh in my previous comment.

So you define Nakamoto coefficient by liveness? Why not safety?

[alfredonodo]

This is not my definition, but the original Balaji Srinavasan and Leland Lee: "the Nakamoto Coefficient is a measure of the smallest number of independent entities that can act collectively to shut down a blockchain". As written by Nakaflow: "On a typical Proof-of-Stake network (like those listed here on Nakaflow), the Nakamoto Coefficient is defined by the number of node operators that, together, control more than one third (33.33%) of all stake on the network."
In any concurrent and/or distributed system, and a blockchain is a particular distributed database, liveness and safety are two sides of the same coin, a compromise must be found. In the case of the BFT-style consensus protocol, the Nakamoto Coefficient is 33% and corresponds to liveness, i.e. if there are more than 33% malicious nodes, the blockchain stops producing blocks. However, to attack the network and alter the blocks, 67% of malicious nodes are needed and this corresponds to safety. In the case of the Nakamoto-style consensus protocol, both numbers are 50%; 51% is needed to block consensus and alter blocks.
Avalanche uses its own probabilistic synchronous BFT-style consensus protocol in which there is 75% safety and 25% liveness and thus a Nakamoto Coefficient that corresponds to 25% malicious nodes.

[kopeboy]

Thanks for the explanation. Now the README should be updated accordingly:

Disclaimer
Please note that the values should be interpreted with context since the same objective treatment is applied for all the chains included here, ie, we simply calculate:

nakamoto-coefficient: no of validators controlling 33% of the total network stake

You are not applying 33% to every chain, but 50% to Bitcoin, 25% to Avalanche, etc..

[alfredonodo]

Thanks for the explanation. Now the README should be updated accordingly:

Disclaimer
Please note that the values should be interpreted with context since the same objective treatment is applied for all the chains included here, ie, we simply calculate:
nakamoto-coefficient: no of validators controlling 33% of the total network stake

You are not applying 33% to every chain, but 50% to Bitcoin, 25% to Avalanche, etc..

I agree with you. The problem is that the code is structured in such a way that the threshold for the Nakamoto coefficient is a shared constant instead of a blockchain-specific constant.