Ein frisch eingereichter Bug-Report zeigt, dass die v3.2.0‑Software des XRP Ledgers einen Validator-Schlüssel protokolliert, während sie tatsächlich einen anderen ausführt, während rund 30 % der Nodes den umbenannten Server einsetzen.
Wichtige Punkte:
- Ein Node-Betreiber meldete, dass v3.2.0 den neuen Schlüssel eines migrierten Validators im Log anzeigt, während der Server noch den alten nutzt.
- Der Fehler tritt unter Ubuntu 22.04 auf, wenn ein bestehendes Validator-Token zu einem laufenden RPC-Node hinzugefügt wird.
- Die Adoption des Upgrades liegt bei rund 30 %, die meisten Betreiber bleiben auf dem vorherigen Build.
XRP-Ledger-Bug legt Schlüsselinkonsistenz offen
Der Defekt, der im Issue #7581 im GitHub-Tracker des Projekts eingereicht wurde, tritt auf, nachdem ein Betreiber einen bestehenden Validator auf einen bereits laufenden RPC-Node migriert und dann den Dienst neu startet. Das Service-Log meldet die neue Identität des migrierten Validators, während der server_info‑Endpunkt weiterhin den älteren Schlüssel zurückgibt, der in der lokalen wallet.db‑Datei liegt. Die beiden Einträge stimmen nicht mehr überein.
Die Reproduktion der Aufspaltung erfordert nur wenig Aufwand. Laut Betreiber löst das Hinzufügen eines bestehenden Validator-Tokens zu einem aktiven Node und ein anschließender Neustart des Servers den Fehler unter Ubuntu 22.04 aus – eine Abfolge, die bei routinemäßigen Migrationen üblich ist.
Auch lesen: Warnt der Anthropic-Perp-Ausverkauf vor Pre-IPO-Krypto-Wetten?
Validator-Identität verankert den Netzwerk-Konsens
Die Validator-Identität steht im Zentrum des Konsensmechanismus des XRP Ledgers für jede neue Ledger-Version. Die Vorschläge eines Nodes zählen nur, wenn andere Server seinem Schlüssel über ihre Unique Node Lists vertrauen. Eine veraltete oder inkonsistente Identität kann daher alle verwirren, die die Maschine überprüfen. Ein verwirrendes Log kann dieses Vertrauen verlangsamen.
Bisher hat die Inkonsistenz keinen Ausfall verursacht. Dennoch verlängert sie eine Serie von Defekten, die Entwickler seit dem Mid-Month‑Release markiert haben – von Sync‑Fehlern bis zu einem Absturz des Konfigurationsparsers.
Der Melder schlug einen Fix vor und regte an, dass die Service-Logs den Schlüssel ausgeben, den der Server tatsächlich verwendet, oder abgeleiteten und aktiven Schlüssel gemeinsam anzeigen. Bislang wurde dem Report noch kein Maintainer zugewiesen. Mehrere frühere Meldungen wurden bereits als Bugs bestätigt und für eine Prüfung eingeplant, während andere offen bleiben, während Beitragende sie bewerten.
Adoption hinkt hinterher, während über Amendment weiter abgestimmt wird
Die Nutzung des Releases bleibt verhalten. Etwa 30 % der Nodes laufen inzwischen mit Version 3.2.0, während die meisten Betreiber laut öffentlichen Netzwerkdaten weiter auf dem vorherigen 3.1.3‑Build bleiben.
Der Rollout begann am 15. Juni, als das Update die Kernsoftware von rippled in xrpld umbenannte und Speichereinsparungen von 30 % bis 40 % in Aussicht stellte. Seither berichten Betreiber von Sync‑Unterbrechungen, Relay‑Fehlberechnungen und nun dem Schlüssel-Mismatch in der neuen Version – ein Patch steht bislang aus. Nachzügler riskieren zudem einen durch ein Amendment blockierten Zustand, sobald Validatoren fixCleanup3_2_0 ratifizieren, die Bereinigungsänderung, die Ripple in der laufenden Abstimmung bereits unterstützt hat.
Als Nächstes lesen: Mane City Mobile erscheint in über 100 Ländern auf iOS und Android