414 / 736GLOZOW

Gloria Zhao

Programistka mempoolu, przekazywania transakcji i przeglądu kodu

Gloria Zhao pracuje nad tym, jak transakcje Bitcoin przemieszczają się po sieci i czekają na potwierdzenie. Jej wkład w mempool, Package Relay i podnoszenie opłat odpowiada na praktyczne pytanie: jak dostarczyć potrzebną płatność górnikom, gdy pierwotna opłata już nie wystarcza?

Gloria Zhao jest programistką Bitcoin Core i autorką BIP 331 oraz BIP 431. Zajmuje się mempoolem, lokalnym zbiorem niepotwierdzonych transakcji każdego węzła, oraz regułami ich przyjmowania i przekazywania. Te mało widoczne części programu określają, o jakich płatnościach węzeł się dowie i które przekaże dalej. Ich rozwój wymaga pisania kodu, uważnej kontroli i szukania ochrony przed nadużyciami.

Gloria Zhao dołączyła do Brink 4 stycznia 2021 roku jako pierwsza stypendystka. W 2022 roku została opiekunką Bitcoin Core, jedną z osób odpowiedzialnych za jego kod źródłowy i proces rozwoju. To praca nad konkretnym oprogramowaniem, a nie mianowanie na szefową Bitcoina. Sprawdzona podczas tej rewizji lista absolwentów Brink opisuje ją jako byłą opiekunkę. W biografii warto więc patrzeć na daty: artykuł o dawnym powołaniu nie dowodzi, jaką funkcję ktoś pełni dzisiaj. [1] [2]

Dobry kod potrzebuje sprawdzenia przez inne osoby. Zhao pracowała z Bitcoin Core PR Review Club, gdzie nowi współtwórcy uczą się czytać proponowane zmiany i analizować ich skutki. PR, czyli pull request, to prośba o włączenie zmiany do projektu. Klub pomaga zrozumieć rozwiązywany problem i sposób kontroli; jego głównym celem nie jest doprowadzenie do scalenia konkretnego PR. Dyskusja służy nauce i przygotowaniu, a nie automatycznemu zatwierdzaniu kodu czy wydania. [2] [3]

Mempool nie jest jedną kolejką dla całej sieci. Każdy węzeł decyduje, jakie niepotwierdzone transakcje przyjąć i przekazać, uwzględniając na przykład opłaty i ochronę przed przeciążeniem. To lokalna polityka, odrębna od reguł konsensusu służących do sprawdzania ważności bloków. Zhao podpisała oświadczenie programistów z 6 czerwca 2025 roku, podkreślające wybór oprogramowania przez użytkownika. Programista może zaproponować inną politykę, ale ani podpis, ani uprawnienia opiekuna repozytorium nie przepisują programów na cudzych węzłach. [4]

Transakcja może wydawać środki z innej, która nie została jeszcze potwierdzona. Wcześniejszą nazywamy rodzicem, a zależną od niej — dzieckiem. BIP 331 autorstwa Zhao proponuje Package Relay, czyli przekazywanie powiązanych transakcji jako pakietu. Węzły uzgadniałyby obsługę przez sendpackages, najpierw pobierały informacje o potrzebnych przodkach, a potem właściwe dane transakcji. Nie musiałyby mozolnie szukać każdego brakującego ogniwa. Dokument ma status Draft, czyli projektu; samo jego istnienie nie dowodzi pełnego wdrożenia protokołu w sieci. [5]

Wyobraźmy sobie otrzymaną, niepotwierdzoną płatność ze zbyt niską opłatą. Jeśli możesz wydać jej wyjście, możesz utworzyć kolejną transakcję z wyższą opłatą. To CPFP, Child Pays for Parent: aby otrzymać opłatę dziecka, górnik musi uwzględnić również rodzica, więc może oceniać je łącznie. Węzeł, który nie zna rodzica, zwykle nie może jednak przyjąć samego dziecka. Właśnie tę przeszkodę w przekazywaniu podejmuje BIP 331. Wyższa opłata nie zastępuje ważnych podpisów i wejść ani nie gwarantuje potwierdzenia w określonym czasie. [5]

Bitcoin Core 28.0 wprowadził ograniczoną procedurę 1P1C: jeden rodzic i jedno dziecko. Przez istniejącą komunikację P2P, czyli bezpośrednią wymianę między węzłami, program mógł łączyć odpowiednie transakcje i oceniać je razem. To konkretne ulepszenie, ale nie pełne wdrożenie BIP 331. Informacje o wydaniu wyraźnie wykluczają w tej procedurze sieciowej dziecko z wieloma niepotwierdzonymi rodzicami i ostrzegają, że nie jest jeszcze niezawodna podczas ataku. Twórca portfela polegającego na przekazywaniu musi odróżniać ograniczoną funkcję od szerszej propozycji. [5] [6]

Napastnik może wykorzystać limity mempoolu, aby utrudnić zastąpienie transakcji lub zwiększenie jej opłaty. To pinning. Polityka TRUC ogranicza zależności między transakcjami do czasu potwierdzenia, ułatwiając ocenę przyjęcia lub zastąpienia. Bitcoin Core 28.0 wprowadził ją dla transakcji z nVersion=3. BIP 431 autorstwa Zhao opisuje ten sposób w dokumencie informacyjnym o statusie Draft. Ograniczenie niepotwierdzonych przodków i potomków pomaga, lecz ochrona zależy też od przyjęcia polityki przez inne węzły. Nie gwarantuje odporności na każdy pinning ani terminowego umieszczenia w bloku. [6] [7]

Program może przekazać pakiet własnemu węzłowi poleceniem submitpackage. Dokumentacja Bitcoin Core 28.0 wyjaśnia, że polecenie to, dostępne przez interfejs RPC do komunikacji z węzłem, sprawdza zarówno reguły konsensusu, jak i politykę mempoolu. Transakcje przechodzące kontrole mogą zostać przyjęte, nawet jeśli inna część pakietu zawiedzie. Błąd nie musi więc cofnąć całego wyniku. Trzeba czytać ogólne package_msg i poszczególne tx-results. Nawet lokalny sukces nie dowodzi, że pakiet dotarł do całej sieci albo że transakcje weszły do bloku. [8]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Mike Hearn, Mempool, Package Relay. Do tego hasła prowadzą również odsyłacze z Package Relay, Mike Hearn, Sergio Demian Lerner.

DOC · 001Brink — Gloria Zhao dated contribution historyDokumentacja DOC · 002Brink — program alumniDokumentacja DOC · 003Bitcoin Core PR Review Club — purposeDokumentacja DOC · 004Bitcoin Core — relay policy statementDokumentacja DOC · 005BIP 331 — Ancestor Package RelayDokumentacja DOC · 006Bitcoin Core 28.0 — release notesDokumentacja DOC · 007BIP 431 — Topology Restrictions for PinningDokumentacja DOC · 008Bitcoin Core 28.0 — submitpackageDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna