Cardano Node 11.1.3 korrigiert IPv4 Dekodierung

Cardano Node 11.1.3 wurde am 29. September veröffentlicht und korrigiert, wie die Software im Ledger gespeicherte IPv4 Adressen ausliest. Das Update folgt auf eine frühere vorrangige Upgrade Mitteilung von Intersect für Stake Pool Betreiber und andere Organisationen, die Cardano Infrastruktur betreiben.

Wie die IPv4 Korrektur funktioniert

Version 11.1.2 hat unbeabsichtigt die zum Dekodieren von IPv4 Adressen verwendete Byte Reihenfolge verändert. Die jüngste Veröffentlichung stellt die vor der 11.1.x Reihe verwendete standardisierte Netzwerk Byte Reihenfolge wieder her. Die Korrektur ist über Version 1.9.0.1 der Bibliothek cardano-ledger-binary enthalten.

Eine IPv4 Adresse besteht aus vier Bytes, deren Reihenfolge bestimmt, wie die Adresse interpretiert wird. Auf Cardano erscheinen diese Adressen in den Relay Einträgen von Stake Pools. Relays tauschen Blöcke und Transaktionen mit anderen Knoten aus, daher ist eine genaue Interpretation ihrer Adressdaten für die Netzwerkinfrastruktur relevant.

Das Changelog der Veröffentlichung ordnet die Korrektur der Ledger Komponente zu und führt keine Änderungen an den Komponenten Network oder Consensus auf.

Welche Cardano Operatoren betroffen sind

Die Empfehlung von Intersect richtet sich an Stake Pool Betreiber und andere Node Betreiber. Die frühere Upgrade Anleitung umfasste Infrastruktur auf Mainnet, Preprod und Preview.

Cardano Node verarbeitet und validiert Transaktionen, einschließlich ADA Überweisungen, und unterstützt die Blockproduktion durch Stake Pools. Betreiber warten und aktualisieren diese Infrastruktur. Nutzer, die ADA an einen Pool delegieren, verlassen sich darauf, dass dessen Betreiber die Knoten des Pools verwaltet.

Die IPv4 Korrektur adressiert ausdrücklich ein in 11.1.2 eingeführtes Verhalten. Die weiter gefasste Empfehlung, mindestens diese Version zu betreiben, folgt auf ein früheres Problem, das im Preprod Testnet identifiziert wurde.

Die Upgrade Empfehlung von Intersect

Betreibern, die Versionen älter als 11.1.2 einsetzen, wird geraten, direkt auf 11.1.3 zu wechseln. Wer bereits 11.1.2 nutzt, erfüllt das von Intersect genannte Minimum, während 11.1.3 die IPv4 Korrektur hinzufügt. Die Ankündigung nennt keine Frist für den Wechsel zwischen diesen beiden Releases.

Intersect bestätigt, dass kein Ledger Replay erforderlich ist. Das bedeutet, Betreiber müssen den Ledger Zustand im Rahmen des Updates nicht aus historischen Blöcken neu berechnen.

Für Betreiber, die von älteren Releases upgraden, bleiben die in der 11.1 Reihe eingeführten Migrationsanforderungen relevant. Dazu gehören die Entfernung des LMDB Speicher Backends und des Legacy Tracing Systems. Betreiber, die weiterhin LMDB verwenden, müssen das Speicher Backend wechseln, während diejenigen, die auf Legacy Tracing setzen, ihr Monitoring Setup migrieren müssen.