Gloria Zhao est développeuse Bitcoin Core et auteure des BIP 331 et BIP 431. Elle se concentre sur le mempool, la réserve locale de transactions non confirmées de chaque nœud, et sur les règles d’acceptation et de transmission. Ces parties peu visibles du logiciel déterminent quels paiements un nœud découvre et relaie. Les développer demande du code, une revue attentive et des moyens de prévenir les abus.
Gloria Zhao a rejoint Brink le 4 janvier 2021 comme première bénéficiaire de son programme de formation financée. En 2022, elle est devenue mainteneuse de Bitcoin Core, parmi les personnes chargées de son code source et de son processus de développement. Il s’agit de travailler sur un logiciel précis, pas d’être nommée à la tête de Bitcoin. La page des anciens participants de Brink consultée pour cette révision la présente comme ancienne mainteneuse. Les dates comptent donc : un article sur une nomination passée ne prouve pas la fonction occupée aujourd’hui. [1] [2]
Un bon code a besoin d’autres personnes pour l’examiner. Zhao a travaillé au Bitcoin Core PR Review Club, où les nouveaux contributeurs apprennent à lire les changements proposés et à étudier leurs conséquences. Un PR, ou pull request, est une demande d’intégration d’un changement au projet. Le club aide à comprendre le problème traité et la manière de vérifier la solution ; son objectif principal n’est pas de faire intégrer un PR particulier. La discussion sert à apprendre et à se préparer, pas à approuver automatiquement du code ou une version. [2] [3]
Le mempool n’est pas une file unique partagée par tout le réseau. Chaque nœud choisit les transactions non confirmées qu’il accepte et transmet, en tenant compte, par exemple, des frais et de la protection contre la saturation. Ce sont des politiques locales, différentes des règles de consensus qui servent à vérifier la validité des blocs. Zhao a signé la déclaration du 6 juin 2025 soulignant la liberté des utilisateurs de choisir leur logiciel. Un développeur peut proposer une autre politique, mais ni sa signature ni ses droits de maintenance ne réécrivent le programme des autres nœuds. [4]
Une transaction peut dépenser des fonds provenant d’une autre transaction encore non confirmée. La précédente est son parent ; celle qui en dépend est son enfant. Le BIP 331 de Zhao propose Package Relay, la transmission de transactions liées sous forme de paquet. Les nœuds négocieraient cette prise en charge avec sendpackages, obtiendraient d’abord des informations sur les ancêtres nécessaires, puis les données des transactions. Cela éviterait de rechercher péniblement chaque maillon manquant. Le document est classé Draft, donc à l’état de proposition ; son existence ne prouve pas un déploiement complet sur le réseau. [5]
Imaginez recevoir un paiement non confirmé dont les frais sont trop faibles. Si vous pouvez dépenser sa sortie, vous pouvez créer une transaction suivante avec davantage de frais. C’est CPFP, Child Pays for Parent : pour percevoir les frais de l’enfant, le mineur doit aussi inclure le parent et peut donc évaluer leur intérêt ensemble. Mais un nœud qui ne connaît pas le parent ne peut normalement pas accepter l’enfant seul. Le BIP 331 traite cet obstacle au relais. Des frais plus élevés ne remplacent pas des signatures et des entrées valides. Ils ne garantissent pas non plus une confirmation avant une échéance. [5]
Bitcoin Core 28.0 a introduit une procédure limitée 1P1C, soit un parent et un enfant. Par la communication P2P existante, l’échange direct entre nœuds, il pouvait associer des transactions appropriées et les évaluer ensemble. C’est un progrès concret, mais pas le déploiement intégral du BIP 331. Les notes de version précisent que cette procédure réseau ne prend pas en charge un enfant ayant plusieurs parents non confirmés et reste peu fiable en situation d’attaque. Distinguer cette fonction limitée de la proposition plus large est essentiel pour concevoir un portefeuille qui compte sur le relais. [5] [6]
Un attaquant peut exploiter les limites du mempool pour compliquer le remplacement d’une transaction ou l’augmentation de ses frais. C’est le pinning. La politique TRUC limite les dépendances entre transactions jusqu’à leur confirmation afin de faciliter les décisions d’acceptation ou de remplacement. Bitcoin Core 28.0 l’a introduite pour les transactions avec nVersion=3. Le BIP 431 de Zhao décrit cette approche dans un document informatif classé Draft. Limiter les ancêtres et descendants non confirmés aide, mais la protection dépend aussi de l’adoption par d’autres nœuds. Ce n’est ni une protection contre tout pinning ni une promesse d’inclusion rapide dans un bloc. [6] [7]
Une application peut soumettre un paquet à son propre nœud avec submitpackage. La documentation de Bitcoin Core 28.0 explique que cette commande, disponible par l’interface RPC de communication avec le nœud, vérifie les règles de consensus et la politique du mempool. Les transactions qui passent les contrôles peuvent être acceptées même si une autre partie échoue. Une erreur n’annule donc pas nécessairement tout le résultat. Il faut lire le bilan package_msg et chaque tx-results. Même un succès local ne prouve ni la propagation dans tout le réseau ni l’inclusion des transactions dans un bloc. [8]
Pour une vision complète, lisez aussi Mike Hearn, Mempool, Package Relay. Cette entrée est également citée par Package Relay, Mike Hearn, Sergio Demian Lerner.