Zcash a restauré Orchard après une erreur critique

Zcash a restauré Orchard après une erreur critique

Zcash a effectué une mise à jour d'urgence du réseau après avoir découvert une erreur critique dans Orchard, l'un des principaux pools privés du projet. Les développeurs ont temporairement limité les opérations sur ce pool, puis l'ont remis en ligne via une mise à jour.

La Fondation Zcash a déclaré qu'il n'y avait aucun signe d'exploitation de la vulnérabilité. Aucune pièce supplémentaire n'a été émise, les fonds des utilisateurs n'ont pas été affectés et la confidentialité des transactions, selon le fonds, est restée protégée.

Notation

le meilleur commerçants

selon les visiteurs site

“Fermé l'affaire minimum de +40%…”

« Maintenant, nous travaillons avec plus de 1 300 $ par mois. »

« Il s'avère que l'on retire systématiquement 500 à 600 $ »

L'erreur a affecté le mécanisme privé du réseau

Le problème était lié au schéma cryptographique à preuve de connaissance nulle utilisé dans Orchard. Ce mécanisme est nécessaire pour les transactions sécurisées, où le réseau peut vérifier l'exactitude de l'opération sans révéler de données utilisateur inutiles.

La Fondation Zcash a évalué que la vulnérabilité pourrait entraîner des changements d'état incorrects au sein du pool. Cela ne signifie pas qu'une attaque a eu lieu. Cependant, pour un réseau privé, même un risque théorique dans un tel composant nécessite une réponse rapide.

Orchard reste une partie importante de l’architecture moderne de Zcash. Par conséquent, les développeurs ont choisi un scénario prudent : arrêtez d'abord les actions potentiellement dangereuses, puis remettez le pool au travail après le correctif.

La mise à jour a eu lieu en mode urgence

Les développeurs ont agi en deux étapes. Premièrement, ils ont temporairement bloqué les opérations d'Orchard pour éliminer le risque d'activités inappropriées au sein du pool sécurisé. Après cela, le réseau a reçu une mise à jour avec un schéma cryptographique corrigé.

Techniquement, le processus est passé par le client Zebra. La version 4.5.3 limitait la zone problématique et la version 5.0.0 incluait la mise à jour NU6.2 et remettait Orchard en état de fonctionnement. Cette procédure nous a permis de ne pas attendre la sortie prévue et de fermer la vulnérabilité plus rapidement.

Ce n’était pas une mise à jour ordinaire pour Zcash. Orchard est associé à des transactions privées, ce qui signifie que toute erreur dans sa logique affecte la confiance dans l'une des principales fonctions du réseau. Par conséquent, l’équipe a d’abord réduit le risque, puis a ensuite restauré la fonctionnalité.

Les utilisateurs ont confondu la panne avec un arrêt du réseau

Lors de la transition vers de nouvelles règles, une partie de l’écosystème était instable. Certains utilisateurs avaient l'impression que Zcash s'était arrêté parce que l'un des explorateurs de blocs affichait le même dernier bloc depuis longtemps.

L'explorateur de blocs Zcash affiche le dernier bloc extrait il y a quatre heures.

La page affichait un bloc trouvé à 5h27 UTC, mais l'interface indiquait qu'il n'y avait pas eu de nouveaux blocs depuis plusieurs heures. Cela s’est rapidement répandu sur X et a donné lieu à des rapports faisant état d’un éventuel arrêt du réseau.

L'un des développeurs a expliqué plus tard que le réseau avait connu une courte période d'instabilité. Les mineurs ont mis à jour le logiciel et sont passés à de nouvelles règles de consensus. Selon elle, le 2 juin à 3 heures du matin, heure de l'Est, le réseau était complètement stabilisé.

La communauté a débattu de l'ampleur de la panne

Certains participants pensaient que Zcash ne s’était pas arrêté parce que les blocs continuaient d’être extraits. Le responsable d'Helius a déclaré que le problème pourrait provenir des navigateurs individuels connectés au nœud défectueux.

