Compact Block Filters

Anna czeka na płatność w portfelu na telefonie. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Bloki są pakietami transakcji, ale telefon nie musi pobierać każdego pakietu w całości. Najpierw może przeglądać niewielkie filtry, podobnie jak czytelnik korzysta ze skorowidza przed otwarciem właściwej strony. Dla tego samego bloku i typu filtra wszyscy dostają to samo podsumowanie; wybór tego, co dotyczy Anny, następuje dopiero w jej telefonie. Dokumenty techniczne BIP 157 i BIP 158 dzielą się zadaniami: pierwszy opisuje pobieranie i sprawdzanie filtrów, drugi ich zawartość i budowę. Portfel najpierw weryfikuje nagłówki bloków, czyli podstawowe dane wiążące bloki w łańcuch, a potem pobiera dane kontrolne filtrów i same filtry. Po trafieniu ściąga cały blok i szuka rzeczywistej transakcji. Podobnie nazwane Compact Blocks z BIP 152 rozwiązują inny problem: szybkie przekazywanie nowych bloków między węzłami. Węzeł to program, który sprawdza transakcje i bloki oraz wymienia dane z innymi uczestnikami sieci. [1] [2] [5] [6]

Transakcja Bitcoin tworzy wyjścia: kwoty wraz z warunkami ich późniejszego wydania. Kod opisujący te warunki nazywa się scriptPubKey. Wejście nowej transakcji wskazuje wcześniejsze wyjście, które jest wydawane. Filtr basic o identyfikatorze 0x00 zawiera więc zarówno skrypty nowych wyjść, jak i skrypty wcześniejszych wyjść wydawanych w bloku. Anna może szukać w ten sposób wpływów i wydatków. Pomijane są nowe skrypty zaczynające się od OP_RETURN, instrukcji czyniącej wyjście niewydawalnym. Pomijane jest też specjalne wejście transakcji coinbase, która przyznaje nagrodę górnikowi bez wydawania wcześniejszego wyjścia. Puste elementy odpadają, powtórzone liczą się tylko raz. To nie lista wszystkich identyfikatorów transakcji txid, adresów zapisanych tekstem czy danych witness, takich jak podpisy. Do prawidłowej budowy potrzeba także wcześniejszych wydawanych wyjść, nie tylko nowego bloku. [2]

Serwer mógłby wysłać Annie podsumowanie celowo pomijające jej płatność. Portfel sprawdza więc również powiązania z wcześniejszymi filtrami. Hash to krótki cyfrowy odcisk danych. Dwukrotne zastosowanie SHA-256 do zapisanego filtra daje jego double-SHA256. Ten odcisk łączy się z poprzednim nagłówkiem filtra i tak samo hashuje, tworząc następny nagłówek. Zmiana starego filtra zmienia zatem późniejsze dane kontrolne. Jednak nagłówek bloku chroniony przez wydobycie nie zawiera hasha tego pomocniczego łańcucha filtrów. Jeśli wszystkie serwery dostarczą tę samą fałszywą sekwencję, odciski nadal mogą idealnie pasować. Matematyczna spójność sama nie dowodzi zgodności podsumowania z prawdziwym blokiem. [1]

BIP 157 zaleca dlatego połączenia z kilkoma niezależnymi węzłami, nazywanymi w tej wymianie peerami. Alternatywą jest bezpieczne połączenie z zaufanym węzłem, na przykład własnym. Przy sprzecznych łańcuchach filtrów portfel szuka pierwszej rozbieżności. Może odtworzyć właściwy filtr z danego bloku i potrzebnych wcześniejszych wyjść. Gwarancja rozpoznania poprawnych filtrów zakłada co najmniej jednego uczciwego peera; kilka połączeń z tym samym napastnikiem nie spełnia tego warunku. Sam łańcuch też może się zmienić: podczas reorganizacji węzły zastępują część jego końca gałęzią z większą skumulowaną wykazaną pracą. Portfel musi śledzić filtry tej gałęzi i ponownie ocenić dotknięte płatności. Znalezione wcześniej potwierdzenie nadal zależy od łańcucha akceptowanego przez sieć. [1] [2]

