Gloria Zhao je vývojářka Bitcoin Core a autorka BIP 331 a BIP 431. Zaměřuje se na mempool, místní zásobník nepotvrzených transakcí každého uzlu, a na pravidla jejich přijímání a předávání. Tyto zdánlivě skryté části softwaru rozhodují o tom, o kterých platbách se uzel dozví a předá o nich informace dál. Jejich vývoj zahrnuje psaní kódu, pečlivou kontrolu i hledání cest, jak zabránit zneužití.
Do organizace Brink nastoupila Gloria Zhao 4. ledna 2021 jako první stipendistka. V roce 2022 se stala správkyní Bitcoin Core, tedy jednou z lidí odpovědných za údržbu jeho zdrojového kódu a vývojového procesu. Je to práce na konkrétním softwaru, ne jmenování do čela Bitcoinu. Přehled absolventů programu Brink ji při této revizi uvádí jako bývalou správkyni. Je proto dobré číst její životopis s daty: článek o někdejším jmenování ještě neříká, jakou funkci člověk zastává dnes. [1] [2]
Kvalitní kód potřebuje další oči. Zhao se podílela na Bitcoin Core PR Review Club, kde se noví přispěvatelé učí číst návrhy změn a prověřovat jejich důsledky. PR neboli pull request je žádost o začlenění změny do projektu. Klub pomáhá pochopit, co změna řeší a jak ji kontrolovat; jeho hlavním cílem není prosadit sloučení konkrétního PR. Diskuse je součást učení a přípravy, nikoli automatické schválení kódu nebo celého vydání. [2] [3]
Mempool není jednotná fronta pro celou síť. Každý uzel rozhoduje, které nepotvrzené transakce přijme a předá dál, například podle poplatku a ochrany před zahlcením. Tomu se říká místní politika. Liší se od konsenzuálních pravidel, podle kterých uzly ověřují platnost bloků. Zhao podepsala stanovisko vývojářů z 6. června 2025, které zdůrazňuje volbu softwaru uživatelem. Vývojář může navrhnout jinou politiku programu, ale jeho podpis ani přístup ke správě repozitáře nepřepíše software na všech cizích uzlech. [4]
Transakce může utrácet prostředky z jiné transakce, která ještě není potvrzená. Té předchozí říkáme rodič; pokud na ní závisí další transakce, mluvíme o potomkovi. Zhaové BIP 331 navrhuje Package Relay, tedy přenos souvisejících transakcí jako balíku. Uzly by si přes sendpackages dohodly podporu, nejprve získaly informace o potřebných předcích a poté samotná data transakcí. Nemusely by tak složitě dohledávat každý chybějící článek. Dokument má stav Draft, tedy návrh; jeho existence nedokládá plné nasazení protokolu v celé síti. [5]
Představme si, že obdržíte nepotvrzenou platbu s příliš nízkým poplatkem. Pokud můžete její výstup utratit, lze vytvořit navazující transakci s vyšším poplatkem. To je CPFP, Child Pays for Parent: aby těžař získal poplatek potomka, musí zahrnout i rodiče, takže může posuzovat jejich společnou výhodnost. Jenže uzel, který rodiče nemá, nemůže potomka běžně přijmout samostatně. Právě tuto překážku v přenosu řeší BIP 331. Ani vyšší poplatek nenahrazuje platné podpisy a vstupy a nezaručuje potvrzení do určitého času. [5]
Bitcoin Core 28.0 zavedl omezený postup 1P1C, tedy jeden rodič a jeden potomek. Přes existující P2P komunikaci, přímý přenos mezi uzly, dokázal vhodné transakce spojit a posoudit společně. Je to konkrétní zlepšení, ale není to plné nasazení BIP 331. Poznámky k vydání výslovně uvádějí, že tento síťový postup nepodporuje potomka s více nepotvrzenými rodiči a při útoku ještě není spolehlivý. Rozdíl mezi omezenou funkcí vydání a širším návrhem je důležitý při stavbě peněženky, která na přenos spoléhá. [5] [6]
Útočník může zneužít limity mempoolu a zkomplikovat nahrazení transakce nebo zvýšení jejího poplatku. Tomu se říká pinning. Politika TRUC omezuje vzájemné závislosti transakcí do jejich potvrzení, aby bylo snazší rozhodovat o jejich přijetí či nahrazení. Bitcoin Core 28.0 ji zavedl pro transakce s nVersion=3. Zhaové BIP 431 tento přístup popisuje jako informační dokument se stavem Draft. Omezení nepotvrzených předků a potomků pomáhá, ale ochrana závisí i na přijetí politiky dalšími uzly. Nejde o záruku proti každému pinningu ani o příslib včasného vytěžení. [6] [7]
Program může předat balík vlastnímu uzlu příkazem submitpackage. Dokumentace Bitcoin Core 28.0 vysvětluje, že tento příkaz přes rozhraní RPC, určené pro komunikaci s uzlem, kontroluje konsenzuální pravidla i politiku mempoolu. Transakce, které kontrolami projdou, mohou být přijaty, i když jiná část balíku selže. Chyba tedy nemusí zrušit celý předchozí výsledek. Proto se čte jak souhrnné package_msg, tak jednotlivé tx-results. A ani úspěch místního uzlu ještě neznamená, že balík prošel celou sítí nebo že se transakce dostaly do bloku. [8]
Pro nejúplnější obraz čtěte toto heslo společně s Mike Hearn, Mempool, Package Relay. Opačným směrem na něj odkazují také Package Relay, Mike Hearn, Sergio Demian Lerner.