Czym jest CometBFT i jak działa?

Czym jest CometBFT?

CometBFT to oprogramowanie open-source, które sprawia, że wiele komputerów może dojść do porozumienia w sprawie tych samych danych blockchaina. Mówiąc prościej: pomaga węzłom ustawiać transakcje w tej samej kolejności i przechowywać wszędzie ten sam, zaktualizowany stan blockchaina.

Ten proces nazywa się Byzantine Fault Tolerant, czyli BFT. System zakłada przy tym, że część uczestników może popełniać błędy, działać offline albo nawet celowo zachowywać się nieprawidłowo. Dopóki mniej niż jedna trzecia całkowitej siły głosu zachowuje się w ten sposób, CometBFT zapobiega ostatecznemu zatwierdzeniu dwóch różnych bloków w tym samym miejscu blockchaina.

CometBFT jest następcą Tendermint Core i korzysta z algorytmu konsensusu Tendermint. Nie jest gotowym blockchainem ani kompletnym projektem krypto z własnymi stałymi zasadami. Oprogramowanie odpowiada przede wszystkim za konsensus, komunikację między węzłami i produkcję bloków. Zasady samego blockchaina, takie jak to, które transakcje są ważne, znajdują się w osobnej aplikacji.

Połączenie między CometBFT a tą aplikacją nazywa się ABCI, czyli Application Blockchain Interface. ABCI można traktować jak stałą warstwę komunikacji: CometBFT pyta na przykład, czy transakcja jest ważna, a aplikacja odpowiada. Dzięki temu deweloperzy mogą budować własną logikę blockchaina bez konieczności tworzenia od podstaw własnego silnika konsensusu.

Najważniejsze informacje

• CometBFT to oprogramowanie open-source do konsensusu i synchronizacji danych blockchaina między węzłami.
• Wykorzystuje konsensus BFT, dzięki czemu może uwzględniać błędy lub złośliwe zachowanie części walidatorów.
• CometBFT jest forkiem i następcą Tendermint Core.
• Oprogramowanie samo nie decyduje, które transakcje są merytorycznie ważne; robi to podłączona aplikacja.
• ABCI stanowi połączenie między CometBFT a aplikacją blockchaina.

Jak działa konsensus CometBFT?

CometBFT pozwala walidatorom współpracować przy każdym bloku w trzech stałych krokach: propose, prevote i precommit. Walidator to uczestnik, który może podpisywać bloki i głosy. Nie każdy węzeł jest więc automatycznie walidatorem.

Każda nowa pozycja w blockchainie nazywa się block height. Na każdym height sieć próbuje uzgodnić jeden nowy blok. Najpierw protokół wyznacza proposera. To walidator, który w danej rundzie może rozesłać propozycję nowego bloku.

Następnie pozostali walidatorzy analizują propozycję. Czy blok jest ważny i został otrzymany na czas? Jeśli tak, oddają prevote: pierwszy głos za tym blokiem. Jeśli pojawi się wystarczająca zgodność, następuje precommit: drugi i rozstrzygający głos.

Blok zostaje zatwierdzony, gdy ponad dwie trzecie całkowitej siły głosu odda precommit dla dokładnie tego samego bloku. Siła głosu nie musi oznaczać liczby walidatorów. Jeden walidator może na przykład mieć większą siłę głosu niż inny, zależnie od zasad aplikacji blockchaina.

Przykład: Załóżmy, że całkowita siła głosu wynosi 100. Wtedy do zatwierdzenia bloku potrzeba ponad 66 głosów. Nie ma przy tym znaczenia, czy ta siła głosu pochodzi od wielu małych walidatorów, czy od mniejszej liczby większych walidatorów.

Jeśli nie ma ważnej propozycji, proposer jest offline albo głosy docierają zbyt późno, ten sam block height zaczyna się od nowa w kolejnej rundzie. Czas oczekiwania może się w każdej rundzie wydłużać, aby wolniejsze węzły mogły nadrobić zaległości. Nie eliminuje to opóźnień, ale daje sieci sposób na dalsze działanie, gdy runda się nie powiedzie.

