En attente de confirmation : une série sur le mempool et la politique de relais

by Gloria Zhao and Murch

Copies de toutes les parties publiées de notre série hebdomadaire sur le relais de transaction, l’inclusion dans le mempool et la sélection des transactions minières—y compris pourquoi Bitcoin Core a une politique plus restrictive que celle autorisée par le consensus et comment les portefeuilles peuvent utiliser cette politique de la manière la plus efficace.

Pourquoi avons-nous un mempool ?
Mesures d’incitation
Enchères pour l’achat d’un bloc d’espace
Estimation des taux de frais
Politique de protection des ressources des nœuds
Cohérence des politiques
Ressources du réseau
La politique comme interface
Propositions de politique
Impliquez-vous

Pourquoi avons-nous un mempool ?

Originally published in Newsletter #251

De nombreux nœuds du réseau Bitcoin stockent les transactions non confirmées dans un réservoir de mémoire, ou mempool. Ce cache est une ressource importante pour chaque nœud et permet au réseau de relais de transactions de pair à pair de fonctionner.

Les nœuds qui participent au relais de transaction téléchargent et valident les blocs progressivement plutôt que par pics. Toutes les 10 minutes environ, lorsqu’un bloc est trouvé, les nœuds sans mempool connaissent un pic de bande passante, suivi d’une période de calcul intensif pour valider chaque transaction. D’un autre côté, les nœuds disposant d’un mempool ont généralement déjà vu toutes les transactions du bloc et les stockent dans leurs mempools. Avec compact block relay, ces nœuds téléchargent simplement un en-tête de bloc avec des “shortids”, puis reconstruisent le bloc à l’aide des transactions de leurs mempools. La quantité de données utilisées pour relayer les blocs compacts est minime par rapport à la taille du bloc. La validation des transactions est également beaucoup plus rapide : le nœud a déjà vérifié (et mis en cache) les signatures et les scripts, calculé les exigences en matière de timelock, et chargé les UTXO pertinents à partir du disque si nécessaire. Le nœud peut également transmettre rapidement le bloc à ses autres pairs, ce qui augmente considérablement la vitesse de propagation des blocs à l’échelle du réseau et réduit ainsi le risque de blocs périmés.

Les mempools peuvent également être utilisés pour construire un estimateur de frais indépendant. Le marché de l’espace de blocs est une vente aux enchères, et la tenue d’un mempool permet aux utilisateurs d’avoir une meilleure idée de ce que les autres proposent et des offres qui ont été retenues dans le passé.

Cependant, il n’existe pas “un” mempool unique—chaque nœud peut recevoir des transactions différentes. Le fait de soumettre une transaction à un nœud ne signifie pas nécessairement qu’elle a été transmise aux mineurs. Certains utilisateurs sont frustrés par cette incertitude et se demandent pourquoi ils ne soumettent pas leurs transactions directement aux mineurs.

Considérons un réseau Bitcoin dans lequel toutes les transactions sont envoyées directement des utilisateurs aux mineurs. Il serait possible de censurer et de surveiller l’activité financière en demandant au petit nombre d’entités d’enregistrer les adresses IP correspondant à chaque transaction et de refuser toute transaction correspondant à un modèle particulier. Ce type de Bitcoin peut parfois être plus pratique, mais il serait dépourvu de quelques-unes des propriétés les plus précieuses de Bitcoin.

La résistance à la censure et la confidentialité de Bitcoin proviennent de son réseau peer-to-peer. Pour relayer une transaction, chaque nœud peut se connecter à un ensemble anonyme de pairs, dont chacun peut être un mineur ou une personne liée à un mineur. Cette méthode permet d’obscurcir le nœud d’où provient une transaction ainsi que le nœud qui peut être chargé de la confirmer. Une personne souhaitant censurer des entités particulières peut cibler des mineurs, des bourses populaires ou d’autres services de soumission centralisés, mais il serait difficile de bloquer complètement quoi que ce soit.

La disponibilité générale des transactions non confirmées permet également de minimiser le coût d’entrée pour devenir un producteur de blocs—une personne qui n’est pas satisfaite des transactions sélectionnées (ou exclues) peut commencer à miner immédiatement. Le fait de traiter chaque nœud comme un candidat égal pour la diffusion des transactions évite de donner à un mineur un accès privilégié aux transactions et à leurs frais.

En résumé, un mempool est un cache extrêmement utile qui permet aux nœuds de répartir les coûts de téléchargement et de validation des blocs dans le temps, et qui donne aux utilisateurs l’accès à une meilleure estimation des frais. Au niveau du réseau, les mempools soutiennent un réseau distribué de transactions et de relais de blocs. Tous ces avantages sont plus prononcés lorsque tout le monde voit toutes les transactions avant que les mineurs ne les incluent dans les blocs - tout comme n’importe quel cache, un mempool est le plus utile lorsqu’il est “chaud” et doit être limité en taille pour tenir dans la mémoire. La semaine prochaine, nous étudierons l’utilisation de la compatibilité incitative comme mesure permettant de conserver les transactions les plus utiles dans les mempools.

Mesures d’incitation

Originally published in Newsletter #252

L’article de la semaine dernière traitait du mempool comme d’un cache de transactions non confirmées qui fournit une méthode décentralisée permettant aux utilisateurs d’envoyer des transactions aux mineurs. Cependant, les mineurs ne sont pas obligés de confirmer ces transactions ; un bloc contenant uniquement une transaction coinbase est valide selon les règles du consensus. Les utilisateurs peuvent inciter les mineurs à inclure leurs transactions en augmentant la valeur totale d’entrée sans modifier la valeur totale de sortie, ce qui permet aux mineurs de réclamer la différence en tant que frais de transaction.

Bien que les frais de transaction soient courants dans les systèmes financiers traditionnels, les nouveaux utilisateurs de Bitcoin sont souvent surpris de constater que les frais sur la chaîne sont payés non pas en proportion du montant de la transaction, mais en fonction du poids de la transaction. C’est l’espace disponible sur les blocs, et non la liquidité, qui est le facteur limitant. Le taux de change est généralement libellé en satoshis par octet virtuel.

Les règles de consensus limitent l’espace utilisé par les transactions dans chaque bloc. Cette limite permet de maintenir des temps de propagation des blocs faibles par rapport à l’intervalle entre les blocs, ce qui réduit le risque de blocs périmés. Elle permet également de limiter la croissance de la chaîne de blocs et de l’ensemble d’UTXO, qui contribuent directement au coût de démarrage et de maintenance d’un nœud complet.

Ainsi, dans le cadre de leur rôle de cache de transactions non confirmées, les mempools facilitent également une vente aux enchères publique pour l’espace de bloc inélastique : lorsqu’elle fonctionne correctement, la vente aux enchères fonctionne selon les principes du marché libre, c’est-à-dire que la priorité est basée uniquement sur les frais plutôt que sur les relations avec les mineurs.

La maximisation des frais lors de la sélection des transactions pour un bloc (dont le poids total et les opérations de signature sont limités) est un problème NP-hard. Ce problème est encore compliqué par les relations entre les transactions : l’extraction d’une transaction à taux élevé peut nécessiter l’extraction de son parent à taux faible. En d’autres termes, l’extraction d’une transaction à faible taux de falsification peut ouvrir la possibilité d’extraire son enfant à taux de falsification élevé.

