Je suis retourné(e) dans la documentation de Dusk hier soir et je me suis concentré(e) sur quelque chose que j’avais laissé de côté auparavant : qui a réellement le droit de participer au consensus, et comment les transactions prouvent qu’elles sont valides.
Un provisioner est, en gros, quelqu’un qui bloque DUSK en tant qu’enjeu (stake). La documentation décrit actuellement un minimum de 1 000 DUSK, mais le fait de miser (staking) ne rend pas immédiatement un compte éligible au consensus.
Les nouveaux enjeux doivent passer une période de maturité et ne deviennent éligibles qu’au début d’un epoch. Comme les epochs sont actuellement fixés à 2 160 blocs, cela crée un délai volontaire avant que le nouvel enjeu ajouté puisse influencer le processus de consensus.
Cela m’a amené à réfléchir au compromis entre décentralisation.
Cette période de maturité pourrait-elle contribuer à réduire les changements soudains dans l’ensemble actif des validateurs, tout en rendant plus difficile pour de nouveaux participants d’acquérir immédiatement de l’influence ? Et si l’enjeu se concentre entre les mains de détenteurs plus importants, comment cela affecte-t-il la répartition concrète de la puissance de consensus ?
Ensuite, j’ai examiné la validation des transactions.
Moonlight utilise des états de compte publics et des signatures pour prouver la propriété, tandis que Phoenix peut utiliser des preuves à connaissance zéro pour masquer l’information de transaction tout en prouvant que les conditions requises sont satisfaites.
C’est à cet endroit que ma compréhension a changé. La confidentialité ici ne se limite pas à « cacher des transactions ». Le réseau doit encore vérifier la propriété, les soldes, empêcher la double dépense et protéger l’intégrité des transactions. La question intéressante est de savoir quelle quantité d’information peut être dissimulée sans affaiblir ces garanties.
La finalité incrémentielle (rolling finality) ajoute une autre couche. À mesure que davantage de provisioners s’appuient sur un bloc, la confiance dans ce bloc augmente, ce qui rend plus difficile la progression d’un fork concurrent.
Mais je reste curieux : comment cela se comporte-t-il en cas de forte concentration d’enjeu ou de perturbation prolongée du réseau ? Et qu’en pense la communauté : le plus gros défi pour Dusk, c’est de préserver la confidentialité, ou de préserver le consensus décentralisé à mesure que la participation augmente ?
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
Un provisioner est, en gros, quelqu’un qui bloque DUSK en tant qu’enjeu (stake). La documentation décrit actuellement un minimum de 1 000 DUSK, mais le fait de miser (staking) ne rend pas immédiatement un compte éligible au consensus.
Les nouveaux enjeux doivent passer une période de maturité et ne deviennent éligibles qu’au début d’un epoch. Comme les epochs sont actuellement fixés à 2 160 blocs, cela crée un délai volontaire avant que le nouvel enjeu ajouté puisse influencer le processus de consensus.
Cela m’a amené à réfléchir au compromis entre décentralisation.
Cette période de maturité pourrait-elle contribuer à réduire les changements soudains dans l’ensemble actif des validateurs, tout en rendant plus difficile pour de nouveaux participants d’acquérir immédiatement de l’influence ? Et si l’enjeu se concentre entre les mains de détenteurs plus importants, comment cela affecte-t-il la répartition concrète de la puissance de consensus ?
Ensuite, j’ai examiné la validation des transactions.
Moonlight utilise des états de compte publics et des signatures pour prouver la propriété, tandis que Phoenix peut utiliser des preuves à connaissance zéro pour masquer l’information de transaction tout en prouvant que les conditions requises sont satisfaites.
C’est à cet endroit que ma compréhension a changé. La confidentialité ici ne se limite pas à « cacher des transactions ». Le réseau doit encore vérifier la propriété, les soldes, empêcher la double dépense et protéger l’intégrité des transactions. La question intéressante est de savoir quelle quantité d’information peut être dissimulée sans affaiblir ces garanties.
La finalité incrémentielle (rolling finality) ajoute une autre couche. À mesure que davantage de provisioners s’appuient sur un bloc, la confiance dans ce bloc augmente, ce qui rend plus difficile la progression d’un fork concurrent.
Mais je reste curieux : comment cela se comporte-t-il en cas de forte concentration d’enjeu ou de perturbation prolongée du réseau ? Et qu’en pense la communauté : le plus gros défi pour Dusk, c’est de préserver la confidentialité, ou de préserver le consensus décentralisé à mesure que la participation augmente ?
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