Jaką rolę pełnią walidatorzy w CometBFT?

Walidatorzy podejmują decyzje w CometBFT. Podpisują propozycje bloków i głosy, sprawdzają propozycje i pomagają ustalić, który blok zostanie dodany. Zwykły węzeł może przekazywać informacje innym węzłom, ale bez prywatnego klucza walidatora nie może sam brać udziału w głosowaniu konsensusu.

Proposer jest wybierany automatycznie i przewidywalnie według schematu round-robin. Walidatorzy z większą siłą głosu otrzymują proporcjonalnie częściej możliwość złożenia propozycji.

W praktyce walidator wykonuje następujące działania:

• walidator otrzymuje propozycję bloku;
• walidator sprawdza, czy propozycja jest ważna zgodnie z zasadami aplikacji;
• przy ważnej i terminowej propozycji następuje prevote;
• przy wystarczającej liczbie prevote może nastąpić precommit;
• po odpowiedniej liczbie precommitów blok zostaje zatwierdzony.

Jeśli nie otrzymano ważnej propozycji, walidator może zagłosować na nil. Oznacza to po prostu brak głosu za konkretnym blokiem w tej rundzie. Dzięki temu sieć może przejść do kolejnej rundy bez bezrefleksyjnego zaakceptowania nieprawidłowej propozycji.

Zestaw walidatorów i podział siły głosu pochodzą jako dane wejściowe z aplikacji blockchaina. Aplikacja może więc również zawierać zasady dotyczące zmiany zestawu walidatorów. Staking, delegowanie i slashing nie są stałymi, autonomicznymi funkcjami samego CometBFT. To aplikacja decyduje, czy takie zasady istnieją i jak działają.

Jeszcze jedna ważna kwestia: klucze podpisywania walidatorów muszą być dobrze zabezpieczone. Jeśli ten sam walidator podpisze sprzeczne komunikaty, może to stanowić dowód zachowania bizantyjskiego. CometBFT może przetwarzać tego rodzaju dowody, ale ewentualną karę finansową określa aplikacja.

Jak przebiega komunikacja między walidatorami?

Walidatorzy komunikują się za pośrednictwem sieci peer-to-peer, często skracanej do P2P. Węzły przekazują informacje innym węzłom metodą gossip. Brzmi to nieformalnie, ale oznacza po prostu, że wiadomości rozchodzą się w sieci z węzła do węzła.

Za pomocą gossip rozsyłane są między innymi transakcje, fragmenty bloków, propozycje, prevote i precommit. Węzły dzielą się też swoim aktualnym stanem: na jakim block height się znajdują, w której rundzie są i jaki etap konsensusu wykonują. Dzięki temu węzeł, który pozostaje w tyle, może zobaczyć, co się dzieje, i ponownie dołączyć.

Także węzły niewalidujące mogą być tutaj przydatne. Mogą przekazywać propozycje, bloki i głosy, nawet jeśli same nie oddają głosu w konsensusie. Pomaga to szeroko rozprzestrzeniać informacje w całej sieci.

Transakcje, które aplikacja uzna przez CheckTx za wystarczająco ważne, mogą trafić do mempoola. Mempool to w praktyce poczekalnia dla transakcji, które mogą znaleźć się w kolejnym bloku. Za pośrednictwem gossip transakcje te mogą być dalej rozsyłane. Nie daje to jednak gwarancji, że transakcja rzeczywiście zostanie uwzględniona: znaczenie mają proposer, limity bloku i zasady aplikacji.

Komunikacji między węzłami nie należy mylić z ABCI. P2P i gossip dotyczą wiadomości między węzłami w sieci. ABCI odnosi się natomiast do lokalnej komunikacji między CometBFT a aplikacją blockchaina, na przykład w tym samym procesie, przez socket lub przez gRPC.

Jak zbudowany jest CometBFT?

CometBFT składa się w uproszczeniu z części konsensusu i części aplikacyjnej, połączonych przez ABCI. Taki podział jest wygodny: jedna strona odpowiada za to, jak węzły dochodzą do porozumienia, a druga za to, co blockchain faktycznie robi.

