SPV sprawdza nagłówki, nie cały stan
Sekcja 8 whitepaperu opisuje simplified payment verification: klient zachowuje nagłówki łańcucha o największej pracy i gałęzią Merkle’a potwierdza włączenie. Sprawdza proof of work oraz kolejność nagłówków bez pobierania każdej transakcji.
Nie odtwarza jednak zbioru UTXO ani nie sprawdza każdego podpisu, skryptu i reguły emisji. Silniej polega na bodźcach górników oraz na tym, że peery nie ukryją istotnych informacji.
BIP 37 ujawnia filtr serwerowi
Portfel BIP 37 wysyła filtr Blooma utworzony z obserwowanych kluczy, skryptów i wyjść. Peer zwraca dopasowania oraz częściowe drzewo Merkle’a; fałszywie dodatnie wyniki utrudniają rozpoznanie dokładnego zainteresowania, lecz zwiększają ruch.
Powtarzane filtry nadal mogą łączyć adresy między sobą i z połączeniem sieciowym klienta. Złośliwy peer może pominąć dane, a dowód obecności nie potwierdza kompletności odpowiedzi.
BIP 157 i 158 odwracają kierunek
Pełny węzeł tworzy deterministyczny kompaktowy filtr każdego bloku. Klient pobiera go, lokalnie szuka swoich skryptów i po dopasowaniu pobiera cały blok, zamiast wysyłać każdemu peerowi zapytanie wynikające z adresów.
BIP 157 łączy nagłówki filtrów w łańcuch i definiuje ich pobieranie przez P2P. Porównywanie peerów pomaga ujawnić błędny filtr, jeśli co najmniej jedno źródło jest uczciwe; pobranie dopasowanego bloku może jednak zostawić ślad sieciowy.
Dwa znaczenia słowa compact
Filtry BIP 157/158 pomagają lekkim klientom znaleźć istotne bloki historyczne. Compact block relay z BIP 152 odtwarza nowo ogłoszony blok z transakcji, które pełny węzeł ma już w mempoolu. To różne rozwiązania.
Własny pełny węzeł zapewnia najsilniejszą niezależną weryfikację, lecz wymaga zasobów i utrzymania. Lekki klient jest uzasadnionym kompromisem dla ograniczonego urządzenia, jeśli uczciwie wyjaśnia, co weryfikuje i skąd czerpie dane.