MultiversX ha sospeso le operazioni sulla propria mainnet dopo che un attaccante ha tentato di sfruttare un problema di atomicità delle transazioni nel livello della macchina virtuale della rete, lasciando registrate onchain modifiche non valide. Il team ha messo offline la produzione di blocchi, ha inserito una patch in test su shadow fork e ha dichiarato di star valutando un recupero mirato. Non è stato divulgato alcun importo confermato delle perdite.

Cosa ha confermato MultiversX

• Il problema riguardava l'atomicità delle transazioni.
• Modifiche non valide sono state registrate onchain.
• Le operazioni sulla mainnet sono state sospese.
• Una patch è entrata in test su shadow fork.
• Un recupero mirato era in fase di valutazione.

Cosa resta sconosciuto

• Se gli utenti abbiano perso fondi in modo permanente.
• Quali account o contratti siano stati interessati.
• Come l'attaccante abbia innescato il malfunzionamento.
• Quale metodo di recupero verrà adottato.
• Quando ogni servizio sarà riaperto.

La sospensione ha congelato il problema, non l'ha annullato

Nel suo aggiornamento sull'incidente, MultiversX ha dichiarato che un attaccante ha tentato di sfruttare un problema di atomicità nel livello della macchina virtuale della mainnet. Gli sviluppatori hanno sospeso le operazioni di rete mentre tracciavano le modifiche di stato risultanti e preparavano una patch. Non era stato divulgato alcun importo confermato delle perdite.

Interrompere la produzione di blocchi impedisce alle nuove transazioni di basarsi su record che potrebbero essere già errati. Blocca inoltre un altro tentativo con lo stesso metodo mentre gli ingegneri determinano quali saldi o voci di contratto siano stati interessati.

La pausa non annulla le modifiche già accettate dalla rete. Quei record restano il punto di partenza utilizzato da wallet, applicazioni e bridge fino a quando MultiversX non adotta un piano di recupero.

Al momento della verifica del 20 settembre, la pagina di stato di MultiversX classificava il sistema come parzialmente degradato. La API pubblica, xPortal, Explorer, Wallet, Bridge xExchange e xLaunchpad mostravano prestazioni degradate, mentre il gateway e l'indice risultavano operativi.

Queste etichette descrivono singoli servizi e non confermano che l'elaborazione normale delle transazioni sia ripresa. Il ripristino delle interfacce non risolverebbe inoltre il problema contabile sottostante. Per capire perché, conviene partire dall'atomicità delle transazioni.

L'atomicità è la versione blockchain del "tutto o niente"

Una transazione smart contract può contenere diverse operazioni connesse. Un saldo può essere ridotto, un altro aumentato e un pool di liquidità aggiornato. L'esecuzione atomica richiede che l'intera sequenza abbia successo prima che una qualsiasi di queste modifiche diventi permanente.

Risultato atteso: ogni passo richiesto ha successo e tutte le modifiche vengono registrate insieme. Se un passo fallisce, nessuna delle modifiche della transazione dovrebbe essere registrata.

Guasto dell'atomicità: un'operazione fallisce, ma una modifica di stato precedente rimane. La rete può così registrare un risultato parziale che non avrebbe dovuto esistere da solo.

Questo è un esempio semplificato di atomicità, non una ricostruzione dell'incidente di MultiversX. Una transazione corrotta potrebbe lasciare un saldo, un token supply o un record di contratto incoerente con il risultato previsto. MultiversX non ha divulgato quale tipo di dati sia stato alterato, quindi non ci sono prove sufficienti per affermare che l'attaccante abbia creato token, svuotato un contratto specifico o rubato un importo noto.

La finalità dimostra l'accordo, non un'esecuzione priva di bug

La finalità blockchain significa che i validatori hanno concordato quale blocco e quale stato risultante appartengano alla catena canonica. Non dimostra che il software utilizzato per calcolare quello stato fosse privo di difetti.

I validatori eseguono le stesse regole di protocollo e confrontano i propri risultati. Se quelle regole contengono lo stesso difetto su ogni nodo, i validatori possono concordare costantemente un risultato che il protocollo non avrebbe mai dovuto consentire. Il consenso può stabilire quale stato la rete ha accettato; non può garantire che un bug del software non abbia contribuito a produrlo.

Installare il software corretto impedisce che lo stesso percorso di esecuzione funzioni di nuovo, ma non decide cosa debba accadere alle modifiche già registrate. MultiversX deve identificare le voci interessate e fornire ai validatori un modo riproducibile per verificare che l'attività non correlata rimanga invariata.

Lo shadow fork offre una prova generale prima del riavvio della mainnet

MultiversX ha preparato una patch da testare in un ambiente shadow fork. Uno shadow fork copia la storia e lo stato rilevanti della mainnet in un ambiente isolato, permettendo agli ingegneri di riprodurre le condizioni reali della rete senza sperimentare su saldi reali.

