#dusk $DUSK I was reading the privacy transactions chapter in the whitepaper by @Dusk , and I saw a design that really caught my eye: its encrypted notes are never deleted from the tree.
First, let me lay out how it works. Phoenix is its privacy transaction model. The money doesn’t exist as balances; instead, it’s represented by individual encrypted notes, all attached to a Merkle tree. When you spend a note, you provide something called a “nullifier.” This code is derived from the note’s private key and is fixed and unique. The network keeps a list of all nullifiers. Once a nullifier has been seen, it can’t be used again—double-spending is prevented exactly that way.
The counterintuitive part is this: after a note is spent, the network only knows that a certain nullifier was used, but it doesn’t know which note in the tree corresponds to it.
So the tree can’t delete nodes. If it deleted, it would effectively reveal which note was spent to everyone. The tree can only keep growing upward.
At first, I thought this was a flaw—storage costs would expand without limit. Later I realized this is the price of privacy, and it’s a necessary one. The on-chain trace you leave behind is only a nullifier, which can’t be linked to the specific note, the sender’s address, or the amount.
There’s also a detail I think is especially thoughtful. Each note comes with a one-time public key. The sender computes it using the recipient’s public key plus a random value. If the same person receives money a hundred times, the chain will show a hundred completely different addresses—nobody can connect them to the same person. This idea is borrowed from Monero.
There’s also a viewing key as a companion. You can share it separately with an auditor. The auditor can decrypt your notes to see the amounts, but they can’t move your funds. Viewing and spending require two different keys.
So I think Phoenix’s trade-offs are very clear: it uses ever-growing storage to achieve complete unlinkability, and then it uses the viewing key to keep the compliance path open.
How they control storage growth in the long term isn’t explained in the whitepaper—that’s the part I’d be watching.
What do you think? Is on-chain privacy worth paying for with unlimited growth in storage cost? Leave a comment below and let’s discuss.
First, let me lay out how it works. Phoenix is its privacy transaction model. The money doesn’t exist as balances; instead, it’s represented by individual encrypted notes, all attached to a Merkle tree. When you spend a note, you provide something called a “nullifier.” This code is derived from the note’s private key and is fixed and unique. The network keeps a list of all nullifiers. Once a nullifier has been seen, it can’t be used again—double-spending is prevented exactly that way.
The counterintuitive part is this: after a note is spent, the network only knows that a certain nullifier was used, but it doesn’t know which note in the tree corresponds to it.
So the tree can’t delete nodes. If it deleted, it would effectively reveal which note was spent to everyone. The tree can only keep growing upward.
At first, I thought this was a flaw—storage costs would expand without limit. Later I realized this is the price of privacy, and it’s a necessary one. The on-chain trace you leave behind is only a nullifier, which can’t be linked to the specific note, the sender’s address, or the amount.
There’s also a detail I think is especially thoughtful. Each note comes with a one-time public key. The sender computes it using the recipient’s public key plus a random value. If the same person receives money a hundred times, the chain will show a hundred completely different addresses—nobody can connect them to the same person. This idea is borrowed from Monero.
There’s also a viewing key as a companion. You can share it separately with an auditor. The auditor can decrypt your notes to see the amounts, but they can’t move your funds. Viewing and spending require two different keys.
So I think Phoenix’s trade-offs are very clear: it uses ever-growing storage to achieve complete unlinkability, and then it uses the viewing key to keep the compliance path open.
How they control storage growth in the long term isn’t explained in the whitepaper—that’s the part I’d be watching.
What do you think? Is on-chain privacy worth paying for with unlimited growth in storage cost? Leave a comment below and let’s discuss.