Silnik CometBFT zawiera między innymi komponenty do konsensusu, komunikacji P2P, mempoola, rozsyłania bloków, przechowywania stanu oraz serwer RPC. Za pośrednictwem tego serwera RPC aplikacje klienckie mogą pobierać dane o konsensusie i blockchainie.

Aplikacja zarządza natomiast własnymi zasadami i danymi. Chodzi na przykład o to, czy transakcja jest ważna, jak zmieniają się salda albo jakie inne operacje obsługuje blockchain. W wielu węzłach Cosmos SDK CometBFT i aplikacja działają razem w jednym demonie, ale mogą też współpracować jako osobne procesy przez ABCI.

Ważne jest to, że CometBFT wywołuje aplikację przez ABCI. Aplikacja nie steruje więc CometBFT, lecz zwraca odpowiedzi wtedy, gdy CometBFT o nie prosi w trakcie cyklu życia transakcji lub bloku.

Co robi warstwa konsensusu?

Warstwa konsensusu CometBFT odpowiada za to, kiedy i jak nowe bloki są uzgadniane. Ta warstwa obsługuje konsensus BFT, sieć P2P, produkcję bloków i rozsyłanie bloków do węzłów.

Przy każdym nowym bloku protokół wybiera proposera i prowadzi rundy propose, prevote oraz precommit. Gdy ponad dwie trzecie siły głosu precommituje ten sam blok, blok zostaje zatwierdzony.

Warstwa konsensusu zarządza też mempoolem. Gdy węzeł otrzyma transakcję, CometBFT pyta przez ABCI aplikację, czy ta transakcja nadaje się do mempoola. Ta kontrola nazywa się CheckTx. Pomyślne CheckTx nie oznacza jeszcze, że transakcja została ostatecznie wykonana. Oznacza jedynie, że może zostać uwzględniona w późniejszej propozycji bloku.

Po osiągnięciu konsensusu nad blokiem CometBFT sprawia, że aplikacja wykonuje blok i zapisuje nowy stan. Warstwa konsensusu nie decyduje więc sama, czy transakcja merytorycznie się zgadza. To nadal zadanie aplikacji.

Co robi warstwa aplikacji?

Warstwa aplikacji określa zasady blockchaina. To tam zapisane jest na przykład, jakie dane są przechowywane, które transakcje są ważne i jak ważna transakcja zmienia stan.

Ta warstwa jest deterministyczną maszyną stanową blockchaina. To techniczne określenie czegoś prostego: jeśli dwa węzły otrzymają ten sam input, muszą obliczyć dokładnie ten sam wynik. W przeciwnym razie węzły mogłyby otrzymać różne wersje blockchaina, a to oczywiście nie działa.

W aplikacji Cosmos SDK warstwa ta składa się między innymi z modułów, przetwarzania transakcji i magazynów stanu. Aktualny stan otrzymuje też kryptograficzne podsumowanie, czyli AppHash. Jeśli węzły po tym samym bloku obliczą różne wartości AppHash, wskazuje to na problem z wykonaniem.

Przez ABCI aplikacja obsługuje różne momenty procesu:

• CheckTx: sprawdza, czy otrzymana transakcja może trafić do mempoola.
• PrepareProposal: pozwala aplikacji proposera wybrać, uporządkować, pominąć lub dodać transakcje do propozycji bloku w granicach obowiązujących limitów.
• ProcessProposal: pozwala innym walidatorom ocenić, czy akceptują propozycję.
• FinalizeBlock: wykonuje blok po osiągnięciu konsensusu.
• Commit: trwale zapisuje nowy stan.

Nie każde wywołanie ABCI ma dokładnie takie same wymagania. Na przykład PrepareProposal może się różnić, ponieważ wykonuje je tylko proposer. ProcessProposal i wykonywanie bloków muszą natomiast być deterministyczne, aby wszyscy walidatorzy doszli do tego samego wyniku.

Do czego używa się CometBFT?

