Le problème central : Cluster Mempool, les problèmes sont plus faciles par morceaux

Bitcoin Magazine

The Core Issue : Cluster Mempool, les problèmes sont plus faciles par morceaux

Cluster Mempool¹ est une refonte complète de la manière dont le mempool gère l'organisation et le tri des transactions, conceptualisée et mise en œuvre par Suhas Daftuar et Pieter Wuille. La conception vise à simplifier l'architecture globale, à mieux aligner la logique de tri des transactions avec les incitations des mineurs et à améliorer la sécurité des protocoles de seconde couche. Elle a été fusionnée dans Bitcoin Core dans la PR #33629² le 25 novembre 2025. 

Le mempool est un ensemble géant de transactions en attente que votre nœud doit suivre pour plusieurs raisons : estimation des frais, validation du remplacement de transaction et construction de blocs si vous êtes un mineur. 

Il s'agit de nombreux objectifs différents pour une seule fonction de votre nœud à servir. Bitcoin Core jusqu'à la version 30.0 organise le mempool de deux manières différentes pour aider à ces fonctions, toutes deux du point de vue relatif d'une transaction donnée : taux de frais combiné regardant vers l'avant de la transaction et ses enfants (taux de frais descendant), et taux de frais combiné regardant vers l'arrière de la transaction et ses parents (taux de frais ancestral). 

Ceux-ci sont utilisés pour décider quelles transactions expulser de votre mempool lorsqu'il est plein, et lesquelles inclure en premier lors de la construction d'un nouveau modèle de bloc. 

Comment mon Mempool est-il géré ?

Lorsqu'un mineur décide d'inclure ou non une transaction dans son bloc, son nœud examine cette transaction, ainsi que tous les ancêtres qui doivent d'abord être confirmés pour qu'elle soit valide dans un bloc, et examine le taux de frais moyen par octet pour tous ensemble en considérant les frais individuels qu'ils ont payés dans leur ensemble. Si ce groupe de transactions respecte la limite de taille de bloc tout en surpassant les autres en frais, il est inclus dans le bloc suivant. Cela est effectué pour chaque transaction.

Lorsque votre nœud décide quelles transactions expulser de son mempool lorsqu'il est plein, il examine chaque transaction et tous les enfants qu'elle a, expulsant la transaction et tous ses enfants si le mempool est déjà plein de transactions (et leurs descendants) payant un taux de frais plus élevé. 

Regardez l'exemple de graphique de transactions ci-dessus, les taux de frais sont indiqués comme suit entre parenthèses (taux de frais ancestral, taux de frais descendant). Un mineur examinant la transaction E l'inclurait probablement dans le bloc suivant, une petite transaction payant des frais très élevés avec un seul petit ancêtre. Cependant, si le mempool d'un nœud se remplissait, il examinerait la transaction A avec deux enfants massifs payant des frais relatifs faibles, et l'expulserait probablement ou ne l'accepterait pas et ne la conserverait pas si elle venait d'être reçue. 

Ces deux classements, ou ordres, sont complètement en contradiction l'un avec l'autre. Le mempool devrait propager de manière fiable ce que les mineurs mineront, et les utilisateurs devraient être confiants que leur mempool local prédit avec précision ce que les mineurs mineront. 

Le fonctionnement du mempool de cette manière est important pour :

• Décentralisation du mining : obtenir pour tous les mineurs l'ensemble de transactions le plus rentable
• Fiabilité de l'utilisateur : estimation précise et fiable des frais et des temps de confirmation des transactions
• Sécurité de la seconde couche : exécution fiable et précise des transactions d'application on-chain des protocoles de seconde couche

Le comportement actuel du mempool ne s'aligne pas totalement avec la réalité des incitations au mining, ce qui crée des angles morts qui peuvent être problématiques pour la sécurité de la seconde couche en créant une incertitude quant à savoir si une transaction parviendra à un mineur, ainsi qu'une pression pour des canaux de diffusion non publics vers les mineurs, aggravant potentiellement le premier problème. 

Ceci est particulièrement problématique lorsqu'il s'agit de remplacer des transactions non confirmées, soit simplement pour inciter les mineurs à inclure un remplacement plus tôt, soit dans le cadre d'un protocole de seconde couche appliqué on-chain. 

Le remplacement selon le comportement existant devient imprévisible selon la forme et la taille du réseau de transactions dans lequel la vôtre est prise. Dans une situation simple d'augmentation des frais, cela peut échouer à propager et remplacer une transaction, même lorsque miner le remplacement serait meilleur pour un mineur. 

Dans le contexte des protocoles de seconde couche, la logique actuelle permet aux participants d'obtenir potentiellement l'expulsion des transactions ancestrales nécessaires du mempool, ou de rendre impossible pour un autre participant de soumettre une transaction enfant nécessaire au mempool selon les règles actuelles en raison de transactions enfants créées par le participant malveillant, ou de l'expulsion de transactions ancestrales nécessaires. 

Tous ces problèmes résultent de ces classements d'inclusion et d'expulsion incohérents et des désalignements d'incitations qu'ils créent. Avoir un classement global unique résoudrait ces problèmes, mais réorganiser globalement l'ensemble du mempool pour chaque nouvelle transaction est impraticable. 

Tout n'est qu'un graphique

Les transactions qui dépendent les unes des autres sont un graphique, ou une série dirigée de « chemins ». Lorsqu'une transaction dépense des sorties créées par une autre dans le passé, elle est liée à cette transaction passée. Lorsqu'elle dépense en outre des sorties créées par une deuxième transaction passée, elle lie les deux transactions historiques ensemble. 

