Im XRP-Ledger (XRPL) sorgt ein nahender Software-Deadline für Unruhe: Betreiber von Knoten (Nodes) und Infrastruktur diskutieren, ob das anstehende Update auf rippled v3.1.3 praktisch zu einer Netzwerkspaltung führen könnte. Hintergrund ist eine Protokoll-Änderung, die in wenigen Tagen aktiv werden soll und ältere Versionen vom Netz ausbremsen kann.
Update v3.1.3: Wer nicht aktualisiert, kann „rausfallen“
Ausgelöst wurde die Debatte durch Warnungen aus der Validator- und Betreiber-Szene. Der XRPL-Validator-Operator Vet schrieb, dass rippled v3.1.3 bereits seit über einer Woche verfügbar sei und zum Zeitpunkt seines Posts (18. Mai) rund 40% des Netzwerks aktualisiert hatten. Er warnte: Sobald die enthaltene „Fix“-Änderung aktiv wird, könnten Nodes ohne Update nicht mehr mit dem Netzwerk kommunizieren.
Kurz darauf meldete sich auch J. Ayo Akinyele, Head of Engineering bei RippleX, zu Wort. Er sprach von etwa 44% aktualisierten Systemen und rief Betreiber dazu auf, schnell nachzuziehen. Tenor: Es bleiben nur noch wenige Tage, bis die Änderung live geht.
Wichtig: Es geht dabei nicht nur um „nice to have“. Die Version 3.1.3 bringt das Amendment fixCleanup3_1_3 mit, ein Paket an Korrekturen, unter anderem für NFTs, Permissioned Domains, Vaults und das Lending-Protokoll. Laut XRPL.org ist die Standard-Stimme für dieses Amendment auf „Yes“ gesetzt, weil die Fixes als relevant gelten.
Hard Fork oder Sicherheitsmechanismus? Darum streiten sich die Lager
In sozialen Netzwerken entstand daraus schnell das Wort „Hard Fork“. Kritiker argumentierten: Wenn viele Nodes nicht rechtzeitig aktualisieren, könnten sie am Stichtag abgehängt werden und damit entstünde faktisch eine Abspaltung. Ein Nutzer formulierte es zugespitzt so, dass ein großer Teil des Netzwerks „wegforken“ würde und stellte die Frage, wer überhaupt festlegt, welche Version das „Mainnet“ ist.
Andere in der XRPL-Community widersprechen dem. Ihrer Ansicht nach ist das Ganze eher kein klassischer Hard Fork, sondern ein geplanter Mechanismus im XRPL, der „Amendment Blocking“ genannt wird. Im XRP Ledger werden Protokolländerungen über Validator-Abstimmungen aktiviert. Laut XRPL.org braucht ein Amendment dafür mehr als 80% Zustimmung von vertrauenswürdigen Validatoren über einen Zeitraum von zwei Wochen. Erst danach gilt die Änderung dauerhaft für zukünftige Ledger-Versionen.
Der Effekt für veraltete Server ist trotzdem spürbar: Systeme, die die neuen Regeln nicht kennen, können laut XRPL.org die Gültigkeit von Ledgers nicht mehr korrekt beurteilen. Solche Nodes können dann keine Transaktionen sinnvoll verarbeiten oder einreichen, nicht am Konsens teilnehmen und auch nicht über künftige Amendments abstimmen. Mit einem Update auf eine aktuelle rippled-Version lässt sich das wieder beheben.
Wie groß ist das Risiko wirklich? Infrastrukturbetreiber relativieren
Einige Betreiber sehen die Lage deutlich entspannter, als es die reinen Prozentzahlen nahelegen. Daniel Keller, CTO von Eminence, einer Infrastruktur-Firma mit Full-History-Node im XRPL, warnt davor, die Upgrade-Quote zu dramatisch zu lesen. Die entscheidende Frage sei nicht, wie viele Nodes insgesamt noch alt seien, sondern wie viele davon überhaupt relevant für den laufenden Betrieb sind. Ein Teil könne verlassen sein, andere würden schlicht ein paar Stunden später aktualisieren.
Seine Einschätzung: Das ist eher eine Frage von Wartung und Verantwortung. Wer Infrastruktur betreibt, müsse Updates einspielen. „Dezentral“ bedeute nicht, dass nicht gepflegte Systeme ewig mitgeschleppt werden. Ähnlich argumentierte auch ein weiterer Community-Kommentator: Das „Blocking“ sei im XRPL sogar ein Schutzmechanismus, damit alte Software neue Regeln nicht falsch interpretiert.
Zum Zeitpunkt der Berichterstattung lag der XRP-Kurs bei 1,38 US-Dollar.
