Versione popolare: Una semplice "traduzione" per interpretare l'analisi dell'hacker @CetusProtocol da parte del boss tecnologico: Questo attacco espone un classico problema di overflow di numeri interi, che si manifesta nel troncamento dei dati durante la conversione del tipo. Dettagli tecnici smontati: 1) Posizione della vulnerabilità: il problema si verifica nel meccanismo di conversione del tipo della funzione get_amount_by_liquidity e la conversione del cast da U256 a U64 causa una perdita di dati di alto livello. 2) Processo di attacco: 1. L'aggressore passa una grande quantità di parametri di liquidità attraverso la funzione add_liquidity; 2. Il numero di token B necessari per il calcolo della funzione di chiamata get_delta_b di sistema; 3. Nel processo di calcolo, i due dati di tipo U128 vengono moltiplicati e il risultato teorico dovrebbe essere di tipo U256; Difetto chiave: il risultato u256 viene convertito a u64 quando la funzione restituisce, con conseguente troncamento dei dati di alto livello a 128 bit. 3) Effetto di utilizzo: la quota di liquidità che originariamente richiedeva un gran numero di token per essere coniata può ora essere completata con un numero molto ridotto di token. L'attaccante ottiene un'enorme quota di liquidità ad un costo molto basso, per poi realizzare l'arbitraggio della pool distruggendo parte della liquidità. Semplice analogia: proprio come usare una calcolatrice che può visualizzare solo 8 cifre per calcolare 1 miliardo × 1 miliardo, il risultato di un calcolo a 20 cifre può visualizzare solo le ultime 8 cifre e le prime 12 cifre scompaiono direttamente. L'utente malintenzionato sfrutta questa vulnerabilità. Per essere chiari: questa vulnerabilità non ha nulla a che fare con l'architettura di sicurezza sottostante di @SuiNetwork, e la "gloria" della sicurezza del linguaggio Move è ancora credibile per il momento. Perché? Il linguaggio Move presenta vantaggi significativi in termini di gestione delle risorse e di sicurezza dei tipi e può prevenire efficacemente problemi di sicurezza di basso livello, ad esempio la doppia spesa e la perdita di risorse. Tuttavia, questa volta il protocollo Cetus è un errore matematico a livello di logica applicativa, non un difetto di progettazione nel linguaggio Move stesso. In particolare, il sistema di tipi di Move, sebbene rigoroso, si basa ancora sul giusto giudizio dello sviluppatore per il casting esplicito. Quando un programma esegue attivamente una conversione di tipo da U256 a U64, il compilatore non è in grado di stabilire se si tratta di un errore intenzionale o logico. Inoltre, questo incidente di sicurezza non ha nulla a che fare con le funzioni fondamentali di Sui, come il meccanismo di consenso, l'elaborazione delle transazioni e la gestione dello stato. Sui Network esegue fedelmente solo le istruzioni di transazione inviate dal protocollo Cetus e la vulnerabilità deriva dai difetti logici del protocollo a livello di applicazione stesso. Per dirla senza mezzi termini, nessun linguaggio di programmazione avanzato può eliminare completamente gli errori logici a livello di applicazione. Lo spostamento può prevenire la maggior parte dei rischi per la sicurezza sottostanti, ma non può sostituire gli sviluppatori con il controllo dei limiti della logica di business e la protezione dall'overflow delle operazioni matematiche.