CIP-0164 | Voting consistent with implementation + complete parameter list

[ch1bo]

Aggregate update since #1196, collecting PRs from our fork: cardano-scaling/CIPs#31, cardano-scaling/CIPs#33, cardano-scaling/CIPs#34, cardano-scaling/CIPs#36.

1. Key registration, rotation and voting, consistent with the implementation

   Prototyping the stake-based committee in cardano-node / ouroboros-consensus found things CIP-0164 | Replace wFA^LS committee with stake-based committee selection #1196 left open or specified differently from what was buildable:

   • Key Registration and Rotation (new subsection of Votes and Certificates), plus Pool Registration in Appendix B: the bls_key field, its mandatory proof of possession, keyless seats, and epoch-boundary activation aligned to VRF-key rotation.
   • Vote Structure: votes are cast on announcing_rb_hash, not on (slot_no, endorser_block_hash).
   • Votes and Certificates CDDL in Appendix B, and Certificate Validation: brought in line with the above and with the implementation. Worth a close read, this drops fields from both structures.
   • Committee Selection: pins the tie-break and the fewer-pools-than-N_c case, both of which an implementation has to decide because voter_id and the certificate bitfield are positional.
   • Node-to-Client: certifying ranking lblocks reuse the ranking_block CDDL so existing clients work unchanged; merged_block is gone (CIP-5: script prefixes extension #31).

2. A complete parameter list, as a basis for the parameter discussion

   Tables 3 and 7 now list the full set of Leios parameters under consistent names, each with a suggested value. The values are a discussion basis, not settled numbers. Two changes worth attention:

   • committeeSize (N_c) replaces the cumulative-stake target, resolving the TODO CIP-0164 | Replace wFA^LS committee with stake-based committee selection #1196 left on under-representation. See Committee Structure for why a seat count is sound here, and Choosing the committee size (with Table 7a, mainnet coverage at epoch 649) for how to pick it.
   • New parameter: maximum reference script size per endorser block (S_EB-ref), the EB analogue of Praos maxRefScriptSizePerBlock.
   • Fixed the timing parameters to use seconds instead of slots as they need to be independent of slot length and capture diffusion times.

   Choosing the quorum threshold is new too, and bounds τ from both sides rather than just from below.

   Cleanup folded in: consistent naming and matching order across both tables, the RB max size row dropped as an existing Praos parameter, one duplicated row and two typos removed.

---

(rendered updated document + updated summary "Committee Validation")

[rphair]

Thanks @ch1bo as before for keeping this maintained while the project develops. My gut feeling is that such PRs should always be merged soon (cc @Ryun1 @perturbing) when they reflect work that has already achieved consensus through implementation itself.

• So first: please post if I am wrong about assuming you would be happy this was merged right away... vs. having a public discussion about the proposed changes.
• Even if you'd be happy to put it through now, editors generally ask for at least one "second" from the project to approve the changes (please tag some if not covered below; cc primary author @will-break-it).

Also authors of these still-open PRs & their reviewers might look out for inconsistencies, duplicated changes & merge conflicts:

• @coot (still a draft): #1227 (review: @nfrisby)
• @ch1bo: #1213 (review: @Quantumplation @fallen-icarus @lehins

[ch1bo]

@rphair I put this PR up to fix things we encountered, but also as a discussion basis for the parameter list. I want to give it at least 2 weeks for discussion here and in the various parameter working groups.

[rphair]

Confirmed as a valid & update at the CIP meeting today... with @ch1bo planning to get some specialist team feedback this week. I've personally noted to editorially review this (likely approving, if no dispute) in around 1 week to ensure this stays on track for Last Check at the next CIP meeting unless any problem / unresolved discussion emerges.

p.s. this was also confirmed not to have any dependencies with the 2 concurrent (1 live, 1 draft) Leios CIP PR threads I linked above: although these were mainly referenced in hope the advocates & reviewers of these PRs will also be interested in reviewing this one.

[rphair]

OK @ch1bo after #1250 (review) I am guessing that your team meeting(s) last week did not turn up any problems with this update, since none were posted... and that the Ledger commits linked above would have attracted some revisions to this update if anything were incorrect here.

• Therefore I think this update is acceptable by default but please post if you want to hold back from Last Check at our next CIP meeting in a week's time: https://hackmd.io/@cip-editors/143
• If there are still items under consideration & any feedback came from these meetings (or your own work) please post here so editors & other Leios reviewers can follow this as needed.

[ch1bo]

@rphair Correct, nothing came up and I pointed to this PR in multiple groups since it was opened 3 weeks ago. We should be able to merge it on our next CIP editor call