Ewolucja konsensusu Sui: Od Tusk do Mysticeti

Sui dwukrotnie zastąpiło swój rdzeń konsensusu. Sieć nigdy nie potrzebowała hard forka.

Ten artykuł jest częścią serii o Sui:

• Odkrywanie Sui: Blockchain z wieloma innowacjami
• Pod maską Sui: Walidatorzy, konsensus i staking
• Sui: Model obiektowy, czyli przemyślenie blockchainów przez pryzmat danych
• Zarządzanie Sui: Ulepszanie bez zepsucia
• Konsensus Sui wyjaśniony: Jak Narwhal i Mysticeti finalizują w 0,5 sekundy

Powód sprowadza się do wyboru architektonicznego. Narwhal, warstwa odpowiedzialna za rozpowszechnianie transakcji między walidatorami i organizowanie ich w DAG, pozostawała stabilna we wszystkich trzech protokołach. Powyżej niej mechanizm odpowiedzialny za kolejność transakcji mógł być wymieniany. Tusk, potem Bullshark, potem Mysticeti — każdy z nich podłączał się do tego samego fundamentu. Tam gdzie inne blockchainy musiałyby budować od zera, Sui zastąpiło tylko jedną warstwę.

Warto z góry wyjaśnić jedną kwestię terminologiczną. Sui inaczej obsługuje dwa typy transakcji, a to rozróżnienie nie ma nic wspólnego z tym, który protokół konsensusu jest uruchomiony. Obiekty należące do jednej strony — np. prosty transfer — całkowicie omijają konsensus za pomocą Byzantine Consistent Broadcast, co jest szybsze. Tylko obiekty współdzielone wymagają konsensusu do ustalenia kolejności. Mechanizm ten obowiązuje od uruchomienia Sui i działa niezależnie od tego, który protokół konsensusu jest aktywny. Nie należy go mylić z ewolucją samego protokołu konsensusu, która jest tematem tego artykułu.

Tusk: Asynchroniczny punkt wyjścia

Tusk został zaprojektowany dla sieci, w której nic nie można założyć na temat czasu dostarczania wiadomości. Bez ograniczeń czasowych, bez założeń synchroniczności. To najbardziej wrogi scenariusz — a zarazem najbardziej realistyczny dla globalnej sieci, gdzie warunki znacznie różnią się między poszczególnymi walidatorami.

Jego główna idea: gdy DAG Narwhala jest zbudowany, konsensus jest osiągany bez żadnej dodatkowej komunikacji. Każdy walidator stosuje ten sam deterministyczny algorytm do swojego lokalnego widoku DAG i dochodzi do tego samego porządku co każdy inny walidator. Żadnych rund głosowania, żadnej jawnej koordynacji. Kolejność jest odczytywana z samej struktury referencyjnej, poprzez identyfikację punktów zakotwiczenia pełniących rolę znaczników zatwierdzenia.

Testy porównawcze z oryginalnej publikacji, zmierzone na 20 walidatorach, określają przepustowość na około 160 000 transakcji na sekundę przy opóźnieniu wynoszącym około 3 sekund. W tamtym czasie było to więcej niż to, co mogły osiągnąć klasyczne systemy.

Pozostały dwa problemy. Po pierwsze, opóźnienie: 3 sekundy są akceptowalne w wielu przypadkach użycia, ale stanowią przeszkodę nie do pokonania w handlu czy grach w czasie rzeczywistym. Po drugie, sprawiedliwość. W czysto asynchronicznym środowisku walidatorzy lepiej połączeni z siecią częściej widzieli swoje transakcje uwzględniane — strukturalna nierównowaga faworyzująca najszybsze węzły.

Tusk funkcjonował głównie w badaniach i na testnecie. Gdy mainnet Sui uruchomił się w 2023 roku, Bullshark już był na czele.

Bullshark: Częściowa synchroniczność

