Zcash a corrigé une grave faille logicielle qui, dans de mauvaises circonstances, aurait pu permettre aux attaquants de drainer une quantité importante de ZEC d’une partie plus ancienne du réseau.
Le problème résidait dans zcashd, le logiciel de nœud, et était centré sur les transactions impliquant l’ancien pool protégé Sprout.
Selon la divulgation, les nœuds ignoraient la vérification des preuves dans ces cas. C’est le genre de bug qui attire rapidement l’attention dans les systèmes axés sur la confidentialité, car les vérifications de preuves ne sont pas un détail secondaire. Ils font partie du mécanisme de base qui empêche les transferts invalides d’être acceptés en premier lieu.
Un bug dans une vieille piscine, mais un risque quand même réel
La vulnérabilité a été révélée par Alex « Scalar » Sol le 23 mars, et le rapport public a été publié mardi. La zone concernée n’était pas le principal chemin de confidentialité actuel auquel la plupart des utilisateurs pensent aujourd’hui, mais l’ancien pool Sprout, qui est déjà obsolète. Même ainsi, obsolète ne signifie pas inoffensif. Si les fonds restent là, la surface d’attaque reste pertinente.
Ce qui rendait la faille particulièrement sensible était la possibilité que des transactions invalides puissent passer une étape critique de validation. En termes pratiques, cela aurait pu ouvrir la porte à une ponction des fonds du pool sans que le réseau ne détecte le problème là où il aurait dû le faire.
Zcash affirme que les fonds restent en sécurité
Jusqu’à présent, la partie importante est la suivante. Le bug a été corrigé avant toute exploitation connue, et la divulgation indique que tous les fonds des utilisateurs restent en sécurité.
Cela devrait apaiser la panique immédiate, sans pour autant effacer la leçon plus large. Les composants hérités des systèmes cryptographiques ont l’habitude de rester économiquement pertinents longtemps après que l’écosystème s’en soit mentalement éloigné. Anciens pools, logique retirée, chemins de code obsolètes, ces éléments sont toujours importants lorsque les actifs réels restent attachés.
Pour Zcash, l’épisode porte moins sur les dommages visibles que sur l’intérêt de détecter un échec de validation grave avant qu’il ne se transforme en un tel. Dans la sécurité de la blockchain, l’histoire la plus importante est parfois l’exploit qui n’a jamais eu l’occasion.
