IOTA hat am 24. September Protocol 36 im Mainnet aktiviert. Das Upgrade soll Transaktionen unter günstigen Bedingungen schneller bestätigen und bringt zugleich Änderungen für Smart Contracts, Validatoren und Betreiber der Dateninfrastruktur.

Der IOTA-Explorer zeigte in Epoche 506 noch Protokoll 34, in Epoche 507 stellte das Mainnet auf Version 36 um. Änderungen, die in Version 35 enthalten waren, kommen damit ebenfalls ins Mainnet.

IOTA wird durch StarfishSpeed schneller

Die wichtigste Neuerung heißt StarfishSpeed. Im bisherigen Starfish-Verfahren wartet eine Transaktion unter Umständen eine zusätzliche Konsensrunde, bis ausreichend bestätigt ist, dass ihre Daten bei den Validatoren verfügbar sind.

Tipp der Redaktion: IOTA: USDT0 auf dem Mainnet angekommen – Perpetual-Börse in Vorbereitung

Künftig können Validatoren diese Verfügbarkeit bereits mit ihrer Abstimmung über den Leader bestätigen. Liegen genügend Stimmen vor, kann Starfish die Transaktionsdaten früher in die bestätigte Reihenfolge aufnehmen. Der technische Vorschlag erklärt dazu:

„Unter günstigen Bedingungen verfügen der Leader und die meisten ehrlichen Validatoren bereits über die Daten, die der Leader bestätigt. Die zusätzliche Wartezeit erhöht dann lediglich die Latenz.“

Fehlen die erforderlichen Bestätigungen, nutzt das Netzwerk weiterhin den alten Weg. In einem dokumentierten Test mit 19 Validatoren sank die mittlere Bestätigungszeit für Transaktionen von etwa 206 auf 174 Millisekunden.

Die Leader-Auswahl reagiert auf Leistung

Zusätzlich ändert sich, welche Validatoren bevorzugt als Leader zum Zug kommen. Das Netzwerk bewertet ihre Leistung nun anhand eines gleitenden Fensters jüngerer Konsensereignisse. Besonders schwach abschneidende Validatoren werden über einen Leistungswert erkannt und können in der Leader-Reihenfolge ersetzt werden.

Das ist kein Ausschluss aus dem Validator-Komitee: Die Änderung betrifft ihre Rolle bei der Organisation des Konsenses. StarfishSpeed lief bereits auf Devnet und Testnet, ebenso war die neue Leader-Auswahl dort vor dem Mainnet-Start aktiv.

Neue Möglichkeiten für Move-Anwendungen

Für Entwickler werden sogenannte View Functions im Mainnet nutzbar. Das sind ausdrücklich als lesend gekennzeichnete Funktionen in Move-Verträgen: Eine Anwendung kann damit Informationen aus einem Vertrag abfragen, ohne dessen gespeicherten Zustand zu verändern. Auch die Authentifizierung gesponserter Transaktionen ändert sich. Bei ihnen übernimmt ein anderer Account die Transaktionskosten.

Lesetipp: IOTA-Adoption erreicht China: Orobo gewinnt wichtigen Vorentscheid

Die Move-basierte Prüfung dieses Sponsors war im Mainnet mit Protokoll 34 deaktiviert worden und wird nun wieder aktiviert. Zudem prüft das Netzwerk Authentifizierungsfunktionen von Absender und Sponsor wieder vor dem Konsens.

P-COOL weiterhin nicht live

Die Versionshinweise nennen außerdem neue Prüflimits von 2,2 Millionen Meter-Ticks für veröffentlichte Move-Pakete. Sie betreffen vor allem P-COOL, einen anderen Ablauf bei der Verarbeitung von Transaktionen.

Laut IOTA greift diese Änderung dort, wo P-COOL aktiv ist, derzeit auf dem Devnet. Die Erwähnung in der Mainnet-Software bedeutet daher, dass P-COOL auf dem Mainnet weiterhin deaktiviert bleibt.

Knoten und Indexer erhalten Schutzmechanismen

Bei der Kommunikation zwischen Knoten sinkt die Obergrenze für Peer-Anfragen von einem Gibibyte auf ein Mebibyte, für Antworten auf 128 Mebibyte. Inaktive Verbindungen sollen nach zehn statt 30 Sekunden erkannt werden.

Bei der Synchronisierung darf ein Knoten standardmäßig höchstens 100.000 Checkpoints weiter Daten laden, als er bereits verarbeitet hat. Das begrenzt den Speicherbedarf, wenn der Download schneller läuft als die Verarbeitung.

Für Indexer wurden historische Datenbankindizes neu angeordnet. In einem Test schrumpfte ihr Speicherbedarf um rund 60 Prozent.

Für gewöhnliche IOTA-Halter ergibt sich aus dem Upgrade aber kein Handlungsbedarf. Selbst die schnellere Transaktionsbestätigung dürfte Nutzern nicht wirklich auffallen.