Je n’ai jamais trouvé le TPS seul très utile pour évaluer une chaîne comme DUSK.
Ça a l’air impressionnant sur un graphique.
Puis arrivent les charges de travail réelles.
La confidentialité. La génération de preuves. L’exécution de contrats. La croissance de l’état. Des nœuds qui essaient de rester synchronisés.
C’est là que les choses deviennent intéressantes.
DUSK semble mieux comprendre cela que la plupart.
Au lieu de faire tout faire à une seule couche, le réseau répartit le travail.
DuskDS gère le consensus, le règlement et la disponibilité des données.
DuskVM gère les contrats natifs.
DuskEVM donne aux applications basées sur Solidity un environnement d’exécution familier.
On dirait un discours d’architecture.
Mais c’est important, parce que chaque charge de travail a une façon différente de ralentir.
Et il y a aussi un autre élément discret : Kadcast.
Au lieu de bavarder sans fin sur des blocs à travers des pairs au hasard, il utilise un réseau structuré pour la propagation. Moins de trafic dupliqué, plus de livraisons prévisibles.
Ça ne fera peut-être pas un super visuel marketing.
Mais quand un réseau devient chargé, la bande passante gaspillée devient très concrète.
Puis vient la partie que les gens passent généralement sous silence :
la confidentialité a un coût en calcul.
Les preuves à connaissance zéro, c’est un travail réel. On peut avoir un consensus rapide et quand même se heurter à un mur si la génération des preuves devient le goulot d’étranglement.
Donc je ne pense pas que la vraie question de scalabilité de DUSK soit :
« Est-ce qu’il peut traiter un très grand nombre de transactions ? »
C’est plutôt :
Que se passe-t-il quand ces transactions deviennent coûteuses ?
La finalité peut-elle rester prévisible ?
Les nœuds peuvent-ils suivre ?
Les transactions privées peuvent-elles coexister avec l’activité normale des smart-contracts ?
C’est le test le plus difficile.
Et franchement, les petites décisions d’ingénierie me donnent plus d’informations que les grands chiffres.
Comment les données circulent. Comment l’état est accédé. Comment les nœuds se synchronisent. Comment les preuves sont produites. Comment l’exécution est séparée du règlement.
Rien de tout cela ne semble passionnant.
Mais c’est généralement là que se trouve la vraie scalabilité.
Une chaîne durable n’est pas une chaîne où chaque composant est ridiculement rapide.
C’est une chaîne où le travail coûteux sait rester à sa place.
C’est la partie de DUSK que je continue de surveiller.
#dusk $DUSK @Dusk
Ça a l’air impressionnant sur un graphique.
Puis arrivent les charges de travail réelles.
La confidentialité. La génération de preuves. L’exécution de contrats. La croissance de l’état. Des nœuds qui essaient de rester synchronisés.
C’est là que les choses deviennent intéressantes.
DUSK semble mieux comprendre cela que la plupart.
Au lieu de faire tout faire à une seule couche, le réseau répartit le travail.
DuskDS gère le consensus, le règlement et la disponibilité des données.
DuskVM gère les contrats natifs.
DuskEVM donne aux applications basées sur Solidity un environnement d’exécution familier.
On dirait un discours d’architecture.
Mais c’est important, parce que chaque charge de travail a une façon différente de ralentir.
Et il y a aussi un autre élément discret : Kadcast.
Au lieu de bavarder sans fin sur des blocs à travers des pairs au hasard, il utilise un réseau structuré pour la propagation. Moins de trafic dupliqué, plus de livraisons prévisibles.
Ça ne fera peut-être pas un super visuel marketing.
Mais quand un réseau devient chargé, la bande passante gaspillée devient très concrète.
Puis vient la partie que les gens passent généralement sous silence :
la confidentialité a un coût en calcul.
Les preuves à connaissance zéro, c’est un travail réel. On peut avoir un consensus rapide et quand même se heurter à un mur si la génération des preuves devient le goulot d’étranglement.
Donc je ne pense pas que la vraie question de scalabilité de DUSK soit :
« Est-ce qu’il peut traiter un très grand nombre de transactions ? »
C’est plutôt :
Que se passe-t-il quand ces transactions deviennent coûteuses ?
La finalité peut-elle rester prévisible ?
Les nœuds peuvent-ils suivre ?
Les transactions privées peuvent-elles coexister avec l’activité normale des smart-contracts ?
C’est le test le plus difficile.
Et franchement, les petites décisions d’ingénierie me donnent plus d’informations que les grands chiffres.
Comment les données circulent. Comment l’état est accédé. Comment les nœuds se synchronisent. Comment les preuves sont produites. Comment l’exécution est séparée du règlement.
Rien de tout cela ne semble passionnant.
Mais c’est généralement là que se trouve la vraie scalabilité.
Une chaîne durable n’est pas une chaîne où chaque composant est ridiculement rapide.
C’est une chaîne où le travail coûteux sait rester à sa place.
C’est la partie de DUSK que je continue de surveiller.
#dusk $DUSK @Dusk