CometBFT służy jako ogólny silnik konsensusu i replikacji dla blockchainów z własnymi zasadami. Deweloperzy mogą więc umieścić za nim deterministyczną aplikację zamiast budować od zera system, w którym węzły muszą uzgadniać bloki.

Zakres zastosowań jest szeroki. Aplikacja blockchaina może dotyczyć na przykład walut, e-votingu albo orkiestracji infrastruktury. CometBFT nie narzuca przy tym, czym ma być zastosowanie. Dostarcza techniczną podstawę do niezawodnego kopiowania tych samych transakcji i tego samego stanu na wiele węzłów.

W ramach Cosmos Stack CometBFT pełni jasną rolę: odpowiada za konsensus, komunikację sieciową i produkcję bloków. Cosmos SDK dostarcza następnie elementy składowe logiki aplikacji. Dzięki temu deweloperzy nie muszą tworzyć obu części całkowicie samodzielnie.

CometBFT ma też własny serwer RPC. Portfel, dApp lub inny klient może go używać do pobierania danych o blokach i konsensusie, obok API aplikacji Cosmos SDK.

Jak CometBFT współpracuje z Cosmos SDK?

CometBFT i Cosmos SDK uzupełniają się nawzajem: CometBFT odpowiada za konsensus, a Cosmos SDK za aplikację blockchaina. To więc dwa różne elementy, które razem mogą tworzyć jeden działający węzeł blockchaina.

Cosmos SDK oferuje moduły, przetwarzanie transakcji, zarządzanie stanem i inne zasady aplikacji. CometBFT zajmuje się natomiast komunikacją P2P, mempoolem, wyborem proposera i osiąganiem konsensusu nad nowymi blokami.

Mostem między nimi jest ABCI. W aplikacji Cosmos SDK interfejs ten implementuje BaseApp. CometBFT wysyła następnie żądania takie jak CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock i Commit. BaseApp przetwarza te żądania i odsyła odpowiedź.

Przy nowej propozycji CometBFT najpierw wybiera proposera na podstawie siły głosu walidatorów. Następnie aplikacja tego proposera może przez PrepareProposal zdecydować, które transakcje znajdą się w propozycji i w jakiej kolejności, w granicach limitów bloku. Pozostali walidatorzy oceniają propozycję przez ProcessProposal, zanim oddadzą głos.

Taki podział jest praktyczny. Deweloperzy mogą pracować nad własną aplikacją blockchaina, podczas gdy sprawdzony silnik konsensusu pozostaje osobnym komponentem. Dzięki temu ten sam silnik CometBFT może być używany także z różnymi aplikacjami SDK.

Jakie są zalety CometBFT?

Jedną z ważnych zalet CometBFT jest wyraźne bezpieczeństwo BFT. Dopóki mniej niż jedna trzecia odpowiedniej siły głosu walidatorów zachowuje się bizantyjsko, nie dochodzi do zatwierdzania sprzecznych bloków na tym samym block height.

Dużą zaletą jest też podział między konsensusem a logiką aplikacji. Dzięki ABCI deweloper może tworzyć własne zasady blockchaina bez budowania od podstaw pełnego silnika konsensusu BFT. Upraszcza to zadania techniczne: CometBFT odpowiada za dojście do porozumienia, a aplikacja za treść.

Inne zalety to:

• Jasny proces głosowania: blok zostaje uzgodniony dopiero po ponad dwóch trzecich precommitów dla tego samego bloku.
• Technologia wielokrotnego użytku: ten sam silnik może obsługiwać różne aplikacje blockchainowe.
• Elastyczne połączenie: ABCI może działać w procesie w Go, ale także przez socket lub gRPC.
• Podział odpowiedzialności: kod konsensusu i kod aplikacji można rozwijać oddzielnie.

Warto jednak pamiętać, że takie zalety nie oznaczają automatycznie, iż każdy blockchain z CometBFT będzie szybki, bezpieczny lub silnie zdecentralizowany. Zależy to także od zestawu walidatorów, połączeń sieciowych, sprzętu, konfiguracji i kodu aplikacji.

