SPV: jak sprawdzić transakcję w blockchainie bez pobierania całego łańcucha
Jeżeli masz już podstawowe pojęcie o blockchainie (tutaj pisałem o UTXO), wiesz zapewne, że działa on jak wspólna księga: transakcje trafiają do bloków, bloki układają się w łańcuch, a wiele komputerów przechowuje i weryfikuje tę samą historię. Taki model buduje zaufanie, ale ma też bardzo przyziemny koszt - pełna historia takiego blockchaina może być ogromna.
Rozwiązaniem jest Simplified Payment Verification (SPV), czyli uproszczona weryfikacja płatności. SPV pozwala kryptograficznie potwierdzić, że konkretna transakcja została uwzględniona w określonym bloku, bez pobierania, przechowywania i analizowania całego blockchaina.
W świecie BTC utarł się kult pełnych węzłów: wielodniowa synchronizacja, setki gigabajtów danych, dyski SSD jako obowiązkowy sprzęt - i to pomimo tego, że większość użytkowników nie walczy o blok! W BSV przyjęto inne podejście: pełny węzeł to zadanie dla górnika (i infrastruktury sieciowej), a reszta użytkowników korzysta albo z API albo z SPV. Pełny węzeł Teranode przechowuje bardzo dużo danych historii - rzędu wielu terabajtów - co czyni go narzędziem dla profesjonalistów, a nie typowego użytkownika końcowego.
SPV nie jest gorszą wersją weryfikacji - to pragmatyczny wybór: mniej danych, mniej czasu, ta sama kryptograficzna pewność, że transakcja jest w bloku. W dalszej części pokażę, jak to działa od środka i dlaczego w BSV SPV jest naturalnym standardem dla większości aplikacji.
A pełny węzeł?
Pełny węzeł pobiera kompletne bloki i sam sprawdza reguły konsensusu oraz ważność transakcji. Klient SPV sprawdza natomiast przede wszystkim dowód, że transakcja została uwzględniona w bloku należącym do uznanego łańcucha nagłówków. To znacząco zmniejsza wymagania: miejsce na dysku, przepustowość łącza, czas synchronizacji i moc obliczeniową, ale oznacza też węższy zakres niezależnej weryfikacji.
Dla serwera obsługującego infrastrukturę sieciową to ma sens. Dla telefonu, niewielkiej aplikacji czy systemu księgowego firmy, taki model bywa niepraktyczny.
Wyobraź sobie, że chcesz sprawdzić jedno zdanie w encyklopedii. W pełnym węźle musiałbyś najpierw kupić wszystkie tomy, ułóżyć je w odpowiedniej kolejności i sam sprawdzić, czy nikt nie podmienił żadnej strony. W SPV dostaniesz konkretną stronę ze wskazaniem tomu oraz dowód, że ta strona rzeczywiście należy do właściwej, niezmienionej encyklopedii.
Co właściwie robi SPV?
Klient SPV nie zna wszystkiego i nie ma wszystkiego. Interesuje go odpowiedź na pytanie: czy ta konkretna transakcja została umieszczona w konkretnym bloku należącym do łańcucha bloków?
SPV potrzebuje przede wszystkim dwóch rodzajów danych:
- nagłówków bloków;
- dowodu Merkle dla konkretnej transakcji.
Nagłówek bloku można potraktować jak kompaktową metrykę dokumentu. Nie zawiera wszystkich transakcji, ale zawiera ważne informacje identyfikujące blok i wiążące go z blokiem poprzednim. Jeden z najważniejszych elementów tej metryki to tzw. korzeń Merkle’a (Merkle root), czyli skrócony, kryptograficzny odcisk całego zestawu transakcji umieszczonych w bloku.
Dowód Merkle jest natomiast zbiorem informacji potrzebnych, by od konkretnej transakcji dojść do tego odcisku. Gdy wynik obliczeń zgadza się z Merkle root zapisanym w nagłówku bloku, można sprawdzić, że transakcja faktycznie należała do zestawu transakcji w tym bloku.
Kluczowa rzecz: klient SPV nie potrzebuje pobierać wszystkich pozostałych transakcji z bloku. Potrzebuje tylko niewielkiego zestawu skrótów kryptograficznych, które pozwalają matematycznie odtworzyć drogę do wspólnego korzenia drzewa Merkle.
Drzewo Merkle
Załóżmy, że blok zawiera cztery transakcje: A, B, C i D. Dla każdej z nich obliczamy hash. Następnie łączymy hash transakcji A z hashem transakcji B i tworzymy nowy hash. To samo robimy z C i D. Na końcu łączymy te dwa wyniki, tworząc jeden końcowy hash: Merkle root.
Można to zapisać tak:
A ──┐
├─ hash(AB) ──┐
B ──┘ │
├─ Merkle root
C ──┐ │
├─ hash(CD) ──┘
D ──┘
Jeżeli chcesz udowodnić, że transakcja A znajduje się w tym bloku, nie musisz otrzymać pełnej listy A, B, C i D. Wystarczy, że otrzymasz:
- samą transakcję A albo jej hash;
- hash B;
- hash(CD).
Najpierw liczysz hash z A i B. Potem łączysz ten wynik z hash(CD). Jeśli wynik końcowy jest identyczny z Merkle root w nagłówku bloku, dowód się zgadza.
To działa dlatego, że funkcje hashujące są bardzo wrażliwe na zmianę danych. Jeśli ktoś zmieniłby choćby jeden znak w transakcji A, jej hash byłby inny. To zmieniłoby hash(AB), potem Merkle root, a w konsekwencji ujawniłoby, że przedstawiony dowód nie odpowiada blokowi. Ta-da!
Dlaczego nagłówki są ważne?
Dowód Merkle mówi: "transakcja pasuje do tego bloku". Ale naturalnie pojawia się kolejne pytanie: skąd wiadomo, że sam blok należy do łańcucha zaakceptowanego przez sieć?
Tu pomagają nagłówki bloków. Każdy nagłówek odwołuje się do poprzedniego bloku, więc tworzą one łańcuch. Klient SPV pobiera taki łańcuch nagłówków, a następnie sprawdza, czy blok zawierający interesującą go transakcję znajduje się w łańcuchu, który sieć uznaje za właściwy zgodnie z jej zasadami konsensusu.
SPV łączy więc dwie rzeczy:
- Dowód Merkle - pokazuje, że konkretna transakcja znalazła się w konkretnym bloku.
- Łańcuch nagłówków - pokazuje, że ten blok należy do historii blockchaina.
To trochę jak potwierdzenie, że dokument jest na konkretnej stronie konkretnego wydania książki, a następnie sprawdzenie, że to wydanie rzeczywiście pochodzi z oficjalnego, ciągłego katalogu wydań, a nie z przypadkowego pliku stworzonego pięć minut temu.
Czego SPV nie robi?
Wokół SPV łatwo może narosnąć przekonanie, że skoro coś jest zweryfikowane kryptograficznie, to system automatycznie wie wszystko. Nie. SPV jest bardzo dobre w swoim konkretnym zadaniu, ale nie zastępuje całej infrastruktury blockchaina, kontroli biznesowych ani analizy prawnej.
SPV może wykazać, że przedstawiona transakcja pasuje do Merkle root danego bloku. Jeśli ktoś zmieni transakcję, element ścieżki Merkle albo sam dowód, obliczony Merkle root nie będzie zgodny z wartością w nagłówku bloku. SPV Nie odpowiada na pytania takie jak:
- czy osoba posługująca się danym kluczem publicznym jest konkretną osobą fizyczną;
- czy dane wpisane do transakcji były prawdziwe przed ich zapisaniem;
- czy transakcja była zgodna z umową albo zgodna z wewnętrzną polityką firmy;
- czy podmiot przeszedł procedurę KYC lub nie znajduje się na liście sankcyjnej;
- czy organizacja spełniła wszystkie wymogi prawne dotyczące przechowywania, usuwania albo raportowania danych.
SPV jest narzędziem kryptograficznym, które może mocno wzmocnić dowód dotyczący integralności i obecności określonej transakcji w blockchainie. Warto odróżnić dowód obecności od pełnej walidacji. Dowód Merkle potwierdza, że dana transakcja jest częścią konkretnego bloku, a łańcuch nagłówków wiąże ten blok z historią sieci. Klient SPV nie pobiera jednak wszystkich bloków ani nie wykonuje wszystkich kontroli, które przeprowadza pełny węzeł. Dlatego SPV jest świetne do lekkiej, niezależnej weryfikacji włączenia transakcji, ale nie zastępuje pełnej walidacji tam, gdzie wymagany jest najwyższy poziom samodzielnej kontroli.
Dlaczego SPV skaluje się lepiej niż pełny węzeł?
Największa praktyczna przewaga SPV jest prosta: klient nie musi przechowywać pełnego zestawu wszystkich transakcji w blockchainie. Przechowuje przede wszystkim nagłówki bloków oraz dowody potrzebne dla tych transakcji, które są dla niego istotne. Dla typowego obecnego bloku BSV można przyjąć średnio około 8591 transakcji i średni rozmiar bloku około 13,78 MB. Przy drzewie Merkle o tej liczbie liści, dowód dla jednej transakcji potrzebuje zwykle około 14 hashy sąsiednich.
Jeden hash SHA-256 ma 32 bajty. 14 hashy×32 B=448 B
Do tego dochodzą drobne informacje o kolejności łączenia hashy w ścieżce Merkle oraz metadane formatu dowodu. Czyli zamiast przechowywać około 13,78 MB pełnego typowego bloku, aby dowieść obecności jednej wybranej transakcji, klient SPV potrzebuje około 0,5 KB danych dowodowych plus nagłówek bloku. To redukcja rzędu około 27–30 tysięcy razy.
W drzewie Merkle liczba elementów potrzebnych do udowodnienia obecności jednej transakcji rośnie znacznie wolniej niż liczba wszystkich transakcji w bloku. W uproszczeniu, gdy liczba transakcji rośnie, dowód nie musi zawierać całej listy - potrzebuje jedynie ścieżki hashy prowadzącej do Merkle root.
Dla aplikacji mobilnej oznacza to mniejsze zapotrzebowanie na pamięć i transfer. Dla systemu firmowego może oznaczać, że da się utrzymywać weryfikowalny rejestr konkretnych zdarzeń bez budowania własnego magazynu pełnego blockchaina. Dla audytora może to oznaczać możliwość niezależnego sprawdzenia pojedynczej sprawy bez konieczności odtwarzania całej historii sieci.
Gdzie SPV sprawdza się najlepiej?
SPV ma sens wszędzie tam, gdzie ważne jest potwierdzenie, że konkretne zdarzenie zostało zakotwiczone w blockchainie, a jednocześnie pełny węzeł byłby przesadą.
Przykładowe zastosowania:
- lekkie portfele, które chcą sprawdzać własne płatności bez przechowywania kompletnego łańcucha;
- systemy księgowe, które przechowują dowody dotyczące wybranych rozliczeń;
- systemy audytowe, w których potrzebna jest weryfikacja integralności rejestrów;
- łańcuchy dostaw, gdzie istotne jest potwierdzanie kolejnych zdarzeń dotyczących towaru;
- zarządzanie dokumentami, gdzie dokument może być przechowywany off-chain, a jego kryptograficzny odcisk zakotwiczony on-chain;
- procesy raportowe, w których trzeba wykazać, że określona informacja istniała najpóźniej w konkretnym momencie.
Nie każda aplikacja potrzebuje blockchaina, a nie każda aplikacja blockchainowa potrzebuje SPV w tej samej formie. Jednak tam, gdzie istotne są niezależnie weryfikowalne dowody przy ograniczonych zasobach, SPV jest optymalnym narzędziem.
Architektura systemu wykorzystującego SPV.
Jeśli budowałbyś system zgodności oparty na SPV, warto z wyprzedzeniem myśleć o nim warstwowo:
- Warstwa blockchaina zapewnia wspólny, odporny na manipulację zapis transakcji i bloków.
- Warstwa SPV pobiera nagłówki oraz przechowuje i sprawdza dowody Merkle dla istotnych zdarzeń.
- Warstwa aplikacji wie, co oznacza dana transakcja: czy dotyczy faktury, dostawy albo transferu.
- Warstwa danych off-chain przechowuje wrażliwe informacje, dokumenty źródłowe, dane tożsamości i inne, których nie należy publikować wprost w blockchainie.
- Warstwa zgodności określa zasady retencji, dostępów, raportowania, obsługi incydentów, kontroli i wymogów.
Taki podział ma duże znaczenie. Warstwa SPV (2) pozostanie neutralna wobec kraju czy branży, podczas gdy reguły zgodności (5) mogą zmieniać się zależnie od miejsca prowadzenia działalności. Zamiast przebudowywać mechanizm weryfikacji za każdym razem, gdy zmienia się przepis, łatwiej dostosować reguły w warstwie aplikacji lub warstwie zgodności.
Dlaczego warto wiedzieć o SPV?
Bo SPV jest rozwiązaniem, które pokazuje, że blockchain nie musi oznaczać, że wszyscy trzymają wszystko i wszyscy oglądają wszystko. Można budować systemy, które korzystają z kryptograficznej spójności publicznego łańcucha, a jednocześnie są lżejsze, bardziej praktyczne i lepiej dopasowane do rzeczywistych procesów.
Dla osoby technicznej SPV jest eleganckim połączeniem hashy, drzew Merkle i nagłówków bloków. Dla firmy jest sposobem na zachowanie weryfikowalnych dowodów bez kosztu pełnej infrastruktury węzła. Dla audytora może być materiałem, który da się niezależnie sprawdzić. A dla każdego, kto dopiero oswaja blockchain, jest przypomnieniem, że najciekawsze pomysły w tej technologii często nie polegają na przechowywaniu większej liczby danych, lecz na sprytnym udowodnieniu tylko tego, co naprawdę trzeba sprawdzić.
Komentarze
Prześlij komentarz