Le correctif qui décide de l'histoire de Ravencoin n'a pas été écrit par Ravencoin

Une transaction confirmée est censée être un fait acquis. C'est la promesse de départ, celle qui sépare un registre distribué d'une écriture comptable qu'on peut rappeler. Elle vient d'encaisser deux démentis en cinq jours, et le plus instructif des deux ne tient pas à la faille exploitée. Il tient à l'identité de celui qui a tranché : deux opérateurs de minage ont réécrit trois jours de transactions, sans que l'équipe du protocole soit dans la boucle.

Un champ jamais confronté à la réalité

Le défaut de Ravencoin est logé dans la validation de l'en-tête de bloc. Le champ nHeight, qui déclare la position du bloc dans la chaîne, n'était pas confronté à sa position réelle. Ce champ n'a rien de décoratif : il alimente le hachage de preuve de travail et sélectionne l'époque du DAG. Un bloc pouvait donc se déclarer sous le dernier point de contrôle depuis n'importe quelle position, emprunter le chemin de validation allégé que le logiciel réserve à l'historique ancien, et se faire accepter sans avoir fourni le moindre travail de minage. Produire un tel bloc revient à une recherche de hachage ordinaire, sans l'étape gourmande en mémoire qui fait tout le coût du minage honnête.

La borne est datée. L'avis réseau publié par le compte officiel du projet situe le premier bloc invalide connu à la hauteur 4 487 776, miné le 7 août 2026 à 15h44 UTC. N'importe qui peut le vérifier sur un explorateur, ce qui est exactement l'intérêt d'une borne publiée. L'ampleur, elle, vient d'un relevé de réseau principal : 96 blocs affectés sur 2 089 examinés entre les hauteurs 4 489 527 et 4 491 615. Ce n'est pas une extrapolation. C'est un échantillon qui dit ce qu'il a regardé, et sur quelle plage.

Le correctif vient du pool, pas du projet

C'est ici que l'incident cesse d'être une affaire de code. Le correctif d'urgence 4.6.1.1-hf1 a été publié le 10 août par 2Miners, un pool de minage. Sa note de version l'écrit sans détour : le développement amont est inactif, aucun correctif n'a été publié, et le pool a pris la décision d'en livrer un lui-même.

Le dépôt officiel du projet, consulté le 14 août 2026, ne dit pas autre chose. La dernière version publiée y remonte à août 2022, suivie d'un instantané en juin 2026 ; le commit du 10 août sur la branche de développement corrige un dépassement sur les transferts d'actifs, pas la validation de hauteur d'en-tête. Le pool a d'ailleurs enchaîné le 11 août avec une version 4.8.0 qui remplace la précédente et récupère au passage ce correctif amont. Deux surfaces indépendantes, une même chronologie.

Le patch fait deux choses. Il rejette les blocs dont la hauteur déclarée ne correspond pas à leur position réelle, à partir de 4 487 776. Et il pose un point de contrôle au bloc 4 487 775, le dernier bloc sain. Depuis ce point, 2Miners et RavenMiner minent une chaîne qui ne contient pas les blocs forgés. Les deux pools totalisent la majorité de la puissance de calcul du réseau.

Autrement dit, deux acteurs privés ont écrit la règle, l'ont appliquée à leurs propres machines, et détiennent le hashrate qui décidera laquelle des deux chaînes l'emporte. Aucun vote de détenteurs, aucune procédure écrite d'avance, aucun organe du projet dans la boucle. Le RVN a reculé d'environ 19 % le 11 août, autour de 0,00288 dollar pour une capitalisation proche de 47,3 millions de dollars ; Upbit et Bitget avaient suspendu dépôts et retraits dès la veille.

Un point de contrôle et une réorganisation ne sont pas le même événement

Le mot rollback recouvre ici deux opérations de nature différente, et les confondre change la lecture du risque.

Un point de contrôle verrouille l'amont. Le logiciel refuse toute chaîne qui ne passerait pas par un bloc donné. Rien n'est effacé, l'historique antérieur est simplement figé. C'est ce que fait la version 4.6.1.1-hf1, et cette mesure ne coûte rien à un utilisateur ordinaire.

