AssumeUTXO

Piotr uruchamia swój pierwszy Full Node, program samodzielnie sprawdzający reguły sieci Bitcoin. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Zwykły start wymaga najpierw przejścia przez długą historię. AssumeUTXO pozwala zacząć od przygotowanego zbioru UTXO: niewydanych wyjść transakcji, z których każde opisuje kwotę i warunki jej wydania. Migawka pokazuje stan po określonym bloku. Nie jest archiwum wszystkich płatności ani dowodem, że komputer Piotra sprawdził już całą przeszłość. [1] [3]

Nazwa pliku nie czyni migawki poprawną. Podczas ładowania przez loadtxoutset Bitcoin Core v29.0 sprawdza format, blok bazowy (blok, któremu odpowiada migawka) i obsługiwane parametry. Oblicza też hash zawartości UTXO, czyli jej kryptograficzny odcisk, i porównuje go z oczekiwaną wartością przed aktywacją. Zmieniona zawartość nie przejdzie więc kontroli tylko dlatego, że plik otrzymał wiarygodnie brzmiącą nazwę. [2] [3] [6]

Po przyjęciu migawki węzeł kontynuuje od jej stanu, weryfikuje kolejne bloki i może dojść do obecnego końca łańcucha. Nie przyjmuje ich na słowo: nadal sprawdza choćby warunki wydawania i dozwoloną emisję nowych bitcoinów. Zaletą jest to, że droga do bieżącej pracy nie musi czekać na ukończenie starszej historii. Nie oznacza to jednak, że przeszłość już sprawdzono lokalnie. [1] [6]

Jednocześnie powstaje drugi stan, zbudowany z historycznych bloków od początku aż do podstawy migawki. Jest to niezależne obliczenie z historii, nie kolejna kopia pobranego zestawienia. Przez pewien czas program utrzymuje więc dwa stany o różnym postępie. Techniczne polecenie getchainstates potrafi je pokazać. Samo dojście stanu aktywnego do najnowszych bloków nie potwierdza ukończenia pracy w tle. [1] [8]

Oczekiwany hash i obsługiwany blok bazowy należą do konkretnej wersji programu. Dopóki węzeł Piotra sam nie przeliczy historii, polega na poprawności tej wbudowanej informacji. Porównanie hashy pozwala sprawdzić zgodność zawartości, ale samo nie dowodzi, że powstała ona z prawidłowej historii. Gdyby oczekiwany stan był błędny, wcześniejsze korzystanie z węzła opierałoby się na tym błędnym założeniu. Dlatego późniejszej weryfikacji historii nie należy mylić z kontrolą pliku podczas ładowania. [2] [6]

Plik może pochodzić od innego operatora, ale nie daje mu to prawa do ustalania akceptowanego stanu. Liczy się zgodność z wartością obsługiwaną przez program, nie obietnica dostawcy. Nie można też załadować dowolnej migawki z dowolnego bloku: wsparcie zależy od wersji i sieci. Kontrola hasha nie gwarantuje dostarczenia pliku ani nie eliminuje czasu, transferu i miejsca zużywanych na jego pobranie oraz przetwarzanie. [2] [4] [7]

Gdy praca w tle dotrze do tego samego bloku bazowego, węzeł oblicza hash samodzielnie zbudowanego zbioru UTXO i porównuje z oczekiwanym hashem migawki. Nie porównuje dzisiejszego stanu ze starym zdjęciem: oba dotyczą tego samego miejsca historii. Jeśli wyniki się różnią, opisana implementacja zatrzymuje węzeł i przestaje korzystać ze stanu pochodzącego z migawki. Nie ukrywa rozbieżności ani nie ogłasza pomyślnej weryfikacji. [1] [6]

AssumeUTXO zmienia przede wszystkim czas do uzyskania użytecznego węzła. Pobieranie i weryfikacja historii trwają nadal, a tymczasowo działają dwie bazy stanu. To obciąża procesor i dysk. Pruned Node oszczędza miejsce, usuwając starsze, już przetworzone pliki bloków, ale nie pomija sprawdzania reguł. Pruned Node też może używać migawki, ale oszczędzanie miejsca ma własne ograniczenia. Niektóre pomocnicze indeksy muszą przetwarzać historię od początku, więc wcześniejsza dostępność węzła nie oznacza natychmiastowej gotowości wszystkich podłączonych aplikacji. [5] [7]

Zbiór UTXO zawiera informacje o niewydanych wyjściach, nie klucze prywatne upoważniające do wydawania. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Zbiór UTXO nie jest kopią portfela i nie przywróci utraconej Seed Phrase, czyli słów odzyskiwania portfela korzystającego z tego mechanizmu. Starsze płatności też nie muszą pojawić się od razu: ich odnalezienie może wymagać bloków sprzed migawki. Kopia kluczy, odszukanie historii własnego portfela i weryfikacja stanu sieci to różne zadania. [1] [7]

Podobne nazwy łatwo pomylić. AssumeUTXO zaczyna od załadowanego stanu i odtwarza starszą historię w tle. assumevalid może natomiast w określonych warunkach pominąć część historycznych kontroli skryptów, czyli warunków wydawania, w tym podpisów. To odrębna optymalizacja, która może wpływać także na historyczną weryfikację. Samo ukończenie AssumeUTXO nie mówi, że była wyłączona. Czytając instrukcję, rozróżniaj punkt startu węzła, faktycznie wykonywane kontrole i ich zakończenie. [5] [6]