Measure consensus Nakamoto coefficient

[alfredonodo]

Summary

Measure the decentralization of the project via Nakamoto coefficient, which is the measure of the smallest number of independent entities that can act collectively to block the consensus of a blockchain.

Context

An independent open source third party project, nakaflow, compares all major blockchains in terms of Nakamoto coefficient. It would be very interesting to add TON.

Learning goals

How to compare the decentralisation of different blockchains from a consensus protocol perspective.

References

https://nakaflow.io/

Estimate suggested reward

50 $

[Sarvesh-Ghildiyal]

Hello, what do i have to do to resolve this issue? can you please guide me through?

[alfredonodo]

Hello, what do i have to do to resolve this issue? can you please guide me through?

Hi,
the aim of this task is to add TON to the nakaflow project which measures the decentralisation of consensus, so you need to have the list of validators sorted by their stakes and take the first ones who are able to control consensus about 33.3% of the stakes for Catchain PoS.
The project uses the Go language and you can take inspiration from other blockchain, the last one that was added was this one. I found this Toncoin API, but I do not know if there is anything better.
Thank you

[alfredonodo]

This API should obtain the list of validators with the respective stake in JSON format, however, the data does not seem to be in line with the data provided by tonscan and tonwhales.

[mbaneshi]

@alfredonodo, thank you for introducing this noteworthy project centered on measuring the degree of decentralization, a truly valuable indicator. I have a few questions on this matter.

1. Could you elaborate on how TON, its validators, and its transparency function?

2. How confident are you that this indicator will prove beneficial for TON?

3. On what criteria do you base the suggestion of a 50 $ budget for completion?

[alfredonodo]

@mbaneshi

1. TON doc. The first 100 validators sorted according to their stake validate the masterchain while the others periodically chosen at random in groups of 23 validate the shardchains. TON rewards validators with an inflation of between 0.3-0-6% and punishes validators who do not behave honestly, inactive or perform poorly (although these mechanisms need to be reviewed in light of the events of recent weeks).
2. Nakamoto coefficient measures the decentralisation of consensus of any blockchain PoS or PoW and is an easily understood indicator for comparing different projects. TON not only has excellent scalability, it also has one of the highest Nakamoto coefficients based on simple calculations.
3. I am not good at quantifying the work required. However, I think that a person who knows the Go language, using the API above does not take more than 1 hour of work.

[mbaneshi]

@alfredonodo, thank you for your response; I sincerely appreciate it.

I believe that when we require the approval of two out of three validators (with 100 being the norm for the majority of stackers) to commit a single block to the master chain, it means the minimum number required to compromise TON functionality is equal to this number as well.

On the other hand, the question arises: Why would this number of validators want to disrupt the network, especially when they have locked a significant value for security concerns? Let's assume they all come from competitor blockchains and have bad intentions. The question then becomes why participants who invest their time, energy, and money to build diverse applications on top of this network would allow other participants to occupy more than 66 percent of the validators?

I assume this coefficient (minimum number of bad actors) aims to provide an indicator of a critical security concern, but this issue was solved in the first place. If there are no meaningful technical words, or if I am missing something significant, please correct me.

Furthermore, all TON networks utilize a known data structure among the community called Cell. This initiative has a Merkel-proof capacity needed for safety and data integrity in the overall blockchain network.

The difference in TON is that we have a concept of a blockchain of blockchains, meaning the low-level blockchain hash will reside on the master chain and will be committed. However, we have a vertical correction mechanism, which means that if some underlying blockchain makes mistakes, just one block will be corrected and committed without directly affecting the other blocks. This can be reasoned around Merkel's proof. This is my understanding so far.

As I sense it, if another project participates in this indicator, it does not necessarily mean it is applicable and has understandable meaning, at least in the current situation.

I also have a comment on the suggested reward by respect. I believe that resolving such an issue is not just a matter of knowing one language like Go or another but an understanding of the blockchain industry in general and more technical details of the current project as well.

Now the question is, assuming someone with this expertise, how much is their time worth, and what other similar opportunities will pay? It is clear that my expected reward is much more than your suggestion, and I encourage its consideration for the future. Your best friend, always wishing the best for you.

[alfredonodo]

I believe that when we require the approval of two out of three validators (with 100 being the norm for the majority of stackers) to commit a single block to the master chain, it means the minimum number required to compromise TON functionality is equal to this number as well.

Not exactly, read this to better understand how consensus algorithms work. Your reasoning might be true for the masterchain (anyway 1/3 not 2/3 of the validators), not for the whole blockchain. TON is a blockchain of blockchains up to 2^32 each with up to 2^60 shardchains.

On the other hand, the question arises: Why would this number of validators want to disrupt the network, especially when they have locked a significant value for security concerns? Let's assume they all come from competitor blockchains and have bad intentions. The question then becomes why participants who invest their time, energy, and money to build diverse applications on top of this network would allow other participants to occupy more than 66 percent of the validators?
I assume this coefficient (minimum number of bad actors) aims to provide an indicator of a critical security concern, but this issue was solved in the first place. If there are no meaningful technical words, or if I am missing something significant, please correct me.

This is the valid question for each blockchain and the Nakamoto coefficient measures the decentralisation of consensus (and more). The total number of validators or miners does not quantify the decentralisation of the corresponding blockchain. What matters is the minimum number of entities participating in the consensus. For example, in the case of Ethereum there are about 900k validators, but about 10 of them govern the network.

I also have a comment on the suggested reward by respect. I believe that resolving such an issue is not just a matter of knowing one language like Go or another but an understanding of the blockchain industry in general and more technical details of the current project as well.

We can talk about it for a long time. I agree that a single number does not explain an entire project. However, at the same time, one number is enough to compare different blockchains. This is no different from the TPS, the block time and the block finality.
I could do this in Python and I am not a programmer. You have to take the list of validators sorted by their participation and calculate the minimum number to reach the 33% consensus. That's it.

Now the question is, assuming someone with this expertise, how much is their time worth, and what other similar opportunities will pay? It is clear that my expected reward is much more than your suggestion, and I encourage its consideration for the future. Your best friend, always wishing the best for you.

One quite good programmer in Go can find a solution in less than one hour based on projects already implemented. I asked the same thing about Polkadot and they solved it immediately.

[delovoyhomie]

This issue has been automatically closed due to 14 days of inactivity and lack of the additional information requested.
Please feel free to reopen it if you wish to provide further details or require assistance.

[alfredonodo]

This issue has been automatically closed due to 14 days of inactivity and lack of the additional information requested. Please feel free to reopen it if you wish to provide further details or require assistance.

Hello,
what kind of information do you need?
Regards