727 FinanceUn incidente non porta via solo gli asset, ma anche la fiducia. Le cripto non possono continuare così; dobbiamo salvarci da soli.
Autore: Robert Mao, fondatore e CEO di ArcBlock
Questo articolo è autorizzato alla libera riproduzione e inoltro da parte di chiunque, nella speranza che sempre più persone vedano questo appello affinché il settore si salvi da solo.
Le criptovalute non possono continuare così. Ancora e ancora, furti massicci portano via non solo gli asset, ma anche la fiducia dei partecipanti nell'intero settore. Dobbiamo salvarci da soli.
Il 29 ottobre 2026 si è verificato un grave incidente di sicurezza presso Binance. Il suo annuncio preliminare stimava che circa 6,3 miliardi di dollari di asset fossero stati coinvolti, e che circa 3 miliardi di dollari degli asset colpiti fossero stati congelati; le indagini indicavano inizialmente il laptop di un ingegnere DevOps, e successivamente sono stati scoperti anche altri possibili punti di intrusione. Binance ha inoltre dichiarato che non è stata trovata alcuna prova di fuga delle chiavi private dei wallet. L'importo coinvolto non rappresenta la perdita netta finale, e l'intera catena di attacco è ancora in fase di indagine. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Questa iniziativa è rivolta ai costruttori di progetti blockchain come Ethereum e Solana, e anche a Binance, Coinbase, Kraken e a tutti gli exchange, wallet, protocolli e costruttori di sicurezza disposti a partecipare: ricostruiamo insieme le fondamenta per proteggere gli asset. Sono disposto a partecipare, e spero che sempre più persone agiscano insieme.
Questo è già abbastanza grave. Ma ciò che mi preoccupa di più è quanta fiducia nelle criptovalute questo incidente distruggerà, e quanti attaccanti porterà a considerare questo settore un bersaglio che vale ancora la pena continuare ad attaccare. Anche se qualcuno alla fine si assumerà le perdite, il risarcimento non può riparare automaticamente la fiducia degli utenti, né può impedire che lo stesso tipo di distruzione si ripeta.
Binance è solo il punto d'ingresso che oggi ci costringe ad affrontare il problema. Guardando altrove, exchange, bridge, protocolli on-chain e wallet hanno lasciato da tempo una lunga scia di ferite. Nuove reti e nuovi prodotti continuano ad apparire, eppure i vecchi modelli di fallimento si ripetono ancora e ancora. Non possiamo emettere un annuncio, aspettare un po', e poi trattare il prossimo incidente come routine.
Dobbiamo anche riconoscere che le truffe e la pratica di limitarsi a creare concetti senza assumersi la responsabilità di costruire hanno danneggiato questo settore per troppo tempo. I team che costruiscono seriamente tecnologia e infrastrutture devono anch'essi sopportare insieme le conseguenze della perdita di fiducia. Quando le persone vedranno tutto il mondo delle criptovalute come una truffa, anche la tecnologia e l'esplorazione che meritano davvero di essere preservate potrebbero essere abbandonate insieme ad esso.
Come fondatore di ArcBlock e professionista nel settore delle criptovalute e della blockchain, non sono disposto ad accettare un tale esito. Credo che questo settore abbia un valore che merita di essere protetto, e credo anche che dobbiamo assumerci la responsabilità delle nostre fondamenta di sicurezza. Se continuiamo ad aspettare passivamente il prossimo incidente, il sanguinamento ripetuto potrebbe alla fine distruggere tutto ciò che abbiamo costruito insieme.Voglio quindi lanciare questa iniziativa: i costruttori di exchange, wallet e blockchain dovrebbero ricostruire congiuntamente le fondamenta del controllo degli asset e della verifica di sicurezza, in modo che l'ambito del danno da una singola intrusione sia circoscritto. La cronologia che segue spiega perché il cambiamento è necessario; la proposta tecnica che segue è il lavoro che ritengo possiamo iniziare a fare.
Nel 2008, Satoshi Nakamoto propose un sistema di denaro elettronico peer-to-peer, tentando di rendere i pagamenti meno dipendenti da intermediari fidati. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Eppure gravi incidenti da allora hanno ripetutamente esposto il problema di fondi, autorizzazioni e dipendenze software che tornano a concentrarsi.
Di seguito è riportato un elenco cronologico di incidenti rappresentativi in ambiti quali exchange centralizzati (CEX), exchange decentralizzati (DEX), bridge e wallet. Non è un database completo degli incidenti, né una statistica delle perdite anno per anno. Dove sono indicati importi, essi si riferiscono all'impatto lordo approssimativo al momento dell'incidente; furto, congelamento e successivo recupero sono descritti separatamente e non possono essere sommati come perdite permanenti.
2008 · Whitepaper di Bitcoin
Punto di partenza
Il whitepaper di Bitcoin proponeva pagamenti peer-to-peer senza istituzioni finanziarie come intermediari.
Fonte
2011–2014 · Furto di lungo periodo di Mt. Gox
CEX
Mt. Gox subì furti di lungo periodo e infine cessò le operazioni. Una successiva incriminazione del Dipartimento di Giustizia degli Stati Uniti ha allegato che circa 647.000 BTC furono rubati tra il 2011 e il 2014. Non si trattò di un attacco in un solo giorno nel 2014.
Fonte
2012 · Bitcoinica e Bitfloor
CEX / infrastruttura di custodia
L'ambiente di hosting Linode di Bitcoinica fu compromesso; nello stesso anno, il backup non cifrato del wallet di Bitfloor divenne un punto di ingresso per l'attacco. I server e i backup dietro la piattaforma sono anch'essi parte del perimetro di sicurezza degli asset.
Fonte
2015 · Hot wallet di Bitstamp
CEX
L'hot wallet di Bitstamp fu compromesso e l'ambiente operativo fu successivamente ricostruito. La distinzione ufficiale tra l'ambito dell'incidente e le riserve offline mostrò che l'isolamento può limitare l'ambito dell'esposizione.
Fonte
2016 · Bitfinex
CEX
Circa 120.000 BTC furono rubati da Bitfinex. Gli accordi multisignature richiedono comunque autorizzazione e verifica indipendenti end-to-end.
Fonte 1 · Fonte 2
2016 · The DAO
Protocollo on-chain
Il contratto di The DAO subì un attacco di rientranza e circa 3,6 milioni di ETH furono trasferiti in una sub-DAO, innescando successivamente un fork di Ethereum. Un percorso di esecuzione legittimo può produrre esiti commerciali catastrofici.
Fonte 1 · Fonte 2
2017 · Libreria di wallet condivisi di Parity
Wallet di contratto
La libreria di wallet condivisi di Parity fu distrutta e circa 513.000 ETH furono congelati. Anche se non trasferiti, i fondi possono diventare inutilizzabili a causa di dipendenze di codice condiviso.
Fonte
2018 · Coincheck
CEXL'hot wallet NEM di Coincheck è stata violata. Il confine tra riserve offline, permessi delle hot wallet ed esigenze operative è tornato a essere un problema.
Fonte
2019 · Binance
CEX
Binance ha annunciato il prelievo di 7.000 BTC in un'unica transazione. I deflussi di asset su larga scala devono essere vincolati prima della firma.
Fonte
2020 · KuCoin
CEX
Incidente della hot wallet di KuCoin, con una grande quantità di asset successivamente recuperata attraverso la collaborazione tra più parti. L'importo lordo rubato e la perdita finale non sono lo stesso numero.
Fonte
2021 · Poly Network
Protocollo cross-chain
Circa 612 milioni di dollari in asset sono stati trasferiti fuori da Poly Network e successivamente restituiti a fasi. L'autorizzazione cross-chain e il controllo degli asset non possono reggersi solo attraverso i normali percorsi operativi.
Fonte
2022 · Ronin bridge
Bridge
I permessi dei validatori di Ronin sono stati compromessi e sono stati trasferiti fuori 173.600 ETH e 25,5 milioni di USDC. Anche le chiavi di più validatori possono finire nella stessa catena d'attacco.
Fonte
2022 · Slope wallet
Wallet
Incidente della wallet Slope nell'ecosistema Solana. Solana ha dichiarato ufficialmente che le informazioni sulla chiave privata sono state trasmesse accidentalmente a un servizio di monitoraggio delle applicazioni; non si è trattato di una compromissione del consenso di Solana.
Fonte
2023 · Euler
Protocollo di lending
Circa 197 milioni di dollari in asset sono stati trasferiti fuori da Euler a causa di una vulnerabilità del protocollo e successivamente recuperati. Combinazioni complesse in un'unica transazione possono amplificare i difetti della logica operativa.
Fonte
2023 · Ledger Connect Kit
Strumento di connessione wallet
Ledger Connect Kit ha subito un attacco alla supply chain e codice malevolo è entrato nel frontend dell'applicazione. La sicurezza dei dispositivi hardware non può sostituire la verifica del contenuto delle transazioni.
Fonte
2024 · DMM Bitcoin
CEX
Circa 308 milioni di dollari sono stati rubati a DMM Bitcoin. L'FBI e altre agenzie hanno successivamente divulgato attacchi di social engineering mirati al personale pertinente e alla catena di firma.
Fonte
2024 · Radiant Capital
Protocollo di lending / firma
Circa 50 milioni di dollari sono stati rubati a Radiant Capital e più dispositivi degli sviluppatori sono stati compromessi. La firma multipartitica può comunque dipendere collettivamente da informazioni sulle transazioni contaminate.
Fonte
2025 · Bybit / Safe
CEX / frontend wallet
L'incidente di Bybit da circa 1,5 miliardi di dollari ha coinvolto l'ambiente di sviluppo e il frontend di Safe, e i firmatari hanno approvato una transazione che ha modificato la logica di controllo della wallet.
Fonte 1 · Fonte 2
2025 · Cetus DEX
DEXL'incidente da circa 223 milioni di dollari presso Cetus su Sui, con i ricercatori che indicano un difetto in una libreria matematica. Anche gli ambienti non-EVM devono esaminare il proprio codice e l'ambito dell'esposizione degli asset.
Fonte
2026-07 · Difetto del generatore di numeri casuali di COLDCARD
Hardware wallet / generazione del seedUna vulnerabilità del firmware ha indebolito la generazione del seed, consentendo agli attaccanti di ricostruire le chiavi private pertinenti mentre il dispositivo era offline. L'aggiornamento non può correggere i seed deboli già generati; è ancora necessaria la migrazione secondo l'avviso.
Fonte
2026-10 · Impianto hardware Ledger
Hardware wallet / attacco alla distribuzione
Ledger ha confermato che dispositivi autentici sono stati modificati e fatti circolare attraverso i canali di distribuzione nel Sud-Est asiatico, con componenti impiantati che rubavano le frasi di recupero durante l'inizializzazione. Il fornitore afferma che i suoi chip, il sistema operativo e i server non sono stati compromessi.
Fonte
2026 · Incidente multi-chain Binance
CEX / multi-chain
Binance ha inizialmente stimato che circa 6,3 miliardi di dollari in asset siano stati colpiti, e le indagini su altri possibili punti di intrusione sono ancora in corso. Un singolo sistema operativo può esporre asset su più reti contemporaneamente.
Fonte 1 · Fonte 2 · Fonte 3
Qui ci sono CEX, ma anche exchange decentralizzati, protocolli di lending e bridge; ci sono asset rubati e asset congelati. Gli attacchi avvengono a livelli diversi e i metodi di remediation differiscono. Mi oppongo a ridurre tutto questo alla singola frase "gli utenti non sono riusciti a proteggere le proprie chiavi private". Come possono gli utenti sapere che l'ambiente di sviluppo di un certo strumento, una certa libreria condivisa o un'autorizzazione incomprensibile diventeranno il punto di ingresso a tutti i loro asset?
Le reti distribuite hanno già fatto molto, eppure l'isolamento dei guasti per il controllo degli asset è lungi dall'essere sufficiente. L'esecuzione on-chain completa fedelmente una transazione, ma non può rispondere per noi al perché quella transazione abbia il diritto di muovere così tanto.
Il contributo di Ethereum è significativo. Ha permesso a più persone di scrivere applicazioni on-chain e ha favorito un ricco insieme di strumenti ed esperienza di sviluppo. Ma oggi molte nuove chain e L2 (reti di scaling di layer-2) trattano la compatibilità EVM come obiettivo primario. L'EVM, la macchina virtuale che esegue gli smart contract di Ethereum, sta diventando un presupposto tecnico ampiamente replicato. La compatibilità rende effettivamente comoda la migrazione delle applicazioni; la documentazione di progetti come Unichain cita esplicitamente il riutilizzo del tooling di Ethereum come valore di un ambiente di esecuzione equivalente. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Ritengo che trattare la compatibilità EVM come risposta predefinita del settore stia creando una concentrazione strutturale del rischio. Possono esserci molti nomi di rete e i validatori possono differire, ma gli sviluppatori potrebbero distribuire ripetutamente gli stessi contratti, usare le stesse abitudini di autorizzazione e affidarsi alle stesse librerie software. Gli errori nelle dipendenze condivise non scompaiono solo perché la distribuzione avviene su un'altra chain. Questo è un giudizio sul percorso tecnico, non un'affermazione che ogni implementazione EVM abbia necessariamente la stessa vulnerabilità.È anche qui che si colloca la mia critica a Ethereum. La capacità di esecuzione di contratti generici si connette direttamente ad asset trasferibili, ponendo un'enorme responsabilità sul codice applicativo e sulle interazioni con i wallet. I contratti possono chiamare contratti, le autorizzazioni possono persistere a lungo, e una conferma apparentemente ordinaria può cambiare la successiva modalità di controllo di un account. La sicurezza dipende sempre più dal fatto che ogni team di sviluppo comprenda correttamente queste combinazioni, e che ogni utente comprenda correttamente ciò che ha firmato.
EIP-7702 rende questo problema molto chiaro. Un trasferimento ordinario è "quanto a chi questa volta"; un'autorizzazione di delega può essere "da ora in poi, lascia che questo pezzo di codice esegua operazioni per conto del mio account". Ha gli obiettivi di migliorare l'esperienza utente e affinare i permessi, ma impostare una delega di per sé concede un'ampia capacità di esecuzione, e i permessi granulari devono comunque essere implementati correttamente dal codice delegato. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Il preprint "EIP-7702 Phishing Attack" di Minfeng Qi et al. studia il percorso di controllo persistente di un account dopo aver indotto la firma di tali autorizzazioni. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) Con l'aumentare della comodità, aumenta anche la responsabilità per la sicurezza; la prima non può essere semplicemente scaricata sugli utenti.
Questo incidente di Binance coinvolge più catene e l'indagine non è ancora completa, quindi l'intero impatto non può essere attribuito direttamente a EIP-7702 o all'EVM. Reentrancy, compromissione dei servizi di firma e manomissione del front-end non sono nemmeno la stessa vulnerabilità. Ma tali distinzioni non dovrebbero diventare un pretesto per smettere di interrogare l'architettura: perché il livello sottostante non conserva maggiori vincoli che non possano essere facilmente aggirati, per conto degli errori nei livelli superiori?
Anche il MEV mi scontenta. Si riferisce allo spazio in cui i partecipanti ottengono valore extra attraverso l'inclusione, l'esclusione e l'ordinamento delle transazioni. Per me, usare il potere di ordinamento per sandwichare le transazioni degli utenti e peggiorare i loro risultati di esecuzione dovrebbe essere trattato come un bug da correggere, non confezionato come una funzionalità che vale la pena preservare solo perché qualcuno può trarne profitto. Anche la documentazione di Ethereum riconosce esplicitamente il danno del sandwiching delle transazioni per gli utenti e il rischio del MEV per la stabilità della rete. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) Il MEV non è esclusivo di Ethereum e include anche diverse attività come arbitraggio e liquidazione; il settore ha già ricerche sulla mitigazione. La mia critica è che l'incentivo a mantenere la rete non può diventare una ragione per sacrificare le condizioni delle transazioni degli utenti. Un sistema di transazioni migliore dovrebbe scrivere il risultato minimo di consegna e le commissioni consentite nell'autorizzazione, e limitare lo spazio per gli ordinatori di usare informazioni non riempite per danneggiare gli utenti.Ho sempre ritenuto che l'impatto di Ethereum sul mondo delle criptovalute sia in qualche modo simile a quello che PHP ha avuto su Internet: ha permesso a molte persone di costruire cose, ma ha anche lasciato un debito ingegneristico che richiederà molto tempo per essere ripagato. PHP ha comunque dovuto correggere una grave vulnerabilità di esecuzione remota di codice nell'ottobre 2026. La maturità e la popolarità non possono sostituire il rafforzamento continuo. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) Ciò che rende prezioso Internet è che linguaggi, framework e servizi cloud possono evolversi separatamente. Dovremmo anche consentire a modelli di asset e metodi di esecuzione diversi di continuare a svilupparsi, invece di considerare la "compatibilità con la stessa macchina virtuale" come il biglietto d'ingresso per partecipare all'ecosistema.
Pertanto, invito gli ecosistemi Bitcoin, Solana e Ripple/XRP Ledger, nonché costruttori tra cui ArcBlock, a partecipare seriamente alla costruzione di una base di sicurezza comune. Partecipare a standard e interoperabilità non richiede di trasformarsi prima in Ethereum. La diversità deve essere attuata nei metodi di controllo e verifica degli asset e deve essere aperta al controllo pubblico. Gli incidenti Slope e Cetus ci hanno già ricordato che anche il non-EVM non gode di alcuna esenzione in materia di sicurezza.
Ciò che spero di vedere prendere forma è una specifica di sicurezza che diversi ambienti di esecuzione possano tutti adottare: gli stessi limiti sugli asset e requisiti di verifica possono essere implementati separatamente dall'EVM e da altri percorsi, e poi le garanzie e i costi di ciascuno possono essere esaminati pubblicamente.
1. Lasciare che i controlli del rischio sottostanti vincolino il potere di disporre degli asset
I portafogli di grandi dimensioni dovrebbero poter impostare whitelist di destinatari, limiti di spesa cumulativi e periodi di attesa per i nuovi destinatari. Il punto chiave è che queste regole non possono essere immediatamente annullate dalla stessa chiave di transazione quotidiana. Modificare le regole richiede un'autorizzazione indipendente e deve lasciare tempo per il monitoraggio e la revoca.Gli smart account esistenti hanno già una base implementativa, ad esempio Safe Guards può aggiungere restrizioni alle transazioni oltre il multisig. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Dobbiamo rendere questa una capacità fondamentale più facile da adottare che copra tutti i percorsi di controllo degli asset. Se vengono limitati solo i trasferimenti diretti mentre sono consentiti bypass tramite approvazioni illimitate, moduli o aggiornamenti, la protezione fallirà. Anche se il contratto whitelist può essere aggiornato e se i permessi del destinatario sono cambiati devono entrare nell'ambito di verifica.Activation Lock di Apple offre uno spunto dalla vita quotidiana: limita la riattivazione dei dispositivi rubati e limita la calibrazione di alcune parti rubate, con l'obiettivo di ridurre il valore sfruttabile dopo il furto. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Anche i wallet meritano di essere progettati in questa direzione. Se un attaccante ottiene una chiave, la gamma di asset che possono essere incassati rimane limitata, e il rendimento atteso da un attacco può diminuire; rischi come l'interruzione dei servizi devono comunque essere gestiti separatamente.
Questo è ciò che chiamo la "costituzione" della sicurezza degli asset: l'autorità operativa può essere compromessa, ma l'autorità di modificare i confini dovrebbe rimanere indipendente. Anche i processi di recupero devono essere vincolati, per evitare che una singola configurazione errata blocchi permanentemente gli asset.
II. Fare in modo che i wallet si assumano la responsabilità della sicurezza, invece di limitarsi a consegnare le parole mnemoniche
Ho una forte insoddisfazione verso i sistemi di wallet odierni: se un prodotto chiede a una persona comune di copiare una serie di parole, richiede che non le riveli mai, non le perda e non si faccia ingannare per farle uscire, e poi attribuisce tutti i fallimenti successivi alla responsabilità dell'utente, considero questo un design irresponsabile. L'autocustodia dovrebbe dare alle persone il controllo, e dovrebbe anche dare alle persone capacità di protezione e recupero utilizzabili. Non dovrebbe richiedere che ogni utente diventi prima un esperto di sicurezza. Questa è anche una soglia che Crypto deve superare per raggiungere più utenti comuni.Gli incidenti recenti hanno messo questa problematica direttamente sul tavolo. Nell'ottobre 2026, Ledger ha confermato che gli aggressori hanno modificato dispositivi autentici e poi li hanno rimessi sul mercato attraverso i canali di distribuzione nel Sud-Est asiatico, con componenti impiantati che rubavano le parole di recupero durante l'inizializzazione. Ledger ha definito questo come un attacco di distribuzione localizzato dopo che il dispositivo ha lasciato la fabbrica, piuttosto che una compromissione del suo chip, sistema operativo o server. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) L'incidente di luglio di COLDCARD ha coinvolto un firmware che indeboliva la generazione del seed: il dispositivo non necessitava di controllo remoto perché un aggressore potesse ricostruire le chiavi private rilevanti. L'aggiornamento del firmware corregge il processo di generazione per il futuro, ma i seed deboli già generati devono comunque essere migrati. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Questi due incidenti non sono lo stesso tipo di vulnerabilità, ma insieme dimostrano che: anche se gli utenti copiano attentamente le parole e mantengono il dispositivo offline, non possono verificare la casualità e l'integrità della catena di approvvigionamento per conto del produttore. Il fatto che il dispositivo mostri le parole di backup ha lo scopo di consentire il recupero offline, ma fa anche sì che il segreto di recupero completo passi attraverso un percorso di visualizzazione e backup che necessita di protezione. La sicurezza del chip non può sostituire la verifica dell'intero dispositivo e del processo di consegna.
L'obiettivo del miglioramento dovrebbe essere il ciclo di vita completo del wallet: come vengono generate le chiavi, come vengono spiegate le transazioni, come vengono separate le autorizzazioni e come funziona il recupero dopo la perdita di un dispositivo. L'astrazione dell'account, ovvero consentire agli account di verificare l'autorizzazione tramite regole programmabili, e i backup a soglia come SLIP-39, hanno entrambi già standard e basi di implementazione, quindi non si può dire che nessuno nel settore ci stia lavorando. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Ma dobbiamo rendere queste capacità protezioni testate e facili da usare, invece di lasciare che gli utenti assemblino da soli schemi complessi.
La semplice offuscazione delle parole mnemoniche non è sufficiente. Direzioni più affidabili includono backup crittografati verificati, recupero a soglia e autorizzazione tramite dispositivo indipendente, e far completare agli utenti esercitazioni di recupero prima di depositare ingenti quantità di asset. I frammenti di backup e il multisig sono livelli diversi: i primi possono ricombinarsi nello stesso segreto durante il recupero, mentre il secondo richiede l'approvazione di più firmatari indipendenti per una transazione. I servizi di recupero non devono diventare silenziosamente una nuova chiave principale, né una password aggiuntiva deve diventare un'altra trappola in cui perderla significhi una perdita irrecuperabile.I portafogli personali e i sistemi di portafogli degli exchange possono condividere specifiche di sicurezza per le descrizioni delle transazioni, le richieste di firma, le restrizioni sugli asset e i processi di recupero, adottando al contempo limiti e politiche di approvazione differenti. Il PSBT di Bitcoin fornisce già un formato per il passaggio di transazioni non firmate tra strumenti, e questa interfaccia comune merita di essere ulteriormente sviluppata. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) Ciò che è comune sono i requisiti di sicurezza verificabili; ogni catena deve comunque chiarire le proprie regole di adattamento. I portafogli dovrebbero presentare chiaramente cosa trasferirà questa firma e quanta autorità successiva concede a chi, e politiche indipendenti dovrebbero respingere le operazioni fuori dai limiti; una pagina di conferma più bella non è sufficiente.
III. Raggiungere la verificabilità con la divulgazione minima necessaria
Dimostrare che una condizione è soddisfatta non dovrebbe sempre richiedere agli utenti di divulgare tutti i dati sottostanti. La divulgazione selettiva, le prove a conoscenza zero e l'accesso di audit concesso su richiesta dovrebbero diventare opzioni normali nell'infrastruttura. Questo è anche legato alla sicurezza degli asset: l'identità pubblica e le relazioni tra asset possono fornire indizi per inganni mirati; i dati di cui l'attività non ha bisogno dovrebbero essere esposti il meno possibile.
Il sistema delle credenziali verificabili del W3C dispone già di un percorso tecnico per la divulgazione selettiva; tuttavia, dimostrare che gli input siano autentici, che le credenziali rimangano valide e come venga revocato lo stato deve ancora essere chiarito. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Adottare prove a conoscenza zero (ZK) non nasconde automaticamente gli importi e le relazioni delle transazioni; il scaling delle prove e la protezione della privacy sono obiettivi diversi.
Ad esempio, quando un'attività necessita solo di verificare l'idoneità a partecipare, un utente può presentare una valida conclusione di idoneità emessa da un'istituzione attendibile senza divulgare documenti finanziari completi. Quando è necessario dimostrare che un valore nascosto soddisfa una condizione, si può allora utilizzare un meccanismo di prova appropriato. La fonte attendibile della credenziale e il suo stato di revoca devono comunque essere verificati.
La mia iniziativa è chiarire prima "chi deve verificare cosa", e poi progettare i dati che devono essere resi pubblici. Coloro che verificano l'idoneità potrebbero aver bisogno solo della conclusione di idoneità; coloro che hanno specifiche responsabilità di audit possono ottenere prove limitate. I vincoli verificabili pubblicamente dovrebbero ridurre al minimo le informazioni personali esposte permanentemente a tutti.
IV. Rendere i servizi di transazione il più possibile liberi dalla custodia centralizzataIl trade matching, il path finding e il regolamento degli asset dovrebbero essere progettati separatamente. Un servizio che fornisce un punto di ingresso per il trading dovrebbe ottenere solo i permessi necessari per completare il più possibile il regolamento corrente, in modo che gli asset degli utenti rimangano sotto il rispettivo controllo per il resto del tempo. I protocolli di transazione basati su intent esistenti hanno già esplorato parte del percorso, e il settore può continuare a completarlo. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
Ciò a cui gli utenti acconsentono dovrebbero essere condizioni di regolamento chiare, tra cui cosa viene pagato, cosa viene ricevuto come minimo, quando scade e le commissioni consentite. Dopo che un servizio di trading è stato compromesso, l'attaccante può negare il servizio, ma non può modificare arbitrariamente queste condizioni. Le aziende che richiedono ancora una custodia centralizzata dovrebbero anche separare i permessi di riserva e quelli operativi, e limitare l'esposizione degli hot wallet e i limiti di rifornimento automatico.
IBIT è il prodotto negoziato in borsa su bitcoin di iShares, e ciò che viene scambiato sul mercato sono le sue quote. La sua struttura offre un esempio di isolamento parziale: le quote e il Bitcoin sottostante sono registrati separatamente, e le chiavi private pertinenti per il Vault Balance (saldo in custodia) sono collocate in cold storage. Le variazioni nel registro di negoziazione delle quote non richiedono che il Bitcoin sottostante si muova a ogni transazione. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Ciò che si può apprendere da questo è la separazione tra i diritti di negoziazione e i diritti di disposizione delle riserve. Il suo Trading Balance (saldo del servizio di trading) ha una struttura diversa, e la custodia stessa comporta rischi; il cold storage deve essere abbinato a istruzioni indipendenti e verifica delle firme.
Paragono il punto di ingresso del trading a un router nella speranza che possa essere sostituito senza portare un interruttore principale su tutti gli asset degli utenti. Il regolamento è più complesso dell'inoltro di pacchetti, e la consegna degli asset e l'autorizzazione necessitano ancora di verifica indipendente. Rendere un servizio non-custodial e poi concedergli diritti di prelievo illimitati non farà altro che riportare il rischio centralizzato.
V. Utilizzare un'architettura a livelli per isolare i guasti e preservare la sostituibilitàServono interfacce di identità e autorizzazione, politiche sugli asset e metodi di verifica del regolamento che possano evolvere in modo indipendente. Catene diverse possono mantenere i propri modelli di esecuzione e connettersi tramite interfacce chiare. Le interfacce dovrebbero dichiarare le garanzie di sicurezza e le loro condizioni, non limitarsi a dire "la chiamata è riuscita".L'esperienza di Internet sostiene questo approccio. In RFC 9518, "Centralization, Decentralization, and Internet Standards," Mark Nottingham discute specificamente le situazioni in cui la centralizzazione può essere utile, e analizza anche il potere e i rischi che comporta. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) È esattamente l'atteggiamento da cui vale la pena imparare: lasciare che l'architettura risponda a quali responsabilità possono essere centralizzate, in che misura e come impedire che quel potere si espanda. Si può consentire a un servizio di identificare centralmente le anomalie mentre la sua autorizzazione a toccare gli asset è limitata; gli utenti dovrebbero poter cambiare servizio senza perdere le proprie politiche sugli asset e i propri registri di verifica.
La domanda di accettazione più importante è: dopo che un servizio business è stato compromesso, quale strato indipendente può ancora rifiutarlo? Se tutti gli strati condividono un'unica chiave amministrativa, la cosiddetta stratificazione è solo stratificazione su un diagramma di deployment.
Questo obiettivo può essere visto come cinque strati di responsabilità: il servizio di transazione invia le richieste, il wallet esprime l'intento dell'utente, la politica indipendente limita l'autorità sulla disposizione degli asset, il componente di verifica controlla le operazioni e le prove, e lo strato di regolamento impone i vincoli e fornisce registri verificabili. Possono essere implementati da team diversi, e anche le loro dipendenze e condizioni di fallimento devono essere descritte separatamente.
L'architettura target sostenuta in questo articolo. Lo strato di regolamento deve imporre la politica sugli asset; i prompt nel wallet non possono sostituire questo vincolo. La firma quotidiana, le modifiche alle regole e l'autorità di recupero devono essere isolate e sottoposte a test di bypass.
6. Consentire agli utenti di verificare con leggerezza i propri asset
Le persone comuni non dovrebbero dover memorizzare ed eseguire l'intera cronologia dell'intera catena per verificare i propri saldi e le proprie ricevute; né dovrebbero dover fidarsi solo di un singolo server dietro il wallet. Satoshi Nakamoto ha già proposto SPV, la verifica semplificata dei pagamenti, nella Sezione 8 del whitepaper. Il BIP-157 di Bitcoin continua a esplorare la possibilità di consentire ai client di scaricare filtri e trovare i blocchi a loro correlati; anche Ethereum ha progetti di light client. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Quindi il problema non è che nessuno ci abbia mai pensato, ma che dobbiamo ancora costruire una capacità di verifica con condizioni di sicurezza chiare nei wallet che gli utenti usano ogni giorno.Prendiamo come esempio una catena che supporta le prove dello stato dell'account: quando si interroga un saldo, il server dovrebbe restituire sia il saldo sia una prova. Il wallet verifica innanzitutto un breve digest del blocco, cioè l'intestazione del blocco, secondo le regole di quella catena, e poi controlla se questo saldo è coerente con i dati impegnati dal digest. Il server fornisce la risposta e il wallet può verificarla. L'SPV di Bitcoin verifica la prova che le transazioni rilevanti siano state incluse; non può essere copiato direttamente come prova di saldo. Il wallet dovrebbe anche mostrare chiaramente fino a dove si è sincronizzato e quali informazioni sono state verificate; quando mancano le prove, i dati sono obsoleti o le fonti sono in conflitto, dovrebbe avvisare o interrompere le operazioni ad alto rischio che si basano su queste informazioni, e non deve mai ripiegare silenziosamente sulla fiducia cieca.
La verifica leggera ha comunque delle condizioni. Dimostrare che una transazione è stata inclusa in un blocco non equivale a verificare da soli che tutte le transazioni del blocco siano valide. Schemi diversi possono basarsi sull'onestà della maggioranza della potenza di hash, oppure su un record iniziale fidato, cioè un checkpoint; devono anche proteggersi da server che occultano dati o isolano gli utenti su un record di catena obsoleto. Anche la questione se la query stessa esponga gli indirizzi a cui l'utente tiene deve essere gestita. I full node e i produttori di blocchi non sono lo stesso ruolo; Ethereum oggi utilizza i validatori anziché i miner per la produzione dei blocchi.
Ancora più importante, dimostrare che "questo trasferimento è realmente avvenuto on-chain" non può provare che "questo sia esattamente il trasferimento che l'utente voleva". I light client non possono sostituire i precedenti limiti sugli asset e i controlli delle firme. Consentono agli utenti di dipendere meno da una risposta non verificabile, mentre la policy sugli asset garantisce che nemmeno una firma valida possa disporre degli asset senza limiti. Solo costruendo insieme entrambi i livelli la capacità di verifica può essere distribuita tra i partecipanti.
7. Costruire l'identificazione delle anomalie e la verifica di sicurezza come infrastruttura pubblica
Prima di una transazione, qualcuno dovrebbe verificare se l'operazione è conforme alla policy sugli asset e se modifica improvvisamente il comportamento storico. Anomalie evidenti possono attivare una pausa o una revisione escalata; l'espansione dei permessi richiede un altro percorso indipendente. L'IA può partecipare al giudizio, ma non dovrebbe ricevere un lasciapassare che prevalga sulle regole rigide.
Allo stesso tempo, dobbiamo mantenere insieme casi di attacco, test dei permessi e strumenti di verifica eseguibili ripetutamente. Solo condividendo le specifiche e preservando implementazioni indipendenti e verifica indipendente si possono ridurre i guasti di modo comune. Le fondazioni e gli exchange hanno già investimenti in sicurezza, come la Trillion Dollar Security Initiative della Ethereum Foundation. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) La prossima domanda da porsi è se l'investimento possa essere trasformato in infrastruttura pubblica che anche altri team possano adottare e ispezionare.Nessuno di questi sette elementi di lavoro può garantire una sicurezza assoluta. Ciò che devono fornire sono confini ispezionabili: in quali condizioni di compromissione dei permessi, quanta parte degli asset è esposta al massimo, con quale rapidità possono essere rilevate le anomalie e da chi dipende ancora il ripristino.
A questo punto, qualcuno potrebbe dire: la direzione sembra giusta, ma il settore va avanti da così tanti anni; quante persone e quanto tempo richiederebbe una ricostruzione? Non è forse ancora idealismo?
Se si stima secondo il modello passato di produzione del software, questo dubbio è molto realistico. Ma entro il 2026, credo che gli agenti di coding e l'ingegneria del software abilitata all'IA abbiano già cambiato la capacità costruttiva che possiamo mobilitare. Gli agenti di coding qui menzionati sono assistenti di programmazione IA in grado di leggere e scrivere codice, chiamare strumenti, eseguire test e continuare a lavorare in base al feedback in un ambiente di sviluppo. I costruttori stabiliscono gli obiettivi, definiscono i confini di sicurezza, usano questi strumenti per implementare e verificare i sistemi e si assumono la responsabilità dei risultati.
Lavori che in precedenza richiedevano grandi team per implementare, adattare e mantenere ripetutamente possono ora essere tentati da piccoli team con questo nuovo approccio ingegneristico. Un team detiene uno strato, consegna componenti attorno a interfacce chiare, e poi altri team li ispezionano e li combinano. Organizzare il giudizio architetturale umano, la capacità di implementazione degli agenti di coding e la verifica di sicurezza indipendente è, a mio avviso, il percorso costruttivo che vale la pena rivalutare seriamente.
La ricerca di Anthropic e PNNL fornisce un esempio concreto: in un ambiente simulato limitato di infrastrutture critiche, i ricercatori hanno riportato che la ricostruzione dell'attacco è stata ridotta da possibilmente diverse settimane a circa tre ore. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Non può dimostrare che un piccolo team possa già riscrivere in sicurezza l'intero settore, ma mostra che lavori di verifica e di offesa-difesa precedentemente costosi possono avere nuove condizioni di costo.
Un approccio organizzativo che può essere avviato subito è costruire congiuntamente una Build in Public AI Factory. Esperti del settore, studiosi e professionisti scrivono apertamente requisiti e specifiche di accettazione (spec), spiegando cosa deve essere protetto, quali operazioni sono consentite e quali confini devono ancora reggere dopo la compromissione di quali permessi, e poi trasformano questi requisiti in test di accettazione. Gruppi di agenti di coding si assumono il lavoro principale di codifica, test e debug; team diversi ispezionano progetti e risultati, e gli esseri umani si assumono la responsabilità del giudizio e dell'accettazione.I partecipanti possono contribuire con idee, macchine, potenza di calcolo e quote di invocazione dei modelli, cioè token AI. Le aziende di AI e cloud computing possono anche sostenere questa costruzione pubblica attraverso quote di modelli, risorse di calcolo e strumenti. Specifiche, codice prototipo, flussi di lavoro degli agenti, ambienti di test e risultati di verifica possono tutti diventare infrastrutture mantenute in comune, consentendo al team successivo di continuare direttamente da lì. L'obiettivo è trasformare la capacità di sviluppo in strutture pubbliche riutilizzabili e ridurre la dipendenza dal tempo di una singola persona o di un singolo team.
Anche gli attaccanti stanno usando l'AI, e non abbiamo più motivo di lasciare la difesa nei metodi di produzione del passato. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Ma la velocità della generazione di codice è solo il punto di partenza. Solo scrivendo chiaramente i vincoli, rendendo i test ripetibilmente eseguibili e rendendo un componente ispezionabile e sostituibile, la capacità dell'AI può essere trasformata in miglioramento dell'infrastruttura.
I costruttori indipendenti collaborano con l'aiuto di agenti di coding e strumenti AI. Il laboratorio spaziale è una metafora della costruzione pubblica. Vorrei rivolgermi in particolare a coloro che amano ancora costruire. L'"hacker" qui si riferisce a qualcuno disposto a capire come funziona un sistema, disposto a condividere ciò che scopre e disposto a lasciare che altri testino il suo lavoro. Quello spirito un tempo ha spinto avanti Internet, e oggi può spingere avanti anche Crypto.
Non credo che questo settore manchi di persone intelligenti, e non credo che i settori Crypto e AI non riescano a trovare le risorse per sostenere questo lavoro. La difficoltà maggiore è organizzare insieme talento, finanziamenti e responsabilità sostenuta. Le fondazioni e le aziende capaci dovrebbero essere disposte a sostenere il costo a lungo termine di un lavoro di base che non genera direttamente ricavi ma avvantaggia tutti.
Spero che tutti possano lavorare insieme per costruire un'infrastruttura crittografica condivisa a livello globale. Reti e team diversi possono collaborare sotto vincoli di sicurezza condivisi, ciascuno implementando le proprie soluzioni e testando quelle degli altri, e gli utenti possono scegliere e migrare. Si può partire da un singolo componente, ma la direzione dovrebbe essere abbastanza ampia da accogliere l'intero settore che costruisce insieme. Tutti i partecipanti, inclusa ArcBlock, dovrebbero contribuire con lavoro verificabile.
Dovremmo costruire insieme un tipo di infrastruttura in cui, anche se una parte è stata compromessa, gli asset abbiano ancora confini, gli altri sistemi possano ancora rifiutare gli errori e gli utenti abbiano ancora percorsi di recupero e uscita. Prendendo in prestito il nome da Star Wars, questa è la nostra A New Hope. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) La speranza viene da costruttori comuni disposti ad agire, e anche da questo momento in cui gli agenti di coding e i nuovi metodi di ingegneria consentono loro di assumersi più lavoro di costruzione.Voglio estendere un invito ai costruttori di progetti come Ethereum, Solana, Bitcoin e XRP Ledger, agli exchange come Binance, Coinbase e Kraken, e anche ai team di wallet, protocolli, ricerca sulla sicurezza, AI e cloud computing: iniziate con un progetto pilota con ambito chiaramente definito e producete congiuntamente miglioramenti che altri team possano adottare e testare.
I nomi elencati sono solo esempi, in nessun ordine particolare. Indipendentemente dalle dimensioni o dal percorso tecnico scelto, siete benvenuti a partecipare. Questo invito include anche i costruttori dei percorsi tecnici criticati in questo articolo; migliorare congiuntamente la sicurezza degli asset vale l'oltrepassare i confini dei rispettivi ecosistemi.
Io stesso sono disposto a partecipare e a contribuire con la nostra infrastruttura esistente, l'ingegneria del software e le pratiche di collaborazione con l'AI. Siamo solo un piccolo team nel settore, e ciò che possiamo fare è limitato. Spero di iniziare con un prototipo e una serie di test ripetibili.
Le persone con esperienza operativa pratica possono fornire scenari di attacco desensibilizzati, i team di wallet e protocolli possono implementare le protezioni, e i ricercatori indipendenti possono provare a aggirarle. Ogni team si assume la parte che può gestire, testando congiuntamente la soluzione e decidendo il passo successivo.
Sono disposto a partecipare all'organizzazione dei requisiti di limitazione e recupero degli asset descritti in questo articolo nella prima specifica pubblica, e sono anche disposto a contribuire con le pratiche tecniche e ingegneristiche pertinenti per costruire, insieme agli altri partecipanti, una AI Factory pubblica per questo progetto pilota. Scegliamo prima un problema molto specifico: una volta che la chiave per le transazioni quotidiane è stata compromessa, come si può ancora impedire all'attaccante di svuotare il wallet tutto in una volta? Scrivete l'intervallo di perdita consentito, l'autorità di modificare le regole e le condizioni di recupero nei test di accettazione, poi fate implementare un prototipo agli agenti di sviluppo, e fate cercare percorsi di aggiramento da un altro gruppo di agenti e da ricercatori indipendenti. Anche i server dati che restituiscono saldi errati e il recupero dopo la perdita del dispositivo possono essere gradualmente aggiunti ai test. Ciò che il prototipo raggiunge, dove fallisce e quali dipendenze rimangono dovrebbero essere spiegati pubblicamente, e il passo successivo dovrebbe essere deciso sulla base delle evidenze.
Coloro che desiderano partecipare sono invitati a ripubblicare o citare pubblicamente questa iniziativa su X e @mave99a, e a parlare del problema che volete risolvere, di casi di attacco desensibilizzati o delle risorse che potete contribuire. Spero che la discussione proceda pubblicamente, così che più costruttori possano vederla e unirsi.
Le cripto non possono continuare così. Coloro che sono disposti a collaborare, agiamo ora, iniziando con un miglioramento che può essere costruito e può resistere ai test.Binance, post di annuncio ufficiale iniziale e aggiornamento ufficiale dell'indagine successiva, 2026-10-30; analisi multi-chain di TRM. Questa bozza è stata verificata al 2026-10-30; lo stato dell'indagine e del recupero può cambiare. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. La concentrazione del rischio delle dipendenze condivise è il giudizio dell'autore in questo articolo, non una conclusione di quel documento. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, creato 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, preprint arXiv v1; non è un'identificazione di questo incidente Binance. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), meccanismi di ordinamento, diverse tipologie ed effetti negativi; "dovrebbe essere corretto come un bug" è la posizione ingegneristica dell'autore su comportamenti che danneggiano gli utenti. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
Archivio notizie ufficiale PHP 2026; aggiornamento CISA del 2026-10-26 sulle vulnerabilità note sfruttate, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, descrizione delle funzionalità e dei rischi di autorizzazione. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; descrizione attuale del supporto all'accoppiamento delle parti. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, dichiarazione del fornitore su un attacco nella catena di distribuzione; Joe Grand, ricerca di reverse engineering sugli impianti hardware. Non presentare stime non verificate delle perdite di rete come conclusioni definitive. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, consultato il 2026-10-30, registro aggiornato continuamente dell'incidente di luglio 2026 e della remediation; l'aggiornamento e la migrazione del seed sono due operazioni distinte. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, recupero a soglia, compatibilità e rischi aggiuntivi della passphrase. I meccanismi esistenti sono una base su cui costruire e non significano che ogni implementazione sia affidabile. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: Formato delle transazioni Bitcoin parzialmente firmate, un formato di scambio per transazioni non firmate, non una specifica di strategia generale per asset cross-chain. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, 2026-07-30 Group Note; note sulla privacy di Ethereum. Lo stato normativo delle tecnologie descritte nella panoramica è indipendente in ciascun caso. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
Documentazione di CoW Protocol, intenzioni di transazione e meccanismi dei solver; questo articolo non fornisce un'approvazione di sicurezza completa per alcuna implementazione specifica. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 Annual Report, PDF pagine 8–10 accordi di custodia e pagina 45 informative sui rischi. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, presentato in modo indipendente, RFC informativo, non una specifica standards-track. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoin whitepaper Sezione 8 Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. Client leggeri diversi hanno ambiti di verifica e condizioni di fiducia diversi. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI to defend critical infrastructure, 2026-01-08, ricerca in ambiente limitato in collaborazione con PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapping AI-enabled cyber threats, ricerca su campioni reali di abuso. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; questo articolo prende in prestito il titolo e l'immaginario dell'autosalvataggio congiunto. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)