Jakie ograniczenia i ryzyka ma CometBFT?

CometBFT ma wyraźne warunki bezpieczeństwa i ryzyka operacyjne. Najważniejszym warunkiem jest to, że mniej niż jedna trzecia siły głosu walidatorów może zachowywać się bizantyjsko. Bizantyjsko oznacza tutaj, że walidatorzy działają błędnie lub złośliwie, na przykład wysyłając sprzeczne informacje, nie przestrzegając zasad albo współpracując w celu manipulowania siecią. Jeśli ten próg zostanie przekroczony, gwarancja bezpieczeństwa przeciwko sprzecznym commitom przestaje obowiązywać.

Do utrzymania postępu potrzebna jest też wystarczająca aktywna siła głosu. Jeśli walidatorzy dysponujący odpowiednią siłą głosu są offline albo z powodu podziału sieci nie mogą się ze sobą komunikować, sieć nie osiągnie quorum. Wtedy pojawiają się kolejne rundy, a produkcja bloków może zwolnić lub tymczasowo się zatrzymać.

Dużą rolę odgrywają tu opóźnienia sieciowe. Jeśli propozycje, fragmenty bloków lub głosy nie dotrą na czas, runda wygasa, a protokół próbuje ponownie. Time-outy mogą się potem wydłużać. Pomaga to wolniejszym uczestnikom, ale oznacza też, że potwierdzenia mogą trwać dłużej.

Aplikacja stojąca za ABCI to kolejny ważny punkt. Tam, gdzie wymagany jest determinizm, każdy węzeł musi przy tym samym wejściu uzyskać ten sam wynik. Błąd, przez który węzły obliczają różne rezultaty, może spowodować niezgodność AppHash i problemy z konsensusem. Podział między CometBFT a aplikacją nie eliminuje więc wszystkich skutków złego kodu aplikacji.

Klucze walidatorów i infrastruktura węzłów również są wrażliwe. Słabo zabezpieczone klucze podpisywania mogą zostać wykorzystane, a walidatorzy mogą stać się celem ataków typu denial-of-service. Architektura sentry-node może pomóc mniej bezpośrednio wystawiać węzły walidatorów na takie ataki.

Ponadto transakcja w mempoolu nie jest jeszcze bezpiecznie uwzględniona w bloku. Węzły mogą ulec awarii, zanim transakcja trafi do propozycji, przez co może ona zniknąć z mempoola. Osoba wysyłająca transakcję musi więc poczekać, aż rzeczywiście znajdzie się ona w zatwierdzonym bloku.

Na koniec mogą pojawić się problemy zgodności przy aktualizacjach wersji. Breaking changes w minor release mogą wymagać nowego łańcucha albo własnej migracji danych. Aktualizacja wymaga więc dobrego przygotowania, zarówno po stronie aplikacji, jak i węzłów obsługujących blockchain.

Podsumowanie

CometBFT to techniczny silnik, który pomaga węzłom blockchaina dojść do porozumienia w sprawie nowych bloków i utrzymywać ten sam stan. Działa w procesie konsensusu BFT, w którym walidatorzy składają propozycje, głosują i zatwierdzają blok dopiero wtedy, gdy ponad dwie trzecie siły głosu akceptuje ten sam blok.

Siła tego rozwiązania tkwi przede wszystkim w podziale pracy. CometBFT odpowiada za konsensus, komunikację P2P i produkcję bloków, a aplikacja za ABCI określa zasady blockchaina. W połączeniu z Cosmos SDK deweloperzy mogą dzięki temu budować własną aplikację blockchaina bez tworzenia całej warstwy konsensusu od podstaw.

Jednocześnie praktyka pozostaje kluczowa. Bezpieczeństwo zależy od siły głosu walidatorów, niezawodnych sieci, dobrze zabezpieczonych kluczy i aplikacji, która zawsze oblicza ten sam wynik. CometBFT zapewnia więc mocną podstawę techniczną, ale ostateczne działanie łańcucha zawsze zależy też od tego, jak ta podstawa jest wykorzystywana.