Un participant sous le pseudonyme de Zerodarts a adopté une position similaire. Il a noté que des blocs étaient créés sur le réseau et que la plupart des observateurs avaient simplement besoin de mettre à jour leurs nœuds. De ce point de vue, il ne s’agissait pas d’arrêter complètement la blockchain, mais de problèmes d’affichage des données.

D'autres participants ont adopté un point de vue plus sévère sur la situation. L'utilisateur Railgoon a souligné qu'Orchard avait été délibérément gelé avant le hard fork pour fermer la vulnérabilité. Par conséquent, selon lui, le réseau ne peut pas être qualifié de pleinement opérationnel pour le moment : une partie des fonctionnalités privées clés a en effet été désactivée.

La vulnérabilité a été trouvée lors d'un audit

Le bug a été découvert le 29 mai par un chercheur indépendant en sécurité. Il a découvert le problème lors d'un audit de protocole qu'il a mené pour Shielded Labs.

Après découverte, les informations ont été transférées aux ingénieurs de Zcash. L'équipe a confirmé la vulnérabilité et a commencé à préparer des options de correctif. Ce scénario est considéré comme plus sûr : d'abord une notification privée aux développeurs, puis une vérification, et ensuite seulement des actions publiques.

Il s'agit d'un résultat important pour Zcash. Le problème a été découvert avant que l'exploitation ne soit confirmée, aucune pièce supplémentaire n'est apparue et la confidentialité des utilisateurs, selon la Fondation Zcash, n'a pas été affectée. Cependant, l'incident a montré que même les réseaux privés de confiance restent dépendants d'audits réguliers et d'une réponse rapide des développeurs.

La ZEC a chuté mais s'est rapidement redressée

Le jeton ZEC a réagi à la nouvelle avec une baisse modérée. Le prix est brièvement tombé à 599 $ après un sommet intrajournalier d'environ 637 $, selon CoinGecko.

L'actif s'est ensuite rétabli à environ 614 $. Cette dynamique montre que le marché n'a pas perçu la situation comme une crise à part entière. Les investisseurs avaient intégré le risque d'un problème technique, mais n'ont vu aucun signe de piratage ou de dommage dans l'offre de ZEC.

Si le fonds avait signalé une émission illégale de pièces, une perte de fonds ou une violation de la vie privée, la réponse aurait pu être beaucoup plus sévère. Jusqu’à présent, le marché a été davantage confronté à un test de résistance des infrastructures qu’à une attaque contre le réseau.

Qu'est-ce que cela signifie pour Zcash ?

Le principal risque a été clôturé avant de devenir une attaque confirmée. Il s’agit d’un scénario positif pour le réseau, surtout compte tenu de la complexité des technologies à connaissance nulle.

Dans le même temps, l’incident est devenu un rappel du point faible des protocoles privés. Plus l’architecture cryptographique est complexe, plus le coût d’une erreur dans un seul composant est élevé. Même le gel temporaire d'un pool individuel peut semer la confusion parmi les utilisateurs, les bourses, les mineurs et les services qui surveillent le réseau.

La chose la plus importante pour le marché est que Zcash a restauré Orchard et n'a signalé aucune perte de fonds. Le principal défi reste désormais de synchroniser l’infrastructure et de restaurer la confiance après une mise à jour après sinistre.

Quelle est la prochaine étape ?

Les prochains jours montreront à quelle vitesse l’ensemble de l’infrastructure Zcash passera aux règles mises à jour. Les nœuds, les mineurs, les échanges, les portefeuilles et les explorateurs de blocs doivent fonctionner de manière synchronisée pour éviter davantage de rapports de crash.

Pour Zcash, cet épisode peut être considéré comme une crise gérée. La vulnérabilité a été découverte lors d'un audit, le travail d'Orchard a été temporairement limité, puis restauré via une mise à jour. Cela n’élimine pas le risque de réputation, mais cela montre que l’équipe a été capable de résoudre le problème rapidement.

La conclusion principale est neutre-positive. Zcash a préservé les fonds, l'approvisionnement et la confidentialité des utilisateurs, mais a encore une fois rappelé au marché : une infrastructure privée complexe nécessite des contrôles constants et une préparation à des solutions d'urgence rapides.

En savoir plus: Mastercard intégrera les stablecoins dans les paiements



Voir l’article original en russe