Le mempool de Bitcoin Core calcule le taux de frais de chaque entrée et de ses ascendants (appelé ancestor feerate), met en cache ce résultat et utilise un algorithme de construction de modèle de bloc avide. Il trie le mempool dans l’ordre du score d’ancêtre (le minimum du taux de frais de l’ascendant et du taux de frais individuel) et sélectionne les paquets d’ascendants dans cet ordre, en mettant à jour les informations sur les frais et le poids des ascendants des transactions restantes au fur et à mesure. Cet algorithme offre un équilibre entre performance et rentabilité et ne produit pas nécessairement des résultats optimaux. Son efficacité peut être améliorée en limitant la taille des transactions et des paquets ascendants—Bitcoin Core fixe ces limites à 400 000 et 404 000 unités de poids, respectivement.

De même, un descendant score est calculé et utilisé lors de la sélection des paquets à expulser du mempool, car il serait désavantageux d’expulser une transaction à faible taux de frais qui a un descendant à fort taux de frais.

La validation du Mempool fait également appel à des frais et à des tarifs lorsqu’il s’agit de transactions qui dépensent les mêmes intrants, c’est-à-dire des transactions à double dépense ou des transactions conflictuelles. Au lieu de toujours conserver la première transaction qu’ils voient, les nœuds utilisent un ensemble de règles pour déterminer quelle transaction est la plus incitative à conserver. Ce comportement est connu sous le nom de Replace by Fee.

Il est intuitif que les mineurs maximisent les frais, mais pourquoi un opérateur de nœud non-mineur devrait-il mettre en œuvre ces politiques ? Comme indiqué dans le billet de la semaine dernière, l’utilité du pool de mémoire d’un nœud non-mineur est directement liée à sa similarité avec les pools de mémoire des mineurs. Ainsi, même si un opérateur de nœud n’a jamais l’intention de produire un bloc en utilisant le contenu de son mempool, il a intérêt à conserver les transactions les plus compatibles avec les incitations.

Bien qu’il n’y ait pas de règles consensuelles exigeant que les transactions paient des frais, les frais et le taux de frais jouent un rôle important dans le réseau Bitcoin en tant que moyen “équitable” de résoudre la concurrence pour l’espace des blocs. Les mineurs utilisent le taux de frais pour évaluer l’acceptation, l’expulsion et les conflits, tandis que les nœuds non mineurs suivent ces comportements afin de maximiser l’utilité de leurs mempools.

La rareté de l’espace des blocs exerce une pression à la baisse sur la taille des transactions et encourage les développeurs à être plus efficaces dans la construction des transactions. Le billet de la semaine prochaine explorera des stratégies et des techniques pratiques pour minimiser les frais dans les transactions sur la chaîne.

Enchères pour l’achat d’un bloc d’espace

Originally published in Newsletter #253

La semaine dernière, nous avons indiqué que les transactions payaient des frais pour l’espace de blocs utilisé plutôt que pour le montant transféré, et nous avons établi que les mineurs optimisent leur sélection de transactions pour maximiser les frais perçus. Il s’ensuit que seules sont confirmées les transactions qui se trouvent en tête du pool de mémoire lorsqu’un bloc est trouvé. Dans ce billet, nous discuterons de stratégies pratiques pour tirer le meilleur parti de nos frais. Supposons que nous disposons d’une source décente d’estimations de taux de change—nous parlerons plus en détail de l’estimation des taux de change dans l’article de la semaine prochaine.

Lors de l’élaboration des transactions, certaines parties de la transaction sont plus flexibles que d’autres. Chaque transaction nécessite les champs d’en-tête, les sorties du destinataire sont déterminées par les paiements effectués, et la plupart des transactions nécessitent une sortie de changement. L’expéditeur et le destinataire doivent privilégier les types de sorties efficaces en termes d’espace de blocs afin de réduire le coût futur de la dépense de leurs sorties de transaction, mais c’est au cours de la sélection des entrées qu’il est le plus possible de modifier la composition et le poids finaux de la transaction. Comme les transactions se concurrencent par taux [frais/poids], une transaction plus légère nécessite des frais moins élevés pour atteindre le même taux.

Certains portefeuilles, comme le portefeuille Bitcoin Core, essaient de combiner les entrées de manière à éviter d’avoir besoin de changer les sorties. Éviter le changement permet d’économiser le poids d’une sortie maintenant, mais aussi le coût futur de la dépense de la sortie de changement plus tard. Malheureusement, de telles combinaisons d’entrées ne seront que rarement disponibles, à moins que le portefeuille ne dispose d’un grand pool d’UTXO avec une grande variété de montants.

Les types de sortie modernes sont plus efficaces en termes d’espace de blocs que les types de sortie plus anciens. Par exemple, dépenser une entrée P2TR coûte moins de 2/5e du poids d’une entrée P2PKH (essayez-le avec notre calculateur de taille de transaction). Pour les portefeuilles à plusieurs signatures, le schéma MuSig2 et le protocole FROST récemment finalisés permettent de réaliser d’énormes économies en autorisant l’encodage d’une fonctionnalité à plusieurs signatures dans ce qui ressemble à une entrée à une seule signature. En particulier à une époque où la demande d’espace de blocs explose, un portefeuille utilisant des types de sortie modernes se traduit à lui seul par d’importantes économies.

Overview of input and output weights

Les portefeuilles intelligents modifient leur stratégie de sélection en fonction du taux : lorsque le taux est élevé, ils utilisent peu d’entrées et des types d’entrées modernes afin d’obtenir le poids le plus faible possible pour l’ensemble d’entrées. Le fait de toujours sélectionner l’ensemble d’entrées le plus léger minimiserait localement le coût de la transaction en cours, mais réduirait également le pool d’UTXO d’un portefeuille en petits fragments. Cela pourrait préparer l’utilisateur à effectuer plus tard des transactions avec des ensembles d’entrées énormes à des taux élevés. Par conséquent, il est judicieux que les portefeuilles sélectionnent également des entrées plus nombreuses et plus lourdes à des taux faibles afin de consolider de manière opportuniste les fonds dans des sorties modernes moins nombreuses en prévision de pics de demande ultérieurs dans l’espace de blocs.

Les portefeuilles à fort volume regroupent souvent plusieurs paiements en une seule transaction afin de réduire le poids de la transaction par paiement. Au lieu de supporter les frais généraux liés aux octets d’en-tête et à la sortie des modifications pour chaque paiement, ils ne supportent les frais généraux qu’une seule fois, pour tous les paiements. Le simple fait de regrouper quelques paiements permet de réduire rapidement le coût par paiement.

Savings from payment batching with
P2WPKH

Néanmoins, même si de nombreux portefeuilles estiment que les taux se trompent sur les paiements excessifs, en cas de bloc lent ou d’augmentation des soumissions de transactions, les transactions restent parfois non confirmées plus longtemps que prévu. Dans ce cas, l’expéditeur ou le destinataire peuvent souhaiter redéfinir les priorités de la transaction.

Les utilisateurs disposent généralement de deux outils pour accroître la priorité de leur transaction : l’enfant paie pour le parent (CPFP) et le remplacement par des frais (RBF). Dans CPFP, un utilisateur dépense le résultat de sa transaction pour créer une transaction enfant à haut degré de priorité. Comme décrit dans l’article de la semaine dernière, les mineurs sont incités à choisir le parent dans le bloc afin d’inclure l’enfant riche en frais. Le CPFP est accessible à tout utilisateur rémunéré par la transaction, de sorte que le destinataire ou l’expéditeur (s’il a créé une sortie de changement) peut l’utiliser.

