[[alloc] init] présente une proposition de Bitcoin confidentiel pour des transactions privées en Bitcoin

Bitcoin Magazine

[[alloc] init] présente Shielded Bitcoin, une proposition pour des transactions Bitcoin privées

Shielded Bitcoin est une proposition présentée par les chercheurs de [[alloc] init] Clara Shikhelman, Misha Komarov et Aleksei Moskvin. Elle consiste en un nouveau métaprotocol de confidentialité sur la couche de base de Bitcoin, qui permet d’effectuer des transactions Bitcoin protégées sans nécessiter d’opérateurs, de soft forks ni d’autres modifications du consensus de Bitcoin. Vous trouverez le livre blanc ici et l’annonce sur le blog ici.

Le protocole définit une structure transactionnelle et un protocole d’indexation pour des transactions offrant une forte protection de la vie privée, tout en s’appuyant sur les PIPEs de Bitcoin pour transférer des fonds vers le système et les en retirer. Vous trouverez plus d’informations sur le mécanisme des PIPEs à la fin de l’article.

Sa conception est très proche de celle de Bitcoin : il existe un équivalent à un UTXO (une note), les transactions utilisent des notes comme entrées, à l’instar d’une transaction Bitcoin classique, un témoin prouve que les entrées utilisées sont dûment autorisées, les nœuds (des indexeurs dans le cas d’un métaprotocol) analysent l’historique des transactions et établissent l’état actuel des pièces dépensées et non dépensées, etc.

Cependant, tous les détails sont très différents.

Une transaction Shielded Bitcoin n’est qu’un bloc de données auquel est ajouté un préfixe (quelque chose comme « shbtc: »), inclus dans une transaction Bitcoin au moyen d’OP_RETURN, du champ witness ou d’une autre méthode de transport de données. Elle n’a aucune signification pour Bitcoin : le réseau Bitcoin ne fait rien pour la vérifier et n’applique absolument aucune règle à son encontre. Il est tout à fait possible que des transactions Shielded Bitcoin invalides se retrouvent sur la chaîne. Il revient à un indexeur Shielded Bitcoin, qui observe passivement la blockchain (autrement dit, un nœud), d’ignorer ces transactions lorsqu’elles échouent à la validation et de refuser de les prendre en compte dans la mise à jour de l’état des soldes du réseau.

Un indexeur ne supprime pas les notes d’un ensemble de notes non dépensées comme Bitcoin le fait avec les UTXO. Il utilise un ensemble de nullificateurs. Cela permet à un utilisateur de publier publiquement une preuve chiffrée et un nullificateur indiquant qu’une note a été dépensée, sans révéler de quelle note il s’agit. L’idée est que, plutôt que de vérifier si une note figure dans l’« ensemble de notes non dépensées », on vérifie si un nullificateur a déjà été utilisé. Les indexeurs construisent un arbre de Merkle qui s’agrandit indéfiniment et auquel on ne peut qu’ajouter des éléments, contenant chaque sortie de note créée, ainsi que l’ensemble de nullificateurs.

Pour utiliser ce protocole, vous n’avez besoin que d’un nœud Bitcoin et d’un indexeur Shielded Bitcoin. Aucun prestataire de services, coordinateur ou état hors chaîne n’est nécessaire pour récupérer vos fonds. Cela fonctionne exactement comme Bitcoin sur la chaîne : il vous faut seulement votre nœud/indexeur et vos clés.

Chaque portefeuille utilisateur dérive une clé secrète maîtresse, à partir de laquelle sont créés tous les autres ensembles de clés utilisés.

Voyez cela comme un portefeuille HD Bitcoin. Vous pouvez générer de nombreux ensembles d’adresses liés de cette manière. Sk_spend est votre clé privée, le sk_nf sert à invalider les sorties de notes, le vk_in sert à déchiffrer et à consulter les notes entrantes, le vk_out pour consulter vos transactions sortantes, et le sk_view est utilisé pour générer une adresse de réception.

Lorsqu’un utilisateur souhaite communiquer une adresse à quelqu’un pour recevoir des fonds, il génère une valeur de diversificateur j similaire à une valeur de dérivation, puis multiplie cette valeur par sa clé sk_view clé publique qui en résulte, pk_d et j constitue l’adresse de l’utilisateur.

