Podsumowanie przełomu w MonadBFT Wczoraj Category Labs opublikowało artykuł MonadBFT, opisujący mechanizm konsensusu, który będzie zasilał Monad w mainnecie. MonadBFT jest znaczącym osiągnięciem w badaniach konsensusu, ponieważ po raz pierwszy Pipelined HotStuff staje się odporny na widelec ogona. Rozwidlenie ogona ma miejsce, gdy pominięte gniazdo powoduje, że poprzednia propozycja zostaje odrzucona i ponownie wydobyta. Jest to poważny problem w poprzednich formułach Pipelined HotStuff, ponieważ otwiera wieloblokowe ataki MEV, które destabilizują konsensus. Złagodzenie tego problemu to ogromna sprawa, ponieważ daje nam wszystkie korzyści płynące z Pipelined HotStuff - częste bloki, niskie opóźnienia, duże zestawy walidatorów - jednocześnie unikając największych wad. MonadBFT oferuje również ogromne ulepszenie dla ostateczności. Charakteryzuje się jednoslotową (500 ms) spekulatywną ostatecznością i dwuslotową (1s) twardą ostatecznością. "Finalność spekulatywna" oznacza "ostateczność, która powróci tylko w przypadku dwuznaczności (podwójnego podpisu) przez większość walidatorów". Dwuznaczność jest poważnym wykroczeniem w większości systemów blockchain i jest powszechnie karana cięciem; Im większa kara za dwuznaczność, tym bardziej można myśleć o "spekulatywnej celowości" do ostateczności. Jednoslotowa spekulatywna finalność to ogromny unlock dla aplikacji o wysokiej wydajności, które mogą pewnie wyświetlać zaktualizowany stan świata natychmiast po otrzymaniu następnego bloku. Te właściwości sprawiają, że MonadBFT jest ogromnym postępem w konsensusie i godnym uzupełnieniem innych ulepszeń złożonych w Monad, w tym Asynchronous Execution, Optimistic Parallel Execution i MonadDb. Pozostała część tego artykułu służy jako podsumowanie tego, w jaki sposób kolejne ulepszenia w HotStuff opierały się na sobie nawzajem, w celu wyjaśnienia problemu, który rozwiązuje MonadBFT. Podsumowując: 1. HotStuff daje nam liniową złożoność komunikacji, dzięki czemu możemy mieć duże zestawy walidatorów, ale nie jest to zbyt wydajne 2. Pipelined HotStuff daje nam wydajność i niskie opóźnienia w proponowaniu bloków w każdym slocie, ale cierpi na problem widelców ogonowych 3. MonadBFT daje nam opór na widelcu ogonowym i spekulacyjną ostateczność z jednym slotem --- HotStuff: Złożoność komunikacji liniowej umożliwia dużą liczbę węzłów Algorytmy HotStuff są kompletne w ciągu kilku rund komunikacji, które zazwyczaj przyjmują formę komunikacji "fan out, fan in" bezpośrednio od liderów do walidatorów z powrotem do liderów. Każda runda rozpoczyna się od tego, że lider wysyła wiadomość bezpośrednio do innych walidatorów, z których każdy odsyła podpisaną wiadomość potwierdzającą otrzymanie wiadomości. Pod warunkiem, że zdecydowana większość (2/3) walidatorów odeśli zaświadczenie, każda runda kończy się agregacją podpisanych zaświadczeń przez lidera w Certyfikat Kworum (QC), który służy jako dowód, że większość kwalifikowana potwierdziła poprzednią wiadomość. Algorytmy HotStuff mają wiele rund komunikacji w ten sposób. - Pierwszą wiadomością od lidera jest propozycja blokowa - Drugi komunikat to kontrola jakości dla tej propozycji bloku - Trzecia wiadomość to kontrola jakości dotycząca poprzedniej kontroli jakości (tj. kontrola jakości na kontroli jakości) - i tak dalej Jeśli procedura zostanie przerwana w dowolnym momencie przed ostatecznością, blok nie zostanie sfinalizowany i zostanie odrzucony; Transakcje z tego bloku będą musiały zostać ponownie uwzględnione w następnym bloku. Oryginalny protokół HotStuff nie ma potoku i ma 3 rundy komunikacji przed ostatecznością; W każdej rundzie ten sam walidator pełni rolę lidera. --- Pipelined HotStuff: Nowy blok w każdym slocie zwiększa wydajność Pipelining jest tym, co wszyscy robimy intuicyjnie, gdy mamy do wykonania dwa ładunki prania. Zamiast czekać, aż wsad 1 zakończy pełny cykl przed rozpoczęciem wsadu 2, w pipeliningu umieszczamy ładunek 1 w suszarce w tym samym czasie, gdy ładunek 2 trafia do pralki. Możesz myśleć o oryginalnym HotStuff jako o naiwnym podejściu do robienia prania (nie zaczynaj od załadunku 2, dopóki załadunek 1 nie zostanie całkowicie zakończony), podczas gdy Pipelined HotStuff działa intuicyjnie polegając na przechodzeniu wielu ładowań prania w sposób rozłożony w czasie. W Pipelined HotStuff rozkładamy propozycje tak, że w każdej rundzie proponowany jest nowy blok, z nowym blokiem na barana na wierzch wiadomości przenoszącej QC z poprzedniego bloku. Propozycje blokowe zmierzają w kierunku ostateczności w ciągu wielu rund. Korzyści płynące z potokowania są znaczące. Potokowanie zwiększa gęstość propozycji bloków, ponieważ propozycja blokowa jest tworzona w każdym slocie, co zwiększa przepustowość i skraca czas do finalizacji. Jest jednak jedna poważna wada pipeliningu, którą najlepiej zilustrować na przykładzie. Załóżmy, że liderami bloków N, N+1 i N+2 są Alice, Bob i Charlie. Jeśli Bob nie trafi na swoje miejsce, oświadczyny Alicji również zostaną unieważnione, ponieważ wiadomość Boba zawiera zarówno jego propozycję, jak i QC dla propozycji Alicji. Kiedy tak się dzieje, Charlie zostaje wezwany do wyprodukowania bloku, tak jakby propozycja Alice nigdy nie istniała. Nazywamy to zachowanie "rozwidleniem ogona" i można je traktować jako mini-reorganizację głębokości 1. Możliwość rozwidlenia ogona ma poważne konsekwencje, ponieważ pominięte sloty niekoniecznie są przypadkowe. Jeśli istnieje możliwość wydobycia wartości poprzez ponowne wydobycie bloku Alicji podczas ponownego zamawiania lub pomijania niektórych transakcji, Bob i Charlie mogą zmówić się, aby Bob celowo przegapił swoje miejsce, uruchamiając okazję dla Charliego do ponownego wydobycia bloku Alice. Była to znacząca wada protokołów Pipelined HotStuff (niektóre z nich są obecnie dostępne w mainnecie). --- MonadBFT zmienia ten stan rzeczy MonadBFT jest pierwszym protokołem, który umożliwia potokowanie, a jednocześnie sprawia, że algorytm jest odporny na działanie widełek ogonowych. Ten opór przed rozwidleniem ogona wynika z procedury awaryjnej, gdy Bob nie trafia w swoje miejsce, co umożliwia walidatorom zebranie ich zbiorowej wiedzy na temat propozycji Alicji i jej poziomu konsensusu w zestawie walidatorów. W szczególności, w ramach MonadBFT, jeśli Bob nie trafi w swoje miejsce, procedura awaryjna polega na tym, że walidatorzy komunikują się ze sobą za pomocą podpisanych zaświadczeń stwierdzających, czy widzieli blok Alice. Jeśli zdecydowana większość potwierdzi blok Alicji, Charlie jest zmuszony ponownie zaproponować blok Alicji. Jeśli Charlie chce zaproponować inny blok, musi dostarczyć podpisane zaświadczenie od większości walidatorów, potwierdzające, że nie widział bloku Alicji na czas. W typowym przypadku, gdy Charlie ponownie proponuje blok Alicji, następnie może zaproponować swój blok w następnej rundzie. Rezultatem są dwie ważne właściwości: odporność na rozwidlenie ogona i spekulacyjna ostateczność pojedynczego slotu. Mówiliśmy już o odporności na rozwidlenie ogona, ale zrozummy jego wpływ na ostateczność. Tak jak poprzednio, załóżmy, że liderami bloków N, N+1 i N+2 są Alice, Bob i Charlie. W Pipelined 2-Phase HotStuff - tj. przed MonadBFT - jako walidator (lub pełny węzeł), nie możesz sfinalizować propozycji bloku Alice, dopóki nie zobaczysz propozycji bloku Charliego. Dlaczego? Ponieważ jeśli sfinalizujesz, gdy tylko zobaczysz propozycję Boba, możliwe, że Bob zadziera z tobą, przesyłając TYLKO swoją propozycję do ciebie, a w rzeczywistości planuje nie wysłać swojej propozycji do wszystkich innych, tracąc w ten sposób swoje miejsce. Ale w MonadBFT, gdy tylko zobaczysz propozycję Boba, możesz "spekulatywnie" sfinalizować propozycję Alice, ponieważ propozycja Boba zawiera QC na propozycję Alice, co jest dowodem na to, że 2/3 sieci potwierdziło propozycję Alice. Nawet jeśli Bob zadziera z tobą, przesyłając ci TYLKO swoją propozycję i skończy się na tym, że przegapi swoje miejsce, wiesz, że zdecydowana większość sieci widziała propozycję Alice i, kiedy weźmie udział w procedurze awaryjnej, ponownie podpisze się pod propozycją Alice. Jedynym sposobem, w jaki blokada Alicji nie zostanie sfinalizowana, jest to, że walidatorzy niejednoznacznie się potwierdzą i podpiszą, mówiąc, że nie widzieli wiadomości Alicji. Ta wada jest łatwa do udowodnienia - podpisaliśmy od nich sprzeczne wiadomości. Jeśli kara za dwuznaczność jest znaczna - a powinna być - to ta "spekulatywna" celowość nie jest w rzeczywistości aż tak spekulatywna. --- Dania na wynos MonadBFT jest niezwykle ekscytującym osiągnięciem dla konsensusu i jest godnym uzupełnieniem innych ulepszeń łączenia w Monadzie, w tym Asynchronous Execution, Optimistic Parallel Execution i MonadDb. Ogromne gratulacje dla @MohammadMJalal1 i @KushalBabel tego znaczącego przełomu. MonadBFT zostanie wkrótce zaimplementowany w sieci testowej Monad, która obecnie implementuje Pipelined 2-Phase HotStuff. Aby uzyskać więcej informacji, zobacz podlinkowany wpis na blogu i artykuł w następnym tweecie.