Il team può applicare la patch, riprodurre la sequenza interessata e testare un recupero proposto prima che i validatori lo installino sulla mainnet. Tale processo dovrebbe stabilire:

• Se i nodi calcolano lo stesso stato riparato.
• Se i saldi non interessati restano invariati.
• Se le applicazioni leggono correttamente i record correttin- Se bridge ed exchange possono riconciliare i propri dati.
• Se i validatori possono riavviarsi senza produrre catene concorrenti.

Il superamento di questi test non riaprirebbe automaticamente ogni servizio. Il deployment richiede comunque il coordinamento tra validatori, exchange, bridge e fornitori di infrastrutture che collegano utenti e applicazioni a MultiversX.

Una riparazione mirata eviterebbe di riavvolgere l'intera catena

MultiversX ha dichiarato di star valutando un recupero mirato concepito per preservare la storia delle transazioni finalizzate e i record legittimi degli utenti, intervenendo soltanto sulle modifiche connesse all'incidente. Il progetto non ha spiegato come tale correzione verrebbe implementata.

Correzione mirata dello stato. Solo i saldi, l'archiviazione dei contratti o altri record collegati all'incidente verrebbero riparati, e le transazioni non correlate potrebbero restare nella storia finalizzata. La difficoltà principale è dimostrare che la correzione includa ogni modifica non valida—e nient'altro.

Riavvolgimento ampio della catena. La rete tornerebbe a un blocco precedente e ricostruendo da lì. Le transazioni completate dopo quel punto potrebbero scomparire anche se non avevano alcun legame con l'incidente. La difficoltà principale è che i trasferimenti legittimi e l'attività delle applicazioni potrebbero dover essere ripetuti o riconciliati.

Il costo di un riavvolgimento più ampio è emerso dopo lo sfruttamento di Tectonic, quando i validatori di Cronos hanno rimosso quasi 11.000 blocchi corrispondenti a quasi due ore. Il riavvolgimento ha annullato la maggior parte dei prestiti legati all'incidente ancora registrati su Cronos, ma ha anche annullato transazioni non correlate completate in quel periodo. I due incidenti hanno cause diverse; l'esempio di Cronos è rilevante perché mostra il costo collaterale del riavvolgimento di un registro condiviso.

MultiversX dichiara di star valutando una riparazione più ristretta, ma non ha ancora mostrato come i record interessati verrebbero isolati. Una riparazione mirata non eliminerebbe necessariamente i blocchi originali: la storia delle transazioni potrebbe rimanere visibile mentre un cambiamento di protocollo coordinato stabilisce lo stato che applicazioni e validatori riconosceranno dopo il riavvio. Il metodo non può essere valutato correttamente finché MultiversX non pubblica il proprio progetto di recupero.

Cosa dovrebbero fare gli utenti di MultiversX durante la pausa

Per i possessori ordinari, l'istruzione più semplice è attendere. MultiversX non ha chiesto agli utenti di migrare token, collegare wallet a un sito di recupero o approvare una transazione correttiva.

• Non inviare o ritrasmettere transazioni.
• Non depositare o prelevare EGLD o ESDT tramite gli exchange.
• Evitare di spostare tali asset attraverso bridge cross-chain.
• Conservare l'hash delle transazioni per tutto ciò che è stato inviato in prossimità della sospensione.
• Ignorare link di recupero, migrazioni e messaggi di supporto non richiesti.
• Attendere che sia MultiversX sia la piattaforma interessata confermino la riapertura.

Una riparazione della rete verrebbe adottata dai validatori e dagli operatori di infrastrutture. Non richiederebbe agli utenti di rivelare frasi seed o di inviare asset a un indirizzo.

Anche wallet ed explorer potrebbero aver bisogno di tempo per risincronizzarsi dopo la ripresa della produzione di blocchi. Un saldo non aggiornato o una transazione recente mancante in un'interfaccia non dimostrerebbe, di per sé, che gli asset sottostanti siano cambiati.

Un riavvio deve essere verificabile

Il riavvio della produzione di blocchi ripristinerà la disponibilità, ma non risponderà da solo alla questione della finalità. MultiversX deve ancora divulgare quali account o contratti siano stati interessati, come sia stato calcolato lo stato riparato e come i validatori abbiano raggiunto indipendentemente lo stesso risultato.

Se tale documentazione mostra che sono state corrette soltanto le modifiche legate all'incidente, il recupero mirato potrebbe preservare più attività legittima rispetto a un riavvolgimento ampio. Senza di essa, la rete potrebbe ripartire mentre gli utenti restano incapaci di verificare perché alcune modifiche finalizzate sono state alterate e altre conservate.

Questo articolo è fornito a soli fini informativi e non costituisce consulenza finanziaria o di investimento. Le condizioni della rete e le istruzioni di recupero possono cambiare man mano che MultiversX pubblica ulteriori aggiornamenti.