L’expéditeur génère ensuite une valeur aléatoire, le r_seed, ce qui est nécessaire au chiffrement de la sortie de note ainsi qu’à sa nullification (nous y reviendrons dans un instant). Transaction outputs contain only three encrypted things, the value of the output, the j valeur que le destinataire a donnée à l’expéditeur, et la valeur de r_seed de l’expéditeur. L’expéditeur utilise une paire de clés éphémères secrètes et la clé publique du destinataire pour créer un secret partagé. Les deux parties peuvent générer le même secret en multipliant leur clé privée par la clé publique de l’autre. La sortie de note est chiffrée à l’aide de ce secret partagé, et la clé éphémère sk_eph est incluse sans être chiffrée afin que le destinataire puisse générer le secret partagé.

Du côté des entrées de l’image, deux éléments sont nécessaires pour qu’une transaction soit valide : un nullificateur public pour les sorties de note consommées, et une preuve à divulgation nulle de connaissance démontrant que 1) la sortie de note est incluse dans l’arbre de Merkle des notes, 2) la transaction est autorisée par la clé sk_spend appropriée, 3) le nullificateur est correctement dérivé, et 4) aucune création monétaire indue n’a eu lieu.

Si vous remarquez dans l’image ci-dessus, le nullificateur utilise la sk_nf clé, la valeur ρ dérivée de r_seed, et la position de la note dans l’arbre de Merkle des sorties de notes. La preuve à divulgation nulle de connaissance garantit tout cela, ce qui explique pourquoi il suffit de compter les nullificateurs en cas de répétition, au lieu de supprimer les notes dépensées. Même si vous ne savez jamais à quelle sortie de note correspond un nullificateur, les preuves à divulgation nulle de connaissance de chaque transaction garantissent que chaque nullificateur ajouté à l’ensemble provient d’une sortie de note valide. Tant qu’il n’y a pas de répétition, cela offre la même garantie contre la double dépense.

Voilà donc : le protocole vous permet essentiellement d’intégrer des transactions de métaprotocole chiffrées à la blockchain Bitcoin, tout en garantissant que rien ne peut être dépensé deux fois et que des pièces ne sont pas créées à partir de rien.

Il s’agit en fait d’un système très bien conçu du point de vue de la confidentialité, comparable aux pools protégés de Zcash. Il faut tenir compte de certains aspects liés à la confidentialité au moment d’entrer dans le métaprotocole et d’en sortir, et ceux-ci seront détaillés dans un prochain article. Il n’y a pas à se soucier de mesurer la confidentialité ni de procéder à des remélanges périodiques comme avec les coinjoins.

Alors, le peg. L’objectif est de créer un peg à l’aide de PIPEs v2, un schéma de chiffrement à témoin. PIPEs permet de chiffrer une clé privée avec un programme ou un mécanisme qui ne divulguera pas la clé tant que vous ne pourrez pas fournir une preuve ZK attestant qu’une certaine condition a été remplie (par exemple, l’état d’un UTXO, la confirmation d’une transaction, etc.). Cela permettrait à un peg de fonctionner sans opérateur, fédération ni tiers dépositaire des fonds.

Cela ne nécessite aucun soft fork ni aucune modification du protocole Bitcoin, et se déroule entièrement hors chaîne.

Le projet de Shielded Bitcoin, ainsi que la prochaine étape de ses travaux, consiste à mettre en place un mécanisme de peg permettant aux utilisateurs de déposer des fonds dans Shielded Bitcoin à l’aide de clés contrôlées cryptographiquement par PIPEs. Ces clés seraient ensuite « déverrouillées » en générant une preuve ZK de transactions de peg-out légitimes confirmées sur la chaîne.

Les travaux sur le document qui définit cet aspect du système sont en cours et celui-ci devrait paraître prochainement.

Cet article, « [[alloc] init] publie une proposition de Shielded Bitcoin pour des transactions Bitcoin privées », est paru pour la première fois dans Bitcoin Magazine et a été écrit par Shinobi.

Source : BitcoinMagazine