Une proposition qui circule désormais parmi les contributeurs de Zcash, la crypto-monnaie axée sur la confidentialité, viserait à supprimer le mécanisme qui rend invalide les transactions signées en attente à chaque mise à niveau du réseau (NU), après que la dernière activation a laissé les portefeuilles dans l'impossibilité de dépenser jusqu'à la publication de nouvelles versions ou firmwares.

Une plainte récente, avec un exemple tout aussi récent

Dans un message sur le forum publié le 9 novembre, le développeur ValarDragon a inscrit la suppression des mises à jour du consensus branch ID parmi sept objectifs pour NU8, la prochaine mise à niveau, dans le but affiché de mettre fin au schéma de « casse des portefeuilles à chaque NU ».

Cette plainte s'appuie sur un exemple tout frais. NU7 s'est activée la semaine dernière au bloc 3,543,405 sans toucher au format des transactions, et pourtant, comme l'a souligné le membre du forum strahncryptography dans le même fil, chaque portefeuille a tout de même eu besoin d'une nouvelle version ou d'un nouveau firmware avant de pouvoir dépenser à nouveau. Toute personne utilisant un téléphone air-gapped ou un appareil non pris en charge est restée bloquée.

Dès le lendemain matin, le fil avait produit trois positions : supprimer le mécanisme, le conserver mais permettre aux utilisateurs de s'en exempter, ou admettre que le véritable problème est l'obsolescence des portefeuilles plutôt que l'expiration des signatures. Un développeur de coffre-fort (vault) a ensuite montré pourquoi ce choix n'est pas purement théorique.

Ce qui casse réellement

Chaque signature Zcash s'engage sur un consensus branch ID, une étiquette désignant l'ensemble de règles en vigueur. ZIP 200, l'une des propositions d'amélioration Zcash (ZIP) qui spécifient les règles du protocole, l'a introduit afin qu'une transaction signée pour une chaîne ne puisse pas être rejouée sur un fork partageant le même historique. Lorsqu'une mise à niveau s'active, l'ID change, et tout ce qui a été signé sous l'ancien est mort à l'arrivée.

Le ZIP de déploiement de NU7 l'explique explicitement pour la mise à niveau qui vient d'avoir lieu : les transactions de version 5 et de version 6 ont conservé leur structure, mais une transaction reste invalide à travers l'activation car ses signatures sont liées au branch ID. Les transactions sauvegardées et signées hors ligne, ajoute le document, nécessitent les mêmes vérifications d'activation que les transactions en direct.

C'est pourquoi les portefeuilles ont dû publier des mises à jour pour une mise à niveau qui n'a rien changé à la manière dont ils construisent les transactions. Un portefeuille qui ne connaît pas le nouvel ID signe pour une chaîne qui n'existe plus.

Le coffre-fort qui ne peut pas signer à temps

Daniel Gorgonha, qui développe le coffre-fort t-of-n Konclave chez Deega Labs, a décrit plus loin dans le fil le coût pratique. Konclave construit d'abord la transaction puis collecte les signatures de seuil, de sorte que chaque signataire requis doit agir dans la fenêtre d'expiration de la transaction, d'environ 50 minutes. Une mise à niveau survenant au milieu de cette fenêtre annule tout.

La figure de 50 minutes provient de ZIP 203, qui a maintenu l'expiration par défaut à environ cette durée à travers trois changements de temps de bloc. Depuis NU7, cela correspond à 120 blocs à l'espacement cible de 25 secondes. Il s'agit d'une valeur par défaut du portefeuille, configurable par nœud, et une transaction peut être construite sans aucune expiration en réglant le champ à zéro.

L'horloge est donc déjà un problème soluble, du moins lorsque le portefeuille expose ce réglage. La frontière de mise à niveau, elle, ne l'est pas. Un coffre-fort pourrait accorder une semaine à ses membres pour signer et perdre quand même la transaction au moment où le branch ID bascule. La demande de Gorgonha portait sur l'opt-out que nuttycom venait de proposer, afin qu'un groupe puisse collecter des signatures sur plusieurs heures ou jours à ses propres risques.

Trois issues possibles, chacune avec un revers

Supprimer l'engagement sur le branch ID. Il s'agit de la proposition initiale de ValarDragon. str4d, ingénieur chez Electric Coin Company (ECC), a répondu que la protection contre le replay était une exigence ferme des plateformes d'échange et d'autres acteurs de l'écosystème au moment de la rédaction de ZIP 200 ; toute suppression nécessiterait donc un mécanisme de remplacement, idéalement couvrant également les forks hostiles créés uniquement pour perturber la chaîne principale.

Le conserver par défaut et permettre aux utilisateurs de s'en exempter. nuttycom, également chez ECC, a proposé des variantes de signature dans le cadre de ZIP 248 qui omettent à la fois le branch ID et la hauteur d'expiration. Les utilisateurs qui les choisissent renoncent à une partie de la protection contre le replay et obtiennent des transactions qui survivent à une mise à niveau. L'algorithme existant, qui fonctionne très bien pour la grande majorité des transactions selon nuttycom, resterait la valeur par défaut sûre. str4d avait déjà indiqué qu'une telle variante serait facile à définir une fois ZIP 248 actif.

