Exploitation de Pirate Chain : Comment 39,8 millions d'ARRR ont été créés et la blockchain a été annulée

La cryptomonnaie Pirate Chain se présente comme une monnaie axée sur la vie privée, garantissant l'anonymat complet et des restrictions d'offre. Toutes les transactions sur le réseau sont protégées dès le départ, et il existe une limite absolue sur le nombre de pièces, qui s'élève à 200 millions d'ARRR. Les personnes souhaitant garder leurs transactions secrètes et assurer leur stabilité financière se sont senties attirées par elle.

Cependant, cet équilibre délicat a été perturbé le 14 octobre 2026. L'exploiteur a découvert deux vulnérabilités dans le code et les a utilisées pour créer environ 39,82 millions de pièces ARRR de rien du tout. Cet événement inattendu a entraîné une augmentation de 20 % de l'offre en circulation. En moins de quelques jours, tous les membres de la communauté, les mineurs, les plateformes d'échange et les notaires se sont unis pour annuler complètement la chaîne.

Cet article décrit ce qui s'est mal passé, le mécanisme de la collision de bugs, pourquoi les pièces ont disparu si rapidement dans le pool de confidentialité, pourquoi le réseau a dû revenir en arrière dans le temps, et quelles actions chaque utilisateur et mineur devait entreprendre ensuite. Le lecteur obtient une compréhension claire du problème technologique, de ses conséquences et de l'expérience pratique pour le détenteur de pièces de confidentialité.

Pirate Chain est une cryptomonnaie axée sur la confidentialité dont les transferts ont été conçus à l’aide du protocole à connaissance nulle. Il convient de noter que, contrairement à d’autres systèmes qui offrent aux utilisateurs soit un mode transparent, soit un mode privé, Pirate Chain intègre une fonction de masquage obligatoire. Il devient presque impossible de tracer les graphiques de transactions et les soldes. À l’inverse, Pirate Chain a fixé un plafond de 200 millions d’ARRR. Il n’existe aucun autre moyen d’introduire de nouvelles pièces en circulation que le processus d’exploitation minière.

Le réseau a mis en œuvre une mise à jour appelée Ironwood au début d'octobre 2026. Celle-ci incluait le développement d'une couche de comptage appelée le tourniquet, visant à compter avec précision les pièces passant des zones transparentes aux zones protégées. Toutefois, après douze jours, le 14 octobre, une attaque a été détectée par un individu qui a identifié une vulnérabilité permettant de contourner simultanément deux vérifications dans le code de validation. L'une de ces vérifications était chargée de garantir la création d'un nombre limité de pièces. L'autre contrôlait la manière dont le logiciel lisait les scripts de sortie. Lorsque les deux ont échoué ensemble, le logiciel a accepté une transaction qui a créé 39,82 millions de faux ARRR dans le pool de coinbase transparent.

L'attaquant n'est pas resté là. L'attaquant a transféré les jetons nouvellement créés dans le pool protégé Sapling presque immédiatement. Dès que les pièces ont été transférées dans ce pool, les suivre est devenu une tâche difficile. Le transfert protégé rend intentionnellement impossible la connaissance des montants et des adresses, rendant tout mouvement ultérieur impossible à tracer de la même manière que ce qui est fait avec les Explorateurs de blockchain. Il est clair que les explications officielles ont indiqué que la cryptographie à connaissance nulle et les clés de notaire preuve de travail utilisées étaient sûres. La faille n'était qu'un problème d'implémentation au sein du logiciel du nœud.

La validation des transactions agit comme le gardien silencieux de tout réseau blockchain. Chaque nœud examine toutes les transactions entrantes, les vérifie selon un ensemble de critères, puis permet leur inclusion dans un bloc. Dans le cas de Pirate Chain, ces critères impliquent des restrictions sur la création de pièces et un scripting approprié. Dans ce cas, deux bugs indépendants se sont alignés.

La première faille : Contourner la limite de création

La première faille a permis d'ignorer la limite de création. Le protocole est conçu de manière à ce que l'offre totale ne puisse jamais dépasser le plafond de 200 millions en conditions normales. Chaque nouvelle pièce devrait passer une vérification stricte comparant l'émission proposée au reste de la marge disponible sous ce plafond strict. 

