Suis Konsens-Evolution: Von Tusk zu Mysticeti

Sui hat seinen Konsenskern zweimal ersetzt. Das Netzwerk hat nie einen Hard Fork benötigt.

Dieser Artikel ist Teil einer Serie über Sui:

• Sui entdecken: Eine Blockchain mit mehreren Innovationen
• Unter der Haube von Sui: Validatoren, Konsens und Staking
• Sui: Das Objektmodell oder das Umdenken von Blockchains durch Daten
• Sui Governance: Upgraden ohne Unterbrechung
• Suis Konsens erklärt: Wie Narwhal und Mysticeti in 0,5 Sekunden finalisieren

Der Grund läuft auf eine architektonische Entscheidung hinaus. Narwhal, die Schicht, die für die Verbreitung von Transaktionen zwischen Validatoren und deren Organisation in einem DAG verantwortlich ist, blieb über alle drei Protokolle hinweg stabil. Darüber konnte der Mechanismus, der für die Reihenfolge der Transaktionen zuständig ist, ausgetauscht werden. Tusk, dann Bullshark, dann Mysticeti – jeder dockte an dasselbe Fundament an. Wo andere Blockchains von Grund auf neu hätten aufgebaut werden müssen, ersetzte Sui nur eine Schicht.

Ein terminologischer Punkt, der vorab geklärt werden sollte. Sui behandelt zwei Arten von Transaktionen unterschiedlich, und diese Unterscheidung hat nichts damit zu tun, welches Konsensprotokoll läuft. Objekte, die einer einzelnen Partei gehören – etwa eine einfache Übertragung – umgehen den Konsens vollständig über Byzantine Consistent Broadcast, was schneller ist. Nur gemeinsame Objekte erfordern Konsens für die Reihenfolge. Dieser Mechanismus ist seit dem Start von Sui in Betrieb und funktioniert unabhängig davon, welches Konsensprotokoll aktiv ist. Er sollte nicht mit der Entwicklung des Konsensprotokolls selbst verwechselt werden, die das Thema dieses Artikels ist.

Tusk: Der asynchrone Ausgangspunkt

Tusk wurde für ein Netzwerk entwickelt, in dem keine Annahmen über Nachrichtenlieferzeiten gemacht werden können. Keine Zeitbeschränkungen, keine Synchronitätsannahmen. Das ist das adversariellste Szenario – und auch das realistischste für ein globales Netzwerk, in dem die Bedingungen von einem Validator zum nächsten stark variieren.

Seine Kernidee: Sobald der DAG von Narwhal aufgebaut ist, wird Konsens ohne zusätzliche Kommunikation erreicht. Jeder Validator wendet denselben deterministischen Algorithmus auf seine lokale Sicht des DAG an und gelangt zur gleichen Reihenfolge wie jeder andere Validator. Keine Abstimmungsrunden, keine explizite Koordination. Die Reihenfolge wird aus der Referenzstruktur selbst abgeleitet, indem Ankerpunkte identifiziert werden, die als Commit-Markierungen fungieren.

Die Benchmarks des Originalpapers, gemessen über 20 Validatoren, ergaben einen Durchsatz von rund 160.000 Transaktionen pro Sekunde bei einer Latenz von etwa 3 Sekunden. Zu diesem Zeitpunkt war das den klassischen Systemen überlegen.

Zwei Probleme blieben bestehen. Erstens die Latenz: 3 Sekunden sind für viele Anwendungsfälle handhabbar, aber ein K.o.-Kriterium für den Handel oder Echtzeit-Gaming. Zweitens die Fairness. In einem rein asynchronen Umfeld sahen besser vernetzte Validatoren ihre Transaktionen häufiger einbezogen als andere – ein strukturelles Ungleichgewicht, das die schnellsten Nodes begünstigte.

Tusk lebte größtenteils in der Forschung und im Testnetzwerk. Als Suis Mainnet 2023 startete, war Bullshark bereits in Betrieb.

Bullshark: Partielle Synchronität