Douter que cela résolve quoi que ce soit pour les portefeuilles. strahncryptography a fait valoir que les variantes corrigent la longévité des transactions mais pas l'obsolescence : si le branch ID n'est pas codé en dur, l'utilisateur doit fournir le bon, ce qui reporte la même charge sur le logiciel du portefeuille. La protection contre le replay face aux forks amicaux a une valeur, a-t-il écrit, mais les bénéfices doivent être pesés.

Le fil n'a pas résolu le désaccord. Il a en revanche resserré la question : une variante en opt-in vaut-elle la peine d'être construite pour les utilisateurs qui en ont besoin, et à quoi ces utilisateurs devraient-ils renoncer ?

Ce que coûterait l'opt-out

Le risque de replay s'imagine le plus facilement avec la mise à niveau qui vient d'avoir lieu. Pour NU7 uniquement, ZIP 259 a levé l'exigence habituelle selon laquelle les anciens logiciels de nœud se déprécient avant l'activation, ce qui signifie que les opérateurs qui n'ont jamais mis à jour peuvent rester en ligne et continuer à suivre une branche pré-NU7. Une transaction dont la signature n'est liée à aucune branche est précisément le type de transaction qui pourrait être acceptée sur les deux.

L'exposition correspond à la portée d'une autorisation, pas aux clés qui la soutendent. Une transaction rejouée dépense les mêmes entrées sur une autre chaîne que le signataire n'a jamais voulu utiliser ; elle ne permet à personne de forger une nouvelle transaction.

La suppression de la hauteur d'expiration de la signature a un second effet : un paiement autorisé peut rester non confirmé aussi longtemps que ses entrées demeurent non dépensées. C'est la fonctionnalité qu'un coffre-fort recherche et le risque qu'un utilisateur individuel peut ne pas remarquer.

nuttycom a également signalé une possible réduction de l'ensemble d'anonymat. Dans un système à transactions blindées, la confidentialité dépend du fait qu'une transaction ressemble à toutes les autres ; une transaction signée avec une variante rarement utilisée offrirait une foule plus restreinte dans laquelle se dissimuler. Le message n'a pas quantifié cet effet, et aucune variante n'a encore été spécifiée.

Une signature plus durable ne met pas à jour un vieil appareil

ZIP 248, le format de transaction extensible dont tout ceci dépend, est toujours à l'état de projet. str4d a indiqué que sa conception est stable depuis plus de six mois et qu'il a passé la semaine écoulée à le mettre à jour pour les changements de consensus déployés depuis. Il n'a été attribué à aucune mise à niveau, et les variantes d'opt-out n'y existent pas encore.

Même une fois créées, un portefeuille matériel ou un signataire hors ligne aura toujours besoin d'un logiciel comprenant le nouveau format. ZIP 248 interdit aux portefeuilles de construire ou de signer des composants qu'ils ne peuvent pas analyser. Le bénéfice de compatibilité est réel, mais il arrive par le biais des versions de portefeuilles, l'étape qui, selon strahncryptography, échoue constamment.

Rien de tout cela n'aide non plus les transactions dans un format retiré. ZIP 259 note que l'interdiction des transactions de version 4 par NU7 couvre les dépenses transparentes et Sapling ainsi que Sprout, et qu'une re-signature ne peut les sauver ; la seule solution est de reconstruire le paiement dans une version prise en charge. Coindoo a couvert la semaine dernière le cas le plus difficile : les pièces Sprout sans aucun format de remplacement.

Konclave a elle aussi sa part inachevée. Son issue ouverte sur la signature asynchrone sépare les approbations collectées au fil du temps de la cérémonie interactive de seuil que le coffre-fort exécute aujourd'hui. Une transaction qui survit à une mise à niveau supprime un obstacle ; le flux de travail permettant aux membres de contribuer à mesure qu'ils se connectent reste à écrire et à examiner.

Conseils pratiques

Si vous gérez un portefeuille de groupe :

• L'activation est une hauteur de bloc, pas une date ; le ZIP de déploiement de chaque mise à niveau la publie à l'avance.
• N'ouvrez pas de cycle de signature susceptible de chevaucher cette hauteur.
• Tout ce qui a été préparé avant l'activation doit être reconstruit après, même si personne n'a encore signé.

Si vous détenez des pièces sur un ancien appareil :

• Vérifiez si son firmware ou son application a intégré la prise en charge de NU7 avant d'essayer de dépenser.
• Une dépense bloquée depuis un pool pris en charge est un problème de portefeuille, pas des fonds perdus.
• Les transactions de version 4 sauvegardées avant le 6 novembre ne peuvent pas être re-signées pour redevenir valides.

Le précédent examen par Coindoo des améliorations des paiements côté portefeuille couvrait l'écart entre la construction d'une transaction et sa confirmation. Ce fil ajoute une troisième étape entre les deux : maintenir l'autorisation en vie pendant que les personnes et les appareils rattrapent leur retard.

La suite

Fin janvier est l'objectif de ValarDragon, pas un calendrier. str4d a remis en question dans le même fil la suffisance de deux mois et demi pour le pool Tachyon figurant sur la même liste, et l'élément branch ID a suscité la plus vive opposition des sept. Que NU8 soit livrée avec un opt-out, un remplacement de la protection contre le replay, ou ni l'un ni l'autre, sera tranché dans le processus ZIP, et non sur le forum.