Een recent ingediende bugmelding laat zien dat de XRP Ledger-software v3.2.0 één validatorsleutel logt terwijl een andere wordt gebruikt, terwijl ongeveer 30% van de nodes de hernoemde server heeft overgenomen.
Belangrijkste punten:
- Een node-operator meldde dat v3.2.0 de nieuwe sleutel van een gemigreerde validator logt terwijl de server nog steeds de oude draait.
- De fout verschijnt op Ubuntu 22.04 wanneer een bestaande validatortoken wordt toegevoegd aan een live RPC-node.
- De adoptie van de upgrade ligt rond de 30%, waarbij de meeste operators nog op de vorige build draaien.
XRP Ledger-bug legt sleutelmismatch bloot
De fout, ingediend als issue #7581 op de GitHub-tracker van het project, treedt op nadat een operator een bestaande validator migreert naar een al draaiende RPC-node en vervolgens de service opnieuw opstart. De servicelog meldt de nieuwe identiteit van de gemigreerde validator, terwijl de server_info-endpoint nog steeds de oudere sleutel teruggeeft die in het lokale bestand wallet.db staat. De twee registraties komen dan niet meer overeen.
Het reproduceren van deze splitsing kost weinig moeite. Volgens de operator triggert het probleem op Ubuntu 22.04 zodra een bestaande validatortoken aan een actieve node wordt toegevoegd en de server opnieuw wordt gestart – een volgorde die vaak voorkomt bij routinematige migraties.
Ook lezen: Is de verkoop van Anthropic perpetuals een waarschuwing voor pre-IPO-cryptobets?
Validatoridentiteit verankert netwerkconsensus
Validatoridentiteit staat centraal in de manier waarop de XRP Ledger het eens wordt over elk nieuw grootboek. De voorstellen van een node tellen alleen mee wanneer andere servers zijn sleutel vertrouwen via hun unieke nodelijsten, dus een verouderde of niet-overeenkomende identiteit kan iedereen in verwarring brengen die de machine controleert. Een verwarrende log kan dat vertrouwen vertragen.
Tot nu toe heeft de mismatch geen uitval veroorzaakt. Toch verlengt deze fout een reeks problemen die ontwikkelaars sinds de release midden in de maand hebben gesignaleerd, variërend van synchronisatiefouten tot een crash in de configuratieparser.
De melder stelde een oplossing voor en vroeg of de servicelogs de sleutel kunnen tonen die de server daadwerkelijk gebruikt, of zowel de afgeleide als de actieve sleutel samen kunnen weergeven. Er is nog geen maintainer aan de melding toegewezen. Een aantal eerdere meldingen zijn al bevestigd als bugs en in de wachtrij voor review geplaatst, terwijl andere open blijven terwijl contributors ze beoordelen.
Adoptie blijft achter terwijl amendementstemming doorgaat
De adoptie van de release blijft traag. Ongeveer 30% van de nodes draait nu versie 3.2.0, terwijl de meeste operators volgens openbare netwerkdata op de eerdere 3.1.3-build blijven.
De uitrol begon op 15 juni, toen de update de kernsoftware hernoemde van rippled naar xrpld en geheugensbesparingen van 30% tot 40% beloofde. Sindsdien hebben operators meldingen gedaan van sync-onderbrekingen, verkeerde relay-berekeningen en nu de sleutelmismatch in de nieuwe build, zonder dat tot nu toe een patch is uitgebracht. Achterblijvers riskeren bovendien een door een amendement geblokkeerde status zodra validators fixCleanup3_2_0 ratificeren, de opschoningswijziging die Ripple al ondersteunt in de lopende stemming.
Lees hierna: Mane City Mobile komt naar iOS en Android in 100+ landen