Jak Monad skaluje EVM, zachowując decentralizację? MonadBFT to algorytm konsensusu używany w Monad, jest to pierwsza implementacja Hotstuff odporna na tailfork (co to właściwie oznacza?) Oto jak MonadBFT może skalować się do 1000 validatorów, zachowując wydajność 🧵

1/7 Mechanizmy konsensusu Mechanizm, który blockchainy wykorzystują, aby upewnić się, że nowe bloki są zatwierdzane przez większość walidatorów. Algorytmy konsensusu jak dotąd nie są w stanie skalować się ponad kilka setek walidatorów, ponieważ złożoność rośnie w zależności od kwadratu liczby walidatorów (w większości przypadków). Ponieważ każdy walidator rozmawia ze wszystkimi innymi walidatorami, aby uzgodnić bloki: n walidatorów x n wiadomości = n-kwadrat wiadomości. W związku z tym złożoność znacznie wzrasta wraz z liczbą walidatorów.

2/7 Hotstuff to algorytm konsensusu, który może skalować się liniowo (proporcjonalnie do liczby walidatorów) poprzez unikanie komunikacji typu all-to-all i pozwalając jednemu "liderowi" komunikować się ze wszystkimi walidatorami w celu osiągnięcia konsensusu. W ten sposób Hotstuff może skalować się bardziej efektywnie niż tradycyjny konsensus PBFT, ale jest podatny na ataki tailforking. MonadBFT to pierwsza implementacja Hotstuff odporna na tailfork.

3/7 Co to jest tailforking? Tailforking ma miejsce, gdy następny lider (walidator proponujący następny blok) celowo lub przypadkowo nie uwzględnia QC ważnego bloku poprzedniego lidera w swojej propozycji nowego bloku. (QC oznacza certyfikat kworum, który jest dowodem, że wszyscy walidatorzy zgodzili się na poprzedni blok) W rezultacie poprzedni blok, mimo że jest ważny i ma większość poparcia, pozostaje niezatwierdzony i ostatecznie zostaje osierocony lub zastąpiony innym blokiem na tej samej wysokości. To zakłóca mechanizm zachęt: uczciwi proponenci mogą nie otrzymać nagród za blok lub opłat, jeśli ich blok zostanie pominięty, co sprzyja nieuczciwemu zachowaniu i osłabia bezpieczeństwo sieci.

4/7 Jak działa MonadBFT? → Lider (Alice) przesyła podpisaną propozycję bloku do wszystkich innych węzłów (fan out), które potwierdzają jej ważność, wysyłając podpisaną attestację do następnego lidera Boba (fan in). → Bob agreguje attestacje w „Certyfikat Kwarum” (QC) → Bob przesyła QC do wszystkich węzłów, które potwierdzają jego otrzymanie, wysyłając wiadomość do 3. lidera (Charlie), który agreguje te attestacje. Ponieważ attestacje dotyczą QC, nazywamy ten nowy QC QC-na-QC. → Charlie wysyła QC-na-QC do wszystkich. Po otrzymaniu QC-na-QC, wszyscy wiedzą, że blok Alice został sfinalizowany.

5/7 Pipelining W powyższej historii Bob i Charlie wysyłają tylko QC lub QC-na-QC, ale w rzeczywistości propozycje są pipelined: wiadomość Boba zawiera zarówno QC dla bloku Alice, jak i zawartość nowego bloku. Wiadomość Charliego zawiera QC dla bloku Boba (które jest QC-na-QC dla bloku Alice) i również zawiera transakcje dla nowego bloku. Gdy walidatorzy wysyłają zaświadczenie dla wiadomości Boba, potwierdzają zarówno ważność bloku Boba, jak i ważność QC. To pipelining zwiększa przepustowość sieci, ponieważ w każdym slocie produkowany jest nowy blok.

6/7 Raptorcast: Protokół propagacji bloków Monad MonadBFT wymaga, aby lider wysyłał propozycje bloków do każdego walidatora. Jednak bloki mogą być dość duże: 10 000 transakcji/s * 200 bajtów/tx = 2 MB/s. Wysyłanie bezpośrednio do 200 walidatorów wymagałoby 400 MB/s. Idealnie, walidatorzy nie powinni mieć tak wysokiej przepustowości wysyłania. Tutaj wkracza Raptorcast. → Bloki są kodowane erasure przez lidera (Kodowanie erasure oznacza, że wiadomość jest dzielona na zestaw kawałków, a można ją zdekodować z wystarczająco dużego podzbioru tych kawałków) → Lider rozdziela różne zestawy kawałków do wszystkich walidatorów w sieci (walidatorzy z wyższym stawką otrzymują proporcjonalnie więcej) → Każdy walidator ponownie nadaje swoje kawałki do wszystkich innych walidatorów w sieci W ten sposób cała przepustowość sieci jest wykorzystywana do propagacji propozycji bloków.