La pause d'Orchard a été coordonnée par la distribution d'un binaire volontaire aux principaux pools miniers.
Il n'y avait aucun mécanisme de contrôle dans le code : la suspension dépendait de la décision de trois acteurs.
Le 2 juin 2026, le réseau Zcash a suspendu les transactions dans le pool Orchard en raison d'une vulnérabilité critique détectée dans son circuit de test. Aucune exploitation de la vulnérabilité ni perte de fonds n’a été signalée.
La pause a été exécutée en quelques heures grâce à la coordination entre les développeurs et les pools miniers. Cependant, le mécanisme qui a rendu cela possible a généré un débat technique sur les limites réelles de la décentralisation dans les réseaux de preuve de travail avec hashrate concentré.
Le développeur Jacob Gadikian a expliqué le processus dans X : Zcash Open Development distribué un binaire pour les opérateurs de pools miniers qui ont désactivé les transactions Orchard.
Selon Gadikian, les mineurs n'ont pas été obligés d'exécuter le nouveau logiciel. Chacun a évalué la mise à jour et a décidé l'adopter volontairementmotivé par son intérêt à préserver la viabilité du réseau. Il n'y avait, d'après cette lecture, aucun interrupteur central dans le code ni une désactivation à distance de la piscine.
Toutefois, la rapidité de la coordination n’est pas indépendante de la structure du réseau. Les données MiningPoolStats sur les 1 000 derniers blocs montrent que trois pools – ViaBTC (36 %), Foundry Digital (24 %) et F2Pool (19 %) – concentraient 79 % du hashrate total au moment de l'incident. Cette distribution était celui qui permettait d'exécuter la pause en coordonnant simplement trois acteurs.
L'analyste CyberSatoshi a avancé une lecture contraire à celle de Gadikian dans la résistance à la censure signifie zéro bouton de pause.
Selon CyberSatoshi, appeler les principaux pools le week-end et les amener à arrêter une couche du protocole est fonctionnellement équivalent à un mécanisme de contrôle administratifque les mineurs agissent ou non volontairement.
Décentralisation technique versus décentralisation pratique
Le compte OrangeFren.com a résumé le point central du débat dans X : la panne d'Orchard a été possible car trois pools contrôlent plus de 78% du hashrate. Ce n'est pas un bug dans le code, mais d'une propriété émergente de la répartition réelle de la puissance minière.
Zcash est un réseau de preuve de travail, où les mineurs sont les acteurs qui valident et produisent les blocs. Lorsque le hashrate est concentré entre quelques opérateurs, la capacité de coordonner des modifications urgentes du protocole, qu'il s'agisse de corriger une vulnérabilité ou de toute autre intervention, est laissée entre les mains de ce petit groupe.
Dans ce cas, le caractère volontaire du processus n’élimine pas le fait que le résultat dépendait de la décision de trois acteurs.
L'incident n'a entraîné aucune perte signalée. et Zcash Open Development ont confirmé qu'il n'y avait aucune preuve d'exploitation de la vulnérabilité. Mais, selon la position qui a circulé en X, la facilité avec laquelle la pause a été coordonnée est précisément preuve de centralisation: Dans un réseau véritablement décentralisé, ce niveau de coordination ne serait pas possible à ces heures-là.
Cet incident laisse une question clé : la concentration élevée de hashrate rend-elle Zcash plus vulnérable aux futures coordinations, que ce soit pour des correctifs d'urgence ou pour d'éventuelles interventions moins bénignes ? Bien qu'à cette occasion l'action ait été volontaire et visait à protéger le réseau, elle révèle que la véritable gouvernance de Zcash dépend d'un petit nombre d'acteurs.
Pour les autres réseaux PoW, l’affaire constitue une leçon claire : la décentralisation technique dans le code importe peu si le hashrate est très concentré. La véritable résistance à la censure et la décentralisation pratique restent des défis majeurs dans l’écosystème.
Voir l’article original en espagnol
