Bitcoin Optech – Revue annuelle 2022

by
Ailleurs
My articles My books
Follow on:

Revue annuelle de Bitcoin Optech du 21 décembre 2022 traduit par @copinmalin.

Cette édition spéciale de la lettre d’information Optech résume les faits marquants de l’évolution du bitcoin pendant toute l’année 2022. C’est la suite de nos résumés des années précédentes 2018, 2019, 2020, et 2021.

• Janvier
• Février
• Mars
• Avril
• Mai
• Juin
• Juillet
• Aout
• Septembre
• Octobre
• Novembre
• Decembre
• Résumés en vedette

Janvier

En janvier, LDK a fusionné une implémentation de factures apatrides, qui lui permet de générer un nombre infini de factures sans stocker aucune donnée à leur sujet, sauf si le paiement est réussi. Les factures sans état ont déjà été proposées en septembre 2021 et la mise en œuvre de LDK diffère de la méthode suggérée, bien qu’elle accomplisse le même objectif et ne nécessite aucun changement du protocole LN. Plus tard dans le mois, une mise à jour de la spécification LN a été fusionnée pour permettre d’autres types de factures sans état, avec un support au moins partiel ajouté à Eclair, Core Lightning et LND.

En janvier également, un fond de défense juridique Bitcoin a été annoncé par Jack Dorsey, Alex Morcos et Martin White. Il fournit “une entité à but non lucratif qui vise à minimiser les maux de tête juridiques qui découragent les développeurs de logiciels de développer activement Bitcoin et les projets connexes.”

Février

La prise en charge précoce par LDK des factures apatrides lui a permis d’ajouter une méthode nouvelle et simple pour le chargement équilibrant un nœud LN appelé paiements de nœuds fantômes.

Mars

L’algorithme de recherche de route publié pour la première fois en 2021 par René Pickhardt et Stefan Richter a reçu une mise à jour en mars, Pickhardt soulignant une amélioration rendant l’algorithme bien plus efficace computationnellement parlant.

Une méthode cohérente pour permettre l’utilisation des canaux zéro-conf a été spécifiée et a commencé à être implémentée, en débutant par l’addition au LDK en mars du champs alias pour les identifiants de canaux (Short Channel Identifier, SCID), suivi par Eclair, Core Lightning et LND.

Avril

En avril, Ruben Somsen a proposé l’idée des paiements silencieux, qui permettraient à quelqu’un de payer un identifiant public (une “adresse”) sans pour autant utiliser cet identifiant on-chain. Cela participerait à réduire la réutilisation d’adresse. Par exemple, Alice pourrait publier un identifiant public sur son site internet, que Bob serait ensuite en mesure de transformer en une adresse Bitcoin unique que seule Alice peut dépenser. Si Carole se rend par la suite sur le site d’Alice et réutilise le même identifiant public, elle dérivera une adresse différente pour payer Alice, que ni Bob ni aucune autre tierce partie ne pourra relier à Alice. Par la suite, le développeur W0ltx a proposé une implémentation des silent payments pour Bitcoin Core, y apportant ultérieurement d’importantes mises à jour.

Lightning Labs a annoncé Taro, une proposition de protocole (basée sur diverses propositions) permettant de créer et transférer des tokens arbitraires sur la chaîne Bitcoin. L’ambition de Taro est d’être utilisé conjointement au Lightning Network pour router des transactions off-chain au travers du réseau. Similairement à des propositions antérieures pour des transferts entre différents actifs au sein du LN, les noeuds intermédiaires qui se contentent de transférer les paiements n’ont pas besoin d’être conscients du protocole Taro ou des détails des différents actifs transférés—ils se contentent de transférer des bitcoins en utilisant le même protocole que n’importe quel autre paiement Lightning.

Avril a aussi été l’occasion d’une discussion autour de l’échange de clés post-quantique, permettant aux utilisateurs de recevoir des bitcoins sécurisés par des clés résistantes aux attaques menées par les ordinateurs quantiques rapides qui pourraient exister dans le futur.

Mai

Le protocole MuSig2 pour la création de multi-signatures schnorr a connu plusieurs développements en 2022. Une proposition de BIP a reçu d’importants retours d’informations en Mai. Plus tard, en octobre, Yannick Seurin, Tim Ruffing, Elliott Jin, and Jonas Nick ont découvert une vulnérabilité affectant certaines façons dont le protocole pourrait être utilisé. Les chercheurs ont annoncé qu’ils prévoyaient de corriger cela à l’occasion d’une mise à jour.

Un projet de BIP pour le relai de paquet a été posté par Gloria Zhao en Mai. Le relai de paquet corrige un problème important avec les variations de frais “fee bumping” CPFP sur Bitcoin Core où les nœuds individuels n’accepteront une transaction enfant de type “fee-bumping” que si sa transaction parent paye un taux supérieur au taux minimum dynamique du mempool du nœud. Cela rend le CPFP insuffisamment fiable pour les protocoles dépendant de transactions présignées, tels que de nombreux protocoles de contrats (y compris le protocole LN actuel). Le relai des paquets permet d’évaluer une transaction parent et enfant comme une seule unité, éliminant le problème—sans pour autant éliminer d’autres problèmes connexes tels que l’épinglage des transactions. Une discussion supplémentaire sur le relai des paquets s’est produit en Juin.

Le mois de mai a également vu la première fusion du projet de bibliothèque du noyau de Bitcoin (libbitcoinkernel), une tentative de séparer autant que possible le code de consensus de Bitcoin Core dans une bibliothèque séparée, même si ce code comporte encore du code non-consensuel. À long terme, l’objectif est de réduire libbitcoinkernel jusqu’à ce qu’elle ne contienne plus que du code de consensus, ce qui permettra à d’autres projets d’utiliser facilement ce code ou aux auditeurs d’analyser les modifications apportées à la logique de consensus de Bitcoin Core. Plusieurs autres PR de libbitcoinkernel seront fusionnés au cours de l’année.

Juin

En juin, les développeurs LN se sont rencontrés news204 ln pour discuter de l’avenir du développement des protocoles. Parmi les sujets abordés, citons les canaux LN basés sur taproot, tapscript et MuSig2 (y compris MuSig2 récursif), la mise à jour du protocole de gossip pour annoncer les canaux nouveaux et modifiés, les messages en oignons, les chemins aveugles, le sondage et partage d’équilibre, le routage trampoline, et les protocoles d’offres et LNURL.

Juillet

En juillet, Bastien Teinturier a publié un résumé d’une idée qu’il attribue à Rusty Russell pour limiter le débit des messages en oignon afin d’empêcher les attaques par déni de service. Cependant, Olaoluwa Osuntokun a suggéré de reconsidérer sa proposition de mars pour empêcher l’abus des messages en oignon en faisant payer le relai des données. Il semble que la plupart des développeurs participant à la discussion préfèrent tenter de limiter le débit avant d’ajouter des frais supplémentaires au protocole.

Ce mois-ci, Bitcoin Core a également fusionné un PR en ajoutant la prise en charge de la surveillance uniquement pour les descripteurs de script de sortie écrits en miniscript. Un futur PR devrait permettre au portefeuille de créer des signatures pour les descripteurs de dépenses basés sur miniscript. À mesure que d’autres portefeuilles et dispositifs de signature mettent en œuvre la prise en charge de miniscript, il devrait être plus facile de transférer des politiques entre portefeuilles ou de faire coopérer plusieurs portefeuilles pour dépenser des bitcoins, par exemple des politiques multi-sig ou des politiques impliquant différents signataires pour différentes occasions (par exemple, des signataires de secours)

Août

En août, Eclair a fusionné le support pour le protocole de financement interactif, une dépendance pour le protocole de financement double qui permet à l’un (ou aux deux) des deux noeuds de contribuer aux fonds d’un nouveau canal LN. Plus tard dans le mois, une autre fusion a apporté à Eclair un support expérimental pour le double financement. Un protocole ouvert pour le double financement peut contribuer à garantir que les commerçants ont accès à des canaux qui leur permettent de recevoir immédiatement les paiements des clients.

Antoine Riard et Gleb Naumenko ont publiés un guide sur les attaques par brouillage de canaux et proposé plusieurs ssolutions. Pour chaque canal qu’un attaquant contrôle, il peut rendre plus d’une douzaine d’autres canaux inutilisables en envoyant des paiements qui n’aboutissent jamais—ce qui signifie que l’attaquant n’a pas besoin de payer de coûts directs. Le problème est connu depuis 2015, mais aucune solution proposée précédemment n’a été largement acceptée. En novembre, Clara Shikhelman et Sergei Tikhomirov publiaient leur propre papier avec une analyse et une proposition de solution basée sur de petits frais initiaux et des renvois automatisés basés sur la réputation. Par la suite, Riard a publié une solution alternative impliquant des jetons non négociables spécifiques aux nœuds. En décembre, Joost Jager annonce un utilitaire “simple mais imparfait” qui pourrait aider les nœuds à atténuer certains problèmes de brouillage sans nécessiter de modifications du protocole LN.