Bullsharks konzeptueller Sprung beruht auf einer einzigen Annahme: Meistens verhält sich das Netzwerk normal. Anstatt immer auf das Schlimmste vorbereitet zu sein, nutzt das Protokoll Zeiträume, in denen Nachrichten innerhalb vertretbarer Verzögerungen ankommen. Dies ist das partiell synchrone Modell: Zeitbeschränkungen werden unter normalen Bedingungen angenommen; asynchrone Robustheit greift ein, wenn das Netzwerk sich verschlechtert.

Aus dieser Annahme folgt Bullsharks echter schneller Pfad – nicht zu verwechseln mit der oben erwähnten Unterscheidung zwischen eigenen und gemeinsamen Objekten. Während synchroner Perioden kann das Protokoll schneller committen, ohne so viele Runden wie im degradierten Modus abzuwarten. Es ist eine Latenz-Abkürzung, die von der Netzwerkgesundheit abhängt.

Bullshark hat auch das Fairness-Problem behoben, das Tusk ungelöst hinterließ, durch schwache Links. Diese Links erlauben es einem vorübergehend langsamen Validator, in den finalen Konsens einbezogen zu werden, selbst wenn schnellere Validatoren ihn noch nicht referenziert haben. Kein ehrlicher Validator wird aufgrund einer schlechten Verbindung ausgeschlossen. Das Protokoll verfeinerte auch die Ankerauswahl und die Speicherbereinigung, was es ermöglichte, die Last über längere Zeiträume aufrechtzuerhalten.

Der Preis: größere Komplexität. Schwache Links und Netzwerkanpassung führen zu Randfällen und Rechenaufwand. Das Paper berichtet von 125.000 TPS bei 2 Sekunden Latenz über 50 Parteien – auf dem Papier niedriger als Tusk, aber der Vergleich ist irreführend: Tusk wurde über 20 Validatoren gemessen, und der Durchsatz sinkt mechanisch, wenn das Netzwerk wächst. Die beiden Zahlen sind nicht direkt vergleichbar. Die Latenz blieb derweil im Bereich einer Sekunde – immer noch zu langsam für die anspruchsvollsten Anwendungen.

Für Sui hatte der Übergang einen Hauptwert: den Nachweis, dass das Netzwerk seinen Konsens ohne Unterbrechung ändern kann. Ein bedeutendes Vertrauenssignal für Entwickler, die darauf aufbauen.

Mysticeti: Abschaffung der expliziten Zertifizierung

Mysticeti erweitert Bullshark nicht – es verändert die zugrunde liegende Logik. Sowohl Tusk als auch Bullshark stützen sich auf einen zertifizierten DAG: Jeder Block muss von einem Quorum von Validatoren signiert werden, bevor er als verfügbar gilt. Diese Zertifizierung ist kostspielig – in zu produzierenden und zu verifizierenden Signaturen sowie in Netzwerk-Roundtrips. Das war der Engpass, den beide vorherigen Generationen teilten.

Mysticeti entfernt diesen Schritt vollständig. Es arbeitet auf einem nicht zertifizierten DAG: Validatoren signieren und verbreiten ihre Blöcke, und das war's. Über Übereinstimmung wird nicht mehr abgestimmt; sie wird abgeleitet. Wenn ein Validator einen Block eines anderen in seiner eigenen Ausgabe referenziert, stellt dieser Akt des Referenzierens eine implizite Zustimmung dar. Konsens wird aus dem Referenzierungsverhalten abgeleitet, ohne dedizierte Abstimmungsnachrichten.

Die Ergebnisse zeigen sich in zwei Dimensionen. Bei der Latenz committet Mysticeti in drei Nachrichtenrunden – dem theoretischen Minimum, vergleichbar mit praktischem BFT. Bei den Ressourcen reduziert die Eliminierung von Tausenden von Signaturen pro Runde die CPU-Last erheblich: rund 40 % weniger in der Produktion (von ~48 % auf ~29 % über eingesetzte Validatoren). Das Protokoll führt auch mehrere Leader pro Runde parallel aus, was die Median- und Tail-Latenzen senkt, und es absorbiert die Nichtverfügbarkeit von Leadern ohne Blockierung.