Le chemin de code défectueux n'a tout simplement pas appliqué ce plafond pour la transaction fabriquée. En conséquence, le logiciel du nœud a accepté une transaction qui créait bien plus de pièces que les règles ne le permettaient. Cette unique défaillance a ouvert la porte, mais elle n'était pas suffisante en soi.

La deuxième faille : Mauvaise interprétation des scripts de sortie

Le deuxième bug impliquait une mauvaise interprétation des scripts de sortie. Les scripts de sortie indiquent au réseau où les pièces nouvellement créées peuvent être envoyées et dans quelles conditions elles peuvent être dépensées. En raison d'une mauvaise interprétation des scripts par le logiciel, il a traité une sortie invalide ou spécialement formée comme légitime. 

En bref, le processus de vérification a examiné les données de transaction en utilisant une logique d'analyse incorrecte et a conclu que tout était normal malgré les erreurs. L'effet combiné des deux problèmes a permis à l'attaquant de créer de nombreuses nouvelles pièces à l'aide d'une transaction simple.

De la mint transparente au pool masqué

Les pièces sont apparues pour la première fois dans le pool transparent, ce qui a rendu l'inflation visible sur la blockchain pendant une courte période. Toute personne surveillant la blockchain pouvait voir le saut soudain de l'offre. Ensuite, elles ont été transférées vers Sapling. 

Une telle décision était double. Tout d'abord, il serait difficile de surveiller en temps réel l'approvisionnement entrant. Deuxièmement, les chances que les jetons soient gelés par la plateforme d'échange ou un autre système de surveillance seraient faibles jusqu'à ce qu'ils se mélangent aux autres approvisionnements protégés. Après avoir entré le pool Sapling, toutes les transactions sont cachées.

Étapes de containment précoces

Une plateforme d'échange sans KYC, NonKYC, a observé une activité de dépôt inhabituelle liée à la création et a rapidement restreint les comptes concernés, bloquant les retraits.

Cette action a limité la quantité de monnaie contrefaite pouvant quitter le réseau via des plateformes centralisées. La réaction rapide de la plateforme d'échange a gagné un temps précieux tandis que la communauté plus large évaluait les dégâts.

Pourquoi une pause coordonnée était nécessaire

Étant donné que Pirate Chain est décentralisée, aucune partie unique ne peut geler l'ensemble du réseau ou réécrire l'historique seule. Les déclarations initiales du projet ont rendu ce point clair. Le projet a demandé aux utilisateurs d'arrêter de déplacer des fonds. Les pools de minage et les services de preuve de travail différée ont arrêté volontairement leurs activités de notarisation. Les plateformes d'échange ont suspendu les dépôts et retraits des jetons ARRR. Ces mesures ont permis de gagner du temps pour élaborer une stratégie afin de résoudre le problème. Sinon, il aurait été extrêmement difficile de récupérer les jetons perdus.

La combinaison des deux erreurs de validation a transformé deux erreurs d'implémentation en une inflation temporaire de 20 % de l'offre. La mise en place suivante dans le pool protégé, les mouvements rapides de la part d'une plateforme d'échange et les arrêts volontaires sur l'ensemble du réseau ont préparé le prochain grand mouvement : le rollback de la chaîne jusqu'au dernier bloc valide et l'obligation pour toutes les parties de mettre à jour leur logiciel.

Après la découverte initiale, l'équipe de développement et la communauté ont examiné les options. Laisser les pièces supplémentaires en circulation diluerait de manière permanente la part de chaque détenteur existant des 200 millions d'unités en circulation. Geler uniquement les pièces de l'attaquant était impraticable une fois que les jetons avaient pénétré dans le pool protégé. La voie retenue a été un rollback complet de la chaîne en direct jusqu'à l'état précédent connu comme bon, avant l'exploit.

L'état en question était le bloc 4 176 944, miné vers 19:55:14 UTC le 14 octobre. Tous les blocs ultérieurs ont été rejetés par le réseau, ainsi que la transaction ayant créé l'exploit et toute activité ultérieure, légale ou illégale. Il a été nécessaire d'obtenir un consensus entre les opérateurs de nœuds, les pools de minage, les plateformes d'échange et les notaires dPoW qui constituent la couche secondaire de consensus.