W starszym podejściu BIP 37 portfel wysyłał serwerowi własny filtr opisujący obserwowane dane. Compact Block Filters odwracają ten proces: portfel pobiera dane ogólne i wybiera ważne dla siebie informacje lokalnie. Ogranicza to ujawnianie śledzonych skryptów. Dostawca nadal widzi jednak, o które pełne bloki Anna potem prosi, i może powiązać żądania z jej adresem IP, czyli sieciowym adresem połączenia. Powtarzane wizyty mogą ujawnić kolejne wzorce. BIP 157 zaleca losowo wybierać źródła całych bloków spośród węzłów, z którymi portfel sam nawiązał połączenia. Blok może pochodzić z innego węzła niż filtr. Poprawia to prywatność, lecz nie gwarantuje anonimowości. [1]

Filtry opisują bloki już włączone do łańcucha. Nie obejmują bieżącego Mempool, czyli niepotwierdzonych transakcji przechowywanych przez dany węzeł do dalszego przekazywania lub wydobycia. Trafienie nie dowodzi też, że Anna ma klucz do wydania znalezionych środków. Klucz prywatny to tajna wartość liczbowa, której portfel używa do utworzenia podpisu cyfrowego zatwierdzającego wydanie środków. Portfel musi sprawdzić prawdziwą transakcję i jej obecność w bloku. Lekki klient nadal nie weryfikuje każdej transakcji każdego bloku według wszystkich zasad, jak robi to Full Node. Oszczędność zasobów oznacza więc rzeczywisty kompromis bezpieczeństwa. Dostępność danych jest odrębną kwestią: Pruned Node może usunąć stare bloki po sprawdzeniu i zachować ich filtry. Anna otrzyma podsumowanie, ale pełny stary blok musi pobrać gdzie indziej. Samo przycinanie danych nie oznacza rezygnacji z pełnej weryfikacji zasad. [1] [5]

Mały rozmiar ma swoją cenę: filtr może odpowiedzieć „być może tak”, mimo że szukanego elementu nie ma w bloku. To fałszywe trafienie, czyli false positive. Anna pobierze wtedy blok niepotrzebnie, ale portfel nie znajdzie domniemanej płatności i nie powinien jej doliczyć. Prawidłowy filtr nie pomija elementu, który rzeczywiście uwzględnia według swoich zasad; nie czyni to jednak wiarygodnymi danych wymyślonych przez nieuczciwy serwer. Technicznie SipHash-2-4 zamienia elementy na liczby w zakresie o wielkości N × M, gdzie N oznacza liczbę elementów. Liczby są sortowane, a ich różnice zapisywane oszczędnie kodowaniem Golomb-Rice. P=19 steruje kodowaniem, M=784931 wpływa na losowe trafienia; dla pojedynczego zapytania spoza zbioru prawdopodobieństwo wynosi około 1/M. Bajt jest standardową jednostką ilości danych. Klucz SipHash to pierwsze 16 bajtów hasha bloku w kolejności little-endian, od mniej znaczących bajtów. Nie jest to tajny klucz portfela. SipHash zamienia tu elementy na liczby dla filtra, zamiast je szyfrować. Zapis filtra zaczyna się od N w formacie CompactSize dla nieujemnych liczb całkowitych. [2]

W dniu przeglądu 2026-10-17 oba dokumenty mają status Deployed: protokół jest wdrożony, co nie znaczy, że obsługuje go każdy portfel. Ten przykład konfiguracji dotyczy konkretnie Bitcoin Core 29.0. -blockfilterindex tworzy lokalny indeks. -peerblockfilters włącza udostępnianie innym węzłom i wymaga indeksu basic; NODE_COMPACT_FILTERS ogłasza tę możliwość. Interfejs programistyczny RPC udostępnia getblockfilter, zwracający pola filter i header wybranego bloku. Działające RPC samo nie dowodzi zatem dostępności filtrów dla innych węzłów sieci. Dla czytelników specyfikacji: getcfilters/cfilter przesyła filtry, getcfheaders/cfheaders dane powiązań, a getcfcheckpt/cfcheckpt punkty kontrolne pomocniczego łańcucha. To nazwy komunikatów sieciowych, nie polecenia, które musi wpisywać użytkownik portfela w telefonie. [3] [4]