J’ai relu la documentation de Dusk ( @Dusk ) hier soir, et plus j’entrais dans les mécanismes de consensus, plus les cas d’échec devenaient passionnants.
Au début, le mode d’urgence ressemblait à une simple sauvegarde. Mais pourquoi Dusk en a-t-il besoin si le protocole normal peut déjà réessayer les itérations qui ont échoué ? La documentation explique qu’après des échecs répétés, le protocole peut maintenir des itérations ouvertes jusqu’à ce que le consensus aboutisse. Cela me pousse à me demander dans quelle mesure la vivacité est privilégiée au détriment de l’efficacité en cas de conditions réseau extrêmes.
Ensuite, il y a la question des forks. Comment deux blocs candidats peuvent-ils parvenir à un consensus dans le même tour ? Dusk utilise des numéros d’itération et un mécanisme de repli pour résoudre cela, mais un bloc dont l’itération est plus élevée peut quand même être révoqué. Pour le règlement financier, cette distinction semble importante.
J’ai aussi remarqué la structure de récompense. Les generateurs reçoivent la plus grande partie de la récompense de bloc, tandis que les votants reçoivent une part distincte. Cela m’a paru plus clair quand j’ai considéré le problème d’incitation : qu’est-ce qui empêche un futur générateur de profiter du système quand des itérations antérieures échouent ?
Le système de fautes ajoute une couche supplémentaire. Pourquoi séparer les fautes mineures des fautes majeures ? La suspension et le soft slashing semblent conçus différemment du hard slashing pour des comportements graves comme le double vote ou des blocs invalides.
Enfin, Moonlight et Phoenix m’ont fait reconsidérer la couche de transactions. Pourquoi maintenir à la fois un modèle transparent basé sur des comptes et un modèle de confidentialité basé sur les UTXO ?
Cette double conception crée-t-elle une flexibilité utile, ou une complexité supplémentaire ? Et à mesure que Dusk grandit, où la décentralisation et la sécurité pourraient-elles devenir plus difficiles à préserver ?
@Dusk_Foundation #dusk $DUSK
Au début, le mode d’urgence ressemblait à une simple sauvegarde. Mais pourquoi Dusk en a-t-il besoin si le protocole normal peut déjà réessayer les itérations qui ont échoué ? La documentation explique qu’après des échecs répétés, le protocole peut maintenir des itérations ouvertes jusqu’à ce que le consensus aboutisse. Cela me pousse à me demander dans quelle mesure la vivacité est privilégiée au détriment de l’efficacité en cas de conditions réseau extrêmes.
Ensuite, il y a la question des forks. Comment deux blocs candidats peuvent-ils parvenir à un consensus dans le même tour ? Dusk utilise des numéros d’itération et un mécanisme de repli pour résoudre cela, mais un bloc dont l’itération est plus élevée peut quand même être révoqué. Pour le règlement financier, cette distinction semble importante.
J’ai aussi remarqué la structure de récompense. Les generateurs reçoivent la plus grande partie de la récompense de bloc, tandis que les votants reçoivent une part distincte. Cela m’a paru plus clair quand j’ai considéré le problème d’incitation : qu’est-ce qui empêche un futur générateur de profiter du système quand des itérations antérieures échouent ?
Le système de fautes ajoute une couche supplémentaire. Pourquoi séparer les fautes mineures des fautes majeures ? La suspension et le soft slashing semblent conçus différemment du hard slashing pour des comportements graves comme le double vote ou des blocs invalides.
Enfin, Moonlight et Phoenix m’ont fait reconsidérer la couche de transactions. Pourquoi maintenir à la fois un modèle transparent basé sur des comptes et un modèle de confidentialité basé sur les UTXO ?
Cette double conception crée-t-elle une flexibilité utile, ou une complexité supplémentaire ? Et à mesure que Dusk grandit, où la décentralisation et la sécurité pourraient-elles devenir plus difficiles à préserver ?
@Dusk_Foundation #dusk $DUSK