Mina data incorrect

[garethtdavies]

The displayed Nakamoto coefficient for MINA is inaccurate. Likely this has more significance, as it is the largest (inaccurately) by some margin.

This is caused by using an API of "validators". It's probable this excludes non-active or non-public block producer addresses from the calculation, whereby this calculation should be based on Mina's staking ledger.

It's quite simple to confirm this by either looking at the raw data of the current epoch staking ledger (epoch 63) https://storage.googleapis.com/mina-explorer-ledgers/jwbeXmeEZ2aYSyXnBbsMqWUxVDouwYZdzCqBejTaoecCkHoinPy.json or a summary here https://minaexplorer.com/staking?epoch=63 and the % of total stake for each address. For the epoch the top 20 addresses control > 50% of the stake of the network, thus should be the Nakamoto coefficient, but is displayed as 61.

[alfredonodo]

Hi,
I agree, according to this explorer 18 validators controls over 50% of the total stake. According to this which is the same source used by nakaflow and this 95 validators controls over 50% of the total stake. Which of the two is correct?
Thank you

[garethtdavies]

They are showing two different things. The latter is a dashboard for active validators, i.e., ones that are staking and a subset of the former. The former is the staking ledger and the source of truth for this metric. You don't need an explorer to validate you can get it from the daemon e.g. mina ledger export staking-epoch-ledger > /data/staking.json or via a dump listed here https://docs.minaexplorer.com/minaexplorer/data-archive.

For the current epoch 18 addresses control >50% of the stake. Any of those addresses could produce blocks this epoch.

[xenowits]

Hey @garethtdavies , thanks for the insights!

Questions:

• Does the staked percentage per operator change every epoch? For instance, looking at the link https://minaexplorer.com/staking?epoch=63, it seems 7 operators have combined stake > 33% of the network. So, accordingly, the NC value should be 7
• Which API endpoint should we use for the new calculation? I think I can raise a PR with the fix

[garethtdavies]

Hey, yes the staking ledger is different every epoch (14 days and 21 hours). The current epoch staking ledger is a snapshot of the balances in the snarked ledger at the last block of the epoch but 2 epochs prior e.g. epoch 63 staking ledger is the snapshot of the snarked ledger at the last block of epoch 61 etc...

I believe 50% is the correct number, as the assumption is an honest majority. So 18 would be the correct current value.

There isn't actually a suitable API I could point you to. You can get the staking data from https://graphql.minaexplorer.com/ (stakes collection) but this is being deprecated at the next hard fork or get the data from https://minaexplorer.com/staking-data/current which could serve as a temporary stopgap until someone exposes the full staking data via API.

Maybe @duccas could assist in exposing that data or have a query already that would work.

[xenowits]

Hey @garethtdavies ,

How does the liveness & safety assumptions work for 33% vs 50%? I want to understand if we should use the standard operative threshold (33.3) or a new one?

Since NC depends on a lot of factors, we are using the standard threshold of 33.3 for all the chains. See report for more details: https://messari.io/report/evaluating-validator-decentralization-geographic-and-infrastructure-distribution-in-proof-of-stake-networks

[alfredonodo]

@xenowits
The value of 33% is fine as a standard threshold for a BFT-type consensus protocol. However, there are some examples of PoS consensus protocols that deviate from this: Cardano Ouroboros Praos is a Nakamoto-style consensus protocol and therefore has a threshold of 50%, Avalanche is a probabilistic BFT-style consensus protocol and has a threshold of 25%.
Since Mina uses Ouroboros Samasika, derived from Cardano Ouroboros, it has the same 50% consensus threshold.