Un nuovo bug report mostra che il software XRP Ledger v3.2.0 registra 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 la nuova chiave del validatore migrato mentre il server utilizza ancora quella vecchia.
- L’errore compare su Ubuntu 22.04 quando un token di validatore esistente viene aggiunto a un nodo RPC già in esecuzione.
- L’adozione dell’aggiornamento è vicina al 30%, con la maggior parte degli operatori ancora sulla build precedente.
Bug di XRP Ledger mette in luce una mancata corrispondenza delle chiavi
Il difetto, segnalato come issue n. 7581 sul tracker GitHub del progetto, compare 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 vecchia chiave presente nel file wallet.db locale. 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 innesca 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 cripto pre-IPO?
L’identità del validatore ancora il consenso della rete
L’identità del validatore è al centro del modo in cui XRP Ledger concorda su ogni nuovo ledger. Le proposte di un nodo hanno peso solo quando gli altri server si fidano della sua chiave tramite le loro unique node list, quindi un’identità obsoleta o incoerente può confondere chiunque esamini la macchina. Un log fuorviante può rallentare quella fiducia.
Finora la mancata corrispondenza non ha causato interruzioni. Tuttavia, allunga la serie di difetti che gli sviluppatori hanno già segnalato dalla release di metà mese, dai problemi di sincronizzazione al crash del parser di configurazione.
Il segnalatore ha proposto una correzione, chiedendo che i log del servizio stampino la chiave che il server utilizza effettivamente, oppure mostrino insieme chiavi derivate e attive. Nessun maintainer è ancora stato assegnato al report. Diversi ticket precedenti sono già stati confermati come bug e messi in coda per la revisione, mentre altri restano aperti in attesa del confronto tra i contributor.
L’adozione rallenta mentre continua il voto sull’amendment
L’adozione della release resta lenta. Circa il 30% dei nodi ora esegue la versione 3.2.0, mentre la maggior parte degli operatori rimane sulla build precedente 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 risparmi di memoria dal 30% al 40%. Da allora gli operatori hanno segnalato interruzioni di sync, errori di calcolo nel relay e ora la mancata corrispondenza delle chiavi nella nuova build, senza che sia ancora stata rilasciata una patch. I ritardatari rischiano anche di trovarsi in uno stato bloccato dall’amendment 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