I was looking at Dusk's transparent transaction model and initially skipped over something that sounded almost too basic: the nonce.
Moonlight is Dusk's account-based transaction model. Each account has a public key, balance and a nonce, with the nonce acting as a counter for transactions sent from that account.
That tiny counter has a bigger job than it first appears.
The whitepaper explicitly connects the nonce to replay protection. A transaction isn't simply authorized because the signature is valid; the account's transaction sequence also has to make sense.
This is one of those pieces of blockchain infrastructure that users almost never notice when it works correctly.
You sign a transaction, the network processes it, your balance changes and you move on.
But without mechanisms preventing an old valid transaction from being accepted again, the same authorization could potentially become a completely different security problem.
What I find interesting about Dusk is that Moonlight and Phoenix solve the same fundamental transaction requirements through very different models.
Moonlight exposes account state, balances and transaction metadata publicly. Phoenix moves balance verification and double-spend protection into ZK proofs and nullifiers. Yet both still have to establish ownership, prevent malleability and stop double spending.
So the real design decision isn't simply public vs private.
It's how much of the state transition the network can verify directly versus how much must be proven cryptographically.
That makes the humble nonce more interesting than it sounds.
The visible transaction is only the surface. Underneath it is a collection of rules making sure the same authorization cannot simply be replayed.
How many blockchain “features” are actually invisible security assumptions users only notice when they fail?
@Dusk $DUSK #dusk
Moonlight is Dusk's account-based transaction model. Each account has a public key, balance and a nonce, with the nonce acting as a counter for transactions sent from that account.
That tiny counter has a bigger job than it first appears.
The whitepaper explicitly connects the nonce to replay protection. A transaction isn't simply authorized because the signature is valid; the account's transaction sequence also has to make sense.
This is one of those pieces of blockchain infrastructure that users almost never notice when it works correctly.
You sign a transaction, the network processes it, your balance changes and you move on.
But without mechanisms preventing an old valid transaction from being accepted again, the same authorization could potentially become a completely different security problem.
What I find interesting about Dusk is that Moonlight and Phoenix solve the same fundamental transaction requirements through very different models.
Moonlight exposes account state, balances and transaction metadata publicly. Phoenix moves balance verification and double-spend protection into ZK proofs and nullifiers. Yet both still have to establish ownership, prevent malleability and stop double spending.
So the real design decision isn't simply public vs private.
It's how much of the state transition the network can verify directly versus how much must be proven cryptographically.
That makes the humble nonce more interesting than it sounds.
The visible transaction is only the surface. Underneath it is a collection of rules making sure the same authorization cannot simply be replayed.
How many blockchain “features” are actually invisible security assumptions users only notice when they fail?
@Dusk $DUSK #dusk