Bitcoin Core

Paweł sprzedaje książki za bitcoiny. Klientka pokazuje mu potwierdzenie na telefonie, ale on chce wiedzieć, czy płatność naprawdę dotarła i znalazła się w poprawnym bloku. Może zapytać publiczną przeglądarkę bloków albo użyć portfela połączonego z własnym węzłem. Bitcoin Core to program, który taki węzeł uruchamia. Węzeł oznacza tu komputer z programem samodzielnie sprawdzającym reguły Bitcoin, a blok to grupa transakcji dodana do wspólnej historii. Otrzymuje dane od innych, lecz sam ocenia ich poprawność. Paweł jest przykładową postacią: chodzi o zastąpienie wiary w cudzy komunikat własną weryfikacją. Instalacja nie robi z niego górnika, nie przyznaje mu BTC ani nie pozwala cofać cudzych płatności. Kod jest dostępny na licencji MIT, która pozwala go badać, zmieniać i rozpowszechniać zgodnie z jej warunkami. [1] [16]

Łatwo pomylić te zadania, bo Bitcoin Core może wykonywać oba. Węzeł sprawdza historię i nowe bloki. Portfel śledzi odpowiednie środki, tworzy adresy i przygotowuje transakcje; jeśli zarządza kluczami prywatnymi, może też nimi podpisywać. Klucz prywatny to tajne dane, których portfel używa do stworzenia podpisu cyfrowego upoważniającego do wydania odpowiednich bitcoinów. Sam klucz nie jest wysyłany innym węzłom. Core może jednak działać zupełnie bez portfela. Paweł może płacić przez inną zgodną aplikację, a ze swojego węzła czerpać sprawdzone dane; czasem potrzebne jest dodatkowe oprogramowanie. Samo uruchomienie Core nie przekieruje wszystkich pozostałych portfeli do jego węzła. Warto rozpoznawać nazwy: bitcoin-qt daje interfejs graficzny, bitcoind działa w tle, a bitcoin-cli wysyła polecenia do programu. [12] [17]

Nowy węzeł musi najpierw nadrobić historię. To Initial Block Download, w skrócie IBD, czyli początkowe pobieranie bloków. Przy zwykłej synchronizacji pobiera bloki i sprawdza ich powiązania, pracę górników oraz reguły transakcji. Buduje w ten sposób chainstate: własny zapis jeszcze niewydanych wyjść, zwanych UTXO. Wyjście transakcji określa kwotę i warunki jej wydania, na przykład wymagany podpis. Pozostaje w tym zapisie, dopóki inna transakcja go nie wyda. Nie jest to lista nazwisk i kont bankowych. Szybkość zależy od komputera, dysku i łącza; powolny początek nie musi oznaczać usterki. Przed sprawdzaniem bieżących płatności Paweł upewnia się, że synchronizacja się skończyła.

Ważne doprecyzowanie: assumevalid może w określonych warunkach pomijać sprawdzanie skryptów, czyli warunków wydania środków, w odległej historii; -assumevalid=0 wyłącza ten skrót. Inna funkcja, AssumeUTXO, pozwala zacząć od sprawdzonej migawki stanu i przetwarzać wcześniejszą historię w tle. Migawka zapisuje stan UTXO przy określonym bloku. Program najpierw porównuje jej hash, czyli cyfrowy odcisk, z oczekiwaną wartością w kodzie; nie oznacza to jeszcze zakończenia samodzielnej weryfikacji całej wcześniejszej historii. Te metody mają inne założenia, więc nie każda instalacja od początku wykonała dokładnie te same kontrole. [9] [10] [12] [17]

Po synchronizacji Core nadal odbiera dane od połączonych węzłów, nazywanych peers. Przyjęte niepotwierdzone transakcje trzyma w swoim Mempoolu, tymczasowej poczekalni. Obecność w niej nie jest potwierdzeniem w bloku, a zawartość może różnić się między węzłami. Gdy przychodzi nowy blok, Core go sprawdza. Spośród poprawnych łańcuchów wybiera ten o największej skumulowanej pracy, nie według głosów komputerów ani samej liczby bloków. Paweł odróżnia więc zauważenie płatności od jej potwierdzenia. Własny węzeł nie gwarantuje natychmiastowego włączenia transakcji i nie usuwa reorganizacji, gdy inna poprawna gałąź zastępuje część śledzonej historii. [16]