Lorsqu'elles ne sont pas confirmées, les chaînes de transactions comme celle-ci doivent avoir les transactions antérieures confirmées en premier pour que les transactions ultérieures soient valides. Après tout, vous ne pouvez pas dépenser des sorties qui n'ont pas encore été créées. 

C'est un concept important pour comprendre le mempool, il est explicitement ordonné de manière directionnelle. 

Tout n'est qu'un graphique. 

Les morceaux font des clusters font des mempools

Dans le cluster mempool, le concept de cluster est un groupe de transactions non confirmées qui sont directement liées les unes aux autres, c'est-à-dire dépensant des sorties créées par d'autres dans le cluster ou vice versa. Cela devient une unité fondamentale de la nouvelle architecture du mempool. Analyser et ordonner l'ensemble du mempool est une tâche impraticable, mais analyser et ordonner des clusters est beaucoup plus gérable. 

Chaque cluster est décomposé en morceaux, petits ensembles de transactions du cluster, qui sont ensuite triés par ordre de taux de frais par octet du plus élevé au plus bas, en respectant les dépendances directionnelles. Ainsi, par exemple, disons que du taux de frais le plus élevé au plus bas, les morceaux du cluster (A) sont : [A,D], [B,E], [C,F], [G, J], et enfin [I, H]. 

Cela permet de pré-trier tous ces morceaux et clusters, et un tri plus efficace de l'ensemble du mempool dans le processus. 

Les mineurs peuvent maintenant simplement prendre les morceaux à taux de frais le plus élevé de chaque cluster et les mettre dans leur modèle, s'il reste de la place, ils peuvent descendre aux morceaux à taux de frais suivants les plus élevés, continuant jusqu'à ce que le bloc soit à peu près plein et ait juste besoin de déterminer les dernières transactions qu'il peut inclure. C'est à peu près la méthode de construction de modèle de bloc optimale en supposant l'accès à toutes les transactions disponibles. 

Lorsque les mempools des nœuds se remplissent, ils peuvent simplement prendre les morceaux à taux de frais le plus bas de chaque cluster, et commencer à les expulser de leur mempool jusqu'à ce qu'il ne dépasse pas la limite configurée. Si cela ne suffisait pas, il passe aux morceaux à taux de frais suivants les plus bas, et ainsi de suite, jusqu'à ce qu'il soit dans ses limites de mempool. De cette manière, cela supprime les cas limites étranges désalignés avec les incitations au mining. 

La logique de remplacement est également considérablement simplifiée. Comparez le cluster (A) au cluster (B) où la transaction K a remplacé G, I, J et H. Le seul critère qui doit être satisfait est que le nouveau morceau [K] doit avoir un taux de frais de morceau plus élevé que [G, J] et [I, H], [K] doit payer plus de frais au total que [G, J, I, H], et K ne peut pas dépasser une limite supérieure du nombre de transactions qu'il remplace. 

Dans un paradigme de cluster, toutes ces utilisations différentes sont alignées les unes avec les autres. 

Le nouveau Mempool

Cette nouvelle architecture nous permet de simplifier les limites de groupe de transactions, supprimant les limitations précédentes sur le nombre d'ancêtres non confirmés qu'une transaction dans le mempool peut avoir et les remplaçant par une limite de cluster globale de 64 transactions et 101 kvB par cluster. 

Cette limite est nécessaire pour maintenir le coût de calcul du pré-tri des clusters et de leurs morceaux suffisamment bas pour être pratique pour les nœuds à effectuer de manière constante. 

C'est la véritable idée clé du cluster mempool. En gardant les morceaux et les clusters relativement petits, vous rendez simultanément la construction d'un modèle de bloc optimal peu coûteuse, simplifiez la logique de remplacement de transaction (augmentation des frais) et améliorez donc la sécurité de la seconde couche, et corrigez la logique d'expulsion, tout à la fois. 

Plus de calcul coûteux et lent à la volée pour la construction de modèles, ou de comportement imprévisible dans l'augmentation des frais. En corrigeant le désalignement des incitations dans la manière dont le mempool gérait l'organisation des transactions dans différentes situations, le mempool fonctionne mieux pour tout le monde. 

Le cluster mempool est un projet qui a été en cours depuis des années, et aura un impact matériel sur la garantie que les modèles de blocs rentables sont ouverts à tous les mineurs, que les protocoles de seconde couche ont des comportements de mempool solides et prévisibles sur lesquels construire, et que Bitcoin peut continuer à fonctionner comme un système monétaire décentralisé. 

Pour ceux qui souhaitent approfondir les détails techniques de la façon dont le cluster mempool est implémenté et fonctionne en coulisses, voici deux fils Delving Bitcoin que vous pouvez lire :

Aperçu de l'implémentation de haut niveau (avec justification de conception) : https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393 

Comment fonctionnent les diagrammes de taux de frais du Cluster Mempool : https://delvingbitcoin.org/t/mempool-incentive-compatibility/553 

Ne manquez pas votre chance de posséder The Core Issue — avec des articles écrits par de nombreux développeurs Core expliquant eux-mêmes les projets sur lesquels ils travaillent !

Cet article est la lettre de l'éditeur présentée dans la dernière édition imprimée de Bitcoin Magazine, The Core Issue. Nous le partageons ici comme un aperçu précoce des idées explorées tout au long du numéro complet.

[1] https://github.com/bitcoin/bitcoin/issues/27677 

[2] https://github.com/bitcoin/bitcoin/pull/33629 

Cet article The Core Issue : Cluster Mempool, Problems Are Easier In Chunks est apparu en premier sur Bitcoin Magazine et est écrit par Shinobi.