WHY DUSK DOESN’T MAKE ONE NODE DO EVERYTHING
Two weeks ago I was trying to save money on a VPS. I put my main app, database backups and a heavy image-processing job on the same small server. Seemed efficient. It wasn't. The image job would start, and suddenly my main app was missing requests.
That stupid little VPS problem comes back to me when I read Dusk's node setup. Dusk separates the work between Provisioner, Archive and Prover roles. They aren't three fancy names for one machine doing everything.
A Provisioner focuses on consensus and needs at least 1,000 DUSK staked. An Archive Node keeps finalized history for things like "moonlightHistory" and "finalizedEvents". A Prover handles the heavier Zero-Knowledge proof work.
Then I get to the Prover and the hardware problem changes again. Dusk says proof generation is single-threaded, so strong single-core performance matters. Archive infrastructure has a different starting point: 4 cores, 8 GB RAM, 500 GB storage and 100 Mbps networking.
And this is the part that feels familiar. Dusk recommends keeping production API infrastructure separate from Provisioner duties because query traffic and maintenance can compete with consensus work. I learned the same thing the annoying way on that VPS.
Now I’m looking at the three roles a little differently. If consensus, historical queries and ZK proving all start fighting for the same resources, maybe one box doing everything isn't actually the simpler option.
@Dusk #dusk $DUSK
Two weeks ago I was trying to save money on a VPS. I put my main app, database backups and a heavy image-processing job on the same small server. Seemed efficient. It wasn't. The image job would start, and suddenly my main app was missing requests.
That stupid little VPS problem comes back to me when I read Dusk's node setup. Dusk separates the work between Provisioner, Archive and Prover roles. They aren't three fancy names for one machine doing everything.
A Provisioner focuses on consensus and needs at least 1,000 DUSK staked. An Archive Node keeps finalized history for things like "moonlightHistory" and "finalizedEvents". A Prover handles the heavier Zero-Knowledge proof work.
Then I get to the Prover and the hardware problem changes again. Dusk says proof generation is single-threaded, so strong single-core performance matters. Archive infrastructure has a different starting point: 4 cores, 8 GB RAM, 500 GB storage and 100 Mbps networking.
And this is the part that feels familiar. Dusk recommends keeping production API infrastructure separate from Provisioner duties because query traffic and maintenance can compete with consensus work. I learned the same thing the annoying way on that VPS.
Now I’m looking at the three roles a little differently. If consensus, historical queries and ZK proving all start fighting for the same resources, maybe one box doing everything isn't actually the simpler option.
@Dusk #dusk $DUSK
