Pool de mémoire du cluster1 est une refonte complète de la façon dont 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 deuxième couche. Il a été fusionné avec Bitcoin Core dans le PR #33629.2 le 25 novembre 2025.
Le mempool est un ensemble géant de transactions en attente que votre nœud doit suivre pour un certain nombre de raisons : estimation des frais, validation du remplacement des transactions et construction de blocs si vous êtes un mineur.
Cela représente de nombreux objectifs différents à desservir par une seule fonction de votre nœud. Bitcoin Core jusqu’à la version 30.0 organise le mempool de deux manières différentes pour aider à ces fonctions, à la fois du point de vue relatif d’une transaction donnée : frais combinés analysant la transaction et ses enfants (frais descendants) et frais combinés regardant en arrière de la transaction et de ses parents (frais ancêtres).
Ceux-ci sont utilisés pour décider quelles transactions expulser de votre pool de mémoire lorsqu’il est plein et lesquelles inclure en premier lors de la construction d’un nouveau modèle de bloc.
Comment mon pool de mémoire 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 moyen par octet pour l’ensemble d’entre eux en tenant compte des 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 termes de frais, il est inclus dans le bloc suivant. Ceci est fait pour chaque transaction.
Lorsque votre nœud décide quelles transactions expulser de son pool de mémoire lorsqu’il est plein, il examine chaque transaction et tous ses enfants, expulsant la transaction et tous ses enfants si le pool de mémoire est déjà plein de transactions (et de leurs descendants) payant des frais plus élevés.
Regardez l’exemple de graphique de transactions ci-dessus, les frais sont indiqués comme tels entre parenthèses (frais ancêtres, frais descendants). 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 pool de mémoire 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 la conserverait si elle venait d’être reçue.
Ces deux classements, ou ordres, sont complètement en contradiction l’un avec l’autre. Le pool de mémoire doit propager de manière fiable ce que les mineurs exploiteront, et les utilisateurs doivent être sûrs que leur pool de mémoire local prédit avec précision ce que les mineurs exploiteront.
Le mempool fonctionnant de cette manière est important pour :
- Décentralisation minière : obtenir tous les mineurs constituent l’ensemble de transactions le plus rentable
- Fiabilité des utilisateurs : estimation précise et fiable des frais et délais de confirmation des transactions
- Sécurité de deuxième couche : exécution fiable et précise des transactions d’application en chaîne des protocoles de deuxième couche
Le comportement actuel du mempool ne correspond pas entièrement à la réalité des incitations minières, ce qui crée des angles morts qui peuvent être problématiques pour la sécurité du deuxième niveau en créant une incertitude quant à savoir si une transaction parviendra à un mineur, ainsi qu’une pression sur les chaînes de diffusion non publiques vers les mineurs, aggravant potentiellement le premier problème.
Cela 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 deuxième couche appliqué en chaîne.
Le remplacement selon le comportement existant devient imprévisible en fonction de la forme et de la taille du réseau de transactions dans lequel la vôtre est prise. Dans une simple situation de majoration des frais, cela peut ne pas réussir à propager et à remplacer une transaction, même lors de l’exploitation minière, le remplacement serait préférable pour un mineur.
Dans le contexte des protocoles de deuxième couche, la logique actuelle permet aux participants d’obtenir potentiellement les transactions ancêtres nécessaires expulsées du pool de mémoire, ou de rendre impossible à un autre participant de soumettre une transaction enfant nécessaire au pool de mémoire selon les règles actuelles en raison de transactions enfants créées par le participant malveillant, ou de l’expulsion de transactions ancêtres nécessaires.
Tous ces problèmes sont le résultat de ces classements incohérents d’inclusion et d’expulsion et des désalignements d’incitations qu’ils créent. Avoir un classement mondial unique résoudrait ces problèmes, mais réorganiser globalement l’intégralité du pool de mémoire pour chaque nouvelle transaction n’est pas pratique.
Ce 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 produits créés par une autre dans le passé, elle est liée à cette transaction passée. Lorsqu’il dépense en outre les résultats créés par une transaction antérieure, il relie les deux transactions historiques entre elles.
Lorsqu’elles ne sont pas confirmées, des chaînes de transactions comme celle-ci doit faites confirmer d’abord les transactions antérieures pour que les dernières soient valides. Après tout, vous ne pouvez pas dépenser des résultats qui n’ont pas encore été créés.
Il s’agit d’un concept important pour comprendre le pool de mémoire, il est explicitement ordonné de manière directionnelle.
Ce n’est qu’un graphique.
Les morceaux créent des clusters et créent des pools de mémoire
Dans le cluster mempool, le concept de grappe est un groupe de transactions non confirmées qui sont directement liées les unes aux autres, c’est-à-dire les dépenses créées par d’autres dans le cluster ou vice versa. Cela devient une unité fondamentale de la nouvelle architecture mempool. Analyser et classer l’intégralité du pool de mémoire est une tâche peu pratique, mais analyser et classer les clusters est une tâche beaucoup plus gérable.
Chaque cluster est décomposé en morceauxde petits ensembles de transactions du cluster, qui sont ensuite triés par ordre croissant par octet au plus bas, en respectant les dépendances directionnelles. Ainsi, par exemple, disons, du plus haut 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 de trier plus efficacement l’ensemble du pool de mémoire au cours du processus.
Les mineurs peuvent désormais simplement récupérer les morceaux les plus élevés de chaque cluster et les insérer dans leur modèle. S’il y a encore de la place, ils peuvent passer aux morceaux suivants les plus élevés, en continuant jusqu’à ce que le bloc soit à peu près plein et qu’il leur suffit de déterminer les dernières transactions qu’il peut contenir. Il s’agit à peu près de la méthode de construction de modèle de bloc optimale en supposant l’accès à toutes les transactions disponibles.
Lorsque les pools de mémoire des nœuds sont pleins, ils peuvent simplement récupérer les morceaux les plus bas de chaque cluster et commencer à les expulser de leur pool de mémoire jusqu’à ce qu’il ne dépasse pas la limite configurée. Si cela ne suffit pas, il passe aux morceaux suivants les plus bas, et ainsi de suite, jusqu’à ce qu’il soit dans les limites de son pool de mémoire. Fait de cette façon, il supprime les cas extrêmes étranges qui ne sont pas alignés sur les incitations minières.
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 à remplir est le nouveau bloc. [K] doit avoir un taux de fragmentation plus élevé que [G, J] et [I, H], [K] doit payer plus en frais totaux 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 différentes utilisations sont alignées les unes sur les autres.
Le nouveau pool de mémoire
Cette nouvelle architecture nous permet de simplifier les limites des groupes de transactions, en supprimant les limitations précédentes sur le nombre d’ancêtres non confirmés qu’une transaction dans le pool de mémoire peut avoir et en les remplaçant par une limite globale de cluster de 64 transactions et 101 kvB par cluster.
Cette limite est nécessaire afin de maintenir le coût de calcul du pré-tri des clusters et de leurs fragments suffisamment bas pour permettre aux nœuds de fonctionner de manière constante.
C’est le véritable élément clé du pool de mémoire du cluster. En gardant les morceaux et les clusters relativement petits, vous rendez simultanément la construction d’un modèle de bloc optimal bon marché, vous simplifiez la logique de remplacement des transactions (augmentation des frais) et vous améliorez donc la sécurité de la deuxième couche et corrigez la logique d’expulsion, tout en même temps.
Fini les calculs à la volée coûteux et lents pour la création de modèles, ni les comportements imprévisibles en matière de majoration des frais. En corrigeant le désalignement des incitations dans la façon dont le mempool gérait l’organisation des transactions dans différentes situations, le mempool fonctionne mieux pour tout le monde.
Cluster Mempool est un projet qui a duré des années et qui aura un impact matériel en garantissant que des modèles de blocs rentables sont ouverts à tous les mineurs, que les protocoles de deuxième couche ont des comportements de mempool solides et prévisibles sur lesquels s’appuyer et que Bitcoin peut continuer à fonctionner comme un système monétaire décentralisé.
Pour ceux qui souhaitent approfondir la façon dont le cluster mempool est implémenté et fonctionne sous le capot, voici deux fils de discussion Delving Bitcoin que vous pouvez lire :
Aperçu de la mise en œuvre de haut niveau (avec justification de la conception) : https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393
Fonctionnement des diagrammes Cluster Mempool Feerate : https://delvingbitcoin.org/t/mempool-incentive-compatibility/553
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/bitcoin/issues/27677
[2] https://github.com/bitcoin/bitcoin/pull/33629