#dusk $DUSK @Dusk When I was reading Dusk’s documentation in translation, I noticed an easily overlooked detail: its node discovery mechanism does not rely on domain name servers.
When Bitcoin and Ethereum nodes first connect to a network, they need to obtain the addresses of other nodes from a hardcoded list of domain names in the code. This design is simple and effective, but it has a vulnerability—domain name servers can be blocked or hijacked, preventing new nodes from joining the network.
Dusk, instead, uses Kadcast’s built-in node discovery mechanism. When a new node starts, it only needs to know the address of one or more bootstrap nodes, and then fills its own routing table step by step through iterative queries. Once it’s connected to the network, the node no longer depends on the bootstrap nodes; instead, it maintains connections with other nodes through the routing table.
This design is more resistant to censorship. Even if all bootstrap nodes are blocked, as long as any node in the network is online, a new node can obtain its address in some way and connect to the network. For the globally compliant financial markets that Dusk is targeting, this censorship resistance is necessary—you can’t let a country’s network blockade prevent the entire network’s nodes from being able to connect.
I also found another detail: the persistence of node identity. Each node generates a fixed identity identifier when it starts for the first time, and this identifier is bound to the node’s staking address. Even if a node’s IP address changes, as long as the identity identifier remains the same, other nodes in the network can still recognize it. This solves the problem of tracking node identity in dynamic IP scenarios.
Of course, Kadcast’s node discovery also comes with a cost. The first time a new node synchronizes its routing table takes a few minutes, unlike domain name servers that can connect to a bunch of nodes in just a few seconds. But for a financial network that aims for long-term stable operation, a few minutes of initialization time is acceptable.$ETH
When Bitcoin and Ethereum nodes first connect to a network, they need to obtain the addresses of other nodes from a hardcoded list of domain names in the code. This design is simple and effective, but it has a vulnerability—domain name servers can be blocked or hijacked, preventing new nodes from joining the network.
Dusk, instead, uses Kadcast’s built-in node discovery mechanism. When a new node starts, it only needs to know the address of one or more bootstrap nodes, and then fills its own routing table step by step through iterative queries. Once it’s connected to the network, the node no longer depends on the bootstrap nodes; instead, it maintains connections with other nodes through the routing table.
This design is more resistant to censorship. Even if all bootstrap nodes are blocked, as long as any node in the network is online, a new node can obtain its address in some way and connect to the network. For the globally compliant financial markets that Dusk is targeting, this censorship resistance is necessary—you can’t let a country’s network blockade prevent the entire network’s nodes from being able to connect.
I also found another detail: the persistence of node identity. Each node generates a fixed identity identifier when it starts for the first time, and this identifier is bound to the node’s staking address. Even if a node’s IP address changes, as long as the identity identifier remains the same, other nodes in the network can still recognize it. This solves the problem of tracking node identity in dynamic IP scenarios.
Of course, Kadcast’s node discovery also comes with a cost. The first time a new node synchronizes its routing table takes a few minutes, unlike domain name servers that can connect to a bunch of nodes in just a few seconds. But for a financial network that aims for long-term stable operation, a few minutes of initialization time is acceptable.$ETH