A transaction that Dusk can replay should be admissible live too.
That boundary is stricter.
I assumed transaction format was one rule: decode it successfully, and the network is happy.
Dusk split that path.
The current Rusk implementation separates live transaction ingress from canonical ledger data. Aegis and Boreas envelopes can enter through live admission and be normalized to the active ingress format, then pass through `CanonicalTransaction` and `LedgerTransaction` before the locally sealed transaction is canonicalized for block commitment. Consensus still checks that the ledger encoding matches the canonical format required at that block height.
And the strange part is what happens to older formats.
Dusk's mainnet Aegis activation default is block **3,590,904**. Historical transaction formats remain decodable for ledger replay, but those same historical formats are rejected during live mempool admission once the format is no longer permitted there.
So imagine an old transaction from before that boundary sitting in the chain's history.
Dusk can still understand it while replaying the ledger.
But try to push that historical format through live admission after the protocol has moved on, and it gets rejected.
The node can preserve the past without letting the past define what becomes new ledger data.
How much of Dusk's transaction compatibility comes from preserving old formats for the chain's history, and how much of its consistency comes from refusing to let those formats back into the live path?
@Dusk $DUSK #dusk
That boundary is stricter.
I assumed transaction format was one rule: decode it successfully, and the network is happy.
Dusk split that path.
The current Rusk implementation separates live transaction ingress from canonical ledger data. Aegis and Boreas envelopes can enter through live admission and be normalized to the active ingress format, then pass through `CanonicalTransaction` and `LedgerTransaction` before the locally sealed transaction is canonicalized for block commitment. Consensus still checks that the ledger encoding matches the canonical format required at that block height.
And the strange part is what happens to older formats.
Dusk's mainnet Aegis activation default is block **3,590,904**. Historical transaction formats remain decodable for ledger replay, but those same historical formats are rejected during live mempool admission once the format is no longer permitted there.
So imagine an old transaction from before that boundary sitting in the chain's history.
Dusk can still understand it while replaying the ledger.
But try to push that historical format through live admission after the protocol has moved on, and it gets rejected.
The node can preserve the past without letting the past define what becomes new ledger data.
How much of Dusk's transaction compatibility comes from preserving old formats for the chain's history, and how much of its consistency comes from refusing to let those formats back into the live path?
@Dusk $DUSK #dusk