mirror of
https://github.com/luxfi/consensus.git
synced 2026-09-24 00:26:58 +00:00
zeekayandHanzo Dev
7d990c2592
It did not. QuasarConsensus::create_certificate stamped ceil(alpha * k), the CONFIGURED accept quorum, while every floor that certificate is then held to is derived from the SET. Those are two quantities: one is about a committee, the other about who can sign. They part at every n != k, and the testnet preset parts at its own k — five validators, alpha 0.6, a stamped 3 against a derived 4 — so the public issue path was dead on that preset at every set size, and its refusal came back as NoQuorum over a set holding a unanimous one. So the threshold is derived here and now, exactly as Tally::cert derives it: signer_floor(tier, signer_count) at the moment of issue. The liveness pre-gate reads the same derived number rather than the configured one, so it can never stop short of a quorum the predicate below would have admitted — the door-in-front-of-a- gate mistake, which this one was also making at every n where the config asked more than the set does. The suite stayed at 170 green through all of it because it only ever asked the DEFAULT preset at n=20, which is the one point where ceil(0.69 * 20) and two_thirds_count(20) are both 14. The new rows straddle that point, on both presets, and every one of them fails on the old stamp. THE REFUSAL IS CARRIED WHOLE. verify_weighted's answer was flattened to NoQuorum, so "the voters hold 3 of 10_003 stake" and "two seats cannot carry a supermajority at all" and "the votes are not in yet" were one sentence. ConsensusError::Cert carries the CertError, and the two registration doors stop stringifying theirs through CryptoError — one way to carry one thing. THE CONFIGURED NUMBER STAYS, under its own name. QuasarConsensus::alpha is what has_quorum asks: has the membership grown to the committee this node was told to expect. It is a readiness question and it touches no certificate. It was called `threshold`, which is why it ended up stamped on one. ONE READ PER ISSUE. Tally::cert derived its threshold from signer_count and then handed verify_weighted the source, which reads signer_count again to check that same threshold. A source that need not answer twice alike makes those two numbers, and the second refuses what the first built. The count is taken once and answers every clause of the issue. Only the issue: the ARRIVAL road keeps its independent reads, and the rung's count clause reading the set again is what refuses a certificate whose set moved under it — which is why that clause is not dead. CertError and ConsensusError are #[non_exhaustive]. A refusal is a fact about the protocol and the protocol acquires facts; ThresholdNotDerived is one it just acquired. This cut breaks an exhaustive match either way, so it is the cut that should make it the last time. 1.23.0: new API, non-breaking variants after. Co-authored-by: Hanzo Dev <[email protected]>