Le multisig est un concept familier pour la plupart des gens dans Bitcoin : une transaction multisig nécessite l'approbation de plusieurs parties avant de pouvoir être exécutée. Nous faisons la distinction entre «n-de-n” multi-signatures, où le nombre de parties impliquées est net ils doivent tous approuver, et “t-de-n” signatures de seuil, où seul un nombre plus petit t des participants doivent approuver. Les schémas cryptographiques tels que MuSig, MuSig-DN et MuSig2 pour les multi-signatures et FROST de Komlo et Goldberg pour les signatures de seuil peuvent réduire les coûts de transaction et améliorer la confidentialité des portefeuilles multisig.
Jusqu'à présent, FROST n'a été utilisé dans la communauté Bitcoin que dans des implémentations expérimentales. Dans cet article, nous expliquons pourquoi c'est le cas et comment nous souhaitons faire progresser FROST dans un environnement de production Bitcoin grâce à notre récente publication d'un projet BIP pour le protocole de génération de clés distribuées ChillDKG.
Tout d’abord, quels sont les avantages de FROST ?
Gains de confidentialité et d'efficacité avec MuSig2 et FROST
Avec MuSig2 et FROST, même si plusieurs participants contribuent au processus de signature, le résultat est une signature unique.
Cela permet non seulement d'améliorer la confidentialité des participants en faisant en sorte que la transaction ressemble à une transaction ordinaire avec un portefeuille à signature unique. Cela permet également de réduire la transaction, en réduisant sa taille et donc en diminuant les frais de transaction. Tout cela est formidable !
MuSig2 et FROST permettent aux utilisateurs de Bitcoin d'utiliser un portefeuille multisig avec le même coût de transaction qu'un portefeuille à signature unique classique. Les avantages en termes de coûts sont particulièrement importants pour les systèmes comportant un grand nombre de signataires et des transactions fréquentes, comme les chaînes latérales fédérées comme Liquid ou Fedimint. Contrairement au multisig traditionnel, qui laisse une empreinte digitale distincte permettant aux observateurs de la blockchain d'identifier les transactions du portefeuille, les portefeuilles basés sur FROST sont indiscernables des portefeuilles à signature unique classiques sur la blockchain. Par conséquent, ils offrent une amélioration de la confidentialité par rapport aux portefeuilles multisig traditionnels.
Si MuSig2 a été adopté par l'industrie Bitcoin, on ne peut pas en dire autant de FROST à notre connaissance. Cela peut être surprenant, compte tenu de l'existence de plusieurs implémentations de FROST, comme dans ZF FROST (par la Fondation Zcash), secp256kfun (par Lloyd Fournier) et une implémentation expérimentale dans libsecp256k1-zkp (par Jesse Posner et Blockstream Research). Il existe même une spécification IETF pour FROST, RFC 9591 (bien qu'elle ne soit pas compatible avec Bitcoin en raison de modifications de Taproot et de clés publiques x-only). L'une des explications les plus plausibles est que le processus de génération de clés de FROST est considérablement plus complexe que celui de MuSig2.
Le casse-tête non résolu du FROST dans les systèmes de production
FROST se compose essentiellement de deux parties : la génération de clés et la signature. Bien que le processus de signature ressemble beaucoup à celui de MuSig2, la génération de clés est beaucoup plus complexe que dans MuSig2. La génération de clés dans FROST est soit fiable, soit distribuée :
- La génération de clés de confiance implique un « revendeur de confiance » qui génère la clé et distribue les parts de clé aux signataires. Le revendeur représente un point de défaillance unique : en cas de malveillance ou de piratage, le portefeuille FROST risque d'être vidé.
- La génération de clés distribuées (DKG), tout en éliminant le besoin d'un revendeur de confiance, présente ses propres défis : tous les participants doivent être impliqués dans une « cérémonie » de génération de clés interactive avant que la signature puisse commencer.
Le défi principal : l’accord
Le DKG requiert généralement des canaux sécurisés (c'est-à-dire authentifiés et cryptés) entre les participants pour transmettre les parts secrètes aux signataires individuels, ainsi qu'un mécanisme d'accord sécurisé. L'objectif du mécanisme d'accord sécurisé est de garantir que tous les participants parviennent finalement à un accord sur les résultats du DKG, qui incluent non seulement des paramètres tels que la clé publique de seuil générée, mais également si aucune erreur ne s'est produite et si la cérémonie n'a pas été perturbée par un participant mal intentionné.
Bien que la spécification IETF considère que DKG n'entre pas dans le champ d'application, les implémentations FROST mentionnées ci-dessus n'implémentent pas d'accord sécurisé, laissant cette tâche à l'utilisateur de la bibliothèque. Mais l'accord n'est pas simple à mettre en œuvre : il existe d'innombrables protocoles et variantes d'accord, allant des simples schémas de diffusion d'écho aux protocoles de consensus byzantins à part entière, et leurs garanties de sécurité et de disponibilité diffèrent considérablement, et parfois subtilement.
Malgré la confusion qui peut survenir en raison de cette jungle de protocoles d’accord, la nature exacte de l’accord sur lequel s’appuie DKG n’est souvent pas clairement communiquée aux ingénieurs, les laissant dans l’ignorance.
ChillDKG : un DKG autonome pour FROST
Pour surmonter cet obstacle, nous proposons ChillDKG, un nouveau protocole DKG « prêt à l’emploi » adapté à l’utilisation dans FROST (ébauche). Nous fournissons une description détaillée sous la forme d’une ébauche de proposition d’amélioration de Bitcoin (BIP), qui est destinée à servir de spécification aux implémenteurs.
La principale caractéristique de ChillDKG est qu'il est autonome : l'établissement de communications et d'accords sécurisés se fait au sein du protocole, tandis que toute cette complexité sous-jacente est cachée derrière une API simple et difficile à utiliser à mauvais escient. Par conséquent, ChillDKG est prêt à l'emploi dans la pratique et ne repose sur aucune hypothèse de configuration, à l'exception du fait que chaque signataire a décidé de l'ensemble des cosignataires identifiés par des clés publiques individuelles. ChillDKG est basé sur le protocole SimplPedPop, dont Blockstream Research a participé à la conception et à la preuve de sécurité formelle, voir le document CRYPTO 2023 « Practical Schnorr Threshold Signatures Without the Algebraic Group Model » de Chu, Gerhart, Ruffing (Blockstream Research) et Schröder
Les objectifs supplémentaires de la conception de ChillDKG incluent :
- Large applicabilité : ChillDKG prend en charge un large éventail de scénarios, depuis ceux où les appareils de signature sont détenus et connectés par une seule personne jusqu'à ceux où plusieurs propriétaires gèrent les appareils à partir d'emplacements distincts.
- Sauvegardes simples : au lieu de devoir sauvegarder les secrets reçus des autres signataires dans un emplacement sécurisé, ChillDKG permet de restaurer le portefeuille uniquement à partir de la graine de l'appareil et des données publiques qui sont les mêmes pour tous les participants DKG. Par conséquent, un attaquant accédant aux données de sauvegarde publiques n'obtient pas la clé de signature secrète, et si un utilisateur perd sa sauvegarde, il peut la demander à un autre signataire honnête.
Le BIP ChillDKG est actuellement en phase de projet et nous recherchons des commentaires sur les choix de conception et les détails de mise en œuvre. Bien que la spécification soit en grande partie terminée, il lui manque des vecteurs de test et nous envisageons d'ajouter quelques fonctionnalités supplémentaires (par exemple, des « abandons identifiables »). Une fois finalisé, le BIP ChillDKG peut être utilisé en combinaison avec un BIP pour la signature FROST afin d'instancier l'ensemble du protocole FROST.
Il s'agit d'un article invité de Jonas Nick, Kiara Bickers et Tim Ruffing. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou Bitcoin Magazine.