Una nuova segnalazione di bug mostra che il software della XRP Ledger v3.2.0 registra nei log una chiave di validatore mentre ne esegue un’altra, mentre circa il 30% dei nodi adotta il server rinominato.
Punti chiave:
- Un operatore di nodo ha segnalato che la v3.2.0 registra nei log la nuova chiave di un validatore migrato mentre il server utilizza ancora quella vecchia.
- Il difetto appare su Ubuntu 22.04 quando un token di validatore esistente viene aggiunto a un nodo RPC attivo.
- L’adozione dell’aggiornamento è circa al 30%, con la maggior parte degli operatori ancora sulla versione precedente.
Bug di XRP Ledger mette in luce una mancata corrispondenza delle chiavi
Il difetto, segnalato come issue #7581 sul tracker GitHub del progetto, emerge dopo che un operatore migra un validatore esistente su un nodo RPC già in esecuzione e poi riavvia il servizio. Il log del servizio riporta la nuova identità del validatore migrato, mentre l’endpoint server_info continua a restituire la chiave più vecchia presente nel file locale wallet.db. I due record non coincidono più.
Riprodurre la discrepanza richiede poco sforzo. L’operatore afferma che aggiungere un token di validatore esistente a un nodo attivo e riavviare il server la attiva su Ubuntu 22.04, una sequenza comune durante le migrazioni di routine.
Leggi anche: La svendita dei perp su Anthropic è un avvertimento per le scommesse crypto pre-IPO?
L’identità del validatore ancora il consenso della rete
L’identità del validatore è al centro del modo in cui la XRP Ledger raggiunge l’accordo su ogni nuovo ledger. Le proposte di un nodo hanno peso solo quando gli altri server si fidano della sua chiave tramite le proprie liste uniche di nodi, quindi un’identità obsoleta o non allineata può confondere chiunque esamini la macchina. Un log confuso può rallentare quella fiducia.
Finora la mancata corrispondenza non ha causato interruzioni. Tuttavia, allunga la serie di difetti che gli sviluppatori hanno segnalato dalla release di metà mese, dai problemi di sincronizzazione a un crash dell’analizzatore di configurazione.
Chi ha segnalato il bug ha proposto una correzione, chiedendo che i log del servizio stampino la chiave effettivamente utilizzata dal server, o mostrino insieme la chiave derivata e quella attiva. Nessun maintainer è stato ancora assegnato alla segnalazione. Diverse segnalazioni precedenti sono già state confermate come bug e messe in coda per la revisione, mentre altre restano aperte in attesa del confronto tra i contributori.
L’adozione rallenta mentre continua il voto sull’amendamento
L’adozione della release procede lentamente. Circa il 30% dei nodi ora esegue la versione 3.2.0, mentre la maggior parte degli operatori rimane sulla precedente build 3.1.3, secondo i dati pubblici della rete.
Il rollout è iniziato il 15 giugno, quando l’aggiornamento ha rinominato il software core da rippled a xrpld e promesso un risparmio di memoria dal 30% al 40%. Da allora gli operatori hanno segnalato interruzioni di sincronizzazione, errori di calcolo nel relay e ora la mancata corrispondenza delle chiavi nella nuova build, senza che sia stata ancora rilasciata una patch. I ritardatari rischiano anche uno stato bloccato dall’amendamento una volta che i validatori ratificheranno fixCleanup3_2_0, la modifica di pulizia che Ripple ha già sostenuto nel voto in corso.
Da leggere dopo: Mane City Mobile arriva su iOS e Android in oltre 100 paesi