Een recent ingediende bugmelding laat zien dat de software van XRP Ledger v3.2.0 één validator-sleutel 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 de oude gebruikt.
- De fout verschijnt op Ubuntu 22.04 wanneer een bestaande validator-token wordt toegevoegd aan een live RPC-node.
- De adoptie van de upgrade ligt rond 30%, terwijl de meeste operators nog op de vorige build draaien.
XRP Ledger-bug legt sleutel-mismatch bloot
Het defect, ingediend als issue #7581 op de GitHub-tracker van het project, verschijnt nadat een operator een bestaande validator migreert naar een al draaiende RPC-node en vervolgens de service herstart. 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 wallet.db-bestand staat. De twee registraties komen niet langer overeen.
Het reproduceren van de splitsing kost weinig moeite. De operator zegt dat het toevoegen van een bestaande validator-token aan een actieve node en het herstarten van de server dit op Ubuntu 22.04 triggert, een volgorde die vaak voorkomt bij routinematige migraties.
Ook lezen: Is de Anthropic-perp-verkoop 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 wegen alleen mee wanneer andere servers zijn sleutel vertrouwen via hun unieke node-lijsten, 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 het een reeks defecten die ontwikkelaars sinds de release halverwege de maand hebben aangegeven, van synchronisatiefouten tot een crash in de configuratie-parser.
De melder stelde een oplossing voor en vroeg dat de servicelogs de sleutel afdrukken die de server daadwerkelijk gebruikt, of de afgeleide en actieve sleutels samen tonen. Er is nog geen maintainer aan het rapport toegewezen. Verschillende eerdere meldingen zijn al bevestigd als bugs en in de wachtrij gezet voor beoordeling, terwijl andere open blijven terwijl bijdragers ze afwegen.
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 nog steeds 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. Operators hebben sindsdien meldingen gedaan van sync-onderbrekingen, relay-miscalculaties en nu de sleutel-mismatch in de nieuwe build, zonder dat er tot nu toe een patch is uitgebracht. Achterblijvers riskeren ook een door amendement geblokkeerde staat zodra validators fixCleanup3_2_0 ratificeren, de opschoonwijziging die Ripple al heeft gesteund in de lopende stemming.
Lees hierna: Mane City Mobile komt naar iOS en Android in meer dan 100 landen