ZEC bondit de 42 %, le co-fondateur de ZODL explique en détail la mise à niveau d'urgence en deux phases de Zcash

Zcash lance une mise à niveau d'urgence en deux étapes : une soft fork pour suspendre temporairement les transactions Orchard, puis une hard fork NU6.2 pour réparer une vulnérabilité fondamentale. Josh Swihart, fondateur de ZODL, explique en détail tout le processus de réparation.
(Précédent : Zcash résout la crise du double spending ! Activation d'une mise à niveau par hard fork en urgence pour corriger la faille de preuve à divulgation zéro, avec confirmation officielle qu'aucun fonds n'a été perdu)
(Complément d'information : Zcash publie la proposition « Ironwood » : permettre à quiconque de vérifier la circulation de ZEC, cela peut-il restaurer la confiance ?)

Table des matières de cet article

Basculer

• Première étape : soft fork pour suspendre temporairement les transactions Orchard
• Deuxième étape : hard fork NU6.2 pour réparer la couche fondamentale
• Organisation indépendante ShieldedLabs en première ligne
• Collaboration avec les pools miniers et revue de code

Josh Swihart, co-fondateur de la cryptomonnaie privée Zcash et de ZODL, a expliqué en détail le 8 juin sur la plateforme X comment l'équipe Zcash a réparé une vulnérabilité grave dans le pool de confidentialité Orchard. Zcash a lancé une solution de mise à niveau d'urgence en deux étapes : la première étape consiste en une soft fork pour suspendre temporairement les transactions Orchard, la seconde en une hard fork NU6.2 pour corriger la faille sous-jacente.

Première étape : soft fork pour suspendre temporairement les transactions Orchard

Swihart indique que l'équipe ZODL a d'abord utilisé une soft fork pour désactiver temporairement les transactions Orchard, afin d'empêcher l'exploitation de la vulnérabilité avant sa correction. L'avantage de la soft fork est qu'elle ne nécessite pas une mise à jour massive par les pools miniers et les nœuds, tout en conservant toutes les fonctionnalités nouvelles.

Pendant cette première étape, le pool de confidentialité Orchard de Zcash présentait deux problèmes : d'une part, le ZEC nouvellement créé pouvait contenir un « zéro » invisible mais valide, d'autre part, la monnaie de rendu des transactions pouvait être inférieure d'un petit montant à ce qui était prévu. La suspension par soft fork a permis à l'équipe d'avoir suffisamment de temps pour effectuer la vérification et la correction.

Deuxième étape : hard fork NU6.2 pour réparer la couche fondamentale

Le 3 juin, l'équipe a lancé avec succès la hard fork NU6.2. Cette mise à jour a corrigé la logique de calcul du circuit Orchard sous-jacent, permettant à toutes les transactions ZEC de suivre à nouveau le chemin de validation correct.

NU6.2 a également réactivé la fonctionnalité de transaction Orchard, permettant à la confidentialité des transactions Zcash de revenir à la normale. Swihart souligne qu'Orchard est actuellement le principal pool de transactions privées de Zcash, chargé de vérifier que chaque transaction entrant dans le système est légitime.

Organisation indépendante ShieldedLabs en première ligne

Cette vulnérabilité a été divulguée en premier par l'organisation technique indépendante ShieldedLabs. Celle-ci indique que le pool de confidentialité Orchard comportait une faille grave, pouvant théoriquement permettre à un attaquant de créer à l'infini des ZEC falsifiés.

ShieldedLabs confirme que la vulnérabilité a été corrigée et qu'il n'existe actuellement aucune preuve qu'elle ait été exploitée en pratique. Après la réparation, le réseau Zcash a maintenu un état sans perte.

Collaboration avec les pools miniers et revue de code

Swihart révèle qu'au cours du processus, l'équipe ZODL a activement répondu aux demandes de revue de code formulées par les pools miniers et les échanges, afin de garantir la fiabilité de la solution de réparation. Parmi eux, ViaBTC et Foundry ont joué un rôle clé dans la coordination de la réponse d'urgence.

Cet incident met en lumière le mécanisme de contrôle de qualité en coulisses de Zcash — un processus de divulgation préalable, de réparation, puis de vérification, pour assurer la stabilité du réseau principal avant la mise à jour.