Koncepcyjny skok Bullsharka opiera się na jednym założeniu: przez większość czasu sieć zachowuje się normalnie. Zamiast zawsze przygotowywać się na najgorsze, protokół wykorzystuje okresy, gdy wiadomości docierają w rozsądnym czasie. To model częściowej synchroniczności: ograniczenia czasowe są zakładane w normalnych warunkach; asynchroniczna odporność włącza się, gdy sieć się degraduje.

Z tego założenia wynika prawdziwa szybka ścieżka Bullsharka — nie należy jej mylić z wcześniej wspomnianym rozróżnieniem między obiektami własnymi a współdzielonymi. W okresach synchronicznych protokół może zatwierdzać szybciej, bez czekania przez tyle rund co w trybie zdegradowanym. To skrót opóźnienia uzależniony od kondycji sieci.

Bullshark rozwiązał również problem sprawiedliwości, z którym Tusk nie poradził sobie, poprzez słabe łącza. Łącza te pozwalają tymczasowo wolnemu walidatorowi zostać uwzględnionym w ostatecznym konsensusie, nawet jeśli szybsze walidatory jeszcze go nie referencjonowały. Żaden uczciwy walidator nie jest wykluczany z powodu słabego połączenia. Protokół udoskonalił również wybór punktów zakotwiczenia i czyszczenie pamięci, co pozwoliło mu utrzymywać obciążenie przez dłuższe okresy.

Koszt: większa złożoność. Słabe łącza i adaptacja sieciowa wprowadzają przypadki brzegowe i narzut obliczeniowy. Publikacja podaje 125 000 TPS przy 2 sekundach opóźnienia dla 50 stron — niżej niż Tusk na papierze, ale porównanie jest mylące: Tusk był mierzony na 20 walidatorach, a przepustowość mechanicznie spada wraz z rozrostem sieci. Obie wartości nie są bezpośrednio porównywalne. Opóźnienie tymczasem pozostało w zakresie sekundy — nadal zbyt wolno dla najbardziej wymagających aplikacji.

Dla Sui przejście miało jedną główną wartość: udowodnienie, że sieć może zmienić swój konsensus bez zakłóceń. Istotny sygnał pewności dla deweloperów budujących na niej.

Mysticeti: Rezygnacja z jawnej certyfikacji

Mysticeti nie rozszerza Bullsharka — zmienia podstawową logikę. Zarówno Tusk, jak i Bullshark opierają się na certyfikowanym DAG: każdy blok musi zostać podpisany przez kworum walidatorów, zanim zostanie uznany za dostępny. Ta certyfikacja jest kosztowna — w podpisach do wyprodukowania i weryfikacji oraz w rundach sieciowych. To był wąskie gardło wspólne dla obu poprzednich generacji.

Mysticeti całkowicie usuwa ten krok. Działa na niecertyfikowanym DAG: walidatorzy podpisują i rozgłaszają swoje bloki — i to wszystko. Porozumienie nie jest już głosowane; jest wywnioskowane. Gdy walidator referencjonuje blok innego walidatora we własnym wyjściu, ten akt referencjonowania stanowi niejawną akceptację. Konsensus jest wyprowadzany z zachowania referencjonowania, bez żadnych dedykowanych wiadomości głosowania.

Wyniki są widoczne w dwóch wymiarach. Pod względem opóźnienia Mysticeti zatwierdza w trzech rundach wiadomości — teoretyczne minimum, na poziomie praktycznego BFT. Pod względem zasobów eliminacja tysięcy podpisów na rundę znacznie zmniejsza obciążenie procesora: około 40% mniej w produkcji (z ~48% do ~29% wśród wdrożonych walidatorów). Protokół uruchamia również wielu liderów równolegle w każdej rundzie, co obniża mediany i opóźnienia ogonowe, i pochłania niedostępność lidera bez zatrzymywania się.

Wariant Mysticeti-FPC dodaje szybką ścieżkę zatwierdzania dla transferów aktywów. Jego wyróżniającą cechą jest wplatanie tych transakcji bezpośrednio w DAG zamiast osobnej ich obsługi, co oszczędza podpisy i wiadomości. Tu właśnie żyje prawdziwa szybka ścieżka zatwierdzania wbudowana w strukturę — nie w Bullsharku.

