Les signatures de Schnorr, prochaine évolution du Bitcoin
Bitcoin évolue lentement mais sûrement. Depuis SegWit en août 2017, aucune nouveauté majeure n'a été apportée au protocole, mais cela pourrait bien changer. Prévues de longue date pour remplacer le schéma de signature actuel, les signatures de Schnorr devraient faire leur apparition prochainement, vraisemblablement au début de l'année 2020. Le projet, supporté par Pieter Wuille et d'autres développeurs de Bitcoin Core, fait déjà l'objet d'un BIP et semble bien avancer.
Le protocole Bitcoin Cash va également profiter de cette amélioration. Les principaux aspects de ce schéma de signature seront en effet implémentés lors de la mise à niveau du 15 mai 2019, grâce à la contribution de Mark Lundeberg.
Dans cet article, nous allons voir ce que sont les signatures de Schnorr, ce qu'elles apportent à Bitcoin et comment aura lieu leur mise en place. Nous nous attarderons enfin sur la façon dont elles améliorent la multi-signature (MuSig).
Que sont les signatures de Schnorr ?
Le schéma de signature numérique de Schnorr est une dérivation du protocole d'authentification du même nom décrit en 1989 par Claus-Peter Schnorr. Ce schéma a été breveté aux États-Unis sous le brevet US4995082A qui expirait le 19 février 2008.
Bitcoin se sert actuellement d'un autre schéma de signature à clé publique appelé ECDSA (Elliptic Curve Digital Signature Algorithm ou algorithme de signature numérique sur courbes elliptiques) qui utilise la courbe elliptique secp256k1 (représentée ci-dessous).
? Comprendre les courbes elliptiques dans Bitcoin
Pour faire usage de cet algorithme, il est nécessaire de générer une paire clé privée / clé publique : la clé privée est un nombre aléatoire gardé secret par l’utilisateur ; la clé publique est calculée à partir de cette clé privée de manière à ce qu’on ne puisse pas faire le calcul en sens inverse. L'algorithme consiste à signer numériquement un message avec la clé privée, et l'authenticité de ce message peut être vérifiée par les autres à l'aide de la clé publique. La clé privée n'est jamais dévoilée et ne peut pas être déduite des signatures produites.
Dans Bitcoin, c'est la transaction elle-même qui est signée par celui ou celle qui souhaite envoyer des bitcoins. Ce sont ensuite les autres membres du réseau qui vérifient que ce message a bien été signé par la clé privée correspondant à ces bitcoins. Par exemple, pour qu'Alice puisse envoyer 1 BTC à Bob, elle devra construire une transaction entre son adresse et celle de Bob (« Moi Alice donne 1 bitcoin à Bob. »), la signer et inclure sa signature dans la transaction. Les nœuds du réseau pourront alors vérifier qu'il s'agit bien d'elle.
Pour connaître ce qui lie les clés et les adresses entre elles, vous pouvez vous référer à notre article « Clés privées, clés publiques et adresses dans Bitcoin ».
Dans le cas des signatures de Schnorr, le principe restera exactement le même : seules les signatures produites seront différentes. De plus, puisqu'il est prévu que le schéma de signature de Schnorr amené sur Bitcoin utilise la même courbe elliptique que ECDSA (secp256k1), les paires clé privée / clé publique seront les mêmes. Ce changement n'est ainsi pas si disruptif. La différence fondamentale réside dans les propriétés des signatures : les signatures de Schnorr présentent en effet de nombreux avantages par rapport à celles de ECDSA.
Pourquoi donc Satoshi n'a-t-il pas utilisé ces signatures si elles étaient supérieures ? On ne le sait pas. Néanmoins, la raison est sans doute que ce schéma de signature n'était pas encore bien standardisé à cause du brevet qui expirait en 2008, alors que ECDSA était largement répandu et utilisé, ce qui explique certainement le choix de Satoshi.
Qu'apportent les signatures de Schnorr ?
Comme on l'a dit, l'implémentation des signatures de Schnorr apportent avec elles de nombreux avantages pour Bitcoin et pour toutes les cryptomonnaies qui souhaiteraient les implémenter.
Le premier apport de ce schéma est d'améliorer la scalabilité. Tout d'abord, le schéma de Schnorr permet de réduire la taille des signatures : celle-ci sera fixée à 64 octets, au lieu de varier entre 70 et 72 octets comme aujourd'hui. Cela représente une réduction de 3 % de la taille d'une transaction classique, ce qui permettra d'alléger le fardeau des nœuds du réseau. Cependant, pour Bitcoin, cela ne représente pas une augmentation de la capacité transactionnelle, puisqu'avec SegWit les signatures sont contenues dans le témoin qui n'est pas le facteur limitant pour le poids des blocs.
Aussi, grâce à la propriété de linéarité de ces signatures, il deviendra possible de procéder à une validation des signatures en lots. Vérifier que la signature d'une transaction correspond bien à une clé publique prend du temps : avec Schnorr, il deviendra possible de valider une multitude de transactions signées par une multitude de clés privées en ne vérifiant qu'une seule égalité mathématique.
De plus, cette propriété permet d'améliorer grandement la multisignature (comme on le verra plus bas) et notamment de procéder à une agrégation des clés. Ceci aidera considérablement la confidentialité et la scalabilité de Bitcoin.
Le troisième point sur lequel le schéma de Schnorr apporte quelque chose est la sécurité : contrairement à ECDSA, il existe une preuve de sécurité pour les signatures de Schnorr.
Le dernier point qui peut être bénéfique est que ce schéma corrige la malléabilité issue des signatures. Il est en effet prouvé que les signatures de Schnorr sont non-malléables, celles-ci ne faisant pas intervenir de nombre aléatoire. Cela est particulièrement intéressant pour Bitcoin Cash car cela permettra d'avoir des transactions non-malléables, c'est-à-dire des transactions dont on ne peut pas changer l'identifiant après signature. Cela favorisera ainsi l'implémentation des canaux de paiements et des atomic swaps.
Comment seront-elles implémentées ?
Les signatures de Schnorr vont être intégrées au protocole Bitcoin ainsi qu'au protocole Bitcoin Cash. Dans les deux cas, il n'est pas question de remplacer brutalement ECDSA : elles resteront optionnelles et devront s'imposer avec le temps.
Dans Bitcoin, les signatures de Schnorr feront partie d'une mise à niveau importante qui utilisera la version 1 de SegWit. En effet, pour le moment, seule la version 0 est utilisée et les versions supérieures sont réservées pour les innovations futures. Grâce à ce versionnage, l'implémentation des signatures de Schnorr pourra être faite sous la forme d'un soft fork. Les utilisateurs resteront libres d'utiliser les transactions traditionnelles ou les transactions SegWit pré-Schnorr qui se basent sur ECDSA. D'autres changements comme Taproot feront partie de cette mise à niveau, même si ce n'est pas encore clairement défini.
Dans Bitcoin Cash, les signatures de Schnorr seront implémentées de façon élégante sous la forme d'un hard fork tout en restant facultatives. Les nœuds devront interpréter le type de signature utilisé selon la taille : les signatures de 64 octets seront vues comme des signatures de Schnorr tandis que les signatures de taille supérieure seront interprétées comme des signatures produites par ECDSA.
L'amélioration de la multisignature : MuSig
Pour créer des comptes joints, on a actuellement des adresses multisignatures qui utilisent le langage de script de Bitcoin. Cela marche bien mais :
- Tout le monde voit qu'il s'agit d'une adresse multisignatures : cela n'est pas très discret et nuit à la confidentialité des participants.
- Lors d'un paiement à partir de cette adresse, les signatures et les clés publiques des participants prennent de la place dans la transaction.
Avec Schnorr, il est possible de mettre en place un schéma de multi-signature particulier qui permet de remédier aux inconvénients évoqués ci-dessus. Celui-ci est appelé MuSig et a été créé par les développeurs Pieter Wuille, Andrew Poelstra, Yannick Seurin et Gregory Maxwell. Les avancées actuelles du projet sont assez encourageantes puisque Blockstream a récemment publié une version test du code.
La particularité de MuSig est qu'il permet de procéder à une agrégation des clés de manière simple et en toute sécurité. Les clés publiques des participants sont combinées et la clé résultante est utilisée comme clé publique unique. Puisque le schéma de signature de Schnorr est linéaire, la combinaison des signatures des différents participants sera égale à la signature correspondant à cette clé publique « agrégée ».
Cela apporte plusieurs avantages. Premièrement, MuSig peut être mis en place par les portefeuilles pour permettre à plusieurs personnes d'utiliser la multi-signature de façon confidentielle. MuSig pourra également favoriser l'implémentation de scriptless scripts (« scripts sans scripts »), permettant l'exécution de contrats autonomes en dehors de la chaîne de blocs.
Secondement, MuSig peut être implémenté au niveau protocolaire, ce qui constitue déjà un changement plus tendancieux. Il s'agit de procéder à une agrégation des clés entre les entrées transactionnelles d'une transaction (cross-input aggregation). Une transaction Bitcoin peut en effet avoir plusieurs entrées, qui comportent chacune une signature permettant de débloquer les fonds. Il est donc possible de combiner les clés liées aux entrées dépensées et ne requérir qu'une seule signature pour toute la transaction.
Puisque ces entrées sont généralement signées par la même personne, cela ne constitue pas une complication démesurée bien qu'il s'agisse d'un changement de paradigme au sein du protocole. Surtout, cette innovation apportera une amélioration monstrueuse de la scalabilité de Bitcoin car elle permettra d'alléger de presque 25 % l'ensemble des transactions !
Notez que seuls les développeurs de Bitcoin comptent procéder à ce changement pour le moment ; les développeurs de Bitcoin Cash sont assez hésitants pour le moment car les enjeux ne sont pas les mêmes. En effet, toutes les pièces de BCH en circulation seraient concernées par ce changement, contrairement à Bitcoin où il ne s'agira que des bitcoins utilisant la version 1 de SegWit et les versions supérieures.
Conclusion
Les signatures de Schnorr constitueront le prochain changement majeur du protocole Bitcoin. Puisque les bonnes idées sont toujours copiées, ces signatures seront également ajoutées au protocole Bitcoin Cash en mai prochain. Dans les deux cas, elles amèneront avec elles un certain nombre d'avantages qui amélioreront la scalabilité, la confidentialité et la sécurité du protocole. En particulier, grâce à l'implémentation protocolaire du schéma de multisignature MuSig, la capacité transactionnelle de Bitcoin pourrait être drastiquement augmentée.
Note des lecteurs