Les chercheurs de [[alloc] init] — Clara Shikhelman, Misha Komarov et Aleksei Moskvin — ont publié Shielded Bitcoin, un livre blanc décrivant un nouveau métaprotocole de confidentialité construit sur la couche de base de Bitcoin. Cette conception permet des transactions Bitcoin shielded sans nécessiter d'opérateurs, de soft forks ni aucune autre modification du consensus de Bitcoin. Le livre blanc et une annonce de blog sont disponibles, et l'équipe a partagé la nouvelle sur X.

Le protocole définit une structure transactionnelle et un protocole d'indexation pour des transactions à forte préservation de la confidentialité, tout en s'appuyant sur Bitcoin PIPEs pour verrouiller et déverrouiller des fonds dans le système. Le mécanisme PIPEs est examiné en détail à la fin de cet article.

Cette propriété d'absence de changement du consensus est importante : le registre de Bitcoin enregistre les montants et les adresses en clair, et les modifications de ses règles ont historiquement exigé une large coordination à l'échelle du réseau. Une conception qui opère entièrement dans le jeu de règles existant ne dépend pas de ce processus pour avancer.

Une conception similaire à Bitcoin avec des détails très différents

L'architecture reflète délibérément celle de Bitcoin. Il existe un équivalent de l'UTXO, appelé note. Les transactions consomment des notes en entrées, tout comme une transaction Bitcoin classique dépense des UTXO. Un témoin prouve que les entrées consommées sont dûment autorisées, et les nœuds — des indexeurs dans le cas d'un métaprotocole — analysent l'historique des transactions et construisent un état courant des pièces dépensées et non dépensées.

Chaque détail sous-jacent, however, est tout à fait différent.

Des transactions que Bitcoin lui-même ignore

Une transaction Shielded Bitcoin est simplement un bloc de données portant un préfixe — quelque chose comme "shbtc:" — intégré dans une transaction Bitcoin via OP_RETURN, le champ witness ou une autre méthode de transport de données. C'est le schéma du métaprotocole : les règles protocole sont appliquées par ses propres indexeurs plutôt que par Bitcoin, de sorte que la chaîne de base ne voit rien d'autre que des données ordinaires. Ce bloc n'a aucune signification pour Bitcoin : le réseau ne fait rien pour le vérifier et n'applique aucune règle à son encontre.

Par conséquent, il est tout à fait possible que des transactions Shielded Bitcoin invalides se retrouvent on-chain. Il revient à un indexeur Shielded Bitcoin, qui observe passivement la blockchain, d'ignorer les transactions qui échouent à la validation et de refuser de les appliquer lors de la mise à jour de l'état des soldes du réseau.

Des nullificateurs au lieu d'un ensemble de dépensés

Un indexeur ne supprime pas les notes d'un ensemble de notes non dépensées comme Bitcoin retire les UTXO dépensés. Il maintient plutôt un ensemble de nullificateurs. Ce mécanisme 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 laquelle. Plutôt que de vérifier si une note figure dans un "ensemble de notes non dépensées", les participants vérifient si un nullificateur donné a déjà été utilisé.

Les indexeurs construisent un arbre de Merkle qui croît indéfiniment et ne peut qu'être enrichi, contenant chaque sortie de note jamais créée, aux côtés de l'ensemble de nullificateurs.

Utiliser le protocole ne requiert qu'un nœud

L'utilisation du protocole ne nécessite rien de plus qu'un nœud Bitcoin et un indexeur Shielded Bitcoin. Aucun service, coordinateur ou état hors chaîne n'est requis pour récupérer des fonds. Cela fonctionne exactement comme Bitcoin on-chain : il suffit à l'utilisateur de son nœud/indexeur et de ses clés.

Chaque portefeuille utilisateur dérive une clé maîtresse secrète, à partir de laquelle tous les autres jeux de clés impliqués sont créés — une conception très proche d'un portefeuille HD dans Bitcoin, à partir de laquelle de nombreux jeux d'adresses peuvent être générés. sk_spend sert de clé privée de dépense, sk_nf sert à nullifier les sorties de notes, vk_in déchiffre et consulte les notes entrantes, vk_out consulte les transactions sortantes, et sk_view génère une adresse de réception.

