search

xenowits / nakomoto-coefficient-calculator

Nakamoto Coefficient for different blockchains to understand levels of decentralization
https://nakaflow.io
MIT License
37 stars 31 forks source link

Fix THRESHOLD to 33.33 #25

Open xenowits opened 1 year ago

xenowits commented 1 year ago

Problem to be solved

The current THRESHOLD value is assumed to be .33. See https://github.com/xenowits/nakomoto-coefficient-calculator/blob/main/core/utils/constants.go.

Also, research what value percentage is applicable for each chain since some might need 51%, while others might need 33% etc.

Proposed solution

Modify the THRESHOLD value to be 33.33 instead.

alfredonodo commented 1 year ago

Hi, the subject is very complex and it is not easy to find a standard threshold, but whitepapers should be studied carefully because the devil is in the details. Unfortunately, I too have sometimes made mistakes by not checking them. I think that in the Messari report there are some errors. Everything starts with the famous availability-finality (consistency) dilemma, which depends on the type of consensus protocol used. Protocols that favour availability (liveness), follow the rule of the longest chain, admit forks and have a probabilistic finality. Conversely, protocols that favour finality (safety), follow the BFT consensus, do not admit forks and have an immediate finality. The thresholds used in the report for liveness=finality=33% and safety=66% are only valid for some PoS chains with BFT consensus (Aptos, Cosmos, Everscale, ICP, TON) or for those that have a mixed-hybrid consensus protocol, but with BFT finality (EOS, Ethereum, MultiversX, Near, Polkadot, Solana). There are some PoS like Cardano or Mina that have probabilistic finality and follow the rule of the longest chain (liveness=finality=safety=50% like Bitcoin), others like Avalanche have immediate finality with "probabilistic" BFT (liveness=finality=25% and safety=75%) while others like Algorand have immediate finality with BFT with modified thresholds (liveness=finality=20% and safety=80%). So I think the threshold parameter should be customised for each blockchain and not fixed as a constant.