Skip to content
Blockchain Posts

protocol

Zcash corrige une faille de soundness dans Orchard via le hard fork NU6.2

Une contrainte manquante dans le circuit Orchard pouvait permettre la frappe de ZEC contrefaits indétectables. Le pool a été gelé le 2 juin puis rouvert le 3 via NU6.2.

par 6 min de lecture
protocolzcashsecurityinfrastructure

Les développeurs de Zcash ont déployé cette semaine une réponse coordonnée en deux temps à une faille critique de soundness dans le circuit de preuve à divulgation nulle de connaissance Orchard. Un soft fork d'urgence, activé au bloc 3 363 426 le 2 juin 2026, a désactivé toutes les transactions Orchard sur le réseau. Le hard fork NU6.2, activé au bloc 3 364 600 le 3 juin, a rouvert le pool blindé avec une nouvelle clé de vérification et un circuit corrigé. La vulnérabilité, jamais observée en exploitation, aurait pu en théorie permettre à un attaquant de frapper du ZEC ex nihilo à l'intérieur d'Orchard — où, par construction, les unités contrefaites auraient été indistinguables des authentiques. Les binaires sont publics : zcash v6.12.5 pour le soft fork, zcash v6.20.0 pour NU6.2.

Ce qui s'est passé

La faille a été identifiée le 29 mai par Taylor Hornby, chercheur en sécurité indépendant mandaté par Shielded Labs pour un audit du protocole. Hornby a divulgué le bug le soir même aux équipes d'ingénierie du Zcash Open Development Lab (ZODL), d'Electric Coin Company (ECC) et de la Zcash Foundation. Selon ses déclarations publiques, le chercheur s'est appuyé sur un framework d'audit assisté par un modèle d'IA pour faire émerger l'erreur — un premier cas public de bug consensus-critique trouvé dans un protocole majeur par une boucle d'audit machine.

Du 30 mai au 1ᵉʳ juin, deux correctifs ont été préparés en sourdine sous régime de divulgation coordonnée : un soft fork minimal pour neutraliser immédiatement l'exposition, puis un hard fork avec circuit corrigé. Mineurs et plateformes d'échange ont été prévenus avant la communication publique. La Zcash Foundation a livré en parallèle Zebra 4.5.3 puis 5.0.0 pour aligner son nœud Rust sur les nouvelles règles.

Mécanisme — une contrainte manquante dans le circuit de preuve

Orchard est le pool blindé de génération actuelle de Zcash. Il s'appuie sur le système de preuves Halo 2. Une transaction Orchard ne révèle rien — ni émetteur, ni destinataire, ni montant. La sécurité économique repose entièrement sur une preuve à divulgation nulle de connaissance qui certifie qu'aucune valeur n'est créée et qu'aucun jeton n'est dépensé deux fois. Cette garantie n'est valide que si le circuit est sound : aucun témoin invalide ne doit pouvoir produire une preuve acceptée.

Le bug divulgué se trouvait dans une section sous-contrainte du circuit Orchard chargée d'une vérification de courbe elliptique. D'après la divulgation, un attaquant pouvait soumettre des entrées falsifiées qui satisfaisaient malgré tout la vérification, produisant une preuve d'apparence valide pour une transaction dont le bilan de valeur était faux. Les montants étant chiffrés à l'intérieur d'Orchard, une frappe illégitime ne se serait pas signalée sur la chaîne par un solde inattendu détectable par un nœud.

NU6.2 remplace les contraintes défectueuses et incrémente la clé de vérification du circuit. D'éventuelles preuves antérieures qui auraient exploité le bug ne valideraient pas sous la nouvelle clé — mais le design de confidentialité empêche de prouver à partir des seules données on-chain si la faille a été exploitée ou non.

Impact

  • L'offre totale de ZEC n'est pas directement observable à l'intérieur d'Orchard. Shielded Labs et la Zcash Foundation estiment la probabilité d'exploitation antérieure faible — le bug exigeait une connaissance spécialisée des internes du circuit — mais aucune ne peut fournir une preuve cryptographique que l'offre est intacte.
  • Plusieurs plateformes d'échange et dépositaires ont suspendu dépôts et retraits ZEC entre le soft fork et l'activation de NU6.2, pour éviter de traiter des transactions Orchard en cours qui auraient été rejetées par le soft fork ou rendues invalides par le nouveau circuit.
  • Les transactions Sapling ne sont pas affectées. Sapling repose sur un circuit plus ancien et distinct. Les transactions transparentes (t-addr) sont également intactes.
  • Les opérateurs de nœud sur zcashd ≤ 6.12.4 et zebrad < 4.5.3 perdent le consensus avec le reste du réseau à la hauteur d'activation de NU6.2 s'ils n'ont pas mis à jour.

Que surveiller

  1. Le projet de mise à niveau « preuve d'offre » de Shielded Labs. Shielded Labs a proposé une mise à niveau ultérieure de Zcash qui permettrait au réseau de prouver l'offre totale de ZEC en suivant la valeur entrant et sortant de chaque pool blindé. La proposition relève désormais de la gouvernance et n'a pas été planifiée.
  2. Un post-mortem technique formel. Hornby et l'ECC se sont engagés à publier un compte rendu détaillé une fois l'activation stabilisée — contrainte manquante précise, méthodologie d'audit, vecteurs de test confirmant le correctif. À la publication, ni post-mortem ni CVE n'ont été émis.
  3. Réaudits indépendants. Une faille de soundness qui survit à plusieurs cycles de revue cryptographique est typiquement l'élément déclencheur d'audits sur les circuits adjacents — y compris le futur travail « Crosslink » (PoS hybride) et tous les circuits Halo 2 utilisés en dehors de Zcash.

Contexte — deuxième patch consensus-critique chez Zcash en neuf jours

C'est le deuxième correctif consensus-critique chez Zcash en moins de deux semaines. Le 29 mai, la Zcash Foundation avait livré Zebra 4.5.0 puis un hotfix 4.5.1, corrigeant un décompte de signature-ops P2SH qui pouvait scinder la chaîne entre Zebra et zcashd. Ce premier lot avait été trouvé par revue de code classique et par un programme de divulgation existant ; celui-ci a été trouvé par un auditeur tiers utilisant un framework d'agent IA contre la spécification du circuit.

Pour les protocoles ZK en général, l'épisode NU6.2 fait fonction de signal. Les bugs de soundness dans des circuits de preuve en production restent rares dans le discours public, mais ne sont pas inédits — Aztec et Polygon ont publié des incidents proches. Ce qui est nouveau ici, c'est le chemin de la divulgation : un auditeur externe payé, équipé d'un framework de test piloté par modèle, repère un bug de soundness dans un circuit en service, et l'équipe affectée coordonne un correctif préservant la confidentialité en cinq jours. Le motif a peu de chances d'être le dernier.

Sources :

Articles liés