$DUSK takes an interesting approach to scaling because the 1MB block limit tells you more than a giant block size ever could. A Phoenix block can hold around 250 confidential transactions, which comes out to roughly 4KB per transaction. That's much heavier than a normal transparent UTXO transfer, but the extra bytes have a reason. Dusk is carrying nullifiers, commitments, and PLONK proof data so the network can verify a transaction without exposing who sent what to whom.
With blocks coming roughly every 10 seconds, you're looking at around 25 confidential TPS. For @Dusk right now, that's not necessarily a problem. The network isn't dealing with massive institutional settlement volume yet, so there isn't much reason to push capacity just for the sake of a bigger number.
The interesting part comes when Dusk's institutional use actually starts picking up. If tokenized securities begin settling at meaningful volume while regular Moonlight activity is happening alongside them, 25 TPS could become a real constraint.
Increasing the block size sounds like the easy answer, and Dusk has kept that parameter configurable. But bigger blocks also mean more data being relayed through Kadcast and more state for provisioners to store. A large operator with strong hardware and bandwidth can handle that pretty easily. A smaller node operator might not.
That's where the scaling discussion gets more important. Dusk isn't just deciding how many transactions it can process. It's also deciding what kind of hardware and bandwidth people need to participate in securing the network.
Privacy already makes transactions larger because the network has to prove things without revealing the underlying details. If Dusk keeps increasing capacity by simply making blocks bigger, it could eventually make running a node harder for smaller operators.
So I think the real test for Dusk isn't whether it can squeeze more transactions into each block. It's whether it can increase throughput while keeping network participation realistic for a broad range of operators.
#dusk $DUSK
With blocks coming roughly every 10 seconds, you're looking at around 25 confidential TPS. For @Dusk right now, that's not necessarily a problem. The network isn't dealing with massive institutional settlement volume yet, so there isn't much reason to push capacity just for the sake of a bigger number.
The interesting part comes when Dusk's institutional use actually starts picking up. If tokenized securities begin settling at meaningful volume while regular Moonlight activity is happening alongside them, 25 TPS could become a real constraint.
Increasing the block size sounds like the easy answer, and Dusk has kept that parameter configurable. But bigger blocks also mean more data being relayed through Kadcast and more state for provisioners to store. A large operator with strong hardware and bandwidth can handle that pretty easily. A smaller node operator might not.
That's where the scaling discussion gets more important. Dusk isn't just deciding how many transactions it can process. It's also deciding what kind of hardware and bandwidth people need to participate in securing the network.
Privacy already makes transactions larger because the network has to prove things without revealing the underlying details. If Dusk keeps increasing capacity by simply making blocks bigger, it could eventually make running a node harder for smaller operators.
So I think the real test for Dusk isn't whether it can squeeze more transactions into each block. It's whether it can increase throughput while keeping network participation realistic for a broad range of operators.
#dusk $DUSK