@Dusk_Foundation I found myself looking at DUSK Network’s Phoenix note tree because depth 34 sounds like a small implementation choice but the scaling behavior behind it is not small.
The obvious number is 17,179,869,184 possible leaves. I think that number is almost the distraction. Phoenix defines a binary Merkle tree at depth 34 so capacity grows exponentially while an inclusion path grows only linearly. Each spent input still needs a valid Merkle path to its anchor.
Compare the curve depth 32 gives about 4.29B leaves depth 34 gives 17.18B and depth 36 gives 68.72B. Two extra levels multiply capacity by 4×. Going from 34 to 35 doubles capacity again while path depth rises from 34 to 35 steps, only about 2.9%.
That looks efficient for DUSK. But theoretical capacity is not the same as practical history management.
The real test is note creation rate vs proof and storage discipline.
How quickly does the tree actually fill? What happens to proving cost witness handling archival storage and state access as history grows?
Some overhead is normal. Privacy needs structure.
What I’m unsure about is whether DUSK Network chose a depth that stays comfortable under real usage not just mathematically enormous.
#dusk $DUSK #dusk $DUSK @Dusk
The obvious number is 17,179,869,184 possible leaves. I think that number is almost the distraction. Phoenix defines a binary Merkle tree at depth 34 so capacity grows exponentially while an inclusion path grows only linearly. Each spent input still needs a valid Merkle path to its anchor.
Compare the curve depth 32 gives about 4.29B leaves depth 34 gives 17.18B and depth 36 gives 68.72B. Two extra levels multiply capacity by 4×. Going from 34 to 35 doubles capacity again while path depth rises from 34 to 35 steps, only about 2.9%.
That looks efficient for DUSK. But theoretical capacity is not the same as practical history management.
The real test is note creation rate vs proof and storage discipline.
How quickly does the tree actually fill? What happens to proving cost witness handling archival storage and state access as history grows?
Some overhead is normal. Privacy needs structure.
What I’m unsure about is whether DUSK Network chose a depth that stays comfortable under real usage not just mathematically enormous.
#dusk $DUSK #dusk $DUSK @Dusk