Compact Block Filters to niewielkie filtry danych tworzone dla poszczególnych bloków. Blok to grupa transakcji dodana do wspólnej historii sieci. Pomagają lekkiemu portfelowi wybrać bloki, które mogą zawierać jego transakcje i warto je pobrać. Działają jak oszczędny indeks orientacyjny, który może dawać fałszywe trafienia. Wyszukiwanie odbywa się w portfelu, bez wysyłania serwerowi listy obserwowanych danych.
Anna po dłuższej przerwie otwiera portfel w telefonie. Aplikacja musi ustalić, czy od ostatniego połączenia ktoś jej zapłacił lub wydano część jej środków. Zamiast wszystkich transakcji pobiera małe filtry i porównuje je z warunkami obserwowanych wyjść. Wyjście to część transakcji określająca kwotę i zasady jej późniejszego wydania. Po trafieniu aplikacja pobiera cały blok i szuka rzeczywistej transakcji. Nie powinna zwiększać salda tylko na podstawie filtru. Filtr nie jest wyciągiem z konta ani dowodem własności. Przed wyszukiwaniem klient synchronizuje nagłówki, czyli zwięzłe dane identyfikujące bloki, oraz powiązane nagłówki filtrów. [1]
W starszym podejściu BIP 37 klient wysyłał innemu węzłowi filtr utworzony z danych, które chciał obserwować. Tutaj kierunek jest odwrotny: serwer dostarcza filtr bloku, a Anna szuka lokalnie. Dla tego samego bloku i typu filtru klienci otrzymują identyczną treść. Nie muszą więc bezpośrednio ujawniać każdemu serwerowi szukanych skryptów. Nie oznacza to anonimowości: druga strona nadal może widzieć adres IP, czas połączenia i zamawiane później pełne bloki. Rozdzielenie pobierania między różne węzły ogranicza wiedzę każdego z nich, ale nie usuwa wszystkich możliwości łączenia informacji. [1]
Compact Block Filters wybierają bloki warte sprawdzenia. Compact Blocks według BIP 152 rozwiązują inny problem: oszczędzają transfer przy przesyłaniu bloku dzięki krótkim identyfikatorom transakcji, które odbiorca często już zna. Sięga po nie do swojego Mempool, lokalnego zbioru niepotwierdzonych transakcji, a brakujące zamawia. Żadne z tych narzędzi samo nie sprawdza wszystkich reguł Bitcoina. Full Node, czyli pełny węzeł, niezależnie weryfikuje bloki i transakcje zgodnie z regułami sieci. Lekki portfel sprawdzający tylko nagłówki i włączenie swojej transakcji wykonuje węższą kontrolę. Oszczędność danych i pełna weryfikacja to różne właściwości. [1] [5]
Format opisuje BIP 158. Filtr basic obejmuje scriptPubKey, skrypt określający warunki wydania, nowych wyjść poza zaczynającymi się od OP_RETURN. Obejmuje też skrypty wcześniejszych wyjść wydawanych w bloku. W przypadku wejść wyjątkiem jest coinbase, pierwsza transakcja bloku rozdzielająca nagrodę górnika, która nie wydaje zwykłych wcześniejszych wyjść. Jej nowe wyjścia podlegają tym samym zasadom włączania co pozostałe nowe wyjścia. Puste elementy są pomijane. Portfel musi przekształcić adres we właściwy skrypt; wyszukiwanie jego wydrukowanej postaci nie wystarczy. Filtr nie jest ogólną wyszukiwarką txid, czyli identyfikatorów transakcji, danych witness takich jak podpisy ani dowolnych notatek. [2] [3]
Po pobraniu bloku Anna może odkryć, że nic jej w nim nie dotyczy. Fałszywe trafienie jest zwykłym kosztem małego filtru, a samo w sobie nie dowodzi błędu. Technicznie elementy otrzymują liczbowe odciski, są sortowane, a różnice zapisuje się oszczędnie kodowaniem Golomb-Rice. Dla basic obowiązują P=19 i M=784931. Pojedyncze zapytanie o nieobecny element daje trafienie z prawdopodobieństwem około 1/M; więcej obserwowanych elementów oznacza więcej okazji do trafienia. Nie jest to stała częstość błędów całego portfela. Poprawnie utworzony filtr nie pomija zawartego elementu. Wynik ujemny wymaga jednak poprawnego filtru, objętego nim rodzaju danych i właściwego zapytania. [2]
BIP 157 określa przesyłanie filtrów i ich powiązane nagłówki. Każdy nagłówek łączy hash, kryptograficzny odcisk bieżącego filtru, z poprzednim nagłówkiem. Zmiana filtru narusza oczekiwane powiązanie. Ten łańcuch nie jest jednak częścią nagłówka bloku Bitcoin, więc praca włożona w jego wydobycie nie potwierdza bezpośrednio zawartości filtrów. Nieuczciwy węzeł może przygotować fałszywe filtry z prawidłowo obliczonymi powiązanymi odciskami. Nie zmienia Bitcoina, ale może ukryć informacje przed odizolowanym klientem. Sprawdzeniu matematycznych powiązań musi więc towarzyszyć weryfikacja danych. [1]
BIP 157 zakłada porównywanie węzłów z co najmniej jednym uczciwym źródłem. Przy rozbieżności klient może znaleźć pierwszy punkt różnicy i sprawdzić filtr na podstawie danych źródłowych. Do utworzenia basic sam nowy blok może nie wystarczyć: potrzebne są również skrypty wcześniejszych wyjść wydawanych przez jego transakcje. Szczególnej obsługi wymaga reorganizacja, gdy sieć przechodzi na inną gałąź poprawnych bloków o większej skumulowanej pracy. Portfel musi powiązać filtry z nową gałęzią i zaktualizować historię oraz saldo. Ta sama wysokość, czyli pozycja w łańcuchu, nie musi oznaczać tego samego bloku. [1] [3]
Portfel potrzebuje dostępnych filtrów i sposobu pobrania wybranych pełnych bloków. Węzeł może usunąć stare bloki po utworzeniu filtrów; wtedy dostarczy je inne źródło. W Bitcoin Core polecenie getblockfilter zwraca filtr i jego nagłówek dla wskazanego bloku przy włączonym odpowiednim indeksie. Dostępność polecenia nie dowodzi świadczenia publicznej usługi P2P innym węzłom ani dostępu do całej historii. Filtry istniejących bloków nie zgłaszają też niepotwierdzonych transakcji w Mempool. Do pokazania oczekującej płatności aplikacja potrzebuje innego mechanizmu. Takie szczegóły decydują, czy lekki portfel naprawdę dobrze działa. [1] [4]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Compact Block Filters, Neutrino, Full Node, Prywatność w Bitcoinie, Compact Blocks, Bitcoin. Do tego hasła prowadzą również odsyłacze z Neutrino, Erlay.