#dusk $DUSK @Dusk
I used to assume that once a blockchain's code was open source, the number of teams implementing it did not really matter. The protocol is the protocol. If the rules are public, anyone could write a second version, and the fact that nobody had yet felt like a detail.
Then I went looking for Dusk's node software and found something that changed how I read the whole project.
There is one client. Rusk, written in Rust. The earlier Go implementation is still on GitHub, publicly marked deprecated and no longer maintained, with a note pointing everyone to Rusk instead.
So every node on the network runs the same code.
This is worth sitting with, because the alternative approach exists for a reason. Ethereum encourages many independent clients so that a bug in one does not stop the chain — the others keep producing blocks while it is fixed. It is expensive, slow and duplicative on purpose. The duplication is the safety feature.
With a single client, a consensus bug is not partial. It is the network.
I do not think this is a mistake. For a small team, one excellent client is a far better use of resources than two mediocre ones, and Rusk has been audited repeatedly — the node library, the consensus layer, the networking protocol, all reviewed by outside firms. Concentrating effort is a defensible engineering decision.
But it does mean that a chain built for regulated settlement currently has no client diversity. The very thing traditional market infrastructure obsesses over — redundancy, independent failure paths, no single point of failure — is the thing that is not there yet.
What I cannot tell from the outside is whether a second implementation is even planned, or whether it is considered unnecessary at this stage of the network's life. Both answers would be reasonable. I would just like to know which one it is.
From here, I stopped reading "open source" as if it automatically meant resilient. Open code is an invitation. Client diversity is what happens when somebody accepts it.
I used to assume that once a blockchain's code was open source, the number of teams implementing it did not really matter. The protocol is the protocol. If the rules are public, anyone could write a second version, and the fact that nobody had yet felt like a detail.
Then I went looking for Dusk's node software and found something that changed how I read the whole project.
There is one client. Rusk, written in Rust. The earlier Go implementation is still on GitHub, publicly marked deprecated and no longer maintained, with a note pointing everyone to Rusk instead.
So every node on the network runs the same code.
This is worth sitting with, because the alternative approach exists for a reason. Ethereum encourages many independent clients so that a bug in one does not stop the chain — the others keep producing blocks while it is fixed. It is expensive, slow and duplicative on purpose. The duplication is the safety feature.
With a single client, a consensus bug is not partial. It is the network.
I do not think this is a mistake. For a small team, one excellent client is a far better use of resources than two mediocre ones, and Rusk has been audited repeatedly — the node library, the consensus layer, the networking protocol, all reviewed by outside firms. Concentrating effort is a defensible engineering decision.
But it does mean that a chain built for regulated settlement currently has no client diversity. The very thing traditional market infrastructure obsesses over — redundancy, independent failure paths, no single point of failure — is the thing that is not there yet.
What I cannot tell from the outside is whether a second implementation is even planned, or whether it is considered unnecessary at this stage of the network's life. Both answers would be reasonable. I would just like to know which one it is.
From here, I stopped reading "open source" as if it automatically meant resilient. Open code is an invitation. Client diversity is what happens when somebody accepts it.