Mit Starfish hat IOTA einen neuen Konsensmechanismus im Mainnet aktiviert. Die Mainnet-Version v1.21.1 führte Protokollversion 24 ein und schaltete Starfish im IOTA-Mainnet frei. In einem technischen Beitrag der IOTA Foundation ordnet Sebastian Mueller aus dem Research-Team den Schritt nicht nur als Performance-Update ein, sondern als grundlegende Änderung daran, wie Informationen im Netzwerk verteilt, bestätigt und für Konsens nutzbar gemacht werden.
Starfish bringt IOTAs Konsens ins Mainnet
Starfish adressiert einen Bereich, der in DAG-basierten BFT-Protokollen oft als Infrastrukturfrage behandelt wird: die Verbreitung von Informationen. Mueller schreibt: „Konsens wird üblicherweise als Einigungsproblem beschrieben. Eine Gruppe von Validatoren muss sich auf eine Historie einigen, auch wenn Nachrichten verzögert werden und einige Teilnehmer byzantinisch handeln können.“ Diese Beschreibung sei korrekt, verdecke aber eine praktische Grenze: Ein Validator könne nicht über einen Block abstimmen, den er nicht gesehen habe.
Der Kern der Änderung liegt darin, Dissemination nicht als externe Broadcast-Schicht zu behandeln, sondern in das Konsensdesign selbst zu integrieren. Mueller formuliert es so: „Unter dem Einigungsproblem liegt also ein Synchronisationsproblem. Wie erreichen die richtigen Informationen die richtigen Nodes schnell genug?“ Gerade bei DAGs sei das sichtbar, weil jeder neue Block auf frühere Blöcke verweist und damit abbildet, was ein Validator bereits kennt.
Technisch trennt Starfish Metadaten vom Payload. Header tragen die für den Konsens relevanten Informationen wie Referenzen, Votes, Acknowledgments, Timing und Commitments, während Transaktionsdaten separat behandelt werden. Für diese Daten nutzt Starfish Reed-Solomon-Encoding: Der Payload eines Blocks wird in Fragmente aufgeteilt, eines pro Validator, mit genügend Redundanz, damit „beliebige f+1 gültige Fragmente“ zur Rekonstruktion reichen. Die Verfügbarkeitsbestätigung erfolgt über ein Data Availability Certificate, kurz DAC, das sich aus 2f+1 Acknowledgments in der kausalen Historie eines später bestätigten Blocks ergibt.
Warum IOTA bei Starfish auf Push statt Pull setzt
Der zentrale Designwechsel betrifft die Frage, ob Validatoren fehlende Daten erst anfordern oder relevante Informationen proaktiv weiterleiten. Mueller beschreibt den klassischen Zielkonflikt klar: „Pull ist schlank, aber spät; Push ist schnell, aber schwer.“ Bei Pull entstehe zusätzliche Latenz, weil jeder fehlende Block eine weitere Request-Response-Runde auslöse. Unter Last könne sich das Problem verschärfen, weil langsamere Validatoren mehr Anfragen stellen und schnellere Validatoren mehr Bandbreite für Antworten verbrauchen.
Starfish setzt deshalb auf einen strukturierten Push-Ansatz. Validatoren schieben nicht naiv vollständige Blöcke an alle anderen Teilnehmer, sondern vor allem die leichten Header sowie kodierte Payload-Fragmente. Die ersten Mainnet-Metriken zeigen nach Angaben der IOTA Foundation, dass ausgehende Requests nach Starfish um ungefähr eine Größenordnung zurückgingen. Gleichzeitig nutzte Starfish im betrachteten Zeitraum etwa doppelt so viel Bandbreite wie Mysticeti, was der Beitrag als bewussten Vorabaufwand beschreibt, um spätere Recovery-Kosten zu vermeiden.
Auch beim Pacemaker verändert Starfish das Verhalten des Netzwerks. Mueller fasst die Intuition knapp zusammen: „Nichts schreitet leer voran. Eine Partei muss ihren eigenen Block erstellen, bevor sie in die nächste Runde wechseln kann.“ Dadurch sollen Validatoren nicht in spätere Runden driften, ohne selbst jene Blöcke beizutragen, die später als Votes und Zertifikate dienen. In den gezeigten Metriken sank die Varianz der Akzeptanzrate deutlich, und Validatoren erholten sich schneller.
Bei der Performance legt der Beitrag den Schwerpunkt weniger auf Spitzendurchsatz als auf Varianz und Tail Latency. Mueller schreibt: „Die wichtigere Produktionsfrage betrifft gewöhnlich die Varianz. Wie breit ist die Latenzverteilung? Wie oft landen Commits im Tail?“ Im Vergleich zu Mysticeti verbesserte sich insbesondere die p99-Commit-Latenz von rund 486 Millisekunden auf etwa 312 Millisekunden. Bei Transaktions-Commits stiegen Median und p90 erwartungsgemäß leicht, während p99 zurückging.
Für IOTA ist Starfish damit nicht nur ein weiterer Konsensmechanismus, sondern eine Rückkehr zu einer älteren Designintuition in moderner BFT-Form. Der ursprüngliche Tangle beruhte auf der Idee, dass Teilnahme auch bedeutet, dem Ledger beim Wachsen zu helfen. Mueller zieht diese Linie ausdrücklich: „Die ehrliche Bewegung besteht darin, dem Netzwerk beim Fortschritt zu helfen. Starfish gibt diesem Instinkt eine byzantinisch fehlertolerante Form.“
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.