Bizantyjska tolerancja błędów w blockchainie

W ciągu ostatnich kilkudziesięciu lat przemysł kryptowalutowy znacznie się rozwinął. Ciągle pojawiają się nowe projekty, co zmusza deweloperów do znalezienia nowych sposobów na rozwiązanie istniejących w branży problemów. Jednym z dość powszechnych określeń jest mechanizm konsensusu BFT. BFT to skrót od Byzantine Fault Tolerance i jest uważany za teoretyczny problem systemów komputerowych, z którym twórcy mieli do czynienia na długo przed pojawieniem się Bitcoina.

Jednak wielu twórców protokołów opartych na blockchainie ma do czynienia z problemami związanymi z bizantyjską tolerancją błędów, więc przyjrzyjmy się naturze problemu i implikacjom, z jakimi mamy do czynienia, gdy się ten problem pojawia.

Problem bizantyjskiej tolerancji błędów

Kwestia bizantyjskiej tolerancji błędów jest jedną z najczęściej rozważanych sytuacji teoretycznych przy omawianiu niuansów konsensusu. Problem ten został po raz pierwszy uznany za istniejący w opracowaniu „Major Problems of Byzantine Failure” autorstwa Leslie Lappport, Roberta Szostaka i Marshalla Pease’a, które ukazało się w 1982 roku.

W badaniu stwierdzono:

Niezawodny system komputerowy musi poradzić sobie z awarią jednego lub więcej komponentów. Uszkodzony komponent może zachować się w sposób, który często jest pomijany, a mianowicie wysyłając sprzeczne informacje do różnych części systemu. Problem rozwiązania tego rodzaju awarii nazywa się abstrakcyjnie „Byzantine Fault Tolerance General Problem”.

Nazwa pochodzi od analogii przedstawionej w opracowaniu.

Mówiąc dokładniej, autorzy opisują teoretyczną sytuację, w której kilka jednostek armii bizantyjskiej stacjonowało poza miastem wroga. Każdy oddział miał swojego dowódcę i każdy oddział był w osobnym obozie. Dowódcy musieli opracować plan wspólnego działania (posuwania się naprzód lub odwrotu), ale mogli porozumiewać się tylko przez posłańców. Z drugiej strony wśród generałów mogli znaleźć się zdrajcy, którzy mogliby uniemożliwić lojalnym generałom dojście do wspólnego mianownika (konsensusu).

Dlatego generałowie musieli znaleźć sposób, by zapewnić, że:

• wszyscy lojalni generałowie działają według tego samego planu działania,
• mała garstka zdrajców nie będzie w stanie przeszkodzić generałom w przyjęciu właściwego planu.

Mówimy więc o systemie, który może rozwiązać opisany wyżej problem i nosi nazwę Byzantine Fault Tolerance Solution (BFS). To właśnie stąd pochodzi algorytm konsensusu BFT. Ogólnie rzecz biorąc, rozwiązanie Byzantine Fault Tolerance zapobiega awarii systemu w wyniku działania nierzetelnych ( błędnych) uczestników.

Rozwiązywanie problemu bizantyjskich generałów

Aby rozwiązać problem bizantyjskich generałów i dokonać bizantyjskiego rozwiązania Fault Tolerance Solution (FTS), większość generałów musi stosować tę samą strategię. Osiąga się to na różne sposoby, w zależności od charakteru systemu i jego przeznaczenia. W blockchainie dwa mechanizmy, „proof-of-stake” i „proof-of-work”, mogą równie osiągnąć konsensus w sprawie bizantyjskiego rozwiązania awaryjnego poprzez zastosowanie różnych podejść.

Większość blockchainów proof-of-stake może działać, gdy jedna trzecia jej istniejących węzłów ulegnie awarii, dając wolną rękę regule „3f+1”, gdzie F i odnosi się do liczby niepracujących węzłów. Sam wzór oblicza liczbę węzłów, które muszą znajdować się w systemie, aby działał on prawidłowo.

Na przykład, aby spełnić regułę (3f+1), w systemie składającym się z 4 węzłów, trzy węzły muszą być w pełni funkcjonalne.

Jak blockchain może rozwiązać ten problem?

Technologia oparta na Blockchainie miałaby kilka sposobów na rozwiązanie problemu bizantyjskich generałów. Jedyną różnicą jest potrzebny algorytm konsensusu i sposób zastosowania BFTS. Różne rozwiązania można znaleźć zarówno po stronie „proof-of-work”, jak i „proof-of-stake”.

Co ciekawe, Satoshi Nakamoto nie wspomniał o „problemie bizantyjskich generałów” w oryginalnym whitepaper bitcoina. Jednak po uruchomieniu sieci Bitcoin, nieznany twórca pierwszej kryptowaluty zaproponował rozwiązanie wspomnianego problemu za pomocą konsensusu „proof-of-work”. Satoshi stworzył sposób na wykorzystanie bezpieczeństwa kryptograficznego i szyfrowania klucza publicznego w sieci cyfrowej. Aby zapobiec jakimkolwiek wyciekom danych, zabezpieczenia kryptograficzne wykorzystują haszowanie, a tożsamość użytkownika sieci jest weryfikowana za pomocą klucza publicznego.

Transakcje są przechwytywane w blokach, które są połączone z resztą kosztem haszowania i są chronione kryptograficznie. Należy również zauważyć, że blockchain wykorzystuje drzewo Merkle do weryfikacji haszy pochodzących z głównego bloku. Każdy blok pochodzący z bloku genesis jest ważny. Bloki te są weryfikowane przez górników, którzy rozwiązują zagadki kryptograficzne w konkursie tworzenia bloków konsensusu.

Bitcoin ustanowił jasny i definitywnie obiektywny zestaw zasad, których blockchain musi przestrzegać, aby pokonać problem bizantyjskich generałów. Uczestnik sieci musi opublikować dowód wykonania pracy, aby móc dodać informację do blockchaina (stąd proof of work). Jest to kosztowne dla uczestnika i zniechęca go do dzielenia się fałszywymi informacjami, ponieważ zostaną one obalone przez innych uczestników sieci.

Wszystkie zasady są jasne i obiektywne, co oznacza, że nie można zmienić informacji.

Co z proof-of-stake?

Sieci rządzone przez algorytm konsensusu proof-of-stake nie opierają się na wydobyciu, tylko na stakingu. Aby stać się walidatorem sieci, użytkownik musi najpierw ułożyć środki w systemie. Ci, którzy posiadają większy udział, mogą również zatwierdzić więcej bloków i otrzymać większe nagrody. Ci, którzy próbują fałszować informacje, ryzykują utratę stawki.

Różne systemy w różny sposób radzą sobie z tym problemem. Na przykład Ethereum 2.0 wykorzystuje algorytm Casper. Wymaga on, aby co najmniej dwie trzecie większości węzłów zgodziło się na dany blok, zanim zostanie on stworzony i dodany do sieci.

Istnieją różne próby rozwiązania problemu w zależności od potrzeby systemu i podejścia zespołu. Na przykład w przypadku delegowanego dowodu udziału (dPoS) konsensus osiąga się znacznie szybciej. Z drugiej strony, niektóre systemy stosują w praktyce bizantyjską odporność na błędy.