Lloyd Fournier a écrit sur les avantages des oracles DLC qui font leurs attestations en utilisant des signatures Boneh-Lynn-Shacham (BLS). Bitcoin ne prend pas en charge les signatures BLS et un soft fork serait nécessaire pour les ajouter, mais Fournier renvoie à un article qu’il a co-écrit et qui décrit comment les informations peuvent être extraites en toute sécurité d’une signature BLS et utilisées avec des adaptateurs de signature compatibles avec Bitcoin sans aucune modification de Bitcoin. Cela permettrait d’avoir des oracles “sans état” où les parties à un contrat (mais pas l’oracle) pourraient se mettre d’accord en privé sur les informations qu’elles veulent que l’oracle atteste, par exemple en spécifiant un programme écrit dans n’importe quel langage de programmation qu’ils savent que l’oracle peut exécuter. Ils pourraient ensuite allouer leurs fonds de dépôt conformément au contrat sans même dire à l’oracle qu’ils prévoyaient de l’utiliser. Au moment de régler le contrat, chacune des parties pouvait exécuter le programme elle-même et, si elles étaient toutes d’accord sur le résultat, régler le contrat en coopération sans faire intervenir l’oracle. Si elles n’étaient pas d’accord, n’importe laquelle d’entre elles pouvait envoyer le programme à l’oracle (peut-être avec un petit paiement pour son service) et recevoir en retour une attestation BLS du code source du programme et de la valeur obtenue en l’exécutant. L’attestation pourrait être transformée en signatures qui permettraient de régler le DLC sur la chaîne. Comme avec les contrats DLC actuels, l’oracle ne saurait pas quelles transactions onchain sont basées sur ses signatures BLS.

Septembre

Lisa Neigut a posté sur la liste de diffusion Lightning-Dev une proposition de tarification des frais qui permettrait à un nœud d’annoncer quatre tarifs échelonnés pour les frais de transfert. Une meilleure publicité des frais d’acheminement, y compris la possibilité de fixer des frais négatifs dans certains cas, pourrait contribuer à garantir que les nœuds d’acheminement ont suffisamment de capacité pour relayer les paiements vers leur destination finale. Le développeur ZmnSCPxj, qui avait [posté]news204 lnfees] sa propre solution payante pour améliorer le routage plus tôt dans l’année, a décrit une façon simple d’utiliser les cartes tarifaires : “vous pouvez modéliser une carte tarifaire comme quatre canaux séparés entre les deux mêmes nœuds, avec des coûts différents pour chacun. Si le chemin au coût le plus bas échoue, il suffit d’essayer une autre route qui peut avoir plus de sauts mais un coût effectif plus faible, ou bien essayer le même canal à un coût plus élevé.” Une autre méthode de contrôle des flux de paiement a été suggérée par René Pickhardt.

Octobre

En octobre, Gloria Zhao a proposé d’autoriser les transactions via la version numéro 3 à utiliser un ensemble modifié de politiques de relais de transaction. Ces politiques sont basées sur l’expérience de l’utilisation de CPFP et de RBF, plus des idées pour les relais de paquets, et sont conçues pour aider à prévenir les attaques par épinglage contre les protocoles de contrat à deux parties comme LN—en s’assurant que les utilisateurs peuvent rapidement obtenir des transactions confirmées pour fermer les canaux, régler les paiements (HTLCs), et appliquer les pénalités pour mauvais comportement. Greg Sanders suivra plus tard dans le mois avec une proposition supplémentaire pour les ancres éphémères, une forme simplifiée des sorties ancrées déjà utilisables avec la plupart des implémentations de LN.

Eclair a ajouté le support pour une forme basique de paiements asynchrones lorsque le relai par tremplin est utilisé. Les paiements asynchrones permettent de payer un nœud hors ligne (comme un portefeuille mobile) sans confier les fonds à un tiers. Le mécanisme idéal pour les paiements asynchrones dépend de PTLC, mais une implémentation partielle nécessite simplement qu’un tiers retarde l’envoi des fonds jusqu’à ce que le nœud hors ligne revienne en ligne. Les nœuds Trampoline peuvent fournir ce délai et ce PR les utilise donc pour permettre l’expérimentation des paiements asynchrones.

