Cluster mempool

Les transactions non confirmées qui dépensent les unes les sorties des autres forment un graphe de dépendances, et pendant des années le logiciel n'a pu en raisonner qu'au moyen de plafonds grossiers sur le nombre d'ancêtres et de descendants autorisés pour chaque entrée. La version 31.0 les a remplacés par une seule règle : aucun groupe lié de plus de 64 transactions ou de 101 kB de taille virtuelle. La majoration des frais et le remplacement sont tous deux devenus plus prévisibles en conséquence.

Comment cela fonctionne

Un cluster est une composante connexe de la mempool. Prenez une transaction non confirmée quelconque, suivez chaque lien parent et enfant dans les deux sens, et tout ce que vous pouvez atteindre appartient au même cluster.

L'ancienne conception suivait séparément les ancêtres et les descendants et plafonnait chacun à 25, avec un plafond de taille en complément. C'était peu coûteux à calculer et faux d'une manière importante. Elle indiquait à un nœud la taille d'une famille sans lui dire dans quel ordre un mineur rationnel prendrait cette famille, de sorte que la mempool ne pouvait pas répondre à sa propre question centrale : si je devais construire un bloc maintenant, que contiendrait-il ?

Le cluster mempool y répond en gardant chaque cluster linéarisé à tout moment. Une linéarisation est un ordre découpé en tronçons, chaque tronçon étant un ensemble de transactions qui seraient minées ensemble et partageant un même taux de frais effectif. Le tri de ces tronçons produit un diagramme des taux de frais pour toute la mempool, et c'est à ce diagramme que les décisions sont désormais comparées.

Les limites sont de 64 transactions et de 101 kB de taille virtuelle par cluster, et elles ont entièrement remplacé les comptes d'ancêtres et de descendants. Le CPFP carveout, une exception qui laissait auparavant un enfant supplémentaire dépasser la limite de descendants, a été supprimé en même temps, car rien n'est autorisé à contourner le plafond du cluster.

Le bénéfice apparaît dans le remplacement. Les anciennes règles de remplacement par les frais étaient une poignée de conditions assemblées, et elles pouvaient être détournées en attachant des déchets peu coûteux à une transaction partagée jusqu'à ce que son remplacement devienne absurdement cher. Comparer les diagrammes des taux de frais donne un seul test : un remplacement est accepté lorsqu'il laisse le diagramme nulle part moins bon et quelque part meilleur. Deux nouveaux RPC exposent le mécanisme, getmempoolcluster pour le contenu et l'ordre d'un cluster et getmempoolfeeratediagram pour le diagramme lui-même.

Où cela se voit

Le cluster mempool apparaît sous forme de message d'erreur lorsque vous enchaînez trop de dépenses non confirmées, et sous forme de majoration de frais qui réussit là où vous attendiez des difficultés.

Les utilisateurs de portefeuille rencontrent la limite dans une situation courante : dépenser sans cesse de la monnaie rendue non confirmée pendant une période chargée. Soixante-quatre transactions, c'est généreux pour une personne et serré pour un service qui regroupe des paiements, ce qui correspond à peu près au public pour lequel ce nombre a été conçu. Quand un portefeuille refuse une dépense et mentionne un cluster, la solution est d'attendre une confirmation plutôt que d'augmenter les frais.

Le bénéfice plus discret est que le paiement du parent par l'enfant fait désormais ce qu'il annonce. Majorez une transaction bloquée en dépensant sa sortie à un taux élevé et le nœud voit immédiatement si la paire bat ce qui est déjà en file, de sorte que vous obtenez une réponse directe en une étape au lieu d'une approximation.

Cluster mempool vs mempool

La mempool est l'ensemble des transactions qu'un nœud détient ; le cluster mempool est la façon dont un programme organise cet ensemble en interne. Aucune règle de consensus n'a changé, aucun fork n'a eu lieu, et un nœud qui exécute encore une version plus ancienne détient les mêmes transactions avec une comptabilité moins bonne. La distinction compte parce que le changement est parfois rapporté comme si bitcoin avait gagné une nouvelle règle à l'échelle du réseau sur les chaînes de transactions. Ce n'est pas le cas. Il s'agit d'une politique, choisie nœud par nœud, et tout opérateur peut modifier les limites sur sa propre machine avec un argument de ligne de commande.