@Dusk Beaucoup de gens disent que les réseaux P2P deviennent naturellement plus rapides dès lors que le nombre de nœuds est suffisamment élevé, mais je n’ai jamais vraiment été convaincu par cette phrase. Ce n’est qu’en lisant les Core Components de $DUSK que j’ai remarqué que Kadcast n’utilise pas un gossip aléatoire, mais un overlay structuré. L’objectif est de réduire la bande passante et de rendre la latence plus prévisible. Ce choix m’a amené à changer d’avis : l’efficacité d’un réseau ne dépend pas seulement du nombre de nœuds, mais aussi des relations de connexion par lesquelles les messages parviennent à la destination.
Pour les opérateurs de nœuds, ce n’est pas une notion abstraite. Quand les routes sont plus structurées, les nœuds dépendent davantage de la découverte des voisins et de la qualité de la connectivité du réseau. Et dès que l’environnement d’exploitation bloque un canal UDP ou les adresses de Kadcast, en théorie, la latence prédictible ne se transforme pas automatiquement en performances réseau réellement exploitables. Ce que l’opérateur peut observer, c’est simplement que les messages ne sont pas reçus ou que des blocs accusent du retard, tout en devant juger par lui-même s’il s’agit d’un problème de version, d’une stratégie réseau ou d’une configuration défectueuse.
Les scénarios de pression sont très concrets. Quand les événements du marché augmentent, l’application veut que les transactions soient confirmées plus rapidement, mais qu’un nœud clé se retrouve bloqué par un pare-feu. Ce système n’est pas aussi simple que « plus de nœuds = plus de sécurité ». La capacité d’accès des nœuds peut elle aussi déterminer si les messages peuvent se propager comme prévu, et le coût du diagnostic finit par retomber sur la personne qui opère les nœuds en production. C’est pourquoi, lorsque j’évalue la performance réseau de DUSK, je ne me limite plus au temps de bloc ou au nombre de nœuds : je veux aussi vérifier les relations de voisins de Kadcast, les ports de communication et s’il existe des signaux de supervision intuitifs permettant d’identifier les nœuds en retard. @Dusk a choisi une propagation structurée, mais c’est sa capacité à transmettre réellement cette prédictibilité aux opérateurs qui est la partie que le réseau #dusk doit prouver.
Pour les opérateurs de nœuds, ce n’est pas une notion abstraite. Quand les routes sont plus structurées, les nœuds dépendent davantage de la découverte des voisins et de la qualité de la connectivité du réseau. Et dès que l’environnement d’exploitation bloque un canal UDP ou les adresses de Kadcast, en théorie, la latence prédictible ne se transforme pas automatiquement en performances réseau réellement exploitables. Ce que l’opérateur peut observer, c’est simplement que les messages ne sont pas reçus ou que des blocs accusent du retard, tout en devant juger par lui-même s’il s’agit d’un problème de version, d’une stratégie réseau ou d’une configuration défectueuse.
Les scénarios de pression sont très concrets. Quand les événements du marché augmentent, l’application veut que les transactions soient confirmées plus rapidement, mais qu’un nœud clé se retrouve bloqué par un pare-feu. Ce système n’est pas aussi simple que « plus de nœuds = plus de sécurité ». La capacité d’accès des nœuds peut elle aussi déterminer si les messages peuvent se propager comme prévu, et le coût du diagnostic finit par retomber sur la personne qui opère les nœuds en production. C’est pourquoi, lorsque j’évalue la performance réseau de DUSK, je ne me limite plus au temps de bloc ou au nombre de nœuds : je veux aussi vérifier les relations de voisins de Kadcast, les ports de communication et s’il existe des signaux de supervision intuitifs permettant d’identifier les nœuds en retard. @Dusk a choisi une propagation structurée, mais c’est sa capacité à transmettre réellement cette prédictibilité aux opérateurs qui est la partie que le réseau #dusk doit prouver.