Le mois d’octobre a également été marqué par le premier de deux bogues d’analyse des blocs qui ont affecté plusieurs applications. Un bogue déclenché accidentellement dans BTCD l’a empêché, ainsi que le programme en aval LND, de traiter les derniers blocs. Cela aurait pu conduire les utilisateurs à perdre des fonds, bien qu’aucun problème de ce type n’ait été signalé. Un deuxième bogue apparenté, cette fois-ci délibérément déclenché, a de nouveau affecté BTCD et LND, ainsi que les utilisateurs de certaines versions de Rust-Bitcoin. Là encore, les utilisateurs risquaient de perdre de l’argent, bien que nous n’ayons pas connaissance d’incidents signalés.

John Light a posté un rapport de recherche qu’il a préparé sur les validity rollups—un type de sidechain où l’état actuel de la sidechain est stocké de manière compacte sur la chaîne principale. Un propriétaire de bitcoins de sidechain peut utiliser l’état stocké sur la chaîne principale pour prouver combien de bitcoins il contrôle dans la sidechain. En soumettant une transaction sur la chaîne principale avec une preuve de validité, il peut retirer les bitcoins qu’il possède sur la chaîne latérale, même si les opérateurs ou les mineurs de la chaîne latérale tentent d’empêcher le retrait. Les recherches de Light décrivent en profondeur les validity rollups, examinent la manière dont leur prise en charge pourrait être ajoutée à Bitcoin et étudient les différents problèmes liés à leur mise en œuvre.

La proposition de BIP324 pour un protocole de transport P2P v2 crypté a été mise à jour et discutée sur la liste de diffusion pour la première fois en trois ans. Le cryptage du transport des transactions non confirmées peut aider à cacher leur origine aux oreilles indiscrètes qui contrôlent de nombreux relais Internet (par exemple, les grands FAI et les gouvernements). Il peut également aider à détecter les falsifications et éventuellement rendre les attaques par éclipse plus difficiles.

Lors d’une réunion des développeurs du protocole Bitcoin, plusieurs sessions ont été transcrites par Bryan Bishop, notamment des discussions sur le cryptage du transport, les frais de transaction et la sécurité économique, le schéma FROST threshold signature, la durabilité de l’utilisation de GitHub pour l’hébergement de discussions sur le code source et le développement, y compris les spécifications prouvables dans les BIP, le relais de paquet et le relai de transaction v3, le protocole minier Stratum version 2, et la fusion du code dans Bitcoin Core et d’autres projets de logiciels libres.

Novembre

Le mois de novembre a vu Joost Jager mettre à jour une proposition de 2019 visant à améliorer le signalement des erreurs dans LN en cas d’échec des paiements. L’erreur signalerait l’identité d’un canal où un paiement n’a pas pu être transmis par un nœud afin que le payeur puisse éviter d’utiliser les canaux impliquant ce nœud pendant un temps limité. Plusieurs implémentations de LN ont mis à jour leur code pour prendre en charge la proposition, même si elles n’ont pas immédiatement commencé à l’utiliser elles-mêmes, notamment Eclair et Core Lightning.

Décembre

En décembre, le développeur de protocole John Law a posté sur la liste d’envoi Lightning-Dev sa troisième proposition majeure de l’année. Comme ses deux précédentes propositions, il a suggéré de nouvelles façons dont les transactions hors chaîne de LN pourraient être conçues pour permettre l’ajout de nouvelles fonctionnalités sans nécessiter de modification au code de consensus de Bitcoin. Dans l’ensemble, Law a proposé des moyens pour les utilisateurs occasionnels de LN de rester hors ligne pendant plusieurs mois, séparer l’exécution de paiements spécifiques de la part du gestionnaire de tous les fonds réglés afin d’améliorer la compatibilité avec les watchtowers, et optimisé les canaux LN pour une utilisation en usines à canaux qui pourrait réduire de manière significative les coûts de l’utilisation du LN sur la chaîne.

Nous remercions tous les contributeurs de Bitcoin cités ci-dessus, ainsi que les nombreuses personnes dont le travail était tout aussi important, pour une autre année incroyable de développement du bitcoin. La lettre d’information d’Optech reprendra son cours normal de publication dès le mercredi 4 janvier.