Załóżmy, że węzeł Pawła nie przyjął niepotwierdzonej transakcji do Mempoolu. Nie oznacza to automatycznie, że nigdy nie może ona znaleźć się w poprawnym bloku. Reguły konsensusu określają poprawność bloków i wydawania środków. Lokalna relay policy dodaje warunki przyjmowania i przekazywania niepotwierdzonych transakcji, na przykład chroniąc zasoby przed przeciążeniem. Ta polityka nie jest stosowana w ten sam sposób do transakcji wewnątrz otrzymanego bloku: tam liczy się poprawność według konsensusu. Różne ustawienia Mempoolu nie rozdzielają więc same z siebie sieci. Dzięki temu rozróżnieniu łatwiej czytać spory o Core bez uznawania każdej opcji za zmianę reguł pieniądza. [13]

Core przechowuje dane bloków, stan węzła i ewentualnie portfele. Pruning oszczędza miejsce, usuwając po przetworzeniu starsze pliki bloków i dane potrzebne do cofania ich zmian. Węzeł nadal sprawdza nowe bloki; nie ma tylko całego archiwum pod ręką. Zapytania historyczne czy ponowne wyszukiwanie dawnych płatności mogą wymagać pobrania danych jeszcze raz. Indeksy ułatwiają wyszukiwanie; txindex jest na przykład niezgodny z pruningiem. Dobiera się je do zastosowania węzła. Kluczowa różnica jest inna: publiczne bloki można pobrać ponownie, ale nie odzyska się z nich zgubionych kluczy prywatnych. Portfel Core potrzebuje własnej bezpiecznej kopii. Gdy program działa, służy do tego funkcja tworzenia kopii, na przykład backupwallet, a nie przypadkowe kopiowanie bazy w trakcie zapisu. [11] [12]

Paweł zaczyna od oficjalnej strony i czyta instrukcję wybranego wydania. Suma SHA-256 jest odciskiem pobranego pliku: ujawnia różnice względem oczekiwanego. Sama nie mówi jednak, kto opublikował oczekiwany odcisk. Trzeba więc sprawdzić również podpisy cyfrowe i tożsamość kluczy podpisujących. Jeżeli napastnik dostarczy program i własną sumę, ich zgodność nie udaremni ataku. Projekt pozwala też na głębszą kontrolę przez odtwarzalne kompilacje: niezależne osoby mogą z tego samego kodu otrzymać identyczne pliki i porównać wyniki. Guix pomaga ujednolicić środowisko kompilacji. Wzmacnia to sprawdzanie pochodzenia programu, ale nie dowodzi braku błędów w kodzie. [8] [7]

Core udostępnia JSON-RPC, interfejs umożliwiający innym programom sterowanie nim. Przydaje się do odczytu stanu i łączenia usług, lecz zależnie od portfeli i uprawnień może też pozwalać na operacje na środkach. Dane logowania nie powinny trafiać do rzekomego pomocnika. Interfejs sam nie szyfruje ruchu i nie jest przeznaczony do wystawiania w publicznym internecie. Zwykłe połączenia z innymi węzłami Bitcoin to coś innego niż udostępnienie tego sterowania. Lokalnie Core używa też tymczasowych danych w pliku .cookie. Zdalne zarządzanie wymaga zabezpieczonego połączenia i ograniczonego dostępu zgodnie z dokumentacją. Wypróbowanie węzła nie wymaga otwierania jego administracji całemu światu. [14]

Każdy może zaproponować zmianę kodu. Inni uczestnicy ją czytają, testują i komentują; opiekunowie repozytorium, czyli maintainers, mogą scalać zaakceptowane zmiany. Nie daje im to zdalnej kontroli nad węzłem Pawła. Operator wybiera uruchomione oprogramowanie. Ten wybór również nie jest głosem, którym jedna osoba narzuca wszystkim nowe reguły: niezgodna zmiana może oddzielić jej węzeł od reszty. Bitcoin Core jest ważną implementacją reguł, nie firmą posiadającą całą sieć. Czytając ogłoszenia, odróżniaj propozycję, przyjęcie do kodu, publikację wydania i faktyczne używanie. Między tymi etapami może być długa droga. [15]

Można zacząć od węzła bez własnych kluczy prywatnych. Paweł sprawdza plik i podpisy, czeka na koniec IBD i upewnia się, że jego portfel rzeczywiście pobiera dane z jego węzła. Potem obserwuje połączenia, postęp bloków i wolne miejsce. Przed aktualizacją czyta release notes, czyli opis zmian i ewentualnych warunków migracji; jeśli używa portfela, sprawdza kopię i odtwarzanie. Plik diagnostyczny debug.log pomaga badać problemy, lecz nie należy publikować go bez zastanowienia. Pruning, indeksy i RPC mają odpowiadać zastosowaniu, a nie ślepo skopiowanemu poradnikowi. Własny węzeł powinien być zrozumiałym narzędziem kontroli. Nie jest obowiązkowy przy pierwszym małym zakupie, ale ma sens, gdy chcesz wiedzieć, dlaczego uznajesz płatności za poprawne. [12] [14]