Quand un utilisateur veut transmettre une adresse pour recevoir des fonds, il génère une valeur de diversificateur d, similaire à une valeur de dérivation, et la multiplie par sa clé sk_view. La clé publique résultante pk_d, conjointement avec d, constitue l'adresse de l'utilisateur.

L'expéditeur génère ensuite une valeur aléatoire, le r_seed, nécessaire à la fois pour le chiffrement de la sortie de note et pour la nullification. Les sorties de transaction ne contiennent que trois éléments chiffrés : la valeur de la sortie, la valeur d que le destinataire a donnée à l'expéditeur, et la valeur r_seed de l'expéditeur. Pour chiffrer, l'expéditeur utilise une paire de clés éphémère secrète et la clé publique du destinataire pour créer un secret partagé — les deux parties peuvent calculer le même secret en multipliant leur clé privée par la clé publique de l'autre. La sortie de note est chiffrée avec ce secret partagé, et la clé éphémère sk_eph est incluse en clair afin que le destinataire puisse générer lui-même le secret partagé.

Les preuves à divulgation nulle garantissent la validité

Côté entrées, deux éléments sont requis pour qu'une transaction soit valide : un nullificateur public pour chaque sortie de note consommée, et une preuve à divulgation nulle démonant 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 inflation n'a eu lieu.

Le nullificateur intègre la clé sk_nf, une valeur ρ dérivée du r_seed, et la position de la note dans l'arbre de Merkle des sorties de notes. Bien que personne ne puisse savoir à quelle sortie de note correspond un nullificateur, les preuves à divulgation nulle de chaque transaction garantissent que chaque nullificateur ajouté à l'ensemble provient d'une sortie de note valide. Les indexeurs peuvent donc simplement rejeter les nullificateurs répétés plutôt que de supprimer les notes dépensées, et tant qu'il n'y a pas de répétitions, le système fournit la même garantie contre la double dépense.

Le résultat net est que des transactions de métaprotocole chiffrées peuvent être intégrées à la blockchain Bitcoin tout en garantissant qu'aucune double dépense n'a lieu et qu'aucune pièce n'est créée ex nihilo.

Propriétés de confidentialité

Selon l'analyse, le système est bien conçu en termes de propriétés de confidentialité et se situe au niveau de quelque chose comme les pools shielded de Zcash. La comparaison esquisse le paysage plus large : Zcash offre des transactions shielded grâce à des règles intégrées à son propre protocole, tandis que cette conception poursuit des propriétés comparables sur la couche de base de Bitcoin sans toucher au consensus. Les considérations de confidentialité qui se posent au moment d'entrer et de sortir du métaprotocole seront détaillées dans un prochain article, laissant les points d'entrée et de sortie du système parmi les éléments à suivre à mesure que les travaux avancent. Contrairement aux coinjoins, il n'y a aucune préoccupation de mesure de la confidentialité ni de remixage périodique.

Verrouiller des fonds avec PIPEs v2

Le peg envisagé repose sur PIPEs v2, un schéma de chiffrement à témoin. PIPEs permettent de chiffrer une clé privée avec un programme ou mécanisme qui ne divulguera pas la clé à moins qu'une preuve ZK ne soit fournie montrant qu'une certaine condition a été remplie — par exemple, l'état d'un UTXO, ou qu'une transaction a été confirmée. Cela permettrait à un peg de fonctionner sans opérateur, sans fédération ni aucun tiers dépositaire des fonds — une propriété notable, car les conceptions de peg étendant Bitcoin se sont généralement appuyées sur de tels dépositaires. Cela ne requiert aucun soft fork ni changement de protocole pour Bitcoin et se déroule entièrement hors chaîne.

La prochaine phase des travaux de l'équipe est un mécanisme de peg permettant aux utilisateurs de déposer des fonds dans Shielded Bitcoin grâce à des clés contrôlées cryptographiquement par PIPEs, qui seraient ensuite "déverrouillées" en générant une preuve ZK de transactions de peg-out légitimes confirmées on-chain. Les travaux sur l'article définissant cet aspect du système sont en cours et devraient être publiés prochainement ; avec l'article sur la confidentialité des entrées/sorties, il comblera les éléments laissés ouverts par le livre blanc.

---

Cet article, écrit par Shinobi, est initialement paru sur Bitcoin Magazine.