kryptorevolution.de
$IOTA hat die Node-Software v1.28.3 veröffentlicht und führt damit Protokollversion 31 ein. Das Update behebt einen potenziell folgenschweren Fehler bei der Auswahl des Validator-Komitees. Zudem verbessert das Update die Skalierbarkeit sowie den Ressourcenverbrauch von Full Nodes.
$IOTA Protokollversion 31 behebt Validator-Fehler
Protokollversion 31 kann im $IOTA-Mainnet frühestens am 30. Juli 2026 um 07:41 Uhr UTC aktiviert werden. Der Zeitpunkt entspricht dem Beginn von Epoche 451.
Im Mittelpunkt steht die Behebung eines kritischen Fehlers bei der Zusammenstellung des Validator-Komitees. Unter bestimmten Bedingungen konnte die Liste der zugelassenen Validatoren vollständig geleert werden. Dies konnte etwa dann passieren, wenn Validatoren entfernt wurden oder Teilnehmer aufgrund eines zu geringen Stakes aus dem Kreis der Kandidaten ausgeschieden sind.
Piotr Macek, Leiter des Entwicklungsteams bei der $IOTA Stiftung, beschreibt das Problem auf GitHub wie folgt:
„Die Komiteeauswahl ordnet die Menge der zugelassenen Validatoren in jeder Epoche auf Grundlage ausstehender Entfernungen und der Abgänge von Validatoren mit geringem Stake neu zu. Bleibt diese Menge anschließend leer, haben die nachgelagerten Stake-Berechnungen keine Mitglieder mehr, mit denen sie arbeiten können, und der Epochenwechsel wird abgebrochen. Die Änderung macht die Komiteeauswahl gegenüber einer leeren Menge robust, indem sie in diesem Fall auf alle derzeit aktiven Validatoren zurückgreift.“
Stabilere Checkpoint-Rate für höheren Durchsatz
Eine weitere Änderung betrifft die Erstellung von Checkpoints. Mit diesen wird der bestätigte Zustand des Netzwerks fortlaufend dokumentiert. Das Update führt einen neuen Protokollparameter ein, welcher das minimale Checkpoint-Intervall über ein gleitendes Zeitfenster optimiert.
Nikita Polianskii, Forschungsingenieur bei der $IOTA Stiftung, erklärte via GitHub, dass die Checkpoint-Leistung zuvor trotz einer höheren Blockrate zurückging:
„Die Checkpoint-Erstellungsrate ging zurück, nachdem die gleitende Blockerstellung die Block- und Commit-Rate erhöht hatte. Die Blockrate stieg bis zur Obergrenze von 20 Blöcken pro Sekunde, während die Checkpoint-Rate von rund 4,85 auf etwa 4,25 Checkpoints pro Sekunde fiel – besonders deutlich bei großen Komitees. Diese Änderung behält die Obergrenze von ungefähr fünf Checkpoints pro Sekunde bei und stellt die Rate unter den gelockerten Regeln wieder her.“
In lokalen Tests mit mehreren Validatoren stieg die dauerhaft erzielte Checkpoint-Rate demnach von etwa 4,2 auf 4,95 pro Sekunde. Der neue Parameter ist zunächst nur im Devnet aktiviert.
$IOTA begrenzt das Datenbankwachstum
Für Node-Betreiber bringt v1.28.3 zudem Änderungen beim sogenannten Pruning. Nicht mehr benötigte Daten werden nun auf Grundlage von Checkpoints und der On-Chain-Zeitstempel entfernt, statt sich an der lokalen Uhr oder einem separaten Hintergrundtimer zu orientieren.
Falls das Pruning hinter der Ausführung zurückbleibt, kann der Node die Verarbeitung vorübergehend drosseln. Dadurch soll verhindert werden, dass die Datenbank während einer nachholenden Synchronisierung unkontrolliert wächst oder gebündelte Löschvorgänge die Ausführung blockieren.
Zudem ersetzt $IOTA die bisherige Speicherung vollständiger Checkpoint-Inhalte auf der Festplatte durch einen begrenzten Arbeitsspeicher-Cache. Die Standardgröße beträgt 1.024 Megabyte und kann von Node-Betreibern angepasst oder deaktiviert werden.
Full Nodes liefern alle Transaktionsdaten
Über die gRPC-Schnittstelle können Full Nodes künftig Veränderungen von Guthaben und Objekten auf Transaktionsebene ableiten und ausgeben. Anwendungen, Indexer und Analyseplattformen erhalten dadurch weiterhin einen vollständigen und direkteren Zugriff auf alle Transaktionsdaten.
Insgesamt ist v1.28.3 damit kein grundlegender Umbau des $IOTA-Protokolls. Die Änderungen sind jedoch wichtig, um zentrale Komponenten des laufenden Netzwerkbetriebs zu stärken.