Bitcoin Core : : Feuille de route technologique


Le remplacement de l’algorithme de signature numérique de Bitcoin (ECDSA) par l’algorithme Schnorr plus efficace est depuis longtemps en tête de liste de souhaits pour de nombreux développeurs Bitcoin. Un algorithme simple tirant parti de la cryptographie à courbe elliptique, Schnorr permet plusieurs améliorations par rapport au schéma existant tout en préservant toutes ses fonctionnalités et hypothèses de sécurité.

Notamment, les signatures Schnorr prennent en charge le « multisig natif » qui permet l’agrégation de plusieurs signatures en une seule valable pour la somme des clés de leurs entrées respectives. Cette fonctionnalité offre trois avantages importants  :

  • Signatures de taille constante quel que soit le nombre de participants à la configuration multisig. Une transaction 50 sur 50 est effectivement de la même taille qu’une transaction qui utilise une clé publique et une signature uniques. Pour cette raison, les performances de ces schémas sont considérablement améliorées en supprimant l’exigence initiale de validation de chaque signature individuellement. De plus, la vérification des signatures Schnorr est légèrement plus rapide que celle de l’ECDSA.

    Bitcoin Core : : Feuille de route technologique

  • La taille réduite des données à valider et à transmettre sur le réseau se traduit également par des gains de capacité intéressants. Compte tenu de la croissance historique du nombre de transactions multisig affichées ci-dessous, la possibilité de réduire la taille de ces transactions est un ajout intéressant aux efforts de mise à l’échelle existants.

  • Du point de vue de la confidentialité, Schnorr permet à l’intégralité de la politique du multisig d’être obscurcie et indiscernable d’une clé publique unique conventionnelle. Dans une configuration à seuil, il devient également impossible pour les participants de révéler lequel d’entre eux a autorisé ou non une transaction.

Répartition des sorties P2SH non dépensées en fonction de leur configuration multisig. p2sh.info

Malheureusement, contrairement à l’ECDSA, l’algorithme de Schnorr n’a pas été normalisé depuis son invention, probablement à cause du brevet original qui lui a été appliqué (qui a depuis expiré). Bien que les grandes lignes du système soient mathématiquement solides, le manque de documentation et de spécifications rend sa mise en œuvre plus difficile. Plus précisément, son application à la conception de paires de clés éphémères de Bitcoin implique des considérations de sécurité qui nécessitent une optimisation supplémentaire.

Le principal défi est défini par Pieter Wuille dans sa présentation Scaling Bitcoin Milan des signatures Schnorr comme le problème « d’annulation ». La possibilité pour un groupe d’utilisateurs de créer une signature valable pour la somme de leurs clés ouvre la porte à un participant adverse de soustraire de l’ensemble la clé d’un autre utilisateur. Cela fonctionne essentiellement comme ceci :

Supposons un schéma multisig 2 sur 2 utilisant les clés publiques d’entrée Q1 et Q2. Plutôt que d’annoncer sa clé comme Q2 à combiner avec Q1, un participant malveillant pourrait fournir, pendant la phase d’interaction, Q2-Q1 et effectivement annuler la clé de l’autre utilisateur. Tout fonds envoyé à la clé publique commune ne peut désormais être dépensé que par le propriétaire de la clé Q2 sans même que le propriétaire de Q1 soit au courant de ce qui se passe.

Heureusement, une solution est maintenant disponible qui consiste à multiplier chaque clé utilisée lors de la configuration avec un hachage basé sur lui-même et sur toutes les autres clés impliquées avant la signature. Ce processus est appelé délinéarisation. Une preuve de la sécurité de ce schéma est actuellement en cours d’examen par les pairs et sera formellement décrite dans un prochain livre blanc.

À court terme, les signatures Schnorr sont considérées comme un remplacement viable pour deux fonctions importantes du protocole Bitcoin.

Le premier est actuellement utilisé pour vérifier les signatures ECDSA par rapport à leur clé publique respective en fonction du message dans une transaction. En passant à un équivalent qui vérifie les signatures Schnorr plutôt qu’ECDSA, l’opcode peut être utilisé pour autoriser une dépense nécessitant plusieurs signatures. En utilisant une interaction a priori non observable par le réseau.

Ce dernier implique des scénarios de seuil où seules n-sur-m signatures sont nécessaires pour autoriser une transaction. Étant donné que le calcul évolue linéairement avec le nombre de participants, Schnorr propose un schéma beaucoup plus efficace qui remplace la liste des signatures par une seule combinée avec un sous-ensemble des clés publiques requises.

Jusqu’à ce qu’une évaluation plus approfondie du schéma de délinéarisation sécurisant les signataires des acteurs malveillants soit effectuée, d’autres applications des signatures Schnorr peuvent être prématurées, mais la mise en œuvre des fonctionnalités ci-dessus peut, espérons-le, ouvrir la voie à une meilleure compréhension du schéma en production. Sous réserve d’un examen par les pairs supplémentaire, un BIP pour la mise en œuvre de Schnorr Signatures pourrait être proposé d’ici la fin de l’année.

Agrégation de signatures

Les propriétés de Schnorr permettant la combinaison de plusieurs signatures sur une seule entrée sont également applicables à l’agrégation de plusieurs entrées pour toutes les transactions. Le développeur de Bitcoin, Gregory Maxwell, a été le premier à introduire l’idée en utilisant les informations d’une proposition précédente basée sur les signatures BLS.

Pour bien comprendre la différence entre cette application et celles décrites ci-dessus, il est nécessaire de considérer comment les signatures sont agrégées dans chaque cas respectif. Dans la configuration multisig native, les signataires collaborent entre eux pour calculer une clé publique commune et sa signature associée. Cette interaction se produit en dehors du protocole et ne concerne que les parties concernées. L’idée derrière l’agrégation de signatures est de permettre aux validateurs du système, c’est-à-dire. Nœuds Bitcoin pour calculer une clé et une signature uniques pour chaque entrée de toutes les transactions au niveau du protocole.

Étant donné que ce schéma élargit la portée de l’agrégation en dehors de l’ensemble déterministe des participants, il introduit un nouveau vecteur d’attaque pour que les acteurs malveillants exploitent le bogue « d’annulation ». Pour cette raison, le correctif de délinéarisation mis en évidence dans la section précédente est essentiel à la solidité de cette méthode.

En termes d’implémentation, la proposition est assez simple :, les délinéariser et une fois toutes les entrées associées validées, produire une signature combinée pour leurs transactions respectives.

En supposant que chaque signature historique serait réduite à 1 octet, à l’exception d’une par transaction, l’analyse suggère que la méthode entraînerait une réduction d’au moins 25 % en termes de stockage et de bande passante. L’utilisation accrue des seuils n-sur-n est susceptible de se traduire par davantage d’économies bien qu’ils n’aient pas été pris en compte dans cette analyse.

Plus d’informations sur les signatures Schnorr

Informations complémentaires sur l’agrégation de signatures