Une mise à jour logicielle obligatoire, version 6.0.14, a rendu ce changement permanent. Les nœuds exécutant la nouvelle version rejettent automatiquement le bloc d'exploitation et tous les blocs construits dessus. Les notaires dPoW ont accepté de reprendre la notarisation uniquement de la chaîne corrigée. Les versions antérieures du logiciel ont été jugées incompatibles ; les utiliser reviendrait à vivre sur une branche que personne ne soutient ou ne notarise plus.

Lorsqu’un nœud démarre pour la première fois la version 6.0.14, il effectue automatiquement un réindexage complet de la blockchain. Le réindexage reconstruit la vue locale de l’historique selon les nouvelles règles de consensus, puis réanalyse les wallets afin que les soldes protégés correspondent au registre restauré. Les utilisateurs ont été invités à laisser le processus se terminer sans interruption et ont reçu une option de démarrage rapide pour accélérer la récupération. Après la mise à niveau et le réindexage, l’offre est revenue à son niveau antérieur à l’attaque, et le plafond de 200 millions est resté en vigueur. Aucun dommage économique permanent pour les détenteurs légitimes n’a été signalé une fois les fausses pièces supprimées.

The Pirate Chain fait partie d'une série plus longue de défaillances liées à l'offre sur les réseaux de confidentialité. Étant donné que ces chaînes cachent volontairement une grande quantité d'informations, les bugs d'émission peuvent être plus difficiles à détecter en temps réel que des problèmes similaires sur des registres transparents. La mise à jour Ironwood avait introduit une nouvelle logique comptable quelques jours plus tôt. Cette courte fenêtre entre l'activation et l'exploitation montre que même un code soigneusement revu peut cacher des cas limites qui n'apparaissent que dans des conditions adverses.

Dans le même temps, la réaction rapide de la communauté a démontré des atouts que les systèmes entièrement centralisés n'ont pas. Aucun administrateur unique n'aurait pu ordonner le rollback. Les opérateurs indépendants ont dû s'accorder. Sa création en soi, ainsi que le fait que le correctif logiciel ait été déployé suffisamment largement pour garantir que seule la blockchain corrigée ait survécu, est significative en soi. Les plateformes d'échange qui ont temporairement suspendu le trading et la seule plateforme d'échange qui a refusé d'accepter davantage de dépôts suspects ont également apporté leur contribution pratique.

Il existe certaines pratiques que les utilisateurs réguliers doivent prendre en compte à la suite de cet incident particulier. Assurez-vous que le logiciel du nœud est toujours à jour. Considérez toujours les mises à jour de logiciels comme des moments à risque élevé et surveillez étroitement les canaux officiels au cours des quelques jours suivants. Si un projet demande à ses détenteurs de jetons de ne pas déplacer leurs jetons, cela ne durera que brièvement afin d’éviter des problèmes supplémentaires pendant la résolution du problème.

Cependant, il subsiste encore certains problèmes même après un rollback réussi. Les transactions effectuées après la hauteur de coupure sont simplement effacées de l’historique de la blockchain. Les utilisateurs ayant effectué des transactions sur la blockchain devront les répéter une fois que la blockchain sera revenue à son état normal. Les mineurs ayant continué à produire des blocs sur la branche abandonnée perdent le travail associé à ces blocs.

Il y a aussi la question à plus long terme de la confiance. Les monnaies de confidentialité sont déjà soumises à une surveillance accrue. Un incident qui augmente temporairement l'offre, même s'il est ensuite corrigé, peut rendre certains détenteurs et de nouveaux utilisateurs potentiels plus prudents. Le post-mortem technique à venir promis par l'équipe sera important. Une explication détaillée de la manière exacte dont les deux vérifications de validation ont échoué, de ce que la couverture des tests a manqué, et des mesures de sécurité supplémentaires ajoutées dans la version 6.0.14 aidera l'écosystème plus large à tirer des enseignements de cet événement.

Les opérateurs de nœuds supportent un coût opérationnel à court terme. Une réindexation complète prend du temps et des ressources disque. Le projet a atténué ce coût en fournissant un bootstrap pré-indexé, mais cette étape reste obligatoire. Toute personne utilisant encore une version ancienne du logiciel est effectivement hors du réseau jusqu'à ce qu'elle mette à jour.

