Des amis courent après Dusk et me demandent : il a des sorties de bloc manquées en série par son nœud, il a été pénalisé—est-ce que ça compte comme de la malveillance ? Au début, je pensais que la pénalité est la pénalité : dans l’approche de Cosmos, le double-sig prive directement de droits et ferme la porte aux “petits noirs”, il n’y a pas grand-chose à discuter.
Puis j’ai regardé le mécanisme de pénalités de Dusk : il y en a deux. Soft Slashing, la pénalité “douce”, gère les erreurs non malveillantes, par exemple lorsque le nœud est hors ligne au moment où il devait proposer un bloc, ou ne diffuse pas dans la fenêtre prévue—rien de malicieux, juste un problème d’exploitation. La pénalité est, à chaque série d’infractions consécutives, de N fois 10 % de l’actif mis en garantie (N correspondant au nombre de violations consécutives), et elle expulse le nœud du consensus pour N epochs. Un epoch est la période de consensus de Dusk ; à la fin de chaque round, l’ensemble des validateurs est renouvelé. Les DUSK retirés ne sont pas détruits : ils sont transférés hors des garanties actives, et le nœud peut les récupérer.
Hard Slashing, la pénalité “dure”, concerne les comportements malveillants. Les blocs invalides coûtent 10 % du collatéral et sont détruits ; les doubles votes ou les doubles propositions coûtent 20 % et sont détruits. “Détruit” veut dire que c’est vraiment perdu : ce n’est pas juste mis de côté puis restitué.
Je n’avais pas compris pourquoi on distingue deux cas. En relisant la documentation, j’ai compris la partie sur l’imputabilité. Si un nœud rate un bloc à cause d’une fluctuation réseau, tu appliques quand même une pénalité lourde ; les validateurs vont placer ces nœuds les plus “chers” sur le cloud, et les coûts d’exploitation augmentent—au final, la décentralisation s’en trouve même dégradée. Le Soft Slashing sert à pousser les nœuds peu fiables hors de l’ensemble actif tout en leur laissant une chance de revenir : à chaque fois on retire une petite part, sans réduire à la faillite ceux qui exploitent honnêtement.
Ce qui a vraiment changé mon avis, c’est le paramètre N. Plus les violations consécutives sont nombreuses, plus la pénalité est grande et plus la durée d’expulsion est longue. Première coupure : 10 % retirés et 1 epoch en moins. Deuxième fois : 20 % retirés et 2 epochs en moins. Pression exponentielle : soit le nœud revient stable, soit il quitte automatiquement. Le Hard Slashing reste réservé aux actes clairement malveillants : une seule fois, destruction, pas de fenêtre de récupération.
Prenons Polkadot en exemple. Son Slashing est aussi gradué, mais les proportions sont plus fines : de 0,1 % à 100 %, et l’amende est partagée avec le dénonciateur. La logique de Dusk est plus simple : soit erreur, soit malveillance ; le ratio est fixe ; la destruction ne récompense pas le dénonciateur. L’avantage, c’est que les validateurs peuvent prédire le coût d’une erreur et n’hésitent pas à faire tourner un nœud.
Mon ami, après ça, a dit qu’il accepte la fois Soft Slashing : chez lui, le réseau était tombé pendant une demi-heure. Et là aussi, je comprends pourquoi Dusk sépare autant les mécanismes : sans pénalités graduées, les nœuds honnêtes et les nœuds malveillants seraient traités pareil #dusk $DUSK @Dusk
J’ai récemment mené des tests parallèles de plusieurs flux de transactions en comptant différents comptes sur Dusk. Je pensais au départ que les chaînes de confidentialité traitaient principalement le chiffrement et l’anonymat. Puis j’ai fait tourner ensemble des transactions provenant de comptes EVM transparents et de comptes ZK privés, et j’ai compris que le vrai problème n’est pas tant la manière de chiffrer, mais plutôt la façon d’assurer la validation sans divulguer le texte en clair lorsque deux transactions « légitimes » sont simultanément incluses dans la blockchain. J’avais l’impression auparavant qu’il suffisait que les preuves de confidentialité soient valides ; aujourd’hui, je pense de plus en plus que la gestion des conflits de transactions parallèles est le défi central pour une mise en œuvre durable.
C’est un peu comme deux voies de circulation parallèles dans un centre commercial. Vu séparément, les règles de circulation de chaque voie ne posent pas de problème, mais si les règles de changement de voie des véhicules entre les voies adjacentes ne sont pas cohérentes, toute la route se bloque, voire provoque des collisions. Dans les réseaux de transactions confidentielles, c’est pareil : la preuve correcte d’une transaction ZK isolée ne signifie pas que, après soumission en parallèle de plusieurs transactions, l’état sur la chaîne reste cohérent.
Dusk combine, de manière essentielle, le modèle d’UTXO de confidentialité Phoenix, la couche EVM transparente Moonlight, le module de preuves de tarification Citadel et le mécanisme de divulgation ciblée VEP. En substance, cela permet aux utilisateurs de choisir eux-mêmes le niveau de confidentialité de leurs transactions. L’avantage est évident : les utilisateurs ordinaires peuvent protéger la trajectoire de leurs actifs avec des comptes privés, tandis que les utilisateurs institutionnels peuvent effectuer des règlements conformes avec des comptes transparents, sans être limités par un seul mode de confidentialité. Mais un problème apparaît aussi : si une transaction de confidentialité doit appeler une adresse de contrat transparente, et qu’une autre transaction transparente doit lire le solde d’un compte de confidentialité, comment les nœuds peuvent-ils synchroniser l’état sans divulguer le texte en clair ? Dans le passé, beaucoup de chaînes de confidentialité n’avaient pas ce problème, car elles étaient soit entièrement anonymes, soit entièrement transparentes ; il n’existait donc pas de double mode en exécution parallèle.
Ce que je vois maintenant comme compromis (trade-off) est très clair. En augmentant la flexibilité de la confidentialité, la complexité de la validation d’état augmente aussi ; plus il y a de comptes en double mode, plus le coût de génération des preuves ZK est élevé ; et lorsque les transactions inter-couches deviennent fréquentes, les frontières entre le comptage du Gas et l’audit/la traçabilité peuvent devenir floues. Le délai des transactions inter-couches, le taux d’échec de validation des preuves et le temps de vérification de la divulgation ciblée pourraient refléter plus fidèlement la maturité de la mise en œuvre d’une blockchain de confidentialité que le TPS.
À l’avenir, je continuerai à observer les données de transactions inter-couches sur le testnet, les historiques officiels de correctifs liés aux conflits, ainsi que la manière dont les nœuds gèrent les transactions parallèles en double mode. #dusk $DUSK @Dusk
Le week-end, je me suis planqué dans le café juste en bas pour piquer un peu de clim pendant que je testais le réseau Dusk. Après trois essais ratés de suite avec le mauvais mot de passe, j’ai fini par enchaîner au bout d’une demi-heure la 21e transaction. J’ai longtemps fixé les journaux d’exécution de la machine virtuelle Rusk—auparavant j’avais joué avec quelques anciennes chaînes de confidentialité : soit ça bloquait une demi-journée avant de produire un bloc, soit l’anonymat était fait jusqu’au bout de façon à rendre impossible l’ouverture d’autorisations d’audit en conformité. Au départ, je n’attendais plus grand-chose de ce qu’on appelle une « blockchain de confidentialité », mais c’est en personne que j’ai été piégé : en fait, ce n’est pas juste une coque pour vendre un concept.
Au tout début, quand j’ai été chargé du consensus SBA, j’ai d’abord pensé à un PoS “relooké”. En parcourant les règles des nœuds et en faisant tourner dix mille simulations de double-spend, j’ai compris : SBA (Segregated Byzantine Agreement, accord byzantin isolé) répartit les nœuds en deux couches. Une couche s’occupe de produire les blocs et d’assembler les transactions via un comité, l’autre couche contient des valideurs qui font des audits aléatoires en vérification. La graine de l’audit aléatoire est générée par une VDF (fonction de délai vérifiable) : personne ne peut prédire à l’avance qui sera contrôlé. Le navigateur du testnet indiquait qu’il y avait 3 nœuds pénalisés pour avoir soumis des blocs invalides, avec confiscation de garantie. Deux d’entre eux ont subi une pénalité “douce” : ils ont manqué quelques blocs, ont été temporairement retirés de la file du consensus, et leur montant de dépôt effectif a été amputé. Le troisième a subi une pénalité “dure” : double signature démasquée, les jetons déposés ont été directement réduits de 20% puis détruits. Ce type de mécanisme de sanction fait fortement grimper le coût de la mauvaise conduite, et rend l’essai/erreur extrêmement cher.
Lors des tests de transaction, j’ai glissé d’un zéro en trop : le montant est sorti directement de la plage autorisée par le Range Proof. La transaction a été rejetée instantanément, et sur la chaîne il n’est même resté aucune trace de transaction “inutile”. Le protocole Phoenix verrouille fermement la plage des montants avec le Range Proof, et combiné aux engagements de Pedersen qui figent le total des actifs de chaque opération, aucune émission “à partir de rien” n’est possible. En plus, avec une Stealth Address à usage unique qui se renouvelle automatiquement pour chaque transaction, j’ai pu envoyer 5 fois des jetons de test : sur la chaîne, il est pratiquement impossible de relier ces 5 transferts au même compte. Les preuves PLONK d’agrégation récursive sont compressées à 287 octets : la vérification d’une transaction ne prend que 1,8 milliseconde. En pratique, c’est très fluide, et même pendant les heures de pointe du testnet, je n’ai pas rencontré d’engorgement.
La machine virtuelle Rusk a été écrite en Rust de zéro, et supporte nativement la norme d’actifs confidentiels. Pour déployer mon Token de test, je n’ai même pas eu besoin d’écrire plus de 200 lignes de code de confidentialité : le coût en Gas des contrats est inférieur de 63% par rapport à l’EVM lorsqu’on y ajoute une couche ZK. Et elle ménage aussi une porte d’entrée pour les audits côté conformité—confidentialité et conformité n’ont donc pas besoin de s’exclure mutuellement, on peut les avoir ensemble. La nuit où le testnet a tourné jusqu’au bout, j’étais bien plus serein que lors de tout projet auquel j’avais participé auparavant. #dusk $DUSK @Dusk