IOTA und Sui entwickeln sich im DAG-basierten BFT-Konsens sichtbar auseinander. Ausgangspunkt ist Mysticeti, ein Protokoll, das mit dem Verzicht auf klassische Zertifizierung erhebliche Latenzgewinne ermöglichte. Eine technische Research-Note von Kowei, Asia Ecosystem Lead der IOTA Foundation, zeichnet nun nach, warum Sui mit Mysticeti V2 und IOTA mit Starfish unterschiedliche Optimierungsziele verfolgen.
If you want to get deeper technical knowledge of our protocol, and specifically Starfish – @kowei1995 has got you covered with this excellent article. Have a read! https://t.co/wdTklasvvt
— IOTA (@iota) May 26, 2026
IOTA Starfish und Sui Mysticeti trennen sich
IOTA verwies auf X auf die Analyse von Kowei und empfahl sie als technische Vertiefung zu Starfish. Kowei fasst den Ausgangspunkt so zusammen: „Mysticeti v1 beruht auf einem mutigen Trade-off: Es gibt explizite Zertifizierung auf und lässt die DAG-Struktur selbst als virtuelles Zertifikat wirken. Seine direkte Regel kann Leader-Blöcke unter idealen Bedingungen in drei Nachrichtendelay entscheiden, während ein praktischeres Single-Leader-pro-Round-Szenario Mysticeti näher an 4δ bringt.“ Der Vorteil liegt in sehr niedriger Latenz; die Schwachstellen liegen bei Liveness, Datenverbreitung und Skalierung.
Die Trennung der Wege ist dabei keine Abkehr von einem gemeinsamen technischen Ursprung. In der Note heißt es: „Vor Starfish lief auch IOTA bereits mit Mysticeti. In IOTAs offizieller IIP-2-Proposal wird Starfish als verbessertes DAG-basiertes Konsensprotokoll auf Basis von Mysticeti beschrieben.“ Damit geht es weniger um zwei voneinander isolierte Designs als um zwei Antworten auf denselben Grundkonflikt: Was passiert, wenn Zertifikate aus dem Konsenskern entfernt werden, um schneller zu werden?
Sui setzt mit Mysticeti V2 dort an, wo die Research-Note die Integrationskosten außerhalb des Konsenskerns verortet. Der Text beschreibt die Stoßrichtung so: „Mysticeti v2 behandelt den Konsenskern als nahezu optimal und integriert Suis Pre-Consensus-Transaktionsvalidierung in den Konsens, um Systemintegration und Produktlatenz zu optimieren.“ Konkret ersetzt Sui den bisherigen Quorum Driver durch einen Transaction Driver, der Transaktionen an einen ausgewählten Validator sendet, deren Konsensposition erhält und vollständige Effekte von einem Quorum abruft. Die Note nennt als gemeldeten Effekt eine Latenzsenkung bei Full Nodes um rund 35 Prozent in Asien, von 1,00 auf 0,65 Sekunden, und um rund 25 Prozent in Europa, von 0,55 auf 0,40 Sekunden; ab Sui Node v1.60 seien V2 und Transaction Driver Standard.
Warum zwei DAG-Protokolle eigene Wege gehen
Der Kern der Divergenz liegt in der Diagnose. Kowei formuliert es zugespitzt: „Sui fokussiert die Integrationsredundanz; IOTA fokussiert die Robustheitslücken rund um Liveness, Dissemination und Metadaten.“ Mysticeti v1 entfernte Zertifizierung und gewann dadurch Zeit, gab aber Eigenschaften auf, die zertifizierte DAGs zuvor quasi mitlieferten: Schutz gegen widersprüchliche Blöcke, Verfügbarkeitsnachweise und robuste Datenverbreitung. Die Note nennt als Beispiel für Skalierungsdruck eine Starfish-Quantifizierung: Bei 120 Validatoren und 20 DAG-Runden pro Sekunde könne unkomprimierte Metadatenlast in 24 Stunden auf etwa 1 TB wachsen; im Worst Case könne die Metadatenbandbreite rund 10 Gbps erreichen.
Starfish geht deshalb nicht primär auf die Happy-Path-Latenz, sondern auf Verfügbarkeit und beweisbare Liveness. Die Note beschreibt den Mechanismus in mehreren Schritten: „Starfish trennt einen Block in einen kleinen Header und eine schwere Payload. Der Header enthält Referenzen, Stimmen, Bestätigungen und Commitments — also das, was der Konsens sofort braucht. Die Payload enthält die eigentlichen Transaktionsdaten.“ Zusätzlich nutzt Starfish Reed-Solomon-Erasure-Coding, verteilt Fragmente an Validatoren und rekonstruiert Payloads aus f+1 gültigen Fragmenten. Entscheidend ist die Data Availability Certificate-Logik: „Sobald solche Bestätigungen auf 2f+1 anwachsen und alle in der kausalen Historie eines später committed Blocks erreichbar sind, wird dieser spätere Block selbst zum Data Availability Certificate der früheren Payload.“
Der Preis dieses Ansatzes ist nicht null. Kowei schreibt: „Starfish ist kein kostenloses Mittagessen, aber der faire Vergleich ist nicht Mysticeti 3δ gegen Starfish [5δ, 7δ]. Mysticetis 3δ-Zahl ist die ideale direkte Entscheidungslatenz für Leader-Blöcke.“ Unter vergleichbaren sauberen Annahmen liege Mysticeti praktisch näher bei 4δ, Starfish bei etwa 5δ; realistischere Worst-Case-Annahmen könnten Mysticeti in Richtung 6δ und Starfish in Richtung 7δ bringen. Die Research-Note rahmt den Unterschied deshalb als Produkt- und Marktentscheidung: Sui optimiere für Consumer-, DeFi- und High-TPS-Anwendungen, während IOTA mit Starfish auf Enterprise-, regulierte sowie Handels- und Logistikinfrastruktur ziele, wo Vorhersagbarkeit und formale Garantien stärker gewichtet werden.
Die technische Abzweigung zwischen Sui Mysticeti V2 und IOTA Starfish ist damit kein einfacher Wettbewerb um „schneller“ oder „besser“. Sui reduziert Reibung um den Konsens herum und priorisiert Endnutzerlatenz im Normalfall. IOTA holt mit Starfish Verfügbarkeitszertifikate in günstigerer Form zurück in den Konsens und akzeptiert dafür einen Latenzaufschlag. Kowei fasst den Befund entsprechend nüchtern: „Die beiden Pfade sind keine Frage von richtig gegen falsch. Sie sind eine Spaltung der geschäftlichen These.“
KI-Transparenzhinweis: Dieser Artikel wurde mit Unterstützung eines KI-Systems auf Basis der angegebenen Quellen vorbereitet und vor der Veröffentlichung redaktionell durch einen menschlichen Editor geprüft, bearbeitet und freigegeben. Alle Zitate, Daten und Tatsachenbehauptungen sollen aus den genannten Quellen stammen; dennoch können Fehler nicht vollständig ausgeschlossen werden.