Dusk activated PLONK V3 on mainnet at block 3,590,904, but older blocks still rely on the PLONK V1 or V2 rules that applied when they were produced.
At first, that can sound like a simple verifier upgrade. But a new rule for current activity does not automatically become the rule for Dusk's entire history.
Activating PLONK V3 tells me which proof rules Dusk uses from that fork boundary forward. It does not tell me that earlier blocks are re-evaluated under the newer verifier.
What I don't know yet is how reliably the Dusk network keeps those verification eras separated as nodes sync, replay history and validate new activity under different rule sets.
That matters more as Dusk builds infrastructure for native issuance workflows, where more of a regulated security's lifecycle can depend on the ledger preserving a consistent history across protocol upgrades.
Rusk gives one useful mechanism to watch. It selects the appropriate verifier based on block height, so historical blocks are checked under their original rules while newer activity uses PLONK V3.
A successful activation proves Dusk can introduce a new verifier. Consistent replay across V1, V2 and V3 is stronger evidence because nodes have to agree not only on the current rules, but on exactly which rules belong to every earlier part of the chain.
That changes how I would judge cryptographic upgrades on Dusk.
The question is whether Dusk can keep evolving its cryptographic stack while preserving exactly the rules that made every earlier block valid.
I am watching historical replay, node sync across verifier boundaries and whether Dusk components continue to select the same rule set at the same block height.
#dusk $DUSK @Dusk
At first, that can sound like a simple verifier upgrade. But a new rule for current activity does not automatically become the rule for Dusk's entire history.
Activating PLONK V3 tells me which proof rules Dusk uses from that fork boundary forward. It does not tell me that earlier blocks are re-evaluated under the newer verifier.
What I don't know yet is how reliably the Dusk network keeps those verification eras separated as nodes sync, replay history and validate new activity under different rule sets.
That matters more as Dusk builds infrastructure for native issuance workflows, where more of a regulated security's lifecycle can depend on the ledger preserving a consistent history across protocol upgrades.
Rusk gives one useful mechanism to watch. It selects the appropriate verifier based on block height, so historical blocks are checked under their original rules while newer activity uses PLONK V3.
A successful activation proves Dusk can introduce a new verifier. Consistent replay across V1, V2 and V3 is stronger evidence because nodes have to agree not only on the current rules, but on exactly which rules belong to every earlier part of the chain.
That changes how I would judge cryptographic upgrades on Dusk.
The question is whether Dusk can keep evolving its cryptographic stack while preserving exactly the rules that made every earlier block valid.
I am watching historical replay, node sync across verifier boundaries and whether Dusk components continue to select the same rule set at the same block height.
#dusk $DUSK @Dusk
