115 / 736NC

Nakamoto Consensus

Jak Bitcoin uzgadnia historię płatności

Bitcoin nie ma centralnego księgowego. Wspólna historia powstaje dzięki niezależnej weryfikacji, wydobyciu i wyborowi poprawnego łańcucha o największej skumulowanej pracy.

Nakamoto Consensus to nazwa sposobu, w jaki Bitcoin uzgadnia wspólną poprawną historię transakcji bez centralnego arbitra. Full Node, czyli komputer z programem samodzielnie sprawdzającym reguły, najpierw odrzuca niepoprawne bloki. Z poprawnych gałęzi wybiera następnie tę z największą skumulowaną pracą. Kolejne potwierdzenia zwiększają pewność płatności przy określonych założeniach bezpieczeństwa, ale nie czynią jej natychmiast nieodwracalną.

Anna wysyła płatność Piotrowi. Mogłaby jednak podpisać drugą transakcję, wydającą te same środki na rzecz Ewy. Podpisanie oznacza tu użycie klucza prywatnego, czyli tajnej wartości liczbowej, do utworzenia sprawdzalnego dowodu autoryzacji płatności. Inni mogą zweryfikować podpis, nie znając tej tajnej wartości. Oba podpisy mogą być autentyczne, ale obie płatności nie zmieszczą się w jednej poprawnej historii. Piotr i Ewa mogą też otrzymać wiadomości w odwrotnej kolejności. Bitcoin potrzebuje więc czegoś więcej niż sprawdzania podpisów: sposobu uzgodnienia kolejności i zapobiegania podwójnemu wydaniu. Nakamoto Consensus łączy reguły, Proof of Work, wybór gałęzi i nagrody dla górników. Whitepaper Satoshiego, pierwotny opis techniczny Bitcoina, nie używa tej późniejszej nazwy. [1] [4]

Full Node Piotra nie jest kartą do głosowania. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Wyjście transakcji zapisuje kwotę i warunki, pod którymi można ją później wydać. Program Full Node samodzielnie kontroluje transakcje i bloki: czy wydawane wyjścia transakcji są jeszcze niewydane, czy spełniono ich warunki wydania i czy nie powstaje więcej bitcoinów, niż wolno. Górnik może zaproponować blok, ale nie dowolnie ominąć te kontrole. Niepoprawny blok pozostaje niepoprawny nawet przy ogromnej ilości pracy. Porównuje się wyłącznie poprawne gałęzie; wspólna historia wymaga zgodnych reguł uczestników. [2] [3]

Gdyby każdy podłączony komputer miał głos, napastnik mógłby stworzyć wielu pozornie niezależnych uczestników. To Sybil Attack. Proof of Work zamiast liczyć nazwy wiąże wagę gałęzi ze sprawdzalną pracą obliczeniową. Górnicy wielokrotnie obliczają hashe, cyfrowe odciski danych, szukając wyniku spełniającego określony warunek. Próby kosztują energię i sprzęt, a znaleziony wynik łatwo sprawdzić. Wiele tożsamości sieciowych samo w sobie nie dodaje pracy. Nie chodzi o kontrolę dowodów osobistych ani głosowanie wszystkich węzłów. [1] [4]

Górnik składa blok kandydujący i zmienia jego nagłówek, zwięzłe podsumowanie bloku, aż hash nagłówka odczytany jako liczba będzie mniejszy lub równy obowiązującemu celowi. Nie rozwiązuje przy tym użytecznego równania ani nie łamie szyfrowania: szuka rzadkiego wyniku. Dwaj górnicy mogą osiągnąć sukces niemal równocześnie. Część sieci zobaczy najpierw jeden blok, część drugi, przez co na krótko powstaną dwie poprawne gałęzie. To samo w sobie nie jest awarią. Przy normalnym rozchodzeniu się bloków dalsza praca pozwala węzłom przejść na tę samą silniejszą gałąź. [1] [8]

Siłę gałęzi mierzy chainwork, suma pracy przypisanej blokom na podstawie ich celów. Nie jest to licznik prądu ani zapis rzeczywiście wykonanych prób. Jeden górnik mógł mieć szczęście od razu, drugi czekać długo; przy takim samym celu ich poprawne bloki mają identyczną wagę. Full Node wybiera dostępną poprawną gałąź o największej sumie. „Najdłuższy łańcuch” oznacza więc najwięcej pracy, niekoniecznie bloków. Zmiana gałęzi to reorganizacja; płatność z porzuconego bloku może zostać włączona ponownie, jeśli nadal jest poprawna. [1] [2] [3] [7]

