Le conseguenze del caso BatchGate di XRP Ledger si stanno trasformando in una discussione più ampia su chi sia effettivamente responsabile della sicurezza del protocollo e su quanto controllo debbano essere sottoposti gli emendamenti più importanti prima di avvicinarsi alla mainnet. In una dichiarazione pubblicata lunedì, Daniel Keller, operatore di validazione di lunga data, ha affermato che la quasi collisione con XLS-56 ha evidenziato "un fallimento sistemico nei processi di revisione" e lo ha spinto a ritirare il supporto a tutti gli emendamenti attualmente in esame.
Il post di Keller è stato formulato come un chiarimento su cosa dovrebbero fare i validatori dUNL, dopo quella che ha descritto come una confusione diffusa in seguito all'incidente di Batch. Il suo punto centrale era che i validatori sono partecipanti alla governance, non revisori non retribuiti. "Il ruolo dei validatori dUNL è specifico e limitato: coordiniamo l'attivazione (o il rifiuto) degli emendamenti esprimendo voti favorevoli o contrari una volta che un emendamento viene proposto", ha scritto. "Dobbiamo valutare gli emendamenti in sospeso. Questa è la nostra principale funzione di governance".
Questa distinzione è importante perché XLS-56 , noto anche come Batch, è stato bloccato solo dopo che un difetto logico nella convalida delle firme è stato scoperto poco prima dell'attivazione della mainnet. Il bug avrebbe potuto consentire l'esecuzione di transazioni non autorizzate e potenzialmente mettere a rischio miliardi di XRP prima che la modifica venisse sospesa e corretta nella versione 3.1.1 rippled.
Preoccupazioni sulla governance del registro XRP, con Ripple al centro dell'attenzione
Per Keller, l'episodio non è stato un errore isolato, ma l'ultimo esempio di un problema strutturale più profondo. "La dUNL non è un organismo gratuito di revisione del codice o di verifica dei protocolli. Aspettarsi che i validatori trascorrano decine di ore non retribuite a revisionare codici di modifica complessi non è mai stato previsto e non lo sarà mai", ha scritto. "Invece, i proponenti di emendamenti dovrebbero essere tenuti a fornire documentazione completa, suite di test, analisi di sicurezza e prove formali su richiesta. Se volete il mio voto, dimostrate che la modifica è sicura e vantaggiosa".
Ha sostenuto che ora spetta a Ripple finanziare questo processo in modo più incisivo. "Non voterò a favore di alcun emendamento futuro finché Ripple non si impegnerà in modo credibile e concreto ad aumentare sostanzialmente gli investimenti nell'ingegneria del protocollo core XRPL, nella revisione della sicurezza e nella sostenibilità a lungo termine", ha affermato Keller. "Se XRP è davvero la 'Stella Polare' di Ripple, come ripetutamente affermato, allora la sicurezza fondamentale e la decentralizzazione della rete devono ricevere l'attenzione e le risorse che meritano".
La risposta immediata di Keller è stata netta: ritirare tutti gli attuali voti "Yay", ad eccezione delle correzioni in sospeso, e rifiutarsi di aggiornare alla versione rippled 3.1.1, a meno che rimanere sulla versione precedente non comporti il rischio di essere rimossi dalla rete. Ha anche affermato che il fatto che fossero necessari un ricercatore indipendente e uno strumento di intelligenza artificiale per prevenire i danni sottolineava quanto fosse diventata fragile l'attuale rete di sicurezza.
Altre voci di spicco di XRPL hanno concordato sulla necessità di cambiare il processo, sebbene non tutte siano a favore di un rallentamento. Vet, un noto validatore XRPL, ha definito l'incidente di Batch "un'enorme opportunità" per la comunità e la Fondazione XRPL di ripensare l'evoluzione del protocollo. Ha sostenuto la necessità di un programma di modifica più lento, più revisioni a pagamento, audit multipli per modifiche più consistenti, "attackathon" su testnet e un programma di bug bounty sufficientemente ampio da attrarre ricercatori d'élite.
Keller, tuttavia, ha respinto l'idea che la soluzione sia semplicemente procedere più lentamente. "Nel breve termine, abbiamo bisogno di una sorta di accordo con Cantina. Hanno dimostrato il loro valore ed è il migliore che abbiamo al momento", ha scritto. "A medio termine, le ricompense per i bug devono essere aumentate e pagare cifre consistenti. In primo luogo, le persone devono essere incentivate a esaminare il codice; in secondo luogo, deve essere conveniente effettuare una divulgazione responsabile".
Si è spinto oltre in un intervento che ha colto il tono del dibattito: "Non voglio rallentare la nostra velocità di sviluppo; ci sono voluti anni per raggiungere il livello attuale e siamo ancora lenti. È necessario stanziare più risorse e il processo deve iniziare ieri".
Ciò lascia l'XRP Ledger in una situazione tesa ma familiare: una rete che cerca di aggiungere funzionalità senza compromettere la credibilità del suo livello di base. BatchGate non è diventato un exploit attivo. Ma ha posto una domanda più acuta: se la pipeline di emendamenti di XRPL sia ancora operativa con un livello di revisione sufficientemente approfondito per la portata del cambiamento ora proposto.
Al momento della stampa, XRP era quotato a $ 1,3566.
