Spent an evening comparing Dusk's docs against how its consensus actually behaves, and the detail that stuck with me isn't the privacy layer — it's Dusk @Dusk $DUSK #dusk splitting block generation from block ratification into two separate committees instead of one validator set doing both jobs. Most chains treat consensus as a single role wearing two hats. Here the generator is optimizing for throughput, the ratifier for finality safety, and those two objectives aren't automatically aligned. What I couldn't find a clean answer to, in the docs or in testnet activity, is what happens when the two committees genuinely disagree — not a validator going offline, but an actual split in judgment between generation and ratification. The architecture clearly has a resolution path built in, since the chain hasn't halted under normal conditions, but "hasn't halted yet" and "resolves cleanly under adversarial disagreement" are different claims. Almost no current usage stresses that path, since most activity is still light and cooperative. It's a design choice that's invisible right now and only becomes legible once someone tests it under pressure. Curious what that looks like in practice.