IOTA hat die Protokollversion 38 mit der Mainnet-Version v1.34.1 implementiert und damit neue Sicherheitsprüfungen für Transaktionen und Konten eingeführt.

Die Softwareversion v1.34.1 wurde am 21. Oktober veröffentlicht. Protokoll 38 konnte frühestens am 22. Oktober um 09:42 Uhr deutscher Zeit mit Epoche 535 aktiviert werden. Unsere Abfragen der offiziellen Mainnet-Schnittstelle und des Ankr-Endpunkts bestätigen inzwischen die Protokollversion 38 in Epoche 535.

Das bringt IOTA-Protokoll 38

IOTA prüft mit der neuen Version bestimmte Strukturfehler bereits, bevor Validatoren eine Transaktion signieren. Betroffen sind Programmable Transaction Blocks, kurz PTBs, die mehrere Verarbeitungsschritte in einer Transaktion bündeln.

Tipp der Redaktion: IOTA bekommt neuen Dateispeicher: Walrus-Technik, aber kein neuer Token

Verweist ein solcher Ablauf auf eine nicht vorhandene Eingabe oder auf das Ergebnis eines noch nicht ausgeführten Schritts, wird er frühzeitig zurückgewiesen. Bisher konnten diese Transaktionen zunächst angenommen werden und erst bei der Ausführung scheitern. Der Absender musste trotzdem Gas-Gebühren zahlen. Die neue Prüfung verhindert das für diese konkreten Fehler.

Eine weitere Änderung betrifft sogenannte Immutable Accounts, also unveränderliche Kontoobjekte. Seit Protokollversion 36 können solche Objekte eine Transaktion weder als Absender noch als Gebührenzahler authentifizieren. Trotzdem ließen sie sich weiterhin erstellen. Die Entwickler beschreiben den Fehler so:

„Das Framework ließ weiterhin jeden ein solches Konto erstellen. Das Ergebnis war ein Konto, das sich niemals authentifizieren konnte.“

An diese Konten gesendete Vermögenswerte waren damit verloren. Protokoll 38 bricht die Erstellung nun ab und verhindert dadurch, dass weitere solche Konten entstehen.

Ein weiteres Problem wurde beseitigt: Beim Abruf bestätigter Konsensdaten konnten bislang wenige Netzwerkpartner sämtliche verfügbaren Abrufplätze belegen. Andere Nodes mussten dann warten.

Die überarbeitete Verteilung sichert jedem Netzwerkpartner einen ersten parallelen Abruf zu. Zusätzliche Abrufe bleiben begrenzt. Neue Fristen sorgen außerdem dafür, dass unvollständige Anfragen oder nicht abgenommene Antworten Ressourcen nicht unbegrenzt festhalten.

Zudem benötigen Datensicherungen keine separate Datenbankkopie mehr

Full Nodes, die Zustandssicherungen veröffentlichen, lesen dafür künftig einen konsistenten Stand der laufenden Datenbank aus. Die bisherige separate Datenbankkopie entfällt.

Lesetipp: IOTA und TWIN: Private Firma übernimmt britischen Pilotbetrieb

Für neu veröffentlichte Move-Systempakete führt Protokoll 38 eine eigene Größenobergrenze von 200 KiB ein. Für Nutzerpakete bleiben es 100 KiB. Das IOTA-Framework lag laut Entwicklern bereits nahe an dieser bisherigen Grenze. Die Anpassung schafft damit Raum für die Weiterentwicklung der eingebauten Netzwerkfunktionen.

Bei Indexern behebt IOTA einen Fehler, durch den die Auswertung nach einer Wiederherstellung oder Datenbereinigung stehen bleiben konnte. Sie setzt nun beim ersten verfügbaren Datenstand fort.

Für IOTA-Besitzer ergibt sich aus den Release-Notes keine Aufforderung zu einer Token-Migration oder Wallet-Umstellung. Der Nutzen liegt vor allem in zusätzlichen Schutzprüfungen und einem zuverlässigeren Betrieb der Infrastruktur.