Gdy płatność Anny znajdzie się w przyjętym bloku, ma jedno potwierdzenie. Każdy kolejny blok dodaje następne. Aby zastąpić tę historię, konkurencyjna gałąź musiałaby dogonić jej pracę. Przy uczciwej większości mocy obliczeniowej i dostatecznie szybkim rozchodzeniu się bloków ryzyko skutecznego przepisania zwykle maleje wraz z głębokością. To probabilistyczna ostateczność: rosnąca pewność, a nie matematyczna niemożliwość zmiany. Liczba potwierdzeń oczekiwana przez Piotra zależy też od kwoty i ryzyka płatności. Żadna uniwersalna liczba nie gwarantuje bezpieczeństwa w każdych warunkach. [1] [4]

Gdyby po pojawieniu się szybszych maszyn warunek pozostał taki sam, bloki powstawałyby szybciej. Dlatego Difficulty Adjustment przelicza cel w sieci głównej co 2016 bloków, korzystając z wcześniejszych znaczników czasu. Dąży do średnio dziesięciu minut na blok, czyli około dwóch tygodni na taki odcinek. Pojedynczy blok może jednak przyjść dużo wcześniej lub później. Zmianę uruchamia liczba bloków, nie data w kalendarzu: po nagłym ubytku dużej części mocy osiągnięcie następnej korekty może potrwać dłużej. To nie natychmiastowy regulator ani precyzyjny zegar. [2] [8]

Nowe bitcoiny, czyli subsydium blokowe, i opłaty transakcyjne nagradzają górników za bloki, które pozostaną w przyjętej historii. Zachęca to do jej rozwijania, lecz nie zastępuje założeń bezpieczeństwa. Większość mocy może reorganizować poprawne gałęzie, pomijać płatności i próbować cofnąć własne wydatki. Nie zmusi jednak Full Node do przyjęcia niepoprawnego podpisu, nadmiernej emisji czy wydania cudzych środków bez uprawnienia. Próg 50% też nie jest przełącznikiem bezpieczeństwa: niektóre ataki mają szanse poniżej niego. Sama nagroda nie tworzy uczciwości. [1] [2] [3]

Wróćmy do Piotra. Jeżeli napastnik kontroluje wszystkie połączenia jego węzła, może pokazywać mu niepełny obraz wydarzeń. Eclipse Attack to właśnie taka izolacja sieciowa; potwierdzenia mogą wtedy znaczyć coś innego niż przy dobrym połączeniu z resztą sieci. Podział sieci na odłączone części również utrudnia zgodę. Bezpieczeństwo zależy zatem od mocy napastnika, rozchodzenia się wiadomości i uczciwej weryfikacji. Badania Bitcoin Backbone jawnie modelują te warunki. Sam procent mocy, bez założeń dotyczących sieci, nie jest pełnym wyjaśnieniem bezpieczeństwa. [4]

Klasyczne metody BFT (Byzantine Fault Tolerance) dążą do zgody mimo błędów lub złośliwego działania uczestników i często zakładają grupę znaną z góry. Przykłady OM (Oral Messages) i PBFT (Practical Byzantine Fault Tolerance) mają własne warunki oraz zasady wymiany wiadomości. Bitcoin radzi sobie z otwartym uczestnictwem dzięki pracy i probabilistycznemu utrwalaniu historii; nie jest tylko nową nazwą tych metod. Wybór silniejszej poprawnej gałęzi nie zmienia też zasad poprawności. Zmiana reguł wymaga przyjęcia przez uczestników odpowiedniego oprogramowania i zgodnych warunków. Górnicy pomagają ustalić, która poprawna historia będzie kontynuowana, nie co wszyscy muszą uznać za poprawne. [5] [6] [9]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Bitcoin, Proof of Work, Difficulty Adjustment, Reguły konsensusu, Wydobywanie, Full Node. Do tego hasła prowadzą również odsyłacze z Bit Gold, Reusable Proofs of Work, Byzantine Generals Problem, Sybil Attack.

DOC · 001Satoshi Nakamoto — Bitcoin: A Peer-to-Peer Electronic Cash SystemŹródło pierwotne DOC · 002Bitcoin Developer Guide — Block ChainDokumentacja DOC · 003Bitcoin Core v29.0 — Chainstate validationDokumentacja DOC · 004The Bitcoin Backbone ProtocolŹródło pierwotne DOC · 005The Byzantine Generals ProblemŹródło pierwotne DOC · 006Bitcoin Optech — Soft fork activationŹródło pierwotne DOC · 007Bitcoin Core v29.0 — Block proof and chainworkŹródło pierwotne DOC · 008Bitcoin Core v29.0 — Proof of Work and retargetingŹródło pierwotne DOC · 009Castro & Liskov — Practical Byzantine Fault Tolerance (1999)Źródło pierwotne
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna