Les développeurs de protocoles semblent souvent plus pessimistes quant à l’avenir de Bitcoin que la plupart des Bitcoiners. L’exposition quotidienne aux imperfections de Bitcoin façonne certainement une perspective sobre, et il est important de réfléchir à ce que Bitcoin a réalisé. N’importe qui dans le monde, quels que soient sa race, son âge, son sexe, sa nationalité ou tout autre critère arbitraire, est capable de stocker et de transférer de la valeur sur un réseau monétaire neutre plus robuste que jamais. Cela dit, Bitcoin présente des problèmes dont de nombreux Bitcoiners ne sont pas conscients, mais qui pourraient menacer ses perspectives à long terme s’ils ne sont pas résolus correctement. Les vulnérabilités corrigées par Consensus Cleanup en sont un exemple.
Le nettoyage par consensus (BIP 541) est une proposition de soft fork visant à corriger plusieurs vulnérabilités de longue date au sein du protocole de consensus Bitcoin. En tant que proposition de soft fork, elle est de nature distincte de la plupart des autres efforts Bitcoin Core présentés dans cette édition. Bien que la proposition ait été historiquement défendue par des personnes associées au projet Bitcoin Core, elle appartient en réalité à la catégorie plus large du développement de protocoles Bitcoin.
Nous passerons en revue chacun des quatre éléments de la proposition, décrivant l’impact du problème abordé et les mesures correctives appliquées. Nous discuterons de la façon dont les atténuations proposées ont évolué pour répondre aux commentaires ainsi qu’aux nouvelles vulnérabilités. Nous terminerons par un bref aperçu de l’état actuel de la proposition de soft fork.
Le réseau Bitcoin ajuste la difficulté de minage pour maintenir un taux de blocage moyen de un toutes les 10 minutes. Un bug « un par un » (une erreur de programmation courante) dans sa mise en œuvre ouvre une attaque appelée attaque Timewarp, par laquelle une majorité de mineurs peuvent accélérer artificiellement le taux de production de blocs en manipulant la difficulté vers le bas.
Cette attaque nécessite heureusement un seuil de plus de 51 % de mineurs, mais accélérer artificiellement le taux de blocage est un problème critique. Cela signifie que les nœuds complets ne contrôlent plus l’utilisation des ressources et qu’un attaquant peut considérablement accélérer le calendrier d’émission des subventions Bitcoin.
Même si cela nécessite un « mineur à 51 % », il s’agit d’un écart significatif par rapport au modèle standard de menace Bitcoin. Une attaque à 51 % permet traditionnellement à un mineur d’empêcher la confirmation d’une transaction tant qu’il conserve son avantage. Mais la présence de ce bug leur donne le pouvoir de paralyser le réseau en seulement 38 jours en réduisant rapidement les difficultés du réseau.
Au lieu de détruire le réseau, il est plus probable qu’un attaquant exploite ce bug dans une moindre mesure. Les mineurs actuels pourraient se coordonner pour quadrupler le taux de bloc (jusqu’à des blocs de 2,5 minutes) tout en maintenant le réseau Bitcoin dans un état apparemment fonctionnel, quadruplant efficacement l’espace de bloc disponible et volant des subventions globales aux futurs mineurs. Les utilisateurs myopes pourraient être incités à soutenir cette attaque, car plus d’espace de bloc disponible signifierait – ceteris paribus – des frais moins élevés pour les transactions en chaîne. Cela se ferait bien sûr au détriment des exécuteurs de nœuds complets et compromettrait la stabilité à long terme du réseau.
L’attaque Timewarp exploite le fait que les périodes d’ajustement de difficulté ne se chevauchent pas, ce qui permet de définir des horodatages de bloc de sorte qu’une nouvelle période semble commencer avant la fin de la précédente. Parce que les faire se chevaucher serait un hard fork, la meilleure solution consiste à lier les horodatages des blocs aux limites des périodes d’ajustement de difficulté. Les spécifications BIP 54 exigent que le premier bloc d’une période ne puisse pas avoir un horodatage antérieur de plus de deux heures au dernier bloc de la période précédente.
De plus, le cahier des charges BIP 54 stipule qu’une période d’adaptation à la difficulté doit toujours prendre un temps positif. Autrement dit, pour une période d’ajustement de difficulté donnée, le dernier bloc ne peut jamais avoir un horodatage antérieur à celui du premier bloc. Surpris que ce ne soit pas déjà le cas ? Nous avons été surpris que ce soit vraiment nécessaire. Il s’avère qu’il s’agit d’une solution simple pour une attaque intelligente, liée à Timewarp, que les développeurs pseudonymes Zawy et Mark « Murch » Erhardt ont proposé lors de l’examen de la proposition de Consensus Cleanup.
Tout mineur peut exploiter certaines opérations de validation coûteuses pour créer des blocs dont la vérification prend beaucoup de temps. Alors qu’un bloc Bitcoin normal prend de l’ordre d’une centaine de millisecondes à valider, les temps de validation de ces « blocs d’attaque » vont de plus de dix minutes sur un ordinateur haut de gamme à jusqu’à dix heures sur un Raspberry Pi (un choix matériel populaire à nœud complet).
Un attaquant motivé de l’extérieur peut en tirer parti pour perturber l’ensemble du réseau, tandis que dans une variante d’attaque plus rationnelle du point de vue économique, un mineur peut retarder sa concurrence juste assez longtemps pour augmenter ses profits sans créer de perturbation généralisée du réseau.
Les tentatives historiques pour atténuer ce problème ont été tumultueuses, car elles nécessitent d’imposer des restrictions sur les capacités de script de Bitcoin. De telles restrictions ont le potentiel d’être confiscatoires, ce qu’il est primordial d’éviter dans toute conception sérieuse de soft fork.
Le Great Consensus Cleanup original de Matt Corallo de 2019 proposait de résoudre ces longs temps de validation de bloc en invalidant quelques opérations obscures dans un script non Segwit (« hérité »). Certains ont exprimé leur inquiétude quant au fait que, bien que les transactions utilisant ces opérations n’aient pas été relayées ni exploitées par défaut par Bitcoin Core depuis des années, quelqu’un, quelque part, pourrait encore en dépendre à l’insu de tous. Bien entendu, cela doit être mis en balance avec le risque pratique pour tous les utilisateurs de Bitcoin d’un mineur exploitant ce problème.
Même si le problème de la confiscation est assez théorique, il existe un point philosophique sur la manière de développer le protocole Bitcoin en essayant de concevoir une atténuation appropriée de la vulnérabilité avec la plus petite surface de confiscation possible. Ma dernière itération de la proposition Consensus Cleanup a répondu à cette préoccupation en introduisant une limite qui identifie exactement le comportement nuisible, sans invalider aucune opération spécifique du script Bitcoin.
Les en-têtes de bloc Bitcoin contiennent une racine Merkle qui s’engage sur toutes les transactions du bloc. Cela permet de donner une preuve succincte qu’une transaction donnée fait partie d’une chaîne avec un certain nombre de Proof of Work. C’est ce qu’on appelle communément une « preuve SPV ».
En raison d’une faiblesse dans la conception de l’arbre Merkle, l’inclusion d’une transaction de 64 octets spécialement conçue dans un bloc permet à un attaquant de forger une telle preuve pour une fausse transaction arbitraire (inexistante). Cela peut être utilisé pour tromper les vérificateurs SPV, couramment utilisés pour valider les paiements entrants ou les dépôts dans un système parallèle. Il existe des mesures d’atténuation qui permettent aux vérificateurs de rejeter de telles preuves invalides ; cependant, ceux-ci sont souvent négligés, même par les experts en cryptographie, et peuvent s’avérer fastidieux dans certains contextes.
Le Consensus Cleanup résout ce problème en invalidant les transactions dont la taille sérialisée est exactement de 64 octets. De telles transactions ne peuvent pas être sécurisées en premier lieu (elles ne peuvent que brûler des fonds ou les laisser à n’importe qui) et n’ont pas été relayées ou exploitées par défaut par Bitcoin Core depuis 2019. Des approches alternatives ont été discutées, comme un moyen détourné d’améliorer l’atténuation existante.unmais les auteurs ont choisi de résoudre la cause première du problème, éliminant à la fois la nécessité pour les responsables de la mise en œuvre d’appliquer l’atténuation et la nécessité pour eux de connaître la vulnérabilité en premier lieu.
un: s’engager sur la profondeur de l’arborescence Merkle dans une partie du champ de version de l’en-tête du bloc
« Mirco… Mezzo… Macroflation – Économie surchauffée » est le titre d’un article de blog4 Russell O’Connor a publié en février 2012 une publication dans laquelle il décrit comment les transactions Bitcoin peuvent être dupliquées. Il s’agissait d’une faille critique de Bitcoin, qui a brisé l’hypothèse fondamentale selon laquelle les identifiants de transaction (hachages) sont uniques. En effet, les transactions Coinbase des mineurs ont une seule entrée vide, ce qui signifie que toute transaction Coinbase avec les mêmes sorties aurait un identifiant de transaction identique.
Ce problème a été corrigé par les développeurs de Bitcoin Core (alors encore appelé « Bitcoin ») avec BIP 30.2qui nécessitait que les nœuds complets effectuent une validation supplémentaire lors de la réception d’un bloc. Cette validation supplémentaire n’était pas strictement nécessaire pour résoudre le problème et a été contournée avec le BIP 34.3 la même année. Malheureusement, le correctif introduit dans le BIP 34 est imparfait et la validation supplémentaire du BIP 30 sera à nouveau requise dans 20 ans. Au-delà d’être strictement nécessaire, cette validation ne peut pas être effectuée par des conceptions alternatives de clients Bitcoin telles que Utreexo et les empêcherait effectivement de valider complètement la chaîne de blocs.
Le Consensus Cleanup introduit une solution plus robuste et évolutive au problème. Toutes les transactions Bitcoin, y compris les transactions Coinbase, contiennent un champ pour « verrouiller le temps » la transaction. La valeur du champ représente la dernière hauteur de bloc à laquelle une transaction n’est pas valide. Les spécifications BIP 54 exigent que toutes les transactions Coinbase définissent ce champ à la hauteur de leur bloc (moins 1).
Combiné avec une suggestion intelligente d’Anthony Towns pour garantir que la validation du timelock se produit toujours, cela garantit qu’aucune transaction coinbase avec la même valeur de timelock n’a pu être incluse dans un bloc précédent. Cela garantit à son tour qu’aucune transaction Coinbase ne peut avoir le même identifiant unique (hachage) qu’une transaction précédente, sans nécessiter une validation BIP 30.
Les vulnérabilités corrigées par le Consensus Cleanup (BIP 54) ne constituent pas une menace existentielle pour Bitcoin pour le moment. Même si certaines d’entre elles ont le potentiel de paralyser le réseau, il est peu probable qu’elles soient exploitées pour l’instant. Cela dit, cela pourrait changer et il est primordial que nous atténuions de manière proactive les risques à long terme pour le réseau Bitcoin, même si cela signifie devoir supporter le fardeau à court terme de la coordination d’un soft fork.
Le travail sur le Consensus Cleanup a commencé avec la proposition originale de Matt Corallo en 2019. Il s’est concrétisé 6 ans plus tard avec ma publication du BIP 54 et une implémentation du soft fork dans Bitcoin Inquisition, un banc d’essai pour les changements de consensus Bitcoin. Tout au long de cette période, la proposition a reçu de nombreux retours, diverses alternatives ont été envisagées et des mesures d’atténuation des faiblesses supplémentaires ont été intégrées. Je pense qu’il est maintenant prêt à être partagé avec les utilisateurs de Bitcoin pour examen.
Le Consensus Cleanup est un soft fork. Les développeurs du protocole Bitcoin choisissent les améliorations à prioriser et à mettre à la disposition du public. Mais la décision finale d’adopter une modification des règles de consensus de Bitcoin appartient aux utilisateurs. Le choix vous appartient.
Ne manquez pas votre chance de posséder La question centrale — présentant des articles rédigés par de nombreux développeurs principaux expliquant les projets sur lesquels ils travaillent eux-mêmes !
Cet article est la lettre de l’éditeur présentée dans la dernière édition imprimée du magazine Bitcoin, The Core Issue. Nous le partageons ici comme un premier aperçu des idées explorées tout au long du numéro complet.
[1] https://github.com/bitcoin/bips/blob/master/bip-0054.md
[2] https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
[4] https://r6.ca/blog/20120206T005236Z.html