Dans le cas du RBF, l’expéditeur est l’auteur d’un remplacement de la transaction d’origine à un taux plus élevé. La transaction de remplacement doit réutiliser au moins une entrée de la transaction originale pour garantir un conflit avec l’original et pour qu’une seule des deux transactions puisse être incluse dans la blockchain. En général, ce remplacement inclut les paiements de la transaction originale, mais l’expéditeur peut également rediriger les fonds dans la transaction de remplacement ou combiner les paiements de plusieurs transactions en une seule lors du remplacement. Comme décrit dans l’article de la semaine dernière, les nœuds évincent la transaction initiale en faveur de la transaction de remplacement, plus compatible avec les incitations.

Bien que la demande et la production d’espace de blocs soient hors de notre contrôle, il existe de nombreuses techniques que les portefeuilles peuvent utiliser pour faire des offres d’espace de blocs de manière efficace. Les portefeuilles peuvent économiser des frais en créant des transactions plus légères en éliminant la sortie de changement, en dépensant les sorties segwit natives et en défragmentant leur pool UTXO dans les environnements à faible taux de feerate. Les portefeuilles qui prennent en charge CPFP et RBF peuvent également commencer avec un taux de rafraîchissement conservateur, puis mettre à jour la priorité de la transaction à l’aide de CPFP ou de RBF si nécessaire.

Estimation des taux de frais

Originally published in Newsletter #254

La semaine dernière, nous avons exploré les techniques permettant de minimiser les frais payés sur une transaction donnée. Mais quel doit être ce taux ? Idéalement, le plus bas possible pour économiser de l’argent, mais suffisamment élevé pour garantir une place dans un bloc correspondant aux préférences temporelles de l’utilisateur.

L’objectif de l’estimation des frais (taux) est de traduire un délai de confirmation cible en un taux minimal que la transaction devrait payer.

L’estimation des frais est compliquée par l’irrégularité de la production d’espace de bloc. Supposons qu’un utilisateur doive payer un commerçant dans un délai d’une heure pour recevoir ses marchandises. L’utilisateur peut s’attendre à ce qu’un bloc soit extrait toutes les 10 minutes, et donc viser un emplacement dans les 6 blocs suivants. Cependant, il est tout à fait possible qu’il faille 45 minutes pour trouver un bloc. Les évaluateurs de frais doivent faire le lien entre l’urgence ou le délai souhaité par l’utilisateur (quelque chose comme “Je veux que cela soit confirmé avant la fin de la journée”) et l’offre d’espace de blocs (un certain nombre de blocs). De nombreux estimateurs de frais relèvent ce défi en exprimant les objectifs de confirmation en nombre de blocs, en plus du temps.

En l’absence d’informations sur les transactions avant leur confirmation, il est possible de construire un estimateur de frais naïf qui utilise des données historiques sur les taux des transactions qui ont tendance à intégrer les blocs. Comme cet estimateur ne tient pas compte des transactions en attente de confirmation dans les pools de mémoire, il deviendrait très imprécis en cas de fluctuations inattendues de la demande d’espace de bloc et d’intervalles de bloc occasionnellement longs. Son autre faiblesse réside dans le fait qu’il s’appuie sur des informations contrôlées entièrement par les mineurs, qui seraient en mesure de faire grimper les taux de frais en incluant de fausses transactions à taux de frais élevé dans leurs blocs.

Heureusement, le marché de l’espace de blocs n’est pas une vente aux enchères à l’aveugle. Nous avons mentionné dans notre premier article que le fait de conserver un mempool et de participer au réseau de relais de transactions de pair à pair permet à un nœud de voir les offres des utilisateurs. L’estimateur de frais de Bitcoin Core utilise également des données historiques pour calculer la probabilité qu’une transaction à un taux t soit confirmée. L’estimateur de frais de Bitcoin Core utilise également des données historiques pour calculer la probabilité qu’une transaction à la fréquence t soit confirmée dans un délai de n blocs, mais il suit spécifiquement la hauteur à laquelle le nœud voit une transaction pour la première fois et le moment où elle est confirmée. Cette méthode permet de contourner les activités qui se déroulent en dehors du marché public en les ignorant. Si les mineurs incluent dans leurs propres blocs des transactions dont le taux de confirmation est artificiellement élevé, cet estimateur de frais n’est pas faussé car il n’utilise que les données des transactions qui ont été relayées publiquement avant la confirmation.

Nous avons également des informations sur la manière dont les transactions sont sélectionnées pour les blocs. Dans un précédent article, nous avons mentionné que les nœuds simulent les politiques des mineurs afin de conserver les transactions compatibles avec les incitations dans leurs mempools. En développant cette idée, au lieu de regarder uniquement les données passées, nous pourrions construire un estimateur de frais qui simule ce qu’un mineur ferait. Pour déterminer le taux de frais qu’une transaction devrait confirmer dans les n blocs suivants, l’estimateur de frais pourrait utiliser l’algorithme d’assemblage de blocs pour projeter les modèles des n blocs suivants à partir de son mempool et calculer le taux de frais qui battrait la (les) dernière(s) transaction(s) parvenue(s) dans le bloc n.

Il est clair que l’efficacité de l’approche de cet estimateur de frais dépend de la similitude entre le contenu de son mempool et celui des mineurs, ce qui ne peut jamais être garanti. Elle ne tient pas compte non plus des transactions qu’un mineur pourrait inclure pour des raisons extérieures, par exemple des transactions qui appartiennent au mineur ou qui ont payé des frais externes pour être confirmées. La projection doit également tenir compte des diffusions de transactions supplémentaires entre maintenant et le moment où les blocs projetés sont trouvés. Elle peut le faire en diminuant la taille des blocs projetés pour tenir compte des autres transactions - mais de combien ?

Cette question souligne une fois de plus l’utilité des données historiques. Un modèle intelligent pourrait être en mesure d’intégrer des modèles d’activité et de tenir compte d’événements externes qui influencent les taux de frais, tels que les heures d’ouverture habituelles, la consolidation UTXO programmée d’une entreprise et l’activité en réponse aux changements du prix d’échange du bitcoin. Le problème de la prévision de la demande d’espace de blocs reste mûr pour l’exploration, et il est probable qu’il y aura toujours de la place pour l’innovation.

L’estimation des frais est un problème difficile aux multiples facettes. Une mauvaise estimation des frais peut entraîner un gaspillage de fonds par un paiement excessif des frais, ajouter des frictions à l’utilisation de Bitcoin pour les paiements et faire perdre de l’argent aux utilisateurs de L2 en manquant une fenêtre dans laquelle une UTXO bloquée dans le temps disposait d’un autre chemin de dépense. Une bonne estimation des frais permet aux utilisateurs de communiquer clairement et précisément l’urgence de la transaction aux mineurs, et CPFP et RBF permettent aux utilisateurs de mettre à jour leurs offres si les estimations initiales sont inférieures à la réalité. Les politiques de mempool compatibles avec les incitations, associées à des outils d’estimation des frais bien conçus et aux wallets, permettent aux utilisateurs de participer à une vente aux enchères publique efficace pour l’espace des blocs.

Les estimateurs de frais ne renvoient généralement jamais moins que 1sat/vB, quelle que soit la durée de l’horizon temporel ou le nombre de transactions en attente de confirmation. Beaucoup considèrent que 1sat/vB est le taux plancher de facto dans le réseau Bitcoin, en raison du fait que la plupart des nœuds du réseau (y compris les mineurs) n’acceptent jamais tout ce qui est en dessous de ce taux, indépendamment du fait que leurs mempools soient vides. Le billet de la semaine prochaine explorera cette politique des nœuds et une autre motivation pour l’utilisation du taux de frais dans le relais de transaction : la protection contre l’épuisement des ressources.