Eine Variante, Mysticeti-FPC, fügt einen schnellen Commit-Pfad für Asset-Transfers hinzu. Ihr Unterscheidungsmerkmal ist das direkte Einweben dieser Transaktionen in den DAG, anstatt sie separat zu behandeln, was Signaturen und Nachrichten spart. Hier lebt der echte schnelle Commit-Pfad, der in die Struktur eingebettet ist – nicht in Bullshark.

Die Zahlen, gemessen in einer kontrollierten Umgebung: 300.000 TPS mit 10 Nodes und 400.000 TPS mit 50 Nodes, bevor die Latenz eine Sekunde überschreitet. Unter anhaltender Last landen Commits bei etwa 0,5 Sekunden bei 200.000 TPS. In denselben Tests erreichen andere führende Protokolle weniger als 150.000 TPS mit Latenzen ab etwa 2 Sekunden.

Dann gibt es die viel zitierte „80 % Latenzreduzierung gegenüber Bullshark" (von ~1,9 s auf ~400 ms). Die Zahl ist korrekt, aber es handelt sich um einen Best-Case-Vergleich: Er stellt Bullshark unter degradierten Bedingungen Mysticeti unter optimalen gegenüber. Unter typischer Shared-Object-Last ist der Gewinn bescheidener, obwohl keine öffentliche Messung eine genaue Zahl festlegt. Auch erwähnenswert: Die Zahlen von 200.000–400.000 TPS stammen aus kontrollierten Benchmarks. Im Mainnet, unter realen Bedingungen, ist der beobachtete Durchsatz weit niedriger.

Was der Verlauf zeigt

Wenn man die drei Generationen nebeneinanderstellt, ist die Entwicklung klar – solange die Zahlen im Kontext gelesen werden.

Der Durchsatz steigt von ~160.000 TPS (Tusk, 20 Validatoren) auf 125.000 TPS (Bullshark, 50 Parteien) und dann auf 300.000–400.000 TPS je nach Konfiguration (Mysticeti). Die Node-Anzahlen unterscheiden sich, daher sind diese Werte nicht Punkt für Punkt vergleichbar: Sie geben eine Größenordnung an, keine strenge Rangfolge. Die Latenz hingegen sinkt eindeutig: von 3 Sekunden auf etwa 0,5 Sekunden, mit ~2 Sekunden für Bullshark als Zwischenschritt. Auf der Kommunikationsseite geht die Entwicklung von null Overhead, sobald der DAG aufgebaut ist (aber mit teurer Zertifizierung vorgelagert), zu impliziter Zertifizierung, die den Großteil des Abstimmungsverkehrs eliminiert.

Der eigentliche Wendepunkt liegt nicht zwischen Tusk und Bullshark – beide gehören zur gleichen Familie: zertifizierter DAG, explizite Zertifizierung, inkrementelle Optimierungen. Der Bruch liegt zwischen Bullshark und Mysticeti, mit der Aufgabe der Zertifizierung. Tusk und Bullshark optimierten einen Schritt; Mysticeti eliminierte ihn.

Ein Punkt, der betont werden sollte: Über alle drei Protokolle hinweg hat sich Narwhal kaum verändert. Alle Innovationen konzentrierten sich auf die Ordnungsschicht, ohne die Datenweitergabe zu destabilisieren. Diese Trennung der Verantwortlichkeiten ermöglichte es, diese Ersetzungen ohne Serviceunterbrechung durchzuführen – die Art von architektonischer Entscheidung, die sich nicht sofort auszahlt, aber am Ende alles verändert.

Mysticeti ist wahrscheinlich nicht das letzte Wort. Suis Ansatz besteht genau darin, eine Komponente zu ersetzen, wenn eine bessere auftaucht, ohne den Rest anzutasten. Wenn eine vierte Generation kommt, wird sie höchstwahrscheinlich in dasselbe Narwhal eingebunden.

Quellen

• 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

Suis Konsens-Evolution: Von Tusk zu Mysticeti wurde ursprünglich in Coinmonks auf Medium veröffentlicht, wo Menschen das Gespräch fortsetzen, indem sie diese Geschichte hervorheben und darauf reagieren.