Liczby zmierzone w kontrolowanym środowisku: 300 000 TPS przy 10 węzłach i 400 000 TPS przy 50 węzłach, zanim opóźnienie przekroczy jedną sekundę. Przy utrzymywanym obciążeniu zatwierdzenia lądują około 0,5 sekundy przy 200 000 TPS. W tych samych testach inne wiodące protokoły osiągają szczyt poniżej 150 000 TPS przy opóźnieniach zaczynających się od około 2 sekund.

Jest też szeroko cytowane „80% redukcji opóźnienia w stosunku do Bullsharka" (z ~1,9 s do ~400 ms). Liczba jest dokładna, ale to porównanie w najlepszym przypadku: zestawia Bullsharka w zdegradowanych warunkach z Mysticeti w optymalnych. Przy typowym obciążeniu obiektami współdzielonymi zysk jest skromniejszy, choć żaden publiczny pomiar nie podaje dokładnej wartości. Warto też pamiętać: liczby 200 000–400 000 TPS pochodzą z kontrolowanych testów porównawczych. Na mainnecie, w rzeczywistych warunkach, obserwowana przepustowość jest znacznie niższa.

Co pokazuje trajektoria

Zestawiając trzy generacje, progresja jest jasna — o ile liczby są czytane w kontekście.

Przepustowość wzrasta od ~160 000 TPS (Tusk, 20 walidatorów) do 125 000 TPS (Bullshark, 50 stron), a następnie do 300 000–400 000 TPS w zależności od konfiguracji (Mysticeti). Liczby węzłów się różnią, więc te wartości nie porównują punkt do punktu: dają rząd wielkości, nie ścisłe zestawienie. Opóźnienie natomiast spada jednoznacznie: z 3 sekund do około 0,5 sekundy, przechodząc przez ~2 sekundy dla Bullsharka. Pod względem komunikacji progresja przebiega od zerowego narzutu po zbudowaniu DAG (ale z kosztowną certyfikacją upstream) do niejawnej certyfikacji eliminującej większość ruchu głosowania.

Prawdziwy punkt zwrotny nie leży między Tuskiem a Bullsharkiem — oba należą do tej samej rodziny: certyfikowany DAG, jawna certyfikacja, przyrostowe optymalizacje. Przełom leży między Bullsharkiem a Mysticeti, wraz z rezygnacją z certyfikacji. Tusk i Bullshark optymalizowały krok; Mysticeti go wyeliminowało.

Warto podkreślić: we wszystkich trzech protokołach Narwhal prawie się nie zmienił. Cała innowacja skupiła się na warstwie porządkowania, bez destabilizowania dyseminacji danych. To właśnie rozdzielenie odpowiedzialności umożliwiło te wymiany bez przerw w działaniu usługi — rodzaj wyboru architektonicznego, który nie przynosi natychmiastowych korzyści, ale ostatecznie zmienia wszystko.

Mysticeti prawdopodobnie nie jest ostatnim słowem. Podejście Sui polega właśnie na zastępowaniu komponentu, gdy pojawi się lepszy, bez dotykania reszty. Jeśli nadejdzie czwarta generacja, najprawdopodobniej podłączy się do tego samego Narwhala.

Źródła

• Tusk — Danezis, Kokoris-Kogias, Sonnino, Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus (2021). arXiv · PDF
• Bullshark — Spiegelman, Giridharan, Sonnino, Kokoris-Kogias. Bullshark: DAG BFT Protocols Made Practical (2022). arXiv · PDF
• Mysticeti — Babel, Chursin, Danezis, Kichidis, Kokoris-Kogias, Koshy, Sonnino, Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs (2023, NDSS 2025). arXiv · PDF

Ewolucja konsensusu Sui: Od Tuska do Mysticeti została pierwotnie opublikowana w Coinmonks na Medium, gdzie ludzie kontynuują rozmowę, zaznaczając i odpowiadając na tę historię.