Politique de protection des ressources des nœuds

Originally published in Newsletter #255

Nous avons commencé notre série en affirmant qu’une grande partie de la résistance de Bitcoin à la vie privée et à la censure découle de la nature décentralisée du réseau. La pratique selon laquelle les utilisateurs gèrent leurs propres nœuds réduit les points centraux de défaillance, de surveillance et de censure. Il s’ensuit que l’un des principaux objectifs de conception du logiciel de nœud Bitcoin est l’accessibilité élevée de l’exploitation d’un nœud. Exiger de chaque utilisateur de Bitcoin qu’il achète du matériel coûteux, qu’il utilise un système d’exploitation spécifique ou qu’il dépense des centaines de dollars par mois en frais d’exploitation réduirait très probablement le nombre de nœuds sur le réseau.

Par ailleurs, un nœud du réseau Bitcoin est un ordinateur connecté à des entités inconnues qui peuvent lancer une attaque par déni de service (DoS) en créant des messages qui font que le nœud manque de mémoire et tombe en panne, ou qu’il dépense ses ressources informatiques et sa bande passante pour des données sans intérêt au lieu d’accepter de nouveaux blocs. Comme ces entités sont anonymes de par leur conception, les nœuds ne peuvent pas déterminer à l’avance si un pair sera honnête ou malveillant avant de se connecter, et ne peuvent pas l’interdire efficacement même après qu’une attaque a été observée. La mise en œuvre de politiques de protection contre les attaques par déni de service et de limitation du coût de fonctionnement d’un nœud complet n’est donc pas seulement un idéal, c’est un impératif.

Des protections générales contre les attaques par déni de service sont intégrées dans les implémentations des nœuds afin d’éviter l’épuisement des ressources. Par exemple, si un nœud de Bitcoin Core reçoit de nombreux messages d’un seul pair, il ne traite que le premier et ajoute le reste à une file d’attente pour qu’il soit traité après les messages des autres pairs. En règle générale, un nœud télécharge d’abord l’en-tête d’un bloc et vérifie sa preuve de travail (PoW) avant de télécharger et de valider le reste du bloc. Ainsi, tout attaquant souhaitant épuiser les ressources de ce nœud par le biais d’un relais de bloc doit d’abord dépenser une quantité disproportionnée de ses propres ressources pour calculer une preuve de travail valide. L’asymétrie entre le coût énorme du calcul du PoW et le coût trivial de la vérification fournit un moyen naturel d’intégrer la résistance aux attaques par déni de service dans le relais de bloc. Cette propriété ne s’étend pas au relais de transactions non confirmées.

Les protections générales contre les attaques par déni de service n’offrent pas une résistance suffisante pour permettre au moteur de consensus d’un nœud d’être exposé à des données provenant du réseau pair-à-pair. Un attaquant tentant de fabriquer une transaction à forte intensité de calcul, validée par consensus, peut envoyer une transaction comme la “mégatransaction” de 1 Mo dans le bloc #364292, dont la validation a pris un temps anormalement long en raison de la vérification de la signature et de l’ajustement quadratique. Un attaquant peut également rendre toutes les signatures valides, sauf la dernière, ce qui amène le nœud à passer plusieurs minutes sur sa transaction, pour finalement découvrir qu’elle est inutile. Pendant ce temps, le nœud retarderait le traitement d’un nouveau bloc. On peut imaginer que ce type d’attaque vise des mineurs concurrents afin de prendre de l’avance sur le bloc suivant.

Afin d’éviter de travailler sur des transactions très coûteuses en termes de calcul, les nœuds de Bitcoin Core imposent une taille standard maximale et un nombre maximal d’opérations de signature (ou “sigops”) pour chaque transaction, ce qui est plus restrictif que la limite de consensus par bloc. Les nœuds de Bitcoin Core imposent également des limites sur la taille des paquets d’ancêtres et de descendants, ce qui rend les algorithmes de production et d’éviction de modèles de blocs plus efficaces et limite la complexité de calcul de l’insertion et de la suppression du mempool, qui nécessitent la mise à jour des ensembles d’ancêtres et de descendants d’une transaction. Bien que cela signifie que certaines transactions légitimes peuvent ne pas être acceptées ou relayées, ces transactions devraient être rares.

Ces règles sont des exemples de politique de relais de transaction, un ensemble de règles de validation en plus du consensus que les nœuds appliquent aux transactions non confirmées.

Par défaut, les nœuds de Bitcoin Core n’acceptent pas les transactions inférieures au taux de relais minimum de 1sat/vB (“minrelaytxfee”), ne vérifient pas les signatures avant de contrôler cette exigence et ne transmettent pas les transactions à leurs mempools à moins qu’elles ne soient acceptées. D’une certaine manière, cette règle de taux de frais fixe un “prix” minimum pour la validation et le relais du réseau. Un nœud non-mineur ne reçoit jamais de frais - ils sont uniquement payés au mineur qui confirme la transaction. Cependant, les frais représentent un coût pour l’attaquant. Quelqu’un qui “gaspille” les ressources du réseau en envoyant un nombre extrêmement élevé de transactions finit par manquer d’argent pour payer les frais.

La politique Replace by Fee mise en œuvre par Bitcoin Core exige que la transaction de remplacement paie des frais plus élevés que chaque transaction avec laquelle elle entre directement en conflit, mais aussi qu’elle paie des frais totaux plus élevés que toutes les transactions qu’elle remplace. Les frais supplémentaires divisés par la taille virtuelle de la transaction de remplacement doivent être d’au moins 1sat/vB. En d’autres termes, quels que soient les taux des transactions d’origine et de remplacement, la nouvelle transaction doit payer de “nouveaux” frais pour couvrir le coût de sa propre bande passante à 1sat/vB. Cette politique tarifaire n’est pas principalement axée sur la compatibilité des incitations. Il s’agit plutôt d’un coût minimum pour les remplacements répétés de transactions afin de limiter les attaques qui gaspillent la bande passante, par exemple en ajoutant seulement 1 satoshi supplémentaire à chaque remplacement.

Un nœud qui valide entièrement les blocs et les transactions nécessite des ressources, notamment de la mémoire, des ressources informatiques et de la bande passante. Les exigences en matière de ressources doivent rester faibles afin de rendre l’exploitation d’un nœud accessible et de défendre le nœud contre l’exploitation. Les protections générales contre les attaques par déni de service n’étant pas suffisantes, les nœuds appliquent des politiques de relais de transaction en plus des règles de consensus lorsqu’ils valident des transactions non confirmées. Toutefois, la politique n’étant pas un consensus, deux nœuds peuvent avoir des politiques différentes mais être d’accord sur l’état actuel de la chaîne. Le billet de la semaine prochaine traitera de la politique en tant que choix individuel.

Cohérence des politiques

Originally published in Newsletter #256

Le billet de la semaine dernière présentait la politique, un ensemble de règles de validation des transactions appliquées en plus des règles de consensus. Ces règles ne s’appliquent pas aux transactions dans les blocs, de sorte qu’un nœud peut rester dans le consensus même si sa politique diffère de celle de ses pairs. Tout comme un opérateur de nœud peut décider de ne pas participer au relais de transaction, il est également libre de choisir n’importe quelle politique, voire aucune (exposant son nœud au risque de déni de service). Cela signifie que nous ne pouvons pas supposer une homogénéité totale des politiques de mempool dans le réseau. Cependant, pour que la transaction d’un utilisateur soit reçue par un mineur, elle doit passer par un chemin de nœuds qui l’acceptent tous dans leur mempool—la divergence de politique entre les nœuds affecte directement la fonctionnalité du relais de transaction.

