@Dusk
i went digging into how dusk's committee size actually works, since "64 credits per round" gets repeated everywhere as fixed. found a github issue describing something different — committee size caps at 64 but drops below that when there aren't enough eligible provisioners, with quorum computed off that smaller number. except when i went to check which codebase that issue was filed against, it's dusk-blockchain, the old golang client, archived by its own team back in june 2025.
so this was documented behavior in the pre-mainnet implementation, not necessarily what's running now — actually wait, i should be more precise, it's not that it's necessarily different now, it's that i genuinely can't find anything either way. mainnet uses rusk, a full rust rewrite, and whether this exact sortition logic carried over or got redesigned along the way isn't something i could confirm.
that's a weirdly specific gap for a network this deep into public docs — the historical behavior is real and traceable, but nothing i've found actually confirms or denies it in the current live codebase.
has anyone actually checked the current rusk sortition code for this, or is everyone just repeating the old go client's behavior as if it's still true? 🧐
#dusk $DUSK
i went digging into how dusk's committee size actually works, since "64 credits per round" gets repeated everywhere as fixed. found a github issue describing something different — committee size caps at 64 but drops below that when there aren't enough eligible provisioners, with quorum computed off that smaller number. except when i went to check which codebase that issue was filed against, it's dusk-blockchain, the old golang client, archived by its own team back in june 2025.
so this was documented behavior in the pre-mainnet implementation, not necessarily what's running now — actually wait, i should be more precise, it's not that it's necessarily different now, it's that i genuinely can't find anything either way. mainnet uses rusk, a full rust rewrite, and whether this exact sortition logic carried over or got redesigned along the way isn't something i could confirm.
that's a weirdly specific gap for a network this deep into public docs — the historical behavior is real and traceable, but nothing i've found actually confirms or denies it in the current live codebase.
has anyone actually checked the current rusk sortition code for this, or is everyone just repeating the old go client's behavior as if it's still true? 🧐
#dusk $DUSK
