David Schwartz spiega i rischi della rete dopo il rallentamento su XRPL

Un malfunzionamento tecnico che ha portato a un rallentamento delle transazioni sulla rete XRP Ledger ha comportato un'analisi più ampia dell'architettura del protocollo. David Schwartz, ex direttore della tecnologia di Ripple e uno dei sviluppatori del sistema, ha descritto i punti vulnerabili della rete in una valutazione pubblica dopo l'evento.

Le chiusure del libro in rallentamento hanno avviato un'indagine

Il problema è emerso quando il team delle operazioni di XRP Ledger ha registrato un'anomalia nella rete. La chiusura dei libri sulla rete è avvenuta in modo significativamente più lento rispetto al normale, spingendo gli ingegneri a indagare sulla causa del ritardo. Durante questo processo, sono emerse domande sulla resilienza della struttura decentralizzata all'interno della comunità.

Schwartz ha affermato che il software XRPL è protetto da una struttura di sicurezza multilivello. Tuttavia, ha indicato che ci sono due scenari fondamentali che potrebbero fermare completamente l'intera rete. Il primo è il guasto simultaneo di un gran numero di server di validazione in tutto il mondo. Schwartz ha dichiarato che una tale situazione è considerata possibile solo in caso di un grande disastro naturale su scala globale.

Il secondo scenario è stato identificato come un errore nell'algoritmo di consenso o un malfunzionamento a livello di codice di una delle funzioni fondamentali del protocollo. Schwartz ha affermato che il rallentamento registrato durante l'ultimo evento indica che il margine di sicurezza tecnologico del sistema si è ridotto, il che potrebbe segnalare un attacco mirato o un errore nascosto attivato nel codice.

David Schwartz ha sottolineato che le possibilità di paralizzare l'intera rete sono limitate alla perdita massiccia di infrastrutture o al guasto del meccanismo di consenso, mentre l'ultimo rallentamento indica una diminuzione del margine di sicurezza.

Risposta all'affermazione di un unico punto di errore

Schwartz ha anche respinto le affermazioni secondo cui la rete è collegata a un singolo nodo o centro. Ha affermato che XRPL opera in una struttura completamente decentralizzata, e che la chiusura di un grande centro, o anche del proprio nodo, o il sovraccarico non influenzerebbe direttamente la funzionalità generale della rete.

Ripple, come una delle principali aziende dell'ecosistema XRP, sviluppa infrastrutture di pagamento e soluzioni finanziarie basate su blockchain. XRP Ledger è conosciuto come una rete blockchain open source che opera in modo indipendente da Ripple.

I sistemi di monitoraggio hanno subito ritardi sotto carico

Durante l'evento, è emerso che il problema più concreto era che i sistemi di monitoraggio della rete erano deboli sotto carico intenso. Quando i turni di consenso rallentavano, i validatori passavano improvvisamente a un carico massimo. Anche il nodo di Schwartz non ha resistito al traffico di richieste intenso e le connessioni RPC locali sono rimaste bloccate in stato di CLOSE_WAIT.

Mini glossario: RPC è un metodo di comunicazione che consente a un software di richiedere dati e eseguire comandi da un altro sistema a distanza. CLOSE_WAIT indica una situazione in cui una connessione ha ricevuto un segnale di chiusura dall'altra parte, ma il processo locale non è ancora completato.

A causa di questo blocco, il sistema di monitoraggio interno di Schwartz non è riuscito a registrare e inviare i dati diagnostici nel momento più critico. L'ingegnere ha quindi dovuto riavviare il server senza chiarire la causa esatta del guasto.

Schwartz ha riferito che a causa del blocco delle connessioni nel suo nodo, i dati diagnostici sono stati persi nel momento più critico e il server è stato riavviato senza vedere esattamente perché stava causando problemi.

I registri inviati a un vecchio server di test vengono esaminati

Durante l'indagine, è emerso che i registri del centro appartenente a uno degli sviluppatori di XRPL erano stati inviati a un vecchio server principale di test della XRP Ledger Foundation. Questa situazione ha ulteriormente complicato la raccolta completa dei dati al momento dell'evento.

Il team di ingegneria e gli operatori della comunità stanno cercando di isolare il guasto esaminando manualmente i registri rimanenti. Schwartz ha osservato che, sebbene ci sia stata una temporanea riduzione del margine di sicurezza, il team ha mantenuto la situazione sotto controllo e l'architettura della rete ha sufficienti riserve tecniche per continuare a funzionare.