Pour donner un exemple extrême des différences de politique entre les nœuds, imaginons une situation dans laquelle chaque opérateur de nœud choisirait une nVersion aléatoire et n’accepterait que les transactions avec cette nVersion. Comme la plupart des relations d’égal à égal auraient des politiques incompatibles, les transactions ne se propageraient pas aux mineurs.

De l’autre côté du spectre, des politiques identiques à travers le réseau aident à faire converger les contenus des mempools. Un réseau avec des mempools correspondants relaie les transactions le plus facilement, et est également idéal pour l’estimation des frais et le relais de bloc compact comme mentionné dans les posts précédents.

Étant donné la complexité de la validation des mempools et les difficultés qui découlent des disparités entre les politiques, Bitcoin Core a historiquement été conservateur avec la configurabilité des politiques. Alors que les utilisateurs peuvent facilement modifier la façon dont les sigops sont comptés (bytespersigop) et limiter la quantité de données intégrées dans les sorties OP_RETURN (datacarriersize et datacarrier), ils ne peuvent pas renoncer au poids standard maximum de 400 000 unités de poids ou appliquer un ensemble différent de règles RBF liées aux frais sans modifier le code source.

Certaines options de configuration de la politique de Bitcoin Core existent pour tenir compte des différences entre les environnements d’exploitation des nœuds et les objectifs d’exploitation d’un nœud. Par exemple, les ressources matérielles d’un mineur et la raison pour laquelle il conserve un mempool diffèrent de celles d’un utilisateur quotidien qui fait fonctionner un nœud léger sur son ordinateur portable ou son Raspberry Pi. Un mineur peut choisir d’augmenter la capacité de son mempool (maxmempool) ou son délai d’expiration (mempoolexpiry) pour stocker des transactions à faible taux d’échange pendant les pics de trafic, puis les exploiter plus tard lorsque le trafic diminue. Les sites web fournissant des visualisations, des archives et des statistiques sur le réseau peuvent utiliser plusieurs noeuds pour collecter autant de données que possible et afficher le comportement par défaut du mempool.

Sur un nœud individuel, le choix de la capacité du mempool affecte la disponibilité des outils de substitution de frais. Lorsque les taux minimums du mempool augmentent en raison de soumissions de transactions dépassant la taille par défaut du mempool, les transactions purgées du “bas” du mempool et les nouvelles qui sont en dessous de ce taux ne peuvent plus être surtaxées en utilisant CPFP.

D’un autre côté, puisque les entrées utilisées par les transactions purgées ne sont plus dépensées par aucune transaction dans le mempool, il peut être possible de faire du fee-bump via RBF alors que ce n’était pas le cas auparavant. La nouvelle transaction ne remplace rien dans le mempool du noeud, donc elle n’a pas besoin de prendre en compte les règles habituelles de RBF. Cependant, les nœuds qui n’ont pas expulsé la transaction originale (parce qu’ils ont une plus grande capacité de mempool) traitent la nouvelle transaction comme un remplacement proposé et exigent qu’elle respecte les règles RBF. Si la transaction purgée ne signalait pas la remplaçabilité BIP125, ou si les frais de la nouvelle transaction ne répondent pas aux exigences RBF en dépit d’un taux élevé, le mineur peut refuser la nouvelle transaction. Les portefeuilles doivent traiter les transactions purgées avec précaution : les résultats de la transaction ne peuvent pas être considérés comme disponibles pour la dépense, mais les entrées sont également indisponibles pour la réutilisation.

À première vue, il peut sembler qu’un nœud ayant une plus grande capacité de mempool rend le CPFP plus utile et le RBF moins utile. Cependant, le relais des transactions est soumis au comportement émergent du réseau et il se peut qu’il n’y ait pas de chemin de nœuds acceptant le CPFP depuis l’utilisateur jusqu’au mineur. Les nœuds ne transmettent généralement les transactions qu’une fois qu’ils les ont acceptées dans leur mempool et ignorent les annonces de transactions qui existent déjà dans leur mempool - les nœuds qui stockent davantage de transactions agissent comme des trous noirs lorsque ces transactions leur sont rediffusées. À moins que l’ensemble du réseau n’augmente la capacité de ses mempools - ce qui serait un signe de changement de la valeur par défaut - les utilisateurs ne doivent pas s’attendre à ce que l’augmentation de la capacité de leurs propres mempools leur apporte beaucoup d’avantages. Le taux de frais minimum fixé par les mempools par défaut limite l’utilité de CPFP pendant les périodes de fort trafic. Un utilisateur ayant réussi à soumettre une transaction CPFP à son propre mempool, dont la taille a été augmentée, pourrait ne pas remarquer que la transaction ne s’est pas propagée à d’autres utilisateurs.

Le réseau de relais de transactions est composé de nœuds individuels qui rejoignent et quittent dynamiquement le réseau, chacun d’entre eux devant se protéger contre l’exploitation. En tant que tel, le relais de transaction ne peut être que le fruit d’un effort et nous ne pouvons pas garantir que chaque nœud est informé de chaque transaction non confirmée. En même temps, le réseau Bitcoin est plus performant si les nœuds convergent vers un ensemble de politiques de relais de transactions qui rend les mempools aussi homogènes que possible. Le prochain article examinera les mesures qui ont été adoptées afin de répondre aux intérêts du réseau dans son ensemble.

Ressources du réseau

Originally published in Newsletter #257

Un article précédent traitait de la protection des ressources des nœuds, qui peut être unique à chaque nœud et donc parfois configurable. Nous avons également expliqué pourquoi il est préférable de converger vers une seule politique, mais qu’est-ce qui doit faire partie de cette politique ? Ce billet aborde le concept de ressources à l’échelle du réseau, essentielles pour des aspects tels que l’évolutivité, la mise à niveau et l’accessibilité du démarrage et de la maintenance d’un nœud complet.

Comme nous l’avons vu dans les articles précédents, de nombreux objectifs idéologiques du réseau Bitcoin sont incarnés par sa structure distribuée. La nature pair-à-pair de Bitcoin permet aux règles du réseau d’émerger d’un consensus approximatif des choix des opérateurs de nœuds individuels et limite les tentatives d’acquisition d’une influence indue sur le réseau. Ces règles sont ensuite appliquées par chaque nœud qui valide individuellement chaque transaction. Une population de nœuds diversifiée et saine exige que le coût d’exploitation d’un nœud soit maintenu à un niveau bas. Il est difficile de faire évoluer un projet avec une audience mondiale, mais le faire sans sacrifier la décentralisation revient à se battre avec une main attachée dans le dos. Le projet Bitcoin tente de trouver cet équilibre en protégeant farouchement les ressources partagées du réseau : le stock d’UTXO, l’empreinte des données de la blockchain et l’effort de calcul nécessaire pour les traiter, ainsi que les mises à jour permettant de faire évoluer le protocole Bitcoin.

Il n’est pas nécessaire de revenir sur la guerre des tailles de blocs pour comprendre qu’une limite à la croissance de la blockchain est nécessaire pour que l’exploitation de son propre nœud reste abordable. Cependant, la croissance de la blockchain est également dissuadée au niveau politique par le minRelayTxFee de 1 sat/vbyte, assurant un coût minimum pour exprimer une partie de la “ demande illimitée de stockage perpétuel hautement répliqué “.