Une réorganisation, elle, efface. Si la chaîne de récupération devient dominante, le projet annonce une réorganisation profonde d'environ trois jours. Tout ce qui a été confirmé après le bloc 4 487 775 sort alors de l'historique retenu. Le projet précise que certaines transactions pourraient revenir en mémoire tampon et être minées de nouveau, mais il écrit lui-même que ce retour n'est « pas garanti ». La nuance n'est pas rhétorique : un détenteur qui a reçu un paiement le 9 août n'a aucune assurance de le retrouver, et il n'a rien fait d'autre que d'utiliser le réseau normalement. Le coût de la réparation est transféré à des utilisateurs qui n'ont ni causé la faille ni participé à la décision.

Harmony, même question, autre levier

Le 12 août, Harmony annonce une émission non autorisée d'environ 4 milliards de ONE, près de 27 % de l'offre en circulation antérieure. Le pont est suspendu, un correctif validateur bloque toute émission supplémentaire, et le traçage de l'équipe compte 409 portefeuilles destinataires, environ 2,8 milliards de ONE routés vers des plateformes d'échange, et de l'ordre de 115 millions restant vendables sur la chaîne.

Le rollback, lui, est à l'instruction. Le message publié par le compte officiel de l'équipe est explicite : elle travaille avec les plateformes concernées pour arrêter et geler les fonds, et travaille sur un correctif et des options de rollback. Rien n'est exécuté à ce stade. C'est précisément ce qui rend le cas lisible. La capacité d'Harmony à annuler dépend de deux ressources qu'elle ne détient pas : l'alignement de ses validateurs, et le gel décidé par des plateformes centralisées. Au moment où le gel a été demandé, la quasi-totalité des tokens émis avait déjà rejoint des adresses de dépôt de plateformes ou avait été vendue.

Deux incidents, deux leviers, une même réponse à la question de savoir qui peut défaire un historique. Ni les détenteurs, ni les équipes de développement. Ceux qui concentrent la puissance de calcul d'un côté, la liquidité de l'autre.

Le précédent de référence reste la scission d'Ethereum en 2016 après The DAO, précédée d'un vote de détenteurs et suivie d'une chaîne dissidente durable. Rien de tel ici, dans un sens comme dans l'autre. Ravencoin avait déjà connu une émission frauduleuse en 2020, corrigée en quelques jours par un durcissement appliqué à une hauteur donnée : la maintenance du client a changé depuis, le mode de décision non.

La faille d'entropie qui a vidé des portefeuilles Coldcard début août racontait déjà ce déplacement : un fait technique daté suffit à retourner une promesse fondatrice, et la promesse ne tient que là où quelqu'un a les moyens de la tenir. Le piège, pour le lecteur, serait de croire que cela ne concerne que des chaînes de petite taille. Le mécanisme de décision décrit ici est le même partout. Seule change la concentration, et avec elle le nombre d'acteurs qu'il faut réunir pour effacer trois jours.

Reste la question que ni Ravencoin ni Harmony n'avaient écrite avant leur incident : jusqu'à quelle profondeur, et sur décision de qui, un historique peut-il être défait.

Questions fréquentes

Combien de temps d'historique Ravencoin peut-il disparaître ?
Environ trois jours. Le chiffre est celui annoncé par le projet lui-même, et il reste conditionné au fait que la chaîne de récupération minée par 2Miners et RavenMiner devienne la chaîne dominante. Tant que ce n'est pas le cas, rien n'est effacé.

Qui a publié le correctif Ravencoin ?
Le pool de minage 2Miners, avec la version 4.6.1.1-hf1 du 10 août 2026, remplacée dès le 11 août par une version 4.8.0. La note de version indique que le développement amont est inactif et qu'aucun correctif n'avait été publié de ce côté. Le correctif du client officiel reste en attente.

Une transaction annulée par une réorganisation est-elle rejouée automatiquement ?
Non. Le projet indique que certaines transactions pourraient revenir en mémoire tampon et être minées de nouveau, tout en écrivant que ce retour n'est pas garanti. Un paiement confirmé après le bloc 4 487 775 doit donc être considéré comme réversible tant que la situation n'est pas stabilisée.

Le rollback Harmony a-t-il eu lieu ?
Non. Au 14 août 2026, il est à l'instruction : l'équipe le présente comme une option travaillée avec ses validateurs et avec les plateformes d'échange, aux côtés du gel des fonds et de la suspension du pont. Aucune opération d'effacement n'a été exécutée à cette date.