Timechain, czyli bitcoinowy Blockchain, to połączony łańcuch prawidłowych bloków od Genesis Block do aktualnego wierzchołka sieci. Każdy kolejny blok wskazuje hash poprzednika, jego cyfrowy odcisk, i dodaje własny Proof of Work, czyli dowód pracy obliczeniowej potrzebnej do utworzenia bloku. Węzły mogą więc niezależnie sprawdzić, która historia przestrzega reguł i ma największą skumulowaną pracę. „Czas” nie oznacza tu dokładnego zegara dla każdej transakcji; przede wszystkim oznacza możliwą do wykazania kolejność zdarzeń.
Wyobraź sobie publiczną historię księgową, w której tysiące komputerów mogą niezależnie sprawdzić każdą nową stronę. Jedna strona jest blokiem. Zawiera zestaw transakcji i odwołanie do poprzedniego bloku, dlatego strony mają określoną kolejność i nie można ich dowolnie przetasować. Timechain to cała połączona sekwencja od pierwszego bloku do dzisiejszego wierzchołka. Nie mówi, ile bitcoinów ma każda osoba wymieniona z nazwiska; zapisuje historię transakcji, z której węzły ustalają niewydane wyjścia transakcji. Nie jest też serwerem jednej firmy. Każdy Full Node (węzeł samodzielnie sprawdzający transakcje i reguły sieci) może pobrać kopię i ją zweryfikować. [1] [3]
W kontekście Bitcoina obie nazwy oznaczają tę samą historię bloków. Zachowany kod sprzed uruchomienia z listopada 2008 roku używał słowa timechain w komentarzach oraz nazwach zmiennych lub funkcji. Whitepaper mówi natomiast o znakowaniu czasem, łańcuchu bloków i łańcuchu Proof of Work; dokładne słowo timechain w nim nie występuje. Blockchain stał się później terminem powszechnym na całym świecie. Dziś jest też szeroką nazwą innych sieci i baz danych, podczas gdy Bitcoin Timechain jest konkretnym łańcuchem Bitcoina. Dwa słowa w tytule nie oznaczają więc dwóch protokołów. Zachowują historyczną nazwę obok współczesnego, powszechnego terminu. [2] [1] [8]
Podpis cyfrowy może dowieść, że transakcję zatwierdził posiadacz wymaganego klucza. Sam nie powstrzymuje jednak podpisania dwóch sprzecznych transakcji próbujących wydać to samo niewydane wyjście wcześniejszej transakcji, zwane UTXO. Jeden węzeł może najpierw otrzymać płatność dla sprzedawcy, a drugi najpierw zwrot tej samej wartości do nadawcy. Sieć potrzebuje więc wspólnej historii rozstrzygającej, który wydatek został potwierdzony, a który nie może już być prawidłowy. Bloki nadają transakcjom sprawdzalne miejsce w tej kolejności. Nie dowodzą, która wiadomość powstała najpierw w czasie ludzkim lub sieciowym; węzły mogły zobaczyć niepotwierdzone transakcje w różnej kolejności. [1]
Block Header to nagłówek zawierający podstawowe dane bloku. Obejmuje między innymi hash poprzedniego nagłówka oraz Merkle Root, który łączy identyfikatory transakcji bloku w jeden hash. Hash przypomina cyfrowy odcisk palca: nawet mała zmiana danych wejściowych daje inny wynik. Zmiana starej transakcji zmieniłaby Merkle Root, hash bloku oraz odwołanie zapisane w następnym bloku. Edycja nie pozostałaby jedną zmienioną linią historii; zerwałaby całą dalszą sekwencję. Sam hash nie dowodzi, że transakcje przestrzegają reguł. Węzły muszą także sprawdzić transakcje, a każdy blok musi spełniać wymagany Proof of Work. [3] [1]
Węzeł nie przyjmuje gałęzi tylko dlatego, że jest dłuższa albo promuje ją duży górnik. Najpierw sprawdza reguły: Proof of Work, powiązania z poprzednimi blokami, dozwoloną nagrodę, transakcje, warunki wydania i to, czy wskazane wejściami środki nie zostały już wydane. Nieprawidłowa gałąź pozostaje nieprawidłowa bez względu na moc obliczeniową autora. Dopiero wśród prawidłowych kandydatów węzeł wybiera łańcuch o największej skumulowanej pracy. Dokładniej jest więc mówić o prawidłowej gałęzi z największą pracą niż po prostu o „najdłuższym łańcuchu”. Pole chainwork szacuje oczekiwaną liczbę hashy potrzebnych do zbudowania łańcucha przy trudności każdego bloku; nie liczy prób faktycznie wykonanych przez górników. [4] [5] [6]
Proof of Work kosztuje czas, energię elektryczną i moc obliczeniową, a jego wynik można szybko sprawdzić. Osoba zmieniająca stary blok musiałaby wytworzyć dla niego nowy prawidłowy Proof of Work, ponownie połączyć wszystkie późniejsze bloki i stale doganiać pracę dodawaną przez uczciwą gałąź. Im głębiej blok leży pod wierzchołkiem, tym większą przewagę ma zwykła historia. Nie jest to matematyczna obietnica, że przeszłość nigdy się nie zmieni. To obrona ekonomiczna i probabilistyczna: kolejne bloki zazwyczaj szybko podnoszą koszt skutecznego przepisania. Atakujący nie może też umieścić w zastępczej gałęzi dowolnej nieprawidłowej płatności ani emitować bitcoinów ponad limit, bo inne węzły odrzucą blok. [1] [4]
Górnik umieszcza timestamp w Block Header. Reguły konsensusu dopuszczają pewien margines, dlatego wartość time nie jest dokładnym dowodem chwili utworzenia bloku lub konkretnej transakcji. Timestamp bloku nie musi być nawet wyższy od znacznika czasu bezpośredniego poprzednika. Dla części reguł Bitcoin używa więc Median Time Past: mediany znaczników czasu z poprzednich 11 bloków. Medianę otrzymujemy, porządkując te znaczniki czasu i wybierając środkową wartość. Postępuje ona równiej niż pojedyncze wartości. Średni dziesięciominutowy odstęp między blokami również nie jest rozkładem jazdy. Dwa bloki mogą pojawić się niemal razem, a na kolejny można czekać znacznie dłużej. Wysokość bloku daje dokładną pozycję w łańcuchu, nie dokładny czas w kalendarzu. [4] [7]
Dwóch górników może niemal jednocześnie znaleźć różne prawidłowe bloki na tej samej wysokości. Niektóre węzły zobaczą najpierw jedną gałąź, inne drugą. Gdy późniejszy Proof of Work wytworzy różnicę między prawidłowymi gałęziami, węzły przechodzą na tę z większą skumulowaną pracą. Taka zmiana to Reorg. Transakcje z odłączonego bloku mogą potwierdzić się w nowej gałęzi, wrócić do Mempool lub stać się nieprawidłowe, jeśli nowa historia potwierdzi sprzeczny wydatek. Włączenie do bloku jest pierwszym potwierdzeniem; każdy kolejny blok nad nim dodaje następne. Nie istnieje jedna magiczna liczba dla wszystkich płatności. Właściwy poziom pewności zależy od wartości, ryzyka i możliwości czekania. [1] [3]
Bitcoin pozwala utworzyć transakcję, którą można potwierdzić dopiero od określonej wysokości bloku albo po wskazanym czasie. Timelock nie jest poleceniem automatycznego wykonania transakcji w tej minucie. Wyznacza jedynie najwcześniejszy punkt, od którego prawidłowy blok może ją zawrzeć. Dla nLockTime opartego na czasie BIP 113 wykorzystuje Median Time Past poprzedniego bloku zamiast łatwego do przesunięcia znacznika czasu tworzonego bloku. Warunek opiera się więc na historii kilku bloków. Nawet po jego spełnieniu transakcja musi zostać rozgłoszona, przyjęta przez węzły i wybrana przez górnika; włączenie do konkretnego bloku nie jest gwarantowane. [7] [4]
RPC to interfejs pozwalający wysyłać polecenia do węzła i odczytywać jego odpowiedzi. Full Node nie musi ufać zapewnieniu publicznego eksploratora bloków, że blok lub transakcja należy do aktualnej historii. Dla określonego hasha wywołanie RPC getblock może pokazać height, liczbę potwierdzeń, Merkle Root, time, mediantime, poprzedni hash, trudność i chainwork. Każde pole odpowiada na inne pytanie: height podaje pozycję; previousblockhash pokazuje pochodzenie; confirmations określa głębokość pod bieżącym wierzchołkiem; time jest wartością z nagłówka; mediantime jest medianą; chainwork reprezentuje skumulowaną oczekiwaną pracę. Żadna pojedyncza liczba nie wystarcza. Sens Timechain polega na tym, że węzeł sprawdza ich zależności oraz wszystkie reguły konsensusu jako całość. [6] [4]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Genesis Block, Proof of Work, Transakcja, Full Node, Difficulty Adjustment. Do tego hasła prowadzą również odsyłacze z Bitcoin Whitepaper, Genesis Block, Proof of Work, Full Node.