À l’origine, l’état du réseau était déterminé en conservant toutes les transactions dont les résultats n’avaient pas encore été dépensés. Cette partie beaucoup plus importante de la blockchain a été réduite de manière significative avec l’introduction du jeu d’UTXO comme moyen de suivre les fonds. Depuis lors, le jeu d’UTXO est une structure de données centrale. En particulier pendant les IBD, mais aussi de manière générale, les consultations d’UTXO représentent une part importante de tous les accès à la mémoire d’un nœud. Bitcoin Core utilise déjà une structure de données optimisée manuellement pour le cache UTXO, mais la taille du jeu d’UTXO détermine la quantité qu’il ne peut pas contenir dans le cache d’un nœud. Un ensemble d’UTXO plus important se traduit par un plus grand nombre d’échec du cache, ce qui ralentit la vitesse de validation des blocs, de l’IBD et de la transaction. La limite des poussières (dust limit) est un exemple de politique qui restreint la création d’UTXO, en particulier les UTXO qui pourraient ne jamais être dépensés parce que leur montant n’est pas à la hauteur du coût de leur dépense. Malgré cela, des “tempêtes de poussière” avec des milliers de transactions se sont produites pas plus tard qu’en 2020.

Lorsqu’il est devenu populaire d’utiliser des sorties multisig brutes pour publier des données sur la blockchain, la définition des transactions standards a été modifiée pour permettre une sortie OP_RETURN unique en tant qu’alternative. Les gens ont réalisé qu’il serait impossible d’empêcher les utilisateurs de publier des données sur la blockchain, mais qu’au moins ces données n’auraient pas besoin de vivre dans le jeu d’UTXO pour toujours lorsqu’elles sont publiées dans des sorties qui ne peuvent jamais être dépensées. Bitcoin Core 0.13.0 a introduit une option de démarrage -permitbaremultisig que les utilisateurs peuvent activer pour rejeter les transactions non confirmées avec des sorties multisig brutes.

Bien que les règles de consensus permettent aux scripts de sortie d’être libres, seuls quelques modèles bien compris sont relayés par les nœuds de Bitcoin Core. Il est ainsi plus facile de comprendre les nombreuses préoccupations du réseau, notamment les coûts de validation et les mécanismes de mise à jour du protocole. Par exemple, un script d’entrée qui contient des op-codes, une entrée P2SH avec plus de 15 signatures, ou une entrée P2WSH dont la pile de témoins contient plus de 100 éléments chacun, rendrait une transaction non standard. (Consultez cette vue d’ensemble des politiques pour plus d’exemples de politiques et leurs motivations).

Finalement, le protocole Bitcoin est un projet logiciel vivant qui devra continuer à évoluer pour répondre aux défis futurs et aux besoins des utilisateurs. À cette fin, il existe un certain nombre de mécanismes de mise à jour qui ont délibérément laissé le consensus valide mais inutilisé, tels que l’annexe, les versions des leaf taproots, les versions des témoins, OP_SUCCESS et un certain nombre d’opcodes no-op. Cependant, tout comme les attaques sont entravées par l’absence de points centraux de défaillance, les mises à jour logicielles à l’échelle du réseau impliquent un effort coordonné entre des dizaines de milliers d’opérateurs de nœuds indépendants. Les nœuds ne relaieront pas les transactions qui utilisent les hooks de mise à niveau réservés tant que leur signification n’aura pas été définie. Cette mesure vise à dissuader les applications de créer indépendamment des normes contradictoires, ce qui rendrait impossible l’adoption de la norme d’une application dans le consensus sans invalider celle d’une autre application. En outre, lorsqu’un changement de consensus se produit, les nœuds qui ne sont pas mis à niveau immédiatement—et qui ne connaissent donc pas les nouvelles règles de consensus—ne peuvent pas être “trompés” en acceptant une transaction désormais invalide dans leur pool de mémoires. Ce découragement proactif aide les nœuds à être compatibles avec l’avenir et permet au réseau de mettre à jour les règles de consensus en toute sécurité sans nécessiter une mise à jour logicielle entièrement synchronisée.

Nous pouvons voir que l’utilisation d’une politique pour protéger les ressources partagées du réseau aide à protéger les caractéristiques du réseau, et maintient ouvertes les voies pour le développement de protocoles futurs. Pendant ce temps, nous voyons comment la friction de la croissance du réseau contre une blockchain strictement limitée a conduit à l’adoption de meilleures pratiques, d’une bonne conception technique et de l’innovation : le billet de la semaine prochaine explorera la politique de mempool comme une interface pour les protocoles de deuxième couche et les systèmes de contrats intelligents.

La politique comme interface

Originally published in Newsletter #258

Jusqu’à présent dans cette série, nous avons exploré les motivations et les défis associés à la transmission décentralisée des transactions, ce qui conduit à un besoin local et global de règles de validation des transactions plus restrictives que le consensus. Étant donné que les modifications de la politique de transmission des transactions dans Bitcoin Core peuvent avoir un impact sur la transmission des transactions d’une application, elles nécessitent une socialisation préalable avec la communauté Bitcoin plus large avant d’être prises en compte. De même, les applications et les protocoles de deuxième couche qui utilisent la transmission des transactions doivent être conçus en tenant compte des règles de politique afin d’éviter de créer des transactions qui seraient rejetées.

Les protocoles de contrat dépendent encore plus étroitement des politiques liées à la priorisation, car la possibilité de les exécuter on chain dépend de la capacité à faire confirmer rapidement les transactions. Dans des environnements adverses, les contreparties malveillantes peuvent avoir intérêt à retarder la confirmation d’une transaction, il faut donc également réfléchir à la manière dont les particularités de l’interface de la politique de transmission des transactions peuvent être utilisées contre un utilisateur.

Les transactions du Lightning Network respectent les règles de standardité mentionnées dans les publications précédentes. Par exemple, le protocole pair-à-pair spécifie une dust_limit_satoshis dans son message open_channel pour spécifier un seuil de poussière. Étant donné qu’une transaction contenant une sortie d’une valeur inférieure au seuil de poussière ne sera pas transmise en raison des limites de poussière des nœuds, ces paiements sont considérés comme “non exécutoires sur la chaîne” et sont supprimés des transactions d’engagement.

Les protocoles de contrat utilisent souvent des chemins de dépense avec verrouillage temporel pour donner à chaque participant la possibilité de contester l’état publié on chain. Si l’utilisateur concerné ne parvient pas à faire confirmer une transaction dans ce laps de temps, il peut subir une perte de fonds. Cela rend les frais extrêmement importants en tant que mécanisme principal pour augmenter la priorité de confirmation, mais aussi plus difficiles à estimer. L’estimation des frais est compliquée par le fait que les transactions seront diffusées à un moment ultérieur inconnu, que les nœuds fonctionnent souvent en tant que clients légers et que certaines options d’augmentation des frais ne sont pas disponibles. Par exemple, si un participant à un canal LN se déconnecte, l’autre partie peut diffuser unilatéralement une transaction d’engagement pré-signée pour régler la répartition de leurs fonds partagés on chain. Aucune des parties ne peut dépenser unilatéralement l’UTXO partagé, donc lorsque l’une des parties est déconnectée, il n’est pas possible de signer une transaction de remplacement pour augmenter les frais de la transaction d’engagement. À la place, les transactions d’engagement LN peuvent inclure des sorties d’ancrage pour que les participants au canal puissent attacher un enfant d’augmentation des frais au moment de la diffusion.

