Initial Block Download, w skrócie IBD, to początkowa synchronizacja węzła Bitcoin. W zwykłym trybie pobiera on starsze bloki, sprawdza je według reguł swojego oprogramowania i tworzy aktualny zbiór środków, które nie zostały jeszcze wydane.
Uruchamiasz w domu Full Node, czyli program samodzielnie sprawdzający bloki i transakcje Bitcoin. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Pozostali uczestnicy znają już długą historię, lecz twój nowy węzeł jeszcze jej nie ma. Najpierw pobiera nagłówki: krótkie zapisy łączące poszczególne bloki. Zawierają one także Proof of Work, dowód wykonanej pracy obliczeniowej. Górnicy szukają tego dowodu, powtarzając obliczenia; pozostali mogą szybko sprawdzić znaleziony wynik. Lista nagłówków przypomina spis treści książki: pomaga się odnaleźć, ale jego posiadanie nie oznacza przeczytania i sprawdzenia wszystkich stron. [1] [7]
Gdy sąsiedzi proponują różne gałęzie historii, węzeł nie liczy głosów. Nagłówki pozwalają porównać skumulowaną pracę obliczeniową i wybrać obiecującą gałąź do dalszej weryfikacji. Więcej bloków nie musi oznaczać więcej pracy. Nawet ogromna praca nie zwalnia nieprawidłowych transakcji z przestrzegania reguł: zawartość wybranej gałęzi nadal trzeba sprawdzić. [1] [2] [6]
Węzeł może pobierać bloki od kilku sąsiadów naraz, bez uzależnienia od szybkości jednego nadawcy. Aby jednak dołączyć je do zweryfikowanej historii, potrzebuje wcześniejszego stanu. Wejścia płatności wskazują wcześniejsze kwoty, które ma ona wydać. Węzeł musi ustalić, że istnieją i nie zostały już wydane. Późniejszy, pobrany blok może więc czekać na przetworzenie wcześniejszego. Dlatego pobranie danych nie jest tym samym co zakończenie synchronizacji. [1] [2]
Węzeł porównuje zawartość bloku z odciskiem transakcji zapisanym w nagłówku, tworzonym przez Merkle Tree. Sprawdza również między innymi ciągłość wydawania środków oraz to, czy nagroda górnika nie przekracza dozwolonej kwoty. Stosuje reguły obowiązujące w danym miejscu historii. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Dla dawnych kontroli podpisów i innych warunków wydania istnieje specjalne ustawienie assumevalid, wyjaśnione poniżej. Nagłówki ani plik od pozornie wiarygodnego sąsiada nie zastępują całego zestawu tych kontroli. [2] [3]
Przy każdym przetworzonym bloku węzeł usuwa wydane wyjścia i dodaje nowe. Wyjście to konkretna kwota z warunkami jej późniejszego wykorzystania. Jeśli nie została jeszcze wydana, takie wyjście nazywa się UTXO. Ich zbiór pozwala sprawdzić następną płatność bez każdorazowego przechodzenia całej historii od początku. Nie jest to lista rachunków bankowych ani kopia wszystkich dawnych transakcji. [2] [3]
W określonych warunkach Bitcoin Core może pomijać dawne kontrole skryptów, czyli podpisów i innych warunków wydania środków. Ustawienie assumevalid wskazuje znany blok z historią zweryfikowaną zewnętrznie; znaczenie mają też jego powiązanie z poprzednimi blokami, odpowiednia praca i łańcuch zbudowany ponad nim. Pozostałe niezbędne kontrole zostają, ale część wyniku weryfikacji przyjmuje się z góry. Błędne założenie nie jest więc pozbawione ryzyka. assumevalid=0 wyłącza tę optymalizację kosztem większej ilości pracy dla komputera. [2]
Pruned Node usuwa stare pliki bloków po ich przetworzeniu, zachowując aktualny zbiór UTXO i inne potrzebne dane. Podczas zwykłego IBD nadal pobiera i przetwarza historię, jedynie nie przechowuje jej całej na stałe. Oszczędza to miejsce na dysku, niekoniecznie jednak ilość danych pierwszego pobierania. Późniejsze zadanie wymagające usuniętych bloków może wymagać pobrania ich ponownie. [2] [7]
Bitcoin Core v29.0 uwzględnia między innymi wiek ostatnio zaakceptowanego bloku, minimalną skumulowaną pracę oraz stan wczytywania. Gdy ten znacznik działania raz zmieni się na false (czyli „synchronizacja początkowa zakończona”), w tym samym uruchomieniu nie wróci już do true (czyli „synchronizacja początkowa trwa”). Pomaga sterować programem, a nie dowodzi, że nigdzie na świecie nie istnieje nowszy blok. Nawet późniejsza utrata połączenia nie czyni go wiarygodnym wskaźnikiem aktualności. [2] [5]
Szybkie łącze pomaga, ale komputer musi też obliczać i zapisywać dane na dysku. Czas zależy od procesora, pamięci, nośnika i dostępności sąsiadów. W technicznym wyniku getblockchaininfo pole verificationprogress szacuje postęp weryfikacji. Nie obiecuje liczby pozostałych minut ani nie przedstawia wyłącznie odsetka pobranych bajtów. Po prawidłowym zamknięciu kolejne uruchomienie może kontynuować zapisany postęp, zamiast zaczynać wszystko od nowa. [5] [7]
AssumeUTXO umożliwia użycie obsługiwanej migawki UTXO, czyli stanu zapisanego dla konkretnego bloku. Program porównuje jej zawartość z oczekiwanym odciskiem i może wcześniej dotrzeć do teraźniejszości, jednocześnie przetwarzając historię w tle. Następnie porównuje również stan otrzymany w wyniku tej historycznej weryfikacji. Nie jest to dowolna baza od obcej osoby ani sposób na trwałe uniknięcie sprawdzania przeszłości. Wcześniejsza gotowość do działania i ukończona weryfikacja historii to dwa różne etapy. [4] [8]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Pruned Node, AssumeUTXO, Block Propagation, Compact Blocks, Bitcoin, Bitcoin Core. Do tego hasła prowadzą również odsyłacze z Block Propagation, Compact Blocks, Pruned Node, AssumeUTXO.