À la fin octobre 2026, la mise à jour obligatoire avait été publiée et le feu vert avait été donné pour reprendre les activités normales une fois la mise à niveau et la ré-indexation terminées. L'intégrité de l'offre avait été rétablie. Le maximum de 200 millions d'ARRR restait inchangé. La cryptographie de confidentialité de base continuait de fonctionner comme prévu. L'épisode se termine donc comme une défaillance contenue plutôt qu'une rupture permanente.

Le point principal à retenir de tout cela est que même les réseaux les plus privés ne peuvent échapper à la nécessité d'une conception logicielle rigoureuse dans les domaines de l'émission et du comptage de pièces. Les couches d'utilisabilité ou d'auditabilité conçues avec la transparence à l'esprit peuvent devenir des vulnérabilités en raison d'une validation insuffisante. L'action coordonnée de la communauté reste l'un des meilleurs mécanismes de défense.

Le point essentiel pour les lecteurs qui suivent les monnaies privées est très simple : surveillez les mises à jour de mise à niveau, restez à jour avec le logiciel et soyez méfiants face à toute demande de suspension temporaire des transactions, car cela peut indiquer qu’un problème majeur est en cours de résolution. Dans le cas de la récupération de Pirate Chain, nous voyons qu’un réseau décentralisé peut résoudre un problème d’émission important lorsqu’il existe un consensus sur la manière de procéder.

Qu'a exactement été créé lors de l'exploitation de Pirate Chain ?

Environ 39,82 millions de jetons ARRR contrefaits ont été créés le 14 octobre 2026 grâce à deux failles de validation. Les nouvelles pièces ont temporairement augmenté l'offre totale d'environ 20 % avant que le rollback ne les supprime.

Les fonctionnalités de confidentialité de Pirate Chain ont-elles été compromises ?

Non. Les déclarations officielles ont confirmé que la cryptographie à preuve nulle et les clés de notaire à preuve de travail différée n'ont jamais été compromises. Le problème était limité au code de validation des transactions.

Pourquoi les fausses pièces sont-elles entrées dans le pool Sapling ?

Déplacer les nouveaux jetons créés dans le pool protégé a rendu les transferts ultérieurs beaucoup plus difficiles à suivre sur les explorateurs publics, réduisant la probabilité que les outils de surveillance ou les plateformes d'échange les gelent rapidement.

Qu'est-ce que le bloc 4 176 944 et pourquoi est-il important ?

Ce bloc marque l'état de la chaîne juste avant la transaction d'exploitation. Le réseau est revenu à cette hauteur, en rejetant tous les blocs suivants, y compris la création.

Tous les utilisateurs doivent-ils passer à la version 6.0.14 ?

Oui. La mise à jour est obligatoire. Les versions antérieures ne sont pas compatibles avec les règles de consensus corrigées. Les nœuds doivent mettre à jour leur logiciel et terminer la réindexation automatique pour rester connectés au réseau en ligne.

La quantité maximale d'ARRR va-t-elle changer ?

Non. Après le rollback, le plafond reste à 200 millions d'ARRR. L'inflation temporaire a été entièrement annulée.

Que devrait faire quelqu’un s’il a envoyé ou reçu ARRR après la fenêtre d’exploitation ?

Ces transactions n'existent plus sur la chaîne restaurée. Ils devront peut-être soumettre à nouveau les mêmes paiements une fois que le réseau sera entièrement stable et que les plateformes d'échange réouvriront les dépôts et retraits.

Un rapport technique complet est-il disponible ?

Le projet a déclaré qu'il publierait un post-mortem détaillé après les mesures de récupération immédiates. Les lecteurs doivent consulter les canaux officiels pour obtenir l'explication technique finale des deux échecs de validation et des modifications de code qui les ont corrigées.

L'incident de Pirate Chain d'octobre 2026 constitue un exemple clair de la manière dont un réseau de confidentialité peut détecter une défaillance d'émission, coordonner une réponse et restaurer ses règles économiques grâce au consensus communautaire et à une mise à jour logicielle soigneusement exécutée. Les fausses pièces ont disparu, le plafond d'offre reste intact et le réseau continue de respecter ses objectifs de conception initiaux.

Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.