Tadge Dryja

Imaginez que chaque café payé doive être vérifié séparément par des nœuds dans le monde entier, ces ordinateurs qui vérifient les règles de Bitcoin. Comment permettre davantage de paiements sans exiger des ordinateurs toujours plus puissants pour exploiter son propre nœud ? Joseph Poon et Thaddeus Dryja ont exploré un réseau de canaux de paiement. Le livre blanc lié ici présente leur proposition, datée du 14 janvier 2016 et marquée DRAFT 0.5.9.2. Ce document historique explique l’origine de l’idée ; les règles précises des logiciels actuels se trouvent dans leur propre documentation. [1]

Un canal de paiement peut se comprendre comme un accord régulièrement actualisé sur le partage de bitcoins déposés à l’avance. Chaque paiement modifie la part de chaque participant. Ils signent ces changements sans publier chacun d’eux dans la blockchain, l’historique commun des transactions. Lorsque la coopération prend fin, une transaction Bitcoin permet de faire appliquer la répartition. Lightning déplace ainsi de nombreuses mises à jour hors de la blockchain, tandis que le règlement final repose toujours sur les règles de Bitcoin. [1]

Un accord antérieur peut attribuer davantage d’argent à une personne qui en a dépensé une partie depuis. Dans le modèle de révocation décrit par la proposition, publier un état invalidé permet à l’autre participant de réagir avec une transaction de pénalité. Il doit cependant agir dans un délai défini. Le participant ou un surveillant mandaté doit donc observer la blockchain. En pratique, la cryptographie ne rend pas sûre une déconnexion permanente sans surveillance. Organiser un suivi fiable fait partie de la protection des fonds. [1]

Bitcoin ne connaît pas spontanément le taux de change à une date convenue. Les Discreet Log Contracts, ou DLC, permettent de traiter des contrats dont le règlement dépend de cette information. Deux participants préparent les conditions et les versements possibles. Un oracle choisi, c’est-à-dire une source de données extérieure, signe ensuite une annonce du résultat. Les participants l’utilisent pour effectuer le règlement correspondant. Dans ce modèle, l’oracle ne détient pas leurs fonds et n’a pas besoin de savoir qui utilise ses annonces. Il fournit une information sans administrer leur portefeuille. [2]

Une signature numérique aide à identifier l’auteur d’un message et à vérifier son intégrité. Elle ne prouve pas que son contenu est vrai. L’oracle peut annoncer un taux erroné ou ne rien publier. Pour ce silence, Dryja décrit une transaction de remboursement préparée à l’avance, publiable après un délai convenu. Les fonds ne reviennent pas tout seuls : cette possibilité doit faire partie du contrat et quelqu’un doit l’utiliser. Choisir une source fiable et prévoir sa défaillance restent donc essentiels. [2]

Dryja s’est aussi intéressé aux données nécessaires à un nœud pour vérifier les paiements. Les UTXO sont les sorties de transaction non dépensées : des montants individuels assortis de conditions de dépense. Utreexo permet au nœud de représenter leur ensemble par un résumé cryptographique compact, appelé accumulateur. Le paiement s’accompagne d’une preuve que la sortie utilisée appartient à cet ensemble. Cela réduit les données conservées sur l’état actuel. Cela ne supprime pas la vérification des règles et ne compresse pas tout l’historique de Bitcoin dans un minuscule fichier. [4]

Les preuves Utreexo doivent parvenir au vérificateur. Un état conservé plus petit peut donc exiger davantage de données transmises. Le résumé de recherche décrit une simulation du téléchargement de la blockchain jusqu’au début de 2019 : avec 500 MB de cache, une mémoire temporaire, les preuves ajoutaient environ 25 % aux données téléchargées. Ces 500 MB ne représentent pas toute la mémoire du nœud. C’est le résultat d’une expérience précise, pas une garantie des besoins actuels. Il faut examiner ensemble l’espace disque, la mémoire et les transferts. [3]

Dans ses souvenirs publiés par MIT DCI, Dryja raconte ses débuts informels au MIT : venu avec un ordinateur, il discutait de Bitcoin et aidait des étudiants. La directrice Neha Narula lui a alors proposé d’y travailler. Ils ont ensuite enseigné ensemble. Dans ce même texte d’adieu, il annonçait son départ pour Lightspark afin de poursuivre ses travaux sur Bitcoin et Lightning. Ce récit décrit une étape de sa carrière, sans établir son emploi actuel. Ses publications, son code et ses idées expliquent mieux sa contribution qu’un simple intitulé de poste. [5]