I keep thinking about two transaction types Dusk introduced in Rusk: CanonicalTransaction and LedgerTransaction.
They represent different layers of the same transaction. CanonicalTransaction is the form Rusk works with logically, while LedgerTransaction wraps that transaction in the ledger representation required by a particular protocol version. The tension is that Dusk wants those storage formats to evolve without forcing the meaning of a transaction to evolve with them, an important property as it pushes to bring financial markets onchain with EU-licensed institutions. What I don't know yet is whether that separation will actually keep version changes contained inside Rusk, or whether format changes will still spill into wallets, applications and historical replay.
The details worth watching are how Dusk normalizes incoming transactions, selects the correct ledger representation, and interprets older transactions after protocol upgrades.
A wallet continuing to submit transactions after an upgrade is useful evidence of compatibility. The stronger test is whether Dusk can change the representation underneath while preserving the same transaction semantics above it.
I'd judge that abstraction by how little of the versioning complexity applications need to know about.
The question is whether Dusk has truly separated what a transaction means from how the ledger stores it, or simply moved the version-handling burden somewhere else in the stack.
I am watching how that boundary holds up through future format changes and historical replay.
#dusk $DUSK @Dusk
They represent different layers of the same transaction. CanonicalTransaction is the form Rusk works with logically, while LedgerTransaction wraps that transaction in the ledger representation required by a particular protocol version. The tension is that Dusk wants those storage formats to evolve without forcing the meaning of a transaction to evolve with them, an important property as it pushes to bring financial markets onchain with EU-licensed institutions. What I don't know yet is whether that separation will actually keep version changes contained inside Rusk, or whether format changes will still spill into wallets, applications and historical replay.
The details worth watching are how Dusk normalizes incoming transactions, selects the correct ledger representation, and interprets older transactions after protocol upgrades.
A wallet continuing to submit transactions after an upgrade is useful evidence of compatibility. The stronger test is whether Dusk can change the representation underneath while preserving the same transaction semantics above it.
I'd judge that abstraction by how little of the versioning complexity applications need to know about.
The question is whether Dusk has truly separated what a transaction means from how the ledger stores it, or simply moved the version-handling burden somewhere else in the stack.
I am watching how that boundary holds up through future format changes and historical replay.
#dusk $DUSK @Dusk