Full Node

Wyobraź sobie, że portfel pokazuje otrzymaną płatność. Skąd wie, że transakcja naprawdę należy do historii Bitcoina i spełnia reguły? Może zapytać obcy serwer albo skorzystać z twojego węzła. Full Node nadaje drugiej możliwości konkretny sens: sam sprawdza prawidłowość otrzymanych danych. Nie pyta większości podłączonych komputerów, jak ma zdecydować. Jeżeli ktoś wyśle mu blok naruszający reguły, odrzuci go. Więcej połączeń nie zastępuje więc kontroli zasad. Własny węzeł pozwala ci weryfikować dane, na których opierasz płatności. [1] [3]

Węzeł sprawdza powiązania bloków, ich nagłówki oraz Proof of Work, czyli dowód obliczeniowy wymagany dla bloku. W transakcjach weryfikuje między innymi, czy odwołują się do istniejących środków, czy środki nie są wydawane dwa razy i czy spełniono warunki ich użycia. Warunki te zapisane są w skryptach, niewielkich zestawach reguł programowych. Kontroluje też ilość nowo tworzonych bitcoinów. Aktualizowany wynik to UTXO set, zbiór niewydanych wyjść transakcji: zapis konkretnych środków, które pozostają dostępne. Większa skumulowana praca może rozstrzygnąć między dwiema prawidłowymi gałęziami, ale nie sprawi, że nieprawidłowy blok stanie się prawidłowy. [1]

Nie. Full Node sprawdza bloki i transakcje, a sama zwykła weryfikacja nie daje nagrody blokowej. Górnik natomiast składa propozycję bloku i powtarza obliczenia, aż znajdzie odpowiedni wynik. Używa przy tym hasha, cyfrowego odcisku nagłówka. Te role mogą współpracować: górnik musi wiedzieć, którą historię przedłuża i jakie transakcje wolno mu dodać. Nie wynika z tego, że każdy węzeł musi wydobywać. Sprawdzanie i rywalizacja o znalezienie następnego bloku to różne czynności. [5] [1]

Nowy węzeł musi najpierw nadrobić historię sieci. Pobiera bloki i przetwarza ich dane; to początkowa synchronizacja. W zaawansowanych ustawieniach trzeba odróżnić dwa sposoby jej przyspieszania. W określonych warunkach assumevalid pozwala Bitcoin Core pominąć dawne kontrole skryptów; assumevalid=0 wyłącza tę optymalizację. AssumeUTXO pozwala natomiast wczytać snapshot, zapisany stan niewydanych środków dla określonego bloku. Jego cyfrowy odcisk jest porównywany z wartością zawartą w kodzie źródłowym. Starsza historia jest następnie weryfikowana w tle. Możliwość korzystania z aktualnego stanu nie oznacza więc sama w sobie zakończenia kontroli historycznej. [1] [2]

Full Node nie musi zachowywać wszystkich starych plików bloków na zawsze. Pruning usuwa część z nich po przetworzeniu, pozostawiając aktualny UTXO set i potrzebne nowsze dane. Węzeł nadal sprawdza nowe bloki. Węzeł archiwalny przechowuje stare bloki, dzięki czemu może udostępniać je innym lub ponownie przeszukiwać. Oszczędność dysku nie oznacza zatem tego samego co klient SPV, czyli klient z uproszczoną weryfikacją płatności. Nie kontroluje on wszystkich transakcji i ich stanu tak jak Full Node. Różnica dotyczy tego, co sprawdzasz, nie tylko liczby przechowywanych plików. [3]

Podczas zwykłej synchronizacji przycięty węzeł pobiera i przetwarza historyczne bloki, zanim zacznie je stopniowo usuwać. Pruning nie jest przełącznikiem pomijania ich weryfikacji, lecz sposobem oszczędzania miejsca. Wspomniane optymalizacje to osobna kwestia: assumevalid może w określonych warunkach pomijać stare kontrole skryptów, a AssumeUTXO pozwala używać snapshota, gdy sprawdzanie historii jeszcze trwa. Oceniając gotowość węzła, sprawdź więc metodę synchronizacji i rzeczywisty postęp, a nie tylko rozmiar danych na dysku. [3] [2]

Portfel potrzebuje informacji o transakcjach i potwierdzeniach. Jeśli pobiera je z obcego serwera, wysyła zapytania, z których serwer może wywnioskować coś o jego płatnościach. Połączenie z własnym Full Node pozwala korzystać z danych sprawdzonych przez twój węzeł bez tych zapytań do obcego serwera. Sama instalacja i uruchomienie węzła nie przełącza jednak portfela automatycznie. Liczy się źródło danych, które portfel faktycznie obsługuje i wykorzystuje. Własny węzeł nie zapewnia też automatycznej anonimowości: prywatność zależy również od innych danych sieciowych i sposobu korzystania z portfela. [3] [4]

Węzeł może działać bez twoich kluczy prywatnych. Klucze pozwalają podpisywać płatności, a węzeł sprawdza zgodność transakcji i bloków z regułami. Zadania te nie muszą należeć do tego samego urządzenia. Dlatego sprawdź nie tylko, czy twój węzeł gdzieś działa, lecz także skąd portfel odczytuje dane i jak rozsyła transakcje. Samodzielna weryfikacja nie zastąpi bezpiecznej kopii kluczy ani nie usunie wszystkich informacji ujawnianych przez komunikację sieciową. Pomaga w konkretnej części procesu: niezależnie kontrolować dane Bitcoina. [3] [4]

Węzeł ma dwa różne interfejsy. Połączeniami P2P wymienia bloki i transakcje z innymi węzłami. RPC jest interfejsem, przez który aplikacje wydają mu polecenia i mogą ewentualnie sterować także jego portfelem. Otwarcie przychodzącego portu P2P do wymiany danych jest więc czymś innym niż wystawienie RPC obcym osobom. Bitcoin Core zaleca, by nie udostępniać RPC bezpośrednio w publicznym internecie. Do lokalnego dostępu zwykle używa danych logowania w pliku .cookie, potwierdzających uprawnienia aplikacji. Nie jest to śledzący plik cookie przeglądarki. [4]

Polecenia węzła pozwalają sprawdzić więcej niż zieloną ikonę. W getblockchaininfo zwróć uwagę na właściwą sieć, blocks jako liczbę przetworzonych bloków, headers jako liczbę znanych nagłówków oraz initialblockdownload dotyczące początkowej synchronizacji. Przy użyciu snapshota getchainstates pomaga odróżnić aktualny stan od historycznej weryfikacji w tle. Sama liczba połączeń nie dowodzi pełnego sprawdzenia. Na koniec upewnij się, że węzeł nie utknął na nieaktualnym wierzchołku łańcucha i że portfel rzeczywiście pobiera dane właśnie z niego. Dopiero wtedy własna kontrola węzła przekłada się na korzystanie z portfela. [2] [1]