L'XRPL Dashboard ha registrato 30 voti favorevoli tra i 35 validator fidati che monitora al controllo effettuato alle 04:43 UTC del 26 settembre. Questo conteggio avvia una nuova finestra di approvazione per l'emendamento BatchV1_1 — di per sé non completa il processo di attivazione.

Punti chiave:

• BatchV1_1 ha riacquistato 30 dei 35 voti dei validator.
• Il precedente timer di approvazione di due settimane è stato azzerato.
• Ora devono mantenersi almeno 29 voti.
• Il 9 ottobre è la data più vicina, ma condizionale.
• L'attivazione sul ledger conferma l'aggiornamento.

La data è stata azzerata anche se il conteggio dei voti si è ripristinato

BatchV1_1 aveva raggiunto 30 validator favorevoli il 15 settembre. Secondo il calendario originale, ciò collocava l'attivazione verso il 29 settembre. La maggioranza è stata poi revocata il 25 settembre e riformatasi più tardi lo stesso giorno, spostando la stima di circa 10 giorni avanti.

La dashboard identifica i flag ledger in cui la precedente maggioranza è stata revocata e la nuova è stata registrata. Non rivela perché si sia verificata questa variazione temporanea né espone le motivazioni dei singoli validator. Lo sviluppo conferm è il reset stesso: un emendamento richiede un sostegno ininterrotto per l'intera finestra, anche quando il suo conteggio di voti torna successivamente allo stesso livello.

Questo rende il 9 ottobre una stima condizionale derivata dall'attuale registro di maggioranza del ledger. Può spostarsi di nuovo prima dell'attivazione.

Trenta voti favorevoli lasciano un voto sopra la soglia

La soglia di XRPL è spesso sintetizzata con "supporto dell'80%", ma la regola è più severa: un emendamento richiede più dell'80% di sostegno dai validator fidati. Con 35 validator nel set monitorato dalla dashboard, 28 voti corrispondono esattamente all'80%. BatchV1_1 necessita di 29 voti favorevoli per avviare o preservare la sua maggioranza.

L'attuale conteggio di 30 equivale a circa l'85,7%. Ha un voto sopra il requisito di 29 voti. Un passaggio da 30 a 29 lascerebbe intatto il conto alla rovescia; un passaggio a 28 causerebbe un altro reset al relativo flag ledger.

Il processo di emendamento di XRPL verifica i voti in corrispondenza dei flag ledger, in genere circa ogni 15 minuti. Questi flag ledger fungono da checkpoint ricorrenti in cui il supporto viene misurato, e il timer di due settimane scorre solo finché il conteggio resta sopra la soglia. Una volta che un emendamento ha mantenuto più dell'80% di supporto per due settimane, la modifica si applica in modo permanente alle versioni successive del ledger.

Il codice del server e le regole del Mainnet sono fasi separate

Coindoo ha spiegato in precedenza come BatchV1_1 possa coordinare istruzioni di pagamento connesse. Quella utilità non è il problema sollevato dal reset. La questione attuale è se l'emendamento corretto possa completare il processo di validazione necessario affinché quelle regole di transazione abbiano effetto sul Mainnet.

La disponibilità nel software del server rende un emendamento idoneo al voto dei validator, mentre il comportamento del Mainnet cambia solo dopo che la rete lo abilita. Questa separazione è il motivo per cui una data della dashboard va letta come una stima in tempo reale dell'avanzamento della governance, piuttosto che come un annuncio di rilascio di prodotto.

Perché il precedente ritiro per motivi di sicurezza conta ora

BatchV1_1 è il successore corretto di un precedente emendamento Batch ritirato prima dell'attivazione sul Mainnet dopo che i ricercatori avevano individuato un difetto di autorizzazione. La versione originale non è mai diventata attiva, e il problema non ha quindi esposto fondi degli utenti del Mainnet.

Secondo la divulgazione di vulnerabilità di XRPL, la versione sostitutiva ha introdotto modifiche ai controlli di firma e autorizzazione ed è stata sottoposta a ulteriori revisioni prima di tornare alla votazione. L'episodio mostra come il processo funzioni come progettato: il codice che diventa disponibile nel software del server può comunque essere fermato prima di modificare le regole del Mainnet. La nuova finestra di 14 giorni è l'attuale prova di governance per quella implementazione revisionata.

La conferma da osservare è sul ledger

Il 9 ottobre conta solo se la maggioranza si mantiene per l'intera finestra. La conferma arriverà da una pseudo-transazione EnableAmendment registrata sul ledger, dopo la quale BatchV1_1 diventerà una regola attiva del Mainnet per i ledger successivi.

Finché quell'evento non compare, l'aggiornamento rilevante è la continuità della maggioranza dei validator. La dashboard offre una visione utile del conto alla rovescia attuale, ma sarà il registro di attivazione del ledger a determinare se l'emendamento Batch corretto ha effettivamente superato la soglia per entrare nell'infrastruttura XRPL attiva.

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza finanziaria o di investimento. Il supporto dei validator e lo stato dell'emendamento possono cambiare.