Cependant, cette méthode d’augmentation des frais a également des limites. Comme mentionné dans un message précédent, l’ajout d’une transaction CPFP n’est pas efficace si les taux de frais minimum du mempool augmentent au-dessus du taux de frais de la transaction d’engagement, il est donc nécessaire de les signer avec un taux de frais légèrement surestimé au cas où les taux de frais minimum du mempool augmenteraient à l’avenir. De plus, le développement des sorties d’ancrage a pris en compte un certain nombre de considérations liées au fait qu’une partie peut avoir intérêt à retarder la confirmation. Par exemple, une partie (Alice) peut diffuser sa propre transaction d’engagement sur le réseau avant de se déconnecter. Si le taux de frais de cette transaction d’engagement est trop faible pour une confirmation immédiate et si le cocontractant d’Alice (Bob) ne reçoit pas sa transaction, il peut être confus lorsque ses diffusions de sa version de la transaction d’engagement ne sont pas transmises avec succès. Chaque transaction d’engagement comporte deux sorties d’ancrage de sorte que chaque partie puisse utiliser CPFP sur l’une des transactions d’engagement, par exemple, Bob peut essayer de diffuser aveuglément une augmentation des frais CPFP de la version d’Alice de la transaction d’engagement même s’il n’est pas sûr qu’elle ait précédemment diffusé sa version. Chaque sortie d’ancrage se voit attribuer une petite valeur supérieure au seuil de poussière et peut être réclamée par n’importe qui après un certain temps pour éviter d’encombrer l’ensemble des UTXO.

Cependant, garantir la capacité de chaque partie à utiliser CPFP sur une transaction est plus compliqué que de donner à chaque partie une sortie d’ancrage. Comme mentionné dans un message précédent, Bitcoin Core limite le nombre et la taille totale des transactions descendantes qui peuvent être attachées à une transaction non confirmée en tant que protection contre les attaques de déni de service. Étant donné que chaque cocontractant a la possibilité d’attacher des transactions descendantes à la transaction partagée, l’un pourrait bloquer la transaction CPFP de l’autre en épuisant ces limites. La présence de ces transactions descendantes “épingle” par conséquent la transaction d’engagement à son statut de basse priorité dans les mempools.

Pour atténuer cette attaque potentielle, la proposition des sorties d’ancrage LN verrouille toutes les sorties sans ancrage avec un verrouillage temporel relatif, les empêchant d’être dépensées tant que la transaction n’est pas confirmée, et la politique de limite des transactions descendantes de Bitcoin Core a été modifiée pour permettre une transaction descendante supplémentaire lorsque cette nouvelle transaction descendante était de petite taille et n’avait pas d’autres ancêtres. Cette combinaison de modifications des deux protocoles garantit qu’au moins deux participants à une transaction partagée peuvent ajuster les frais au moment de la diffusion, sans augmenter de manière significative la surface d’attaque de déni de service de la transmission des transactions.

La prévention du CPFP par domination de la limite des transactions descendantes est un exemple d’une attaque d’épinglage. Les attaques d’épinglage exploitent les limitations de la politique des mempools pour empêcher les transactions compatibles avec les incitations d’entrer dans les mempools ou d’être confirmées. Dans ce cas, la politique des mempools a fait un compromis entre la résistance aux attaques de déni de service et la compatibilité des incitations. Un compromis doit être fait—un nœud doit prendre en compte les augmentations de frais mais ne peut pas traiter un nombre infini de transactions descendantes. Le découpage du CPFP permet d’affiner ce compromis pour un cas d’usage spécifique.

Outre l’épuisement de la limite des transactions descendantes, il existe d’autres attaques d’épinglage qui empêchent totalement l’utilisation de RBF, rendent RBF prohibitivement coûteux ou utilisent RBF pour retarder la confirmation d’une transaction ANYONECANPAY. L’épinglage n’est un problème que dans les scénarios où plusieurs parties collaborent à la création d’une transaction ou lorsqu’il y a par ailleurs une possibilité pour une partie non fiable d’interagir avec la transaction. Minimiser l’exposition d’une transaction à des parties non fiables est généralement un bon moyen d’éviter l’épinglage.

Ces points de friction mettent en évidence non seulement l’importance de la politique en tant qu’interface pour les applications et les protocoles dans l’écosystème Bitcoin, mais aussi les domaines dans lesquels elle doit s’améliorer. Le prochain article de la semaine prochaine abordera les propositions de politique et les questions ouvertes.

Propositions de politique

Originally published in Newsletter #259

Le post de la semaine dernière a décrit les sorties d’ancrage et l’exclusion CPFP, garantissant à chaque partie du canal la possibilité d’augmenter les frais de leurs transactions d’engagement partagées sans nécessiter de collaboration. Cette approche présente encore quelques inconvénients : les fonds du canal sont bloqués pour créer des sorties d’ancrage, les frais des transactions d’engagement sont généralement surestimés pour s’assurer qu’ils atteignent les frais minimaux du mempool, et l’exclusion CPFP ne permet qu’un seul descendant supplémentaire. Les sorties d’ancrage ne peuvent pas garantir la même capacité d’augmentation des frais pour les transactions partagées entre plus de deux parties, telles que les coinjoins ou les protocoles de contrat multi-parties. Ce post explore les efforts actuels pour remédier à ces limitations et à d’autres.

Package relay comprend un protocole P2P et des modifications de politique pour permettre le transport et la validation de groupes de transactions. Cela permettrait à une transaction d’engagement d’augmenter les frais même si la transaction d’engagement ne respecte pas le taux de frais minimal du mempool. De plus, Package RBF permettrait au descendant qui augmente les frais de payer pour remplacer les transactions en conflit avec son parent. Package relay est conçu pour éliminer une limitation générale au niveau du protocole de base. Cependant, en raison de son utilité pour l’augmentation des frais des transactions partagées, il a également donné lieu à plusieurs efforts pour éliminer l’épinglage pour des cas d’utilisation spécifiques. Par exemple, Package RBF permettrait aux transactions d’engagement de se remplacer mutuellement lorsqu’elles sont diffusées avec leurs descendants qui augmentent les frais, éliminant ainsi le besoin de plusieurs sorties d’ancrage sur chaque transaction d’engagement.

Un inconvénient est que les règles RBF existantes exigent que la transaction de remplacement paie des frais absolus plus élevés que les frais totaux payés par toutes les transactions à remplacer. Cette règle aide à prévenir les attaques de type DoS par des remplacements répétés, mais permet à un utilisateur malveillant d’augmenter le coût de remplacement de sa transaction en attachant un descendant avec des frais élevés mais un taux de frais faible. Cela empêche la transaction d’être extraite en empêchant injustement son remplacement par un package à frais élevés, et est souvent appelé “épinglage de la règle 3”.

Les développeurs ont également proposé des moyens totalement différents d’ajouter des frais aux transactions pré-signées. Par exemple, la signature des entrées de la transaction en utilisant SIGHASH_ANYONECANPAY | SIGHASH_ALL pourrait permettre au diffuseur de la transaction de fournir des frais en ajoutant des entrées supplémentaires à la transaction sans modifier les sorties. Cependant, comme RBF n’a aucune règle exigeant que la transaction de remplacement ait un “score minier” plus élevé (c’est-à-dire qu’elle serait sélectionnée plus rapidement pour un bloc), un attaquant pourrait épingler ces types de transactions en créant des remplacements encombrés par des ancêtres à faible taux de frais. Ce qui complique l’évaluation précise du score de minage des transactions et des packages de transactions, c’est que les limites existantes des ascendants et des descendants sont insuffisantes pour limiter la complexité computationnelle de ce calcul. Toutes les transactions connectées peuvent influencer l’ordre dans lequel les transactions sont sélectionnées pour être incluses dans un bloc. Un composant entièrement connecté, appelé un cluster, peut avoir n’importe quelle taille compte tenu des limites actuelles des ascendants et des descendants.

Une solution à long terme pour remédier à certaines lacunes du mempool et aux attaques d’épinglage RBF consiste à restructurer la structure de données du mempool pour suivre les clusters au lieu de simplement les ensembles d’ancêtres et de descendants. Ces clusters seraient limités en taille. Une limite de cluster restreindrait la manière dont les utilisateurs peuvent dépenser des UTXO non confirmés, mais permettrait de linéariser rapidement l’ensemble du mempool en utilisant l’algorithme de minage basé sur le score des ascendants, de construire des modèles de bloc extrêmement rapidement, et d’exiger que les transactions de remplacement aient un score de minage plus élevé que la ou les transactions à remplacer.

Même ainsi, il est possible qu’aucun ensemble unique de politiques ne puisse répondre à la large gamme de besoins et d’attentes en matière de relais de transactions. Par exemple, bien que les destinataires d’une transaction de paiement groupé bénéficient de la possibilité de dépenser leurs sorties non confirmées, une limite de descendant plus souple laisse place à l’épinglage du package RBF d’une transaction partagée par des frais absolus. Une proposition pour la politique de relais de transactions v3 a été développée pour permettre aux protocoles de contrat d’opter pour un ensemble plus restrictif de limites de package. Les transactions V3 ne permettraient que des packages de taille deux (un parent et un enfant) et limiteraient le poids de l’enfant. Ces limites atténueraient l’épinglage RBF par des frais absolus et offriraient certains avantages du mempool en cluster sans nécessiter une restructuration du mempool.

Les Ancres Éphémères s’appuient sur les propriétés des transactions V3 et du relais de packages pour améliorer davantage les sorties d’ancrage. Elles exemptent les sorties d’ancrage appartenant à une transaction V3 à frais nuls de la limite de poussière, à condition que la sortie d’ancrage soit dépensée par un descendant qui augmente les frais. Étant donné que la transaction sans frais doit être augmentée de frais par exactement un descendant (sinon un mineur ne serait pas incité à l’inclure dans un bloc), cette sortie d’ancrage est “éphémère” et ne fera pas partie de l’ensemble UTXO. La proposition d’ancres éphémères empêche implicitement les sorties autres que les sorties d’ancrage d’être dépensées lorsqu’elles ne sont pas confirmées sans verrouillages temporels 1 OP_CSV, puisque le seul descendant autorisé doit dépenser la sortie d’ancrage. Cela rendrait également la symétrie LN réalisable avec CPFP en tant que mécanisme de provisionnement des frais pour les transactions de fermeture de canal. Cela rend également ce mécanisme disponible pour les transactions partagées entre plus de deux participants. Les développeurs ont utilisé bitcoin-inquisition pour déployer les Ancres Éphémères et ont proposé des soft forks pour construire et tester ces changements multi-couches sur un signet.

Les problèmes d’épinglage mis en évidence dans ce post, entre autres, ont donné lieu à une multitude de discussions et de propositions pour améliorer la politique RBF l’année dernière, sur les listes de diffusion, les PR, les réseaux sociaux et les réunions en personne. Les développeurs ont proposé et mis en œuvre des solutions allant de petites modifications à une refonte complète. L’option -mempoolfullrbf, destinée à résoudre les problèmes d’épinglage et les divergences dans les implémentations de BIP125, a mis en évidence la difficulté et l’importance de la collaboration dans la politique de relais de transactions. Bien qu’un véritable effort ait été fait pour impliquer la communauté en utilisant des moyens habituels, notamment en lançant la conversation sur la liste de diffusion bitcoin-dev un an à l’avance, il était clair que les méthodes de communication et de prise de décision existantes n’avaient pas produit le résultat escompté et nécessitaient des améliorations.

La prise de décision décentralisée est un processus complexe, mais nécessaire pour soutenir l’écosystème diversifié des protocoles et des applications qui utilisent le réseau de relais de transactions de Bitcoin. La semaine prochaine, nous publierons notre dernier post de cette série, dans lequel nous espérons encourager nos lecteurs à participer et à améliorer ce processus.

Impliquez-vous

Originally published in Newsletter #260

Nous espérons que cette série a donné aux lecteurs une meilleure idée de ce qui se passe pendant qu’ils attendent une confirmation. Nous avons commencé par une discussion sur la façon dont certaines valeurs idéologiques de Bitcoin se traduisent dans sa structure et ses objectifs de conception. La structure distribuée du réseau pair à pair offre une résistance accrue à la censure et à la confidentialité par rapport à un modèle centralisé typique. Un réseau de relais de transactions ouvert permet à tout le monde d’apprendre les transactions dans les blocs avant la confirmation, ce qui améliore l’efficacité de la transmission des blocs, facilite l’adhésion en tant que nouveau mineur et crée une enchère publique pour l’espace des blocs. Comme le réseau idéal est composé de nombreuses entités indépendantes et anonymes exécutant des nœuds, le logiciel des nœuds doit être conçu pour se protéger contre les attaques par déni de service et minimiser les coûts opérationnels.

Les frais jouent un rôle important dans le réseau Bitcoin en tant que moyen “équitable” de résoudre la concurrence pour l’espace des blocs. Les pools de mémoire avec des algorithmes de remplacement de transactions et de sélection et d’éviction sensibles aux paquets utilisent la compatibilité des incitations pour mesurer l’utilité de stocker une transaction et permettent aux utilisateurs de bénéficier de mécanismes d’augmentation des frais tels que RBF et CPFP. La combinaison de ces politiques de pool de mémoire, de portefeuilles qui construisent des transactions de manière économique et d’une bonne estimation des frais crée un marché efficace pour l’espace des blocs qui profite à tous.

Les nœuds individuels appliquent également une politique de relais de transactions pour se protéger contre l’épuisement des ressources et exprimer leurs préférences personnelles. À l’échelle du réseau, les règles de normalité et d’autres politiques protègent les ressources essentielles à l’évolutivité, à l’accessibilité de l’exécution d’un nœud et à la capacité de mettre à jour les règles de consensus. Comme la grande majorité du réseau applique ces politiques, elles sont une partie importante de l’interface sur laquelle les applications Bitcoin et les protocoles L2 se basent. Elles ne sont cependant pas parfaites. Nous avons décrit plusieurs propositions liées aux politiques qui abordent des limitations générales et des cas d’utilisation spécifiques tels que les attaques d’épinglage sur les transactions de règlement L2.

Nous avons également souligné que l’évolution continue des politiques du réseau nécessite une collaboration entre les développeurs travaillant sur les protocoles, les applications et les portefeuilles. À mesure que l’écosystème Bitcoin se développe en termes de logiciels, de cas d’utilisation et d’utilisateurs, un processus de prise de décision décentralisé devient de plus en plus nécessaire mais aussi plus difficile. Même si l’adoption de Bitcoin augmente, le système émerge des préoccupations et des efforts de ses parties prenantes—il n’y a pas d’entreprise chargée de recueillir les commentaires des clients et d’embaucher des ingénieurs pour développer de nouvelles fonctionnalités de protocole ou supprimer les fonctionnalités inutilisées. Les parties prenantes qui souhaitent faire partie du consensus approximatif du réseau ont différentes façons de participer : s’informer, soulever des questions et des problèmes, s’impliquer dans la conception du réseau, voire contribuer à la mise en œuvre d’améliorations. La prochaine fois que votre transaction prendra trop de temps à se confirmer, vous saurez quoi faire !