Consensus parameters

Hi

I am interested to know how do you calculate these values:

NumProposers:           30,
SoftCommitteeSize:      2500,
SoftCommitteeThreshold: 1870,
CertCommitteeSize:      1000,
CertCommitteeThreshold: 720,
NextCommitteeSize:      10000,
NextCommitteeThreshold: 7750,
LateCommitteeSize:      10000,
LateCommitteeThreshold: 7750,
RedoCommitteeSize:      10000,
RedoCommitteeThreshold: 7750,
DownCommitteeSize:      10000,
DownCommitteeThreshold: 7750,

They are not same as algorand spec_v1.

Th only thing I could find is this comment:

// v8 uses parameters and a seed derivation policy (the "twin seeds") from Georgios' new analysis

Georgios’ new analysis???
Everyone has consensus about Georgios’ new analysis?

Thanks

Hi @mostafa,

I don’t have the details regarding how these parameters were calculated, however, please note that mainnet was launched with v17 ( i.e. June 2019 @ block 0 ), so some of the numbers mentioned above would never be used.

To complement @tsachi’s answer, the parameters that are actually used are defined below

They match the specs: specs/Algorand_v1_spec-2.pdf at master · algorandfoundation/specs · GitHub

The spec needs tweaked slightly. The spec shows 1550 and 2227 for Cert size/threshold instead of 1500/1112 like it in the the code at the moment.

The rest looks correct.

the parameters that are actually used are defined below

Still I didn’t get me answer. How Georgio got these values? Can Alice get the same values if she calculate them?

The spec needs tweaked slightly.

What do you mean it needs tweak slightly? This document is part of all confirmed blocks in Algorand right now. Do you mean all blocks also needs tweak slightly?

for example, look at block 500000 in Algorand:

{
  'genesis-hash': 'wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=',
  'genesis-id': 'mainnet-v1.0',
  'previous-block-hash': 'fkYoOt9ivfo6EZpDAEda6vYTmjQXlfdy2K7CO7puWV0=',
  rewards: {
    'fee-sink': '',
    'rewards-calculation-round': 500000,
    'rewards-level': 1020,
    'rewards-pool': '737777777777777777777777777777777777777777777777777UFEJ2CI',
    'rewards-rate': 20000000,
    'rewards-residue': 401032240
  },
  round: 50000,
  seed: 'q4nQzKm+11dOvtslV+3DacM3yGZrn8AS828oshaI02A=',
  timestamp: 1560561230,
  transactions: [],
  'transactions-root': 'tGWqr06HVvsHC2hFmu2EhwYBSiMkvIoo5nWxAkUxsLo=',
  'txn-counter': 0,
  'upgrade-state': {
    'current-protocol': 'https://github.com/algorandfoundation/specs/tree/5615adc36bad610c7f165fa2967f4ecfa75125f0',
    'next-protocol-approvals': 0,
    'next-protocol-switch-on': 0,
    'next-protocol-vote-before': 0
  },
  'upgrade-vote': { 'upgrade-approve': false, 'upgrade-delay': 0 }
}

Obviously It is disappointing to me.

No, I was simply saying the two values in the spec need updated to reflect the current values in the running consensus version (the actual code).
What you’re referring to is literally just a checked in PDF and two values in the PDF need updated. That’s it.
The code and consensus parameters are in the node code - the algorand/algorand-go repo (and Fabrice linked to parts earlier).

Code always changes and we always update the code or even refactor it. That’s OK.

But this pdf is part of block structure, Isn’t it? Look at upgrade-state section.