Die IOTA-Entwickler arbeiten an mehreren Verbesserungen für P-COOL, das die Transaktionsverarbeitung im Netzwerk effizienter machen soll. Am 10. November wurden Codeänderungen veröffentlicht, die Validatoren vor Überlastung schützen und den Rechenaufwand bei der Konsensverarbeitung reduzieren sollen.

Hintergrund sind interne Lasttests vom 5. November. Dabei zeigte sich, dass die Transaktionsprüfung nach dem Konsens zum Engpass wurde. In einem Testaufbau mit elf Validatoren erreichte das System eine Grenze von rund 1.100 Transaktionen pro Sekunde (TPS).

IOTA will Überlastung bei Validatoren verhindern

Eine der Änderungen betrifft die Aufnahme neuer Transaktionen. Entwickler Roman Overko beschreibt in Pull Request #13548 ein Problem, das insbesondere bei vielen gleichzeitig eingehenden Anfragen auftreten kann.

Tipp der Redaktion: IOTA im Gmail-Posteingang? DocuNotary will manipulierte Rechnungen erkennen

Bisher berücksichtigt die Überlastungsprüfung im P-COOL-Verfahren eine Transaktion erst dann vollständig, wenn mehrere Vorprüfungen abgeschlossen sind. Gehen währenddessen weitere Transaktionen ein, können diese denselben noch nicht aktualisierten Auslastungswert sehen.

Dadurch lassen Validatoren unter Umständen mehr Transaktionen zu, als ihre Warteschlange eigentlich aufnehmen kann. Overko erklärt zur vorgesehenen Änderung:

„Gleichzeitig eingehende Transaktionen werden gegenseitig berücksichtigt. Es werden nur so viele angenommen, wie das Limit erlaubt.“

Künftig soll jede Transaktion unmittelbar bei ihrer Annahme einen Platz in der Konsens-Warteschlange reservieren. Wird sie abgelehnt oder scheitert die Einreichung, wird dieser Platz wieder freigegeben.

Die Änderung betrifft ausschließlich die Validator-Software. Eine Anpassung der Protokollregeln ist dafür nicht erforderlich.

CPU-Last soll um 10 bis 15 Prozent sinken

Eine weitere Verbesserung stammt von Entwickler Filip Dulić. In Pull Request #13553 beschreibt er, wie wiederholte Datenbankabfragen bei der Transaktionsvalidierung vermieden werden sollen.

Bei P-COOL entfällt die vorherige Zertifizierung von Transaktionen. Konflikte um sogenannte Owned Objects werden stattdessen nach dem Konsens deterministisch aufgelöst.

Die IOTA-Entwickler stellten fest, dass innerhalb eines einzelnen Consensus-Commits häufig dieselben Daten mehrfach abgefragt werden. In einer Testarbeitslast mit rund 80 Transaktionen entfielen ungefähr 400 von insgesamt 1.360 Eingabelesezugriffen auf wiederholte Abfragen.

Dulić will deshalb bereits ermittelte Prüfergebnisse innerhalb eines Commits wiederverwenden. Anstatt dieselben Informationen erneut aus der Datenbank zu laden, greift der Validator auf zwischengespeicherte Ergebnisse zurück. Dulić schreibt:

„Der erwartete Gewinn liegt bei etwa zehn bis fünfzehn Prozent der CPU-Zeit des Consensus-Handlers. Das muss noch gemessen werden.“

Die Grundlage dieser Optimierungen liefern Messungen vom 5. November. Laut Pull Request #13551 entfielen 69 Prozent der CPU-Zeit des Consensus-Handlers auf das Einlesen und Prüfen von Transaktionseingaben. Allein 21 Prozent wurden für bestimmte Suchvorgänge in der RocksDB-Datenbank benötigt.

Lesetipp: IOTA-Projekt VeriPura erreicht nächsten Meilenstein im internationalen Handel

Bei 900 TPS stieg die Verarbeitungszeit pro Commit innerhalb von drei Minuten von etwa 28 auf 37 Millisekunden. Dulić schlägt deshalb einen Prefix-Bloom-Filter vor, mit dem die Datenbank Speicherbereiche überspringen kann, in denen das gesuchte Objekt nicht vorhanden ist.

Pull Request #13559 sieht zudem vor, Eingabedaten mehrerer Transaktionen parallel einzulesen. In einem weiteren Lasttest beanspruchten die Validatoren weniger als 30 Prozent ihrer verfügbaren CPU-Leistung.

Wichtig ist: Die Änderungen befinden sich weiterhin im Entwicklungs- und Prüfprozess. Mehrere Pull Requests sind dem Meilenstein v1.37.0 zugeordnet. Einen bestätigten Mainnet-Aktivierungstermin gibt es noch nicht.

P-COOL wird somit weiter getestet. Die IOTA Foundation hatte im letzten Quartalsbericht angekündigt, das Transaktionsverfahren im vierten Quartal verstärkt unter Last auf öffentlichen Netzwerken zu testen.