Panoramica sulle sfide di sicurezza

Una caratteristica distintiva delle blockchain è la natura atomica delle transazioni: una volta che un aggiornamento è registrato nella blockchain, non c'è possibilità di intervento o inversione. Ciò fornisce forti garanzie di coerenza e sicurezza a livello di protocollo, ma espone gli utenti a un rischio operativo elevato: un singolo errore, una chiave compromessa o un'approvazione affrettata possono portare a perdite irreversibili.

Di conseguenza, un onere significativo per la sicurezza ricade sull'utente. Per utilizzare Ethereum in modo sicuro, individui e organizzazioni devono detenere e gestire in modo sicuro le chiavi, interagire con le applicazioni on-chain e utilizzare le proprie chiavi per firmare le transazioni per trasferire risorse o aggiornare in altro modo lo stato di Ethereum.

Ciascuno di questi requisiti introduce rischi come la compromissione o la perdita delle chiavi, approvazioni affrettate o disinformate, o la compromissione del software del portafoglio su cui gli utenti fanno affidamento per informarli e guidarli nell'interazione con Ethereum.

1.1 Gestione delle chiavi

Molti utenti non sono attrezzati per gestire in modo sicuro le chiavi crittografiche.

I portafogli software più utilizzati si basano sul fatto che gli utenti conservino in modo sicuro le frasi di recupero che rappresentano la loro chiave privata crittografica sottostante, il che spesso li porta a utilizzare soluzioni alternative insicure come la memorizzazione delle frasi di recupero in testo normale, su servizi cloud o scrivendole su carta.

I portafogli hardware sono un'alternativa, che consente agli utenti di gestire una chiave crittografica memorizzata all'interno di un dispositivo fisico per scopi speciali. Tuttavia, i portafogli hardware hanno i loro difetti e la loro superficie di attacco. I portafogli hardware possono essere persi, danneggiati o rubati. Molti portafogli hardware non sono open source e potrebbero avere catene di approvvigionamento opache, aumentando il rischio di un attacco alla catena di approvvigionamento in cui dispositivi compromessi vengono venduti sul mercato.

Sia che le chiavi siano gestite in un portafoglio software o hardware, molti utenti sono comprensibilmente nervosi riguardo all'autocustodia quando questa può essere compromessa attraverso furti fisici o aggressioni.

Gli utenti aziendali e istituzionali affrontano ulteriori sfide nella gestione delle chiavi. Se i singoli dipendenti detengono le chiavi (ad es., come parte di un portafoglio multifirma), l'organizzazione deve essere in grado di sostituirle e crearne di nuove a causa dei cambiamenti di personale nel tempo. I requisiti di conformità in diversi settori e giurisdizioni potrebbero richiedere flussi di lavoro personalizzati o tracce di controllo non supportati dal software del portafoglio esistente. In alcuni casi, gli utenti aziendali si rivolgono a depositari di terze parti per le risorse digitali, il che potrebbe introdurre un ulteriore livello di rischi per la sicurezza da considerare.

1.2 Firma alla cieca e incertezza della transazione

Gli utenti approvano regolarmente le transazioni "alla cieca" senza capire cosa stanno facendo. I portafogli spesso presentano dati esadecimali grezzi, un indirizzo del contratto troncato o altre informazioni che non sono sufficienti affinché l'utente comprenda le conseguenze di una determinata transazione. Ciò lascia gli utenti di tutti i tipi vulnerabili a contratti intelligenti dannosi, phishing, truffe, interfacce falsificate, compromissioni del front-end ed errori di base dell'utente.

1.3 Gestione delle approvazioni e dei permessi

In molte applicazioni di Ethereum, è comune che gli utenti concedano determinati permessi all'applicazione sottostante come parte del normale utilizzo. Ad esempio, un utente potrebbe concedere a un exchange decentralizzato come Uniswap il permesso di spostare i propri token per scambiarli con ETH.

Queste approvazioni possono avere limiti sull'importo, ma molti portafogli per impostazione predefinita concedono approvazioni illimitate senza data di scadenza. Non c'è modo per gli utenti di gestire o rivedere le loro approvazioni in sospeso dall'interno della maggior parte dei portafogli.

Ciò può esporre gli utenti ad app dannose o front-end compromessi, perché il modello predefinito per molti utenti è concedere approvazioni illimitate che possono essere utilizzate per prosciugare i loro fondi. Anche se un utente concede un'approvazione a un contratto intelligente legittimo, se quel contratto venisse successivamente compromesso mentre l'approvazione rimane in vigore, il contratto compromesso potrebbe prosciugare i fondi dell'utente.

Questo è ugualmente un rischio per gli utenti organizzativi. Ad esempio, un'organizzazione potrebbe scegliere di concedere a un router DEX un'indennità USDC illimitata per comodità operativa, il che la espone a rischi se il contratto del router viene aggiornato.

1.4 Interfacce web compromesse

La maggior parte degli utenti non interagisce direttamente con un contratto intelligente, ma piuttosto attraverso un'interfaccia web tramite il proprio dispositivo mobile o browser web.

Questi front-end possono essere vulnerabili agli attacchi attraverso mezzi familiari come il dirottamento DNS, l'iniezione di javascript dannoso, l'hosting insicuro o varie dipendenze di terze parti. Una UX dell'app compromessa può reindirizzare utenti di tutti i tipi verso contratti intelligenti dannosi o portarli a firmare transazioni fuorvianti.

1.5 Privacy

La privacy può mitigare o amplificare i rischi per la sicurezza per gli utenti di tutti i tipi.

Protezioni della privacy più deboli espongono i singoli utenti a una varietà di minacce mirate come phishing, sfruttamento, truffe o attacchi fisici. Molti modelli UX comuni espongono gli utenti, ad es., il riutilizzo dell'indirizzo, i dati KYC e altre fughe di metadati.

Per istituzioni e imprese, la privacy è spesso un requisito aziendale fondamentale per motivi di conformità o per determinati casi d'uso. Oltre a questi problemi, può creare un'esposizione a specifici rischi per la sicurezza. Ad esempio, un utente di un sistema di catena di approvvigionamento costruito su Ethereum potrebbe richiedere forti garanzie di privacy per proteggere le risorse di proprietà intellettuale che potrebbero essere compromesse se il sistema fosse trasparente.

1.6 Frammentazione

Manca coerenza nel modo in cui i diversi portafogli gestiscono i comportamenti principali come la visualizzazione delle transazioni, la gestione delle approvazioni o l'etichettatura dei contratti. Questa frammentazione dell'esperienza utente aggiunge attrito alla capacità dell'utente di imparare a utilizzare in modo sicuro i portafogli e aumenta i rischi.

Ad esempio, gli utenti non possono fare affidamento su segnali UX coerenti per proteggersi da phishing e spoofing poiché differiscono tra i portafogli. Gli utenti non possono formarsi aspettative affidabili su come funziona Ethereum se ogni strumento funziona in modo diverso.

La sicurezza dei contratti intelligenti è radicalmente migliorata nel corso della storia di Ethereum. I primi incidenti di sicurezza come l'hacking della DAO hanno motivato l'ecosistema a professionalizzarsi e a migliorare le salvaguardie lungo il ciclo di vita del software che porta alla distribuzione del codice on-chain. I progressi chiave includono:

• L'auditing di sicurezza è diventato una pratica standard, con diverse società di sicurezza che sono entrate nell'ecosistema e hanno sviluppato competenze.
• Gli strumenti, i test e i sistemi di analisi statica sono maturati e sono diventati una pratica standard.
• Le librerie di componenti comuni pre-verificati hanno fornito agli sviluppatori blocchi di costruzione sicuri per impostazione predefinita.
• Sono state adottate tecniche di verifica formale, in particolare per ponti, sistemi di staking e contratti di alto valore.
• La cultura della sicurezza e le migliori pratiche dell'ecosistema sono migliorate.
• La creazione di significativi programmi di ricompensa che hanno rafforzato il livello dell'app.

Tuttavia, rimangono debolezze e aree di miglioramento in questo dominio.

2.1 Vulnerabilità dei contratti

Nonostante i progressi nella sicurezza dei contratti intelligenti, ci sono ancora vulnerabilità che possono portare a problemi di sicurezza significativi, tra cui:

• Rischio di aggiornamento del contratto. Alcuni contratti sono progettati per essere modificabili dopo la distribuzione, per consentire a un team di sviluppo di continuare ad aggiornare e migliorare un'applicazione. Tuttavia, questo introduce dei rischi. Gli aggiornamenti potrebbero comportare nuove vulnerabilità o la perdita totale dei fondi degli utenti in caso di un aggiornamento dannoso.
• Rientranza, dove il contratto A chiama un contratto esterno B prima di aggiornare il proprio stato interno, e il contratto B richiama il contratto originale A prima che la prima chiamata finisca.
• Uso non sicuro di librerie esterne, dove un contratto chiama una libreria esterna che potrebbe non essere verificata, essere dannosa o aggiornabile.
• Componenti non verificati. Sebbene l'auditing e l'uso di librerie standard siano migliorati, a volte gli sviluppatori si affidano a componenti non verificati nelle loro applicazioni.
• Errori di controllo degli accessi, dove i permessi sono configurati in modo errato o definiti in modo troppo ampio, consentendo agli aggressori di intraprendere azioni dannose.
• Accesso non autorizzato, dove una chiave privata in grado di controllare il contratto viene ottenuta da un attore malintenzionato.
• Ponti e interazioni cross-chain. I ponti e i protocolli cross-chain introducono ulteriore complessità e gli aggressori possono sfruttare le debolezze nel modo in cui i messaggi cross-chain vengono passati o convalidati.
• Delega dell'account controllato esternamente (EOA) o uso improprio della firma. Le applicazioni dannose possono indurre gli utenti a firmare la delega completa del proprio account a un'altra parte, consentendo il furto. Le applicazioni dannose possono anche utilizzare i messaggi firmati dall'utente in modi inaspettati, ad es., in un attacco di replay.
• Rischio emergente di bug introdotti dalla generazione di codice tramite IA o da strumenti di refactoring automatizzati.

2.2 Esperienza degli sviluppatori, strumenti e linguaggi di programmazione

Le vulnerabilità finiscono nel codice distribuito a causa di errori degli sviluppatori. Strumenti per sviluppatori migliorati hanno reso significativamente più facile distribuire contratti intelligenti sicuri. Tuttavia, i problemi rimangono.

• Mancanza di impostazioni predefinite sicure nei framework popolari. Alcuni strumenti danno priorità alla flessibilità o alla velocità rispetto alla sicurezza, impostando impostazioni predefinite insicure come approvazioni di token illimitate nella funzione approve(), o omettendo di includere modelli di controllo degli accessi per impostazione predefinita.
• Codice personalizzato per controlli operativi avanzati. Gli utenti istituzionali con requisiti operativi complessi spesso devono creare le funzionalità richieste da zero, aumentando il rischio di vulnerabilità. C'è una mancanza di componenti o framework sicuri standardizzati per flussi di lavoro di sicurezza avanzati.
• Copertura dei test incoerente tra gli stack di strumenti, così come una mancanza di norme sull'uso di tecniche collaudate come il fuzzing o il controllo degli invarianti.
• Bassa adozione di metodi di verifica formale. Le tecniche di verifica formale sono potenti, ma sono complesse, costose, richiedono competenze di dominio specializzate e non sono ben integrate nei flussi di lavoro standard degli sviluppatori, dove potrebbero essere utilizzate molto prima nella produzione del software per verificare la sicurezza in fase di specifica.
• Problemi relativi alla verifica del contratto. Utenti e sviluppatori non possono valutare facilmente l'affidabilità dei contratti distribuiti, l'entità della loro convalida di sicurezza (ad es., audit del codice) o la presenza di rischi latenti. Sebbene esistano soluzioni a questo scopo, rimangono molti problemi. Gli strumenti che affrontano questi problemi non sono ampiamente adottati, gli standard che unificherebbero gli approcci rimangono frammentati e alcuni dei servizi esistenti sono essi stessi dipendenze centralizzate.
• Rischi del compilatore. I compilatori (il software che converte il codice leggibile dall'uomo come Solidity nel bytecode utilizzato dalla EVM stessa) possono avere difetti che introducono errori nei contratti intelligenti prima che vengano distribuiti. L'ecosistema di Ethereum oggi dipende principalmente dal compilatore solc, il che significa che un bug potrebbe avere effetti diffusi.
• Diversità e profondità dei linguaggi di programmazione. Sebbene Solidity abbia un profondo ecosistema di strumenti costruito su di esso, alcuni sviluppatori desiderano funzionalità di sicurezza più moderne presenti in altri linguaggi di programmazione, come la sicurezza della memoria.

2.3 Valutazione del rischio del codice on-chain

Istituzioni e imprese dispongono di processi, standard e requisiti esistenti per valutare la sicurezza della tecnologia e dei sistemi da cui dipendono. Tuttavia, i framework esistenti spesso non si mappano in modo pulito sui contratti intelligenti, assumendo solitamente codice mutabile, controllo delle modifiche centralizzato e chiare linee di responsabilità o responsabilità legale. I sistemi costruiti su contratti intelligenti a volte possono infrangere tali presupposti, rendendo difficile per le organizzazioni adottare Ethereum e gestire il rischio in modo appropriato.

Questi sistemi sono una superficie di attacco sia per il livello del portafoglio e dell'applicazione (ad es., endpoint RPC per i portafogli) sia per il protocollo Ethereum stesso (ad es., molti validatori sono ospitati su infrastrutture cloud). La compromissione della chiave privata, il phishing e la mancanza di controlli di accesso granulari possono portare a interruzioni su larga scala, furti o modifiche non autorizzate, anche se il protocollo blockchain sottostante rimane sicuro.

3.1 Catene di livello 2

Le catene di livello 2 (L2) fungono da estensioni per Ethereum, consentendo ambienti più veloci e con commissioni inferiori pur mantenendo alcune delle garanzie di sicurezza caratteristiche della rete principale di Ethereum (a seconda del loro design specifico). Tuttavia, hanno anche le loro distinte superfici di attacco, tra cui:

• Complessità delle risorse collegate tramite ponti multi-hop. Quando le risorse viaggiano tra L1 e più L2, sono esposte a più set di contratti, tutti i quali devono essere sicuri. Una contabilità non corrispondente o interruzioni nelle catene L2 possono introdurre vulnerabilità che possono essere sfruttate dagli aggressori.
• Gli L2 rollup si basano su sistemi di prova per far rispettare la correttezza degli aggiornamenti di stato. Bug o configurazioni errate in questi sistemi possono bloccare o impedire la finalizzazione, o consentire la finalizzazione di falsi aggiornamenti di stato portando alla perdita dei fondi degli utenti.
• I consigli di sicurezza sono gruppi di detentori di chiavi che fungono da meccanismo di "backup" per aggiornare il software L2 o rispondere a determinate emergenze. I consigli di sicurezza stessi comportano dei rischi, poiché la compromissione o la collusione tra i membri potrebbe mettere a rischio i fondi degli utenti o congelare le risorse.

Vedi L2Beat (opens in a new tab) per un framework dettagliato e una dashboard di monitoraggio che valuta e confronta le prestazioni e la sicurezza degli L2.

3.2 Infrastruttura RPC e dei nodi

Le applicazioni di Ethereum dipendono da un piccolo numero di fornitori di infrastrutture per l'accesso RPC, le API e i servizi dei nodi. Ciò include fornitori di infrastrutture specifici per le criptovalute, nonché servizi cloud tradizionali che sono comunemente utilizzati per ospitare i nodi (ad es., AWS, Cloudflare, Hetzner).

Se questi fornitori di infrastrutture andassero offline o tentassero di censurare o limitare l'accesso, a molti utenti potrebbe essere impedito di accedere a Ethereum tramite il proprio portafoglio o applicazione, fino a quando non fossero in grado di migrare a un nuovo RPC o altro fornitore di infrastrutture. Alcuni di questi fornitori hanno precedentemente sospeso o chiuso account associati all'attività blockchain, sollevando preoccupazioni sulla loro affidabilità a lungo termine per le applicazioni decentralizzate.

3.3 Vulnerabilità a livello DNS

Il Domain Name System (DNS) è un livello fondamentale di Internet, ma è anche centralizzato e può essere compromesso. Molti utenti accedono alle app tramite domini web, che sono suscettibili a:

• Dirottamento DNS in cui un aggressore inserisce un falso front-end dannoso.
• Sequestro del dominio, in cui un governo o un registrar può sequestrare i domini.
• Phishing tramite domini sosia, in cui gli aggressori registrano nomi quasi identici per confondere gli utenti.

3.4 Catena di approvvigionamento del software e librerie

Gli sviluppatori di Ethereum si affidano a librerie open source, spesso prelevate direttamente da servizi come npm, crates.io o GitHub. Se queste librerie vengono compromesse, possono essere un vettore per attacchi come:

• Iniezione di pacchetti dannosi, dove gli aggressori compromettono un pacchetto ampiamente utilizzato o ne pubblicano uno con un nome simile
• Dipendenze dirottate, dove i manutentori perdono il controllo di un progetto e un attore malintenzionato introduce codice dannoso
• Compromissione dello sviluppatore, dove i pacchetti installati contengono codice che dà all'aggressore il controllo sul computer dello sviluppatore.

3.5 Servizi di distribuzione front-end e rischi correlati

Molte applicazioni di Ethereum servono i loro front-end tramite una Content Delivery Network (CDN) o una piattaforma di hosting basata su cloud (ad es., Vercel, Netlify, Cloudflare). Se questi servizi vengono compromessi, possono essere un vettore per attacchi come l'iniezione di javascript dannoso, in cui gli aggressori servono un front-end alterato agli utenti.

3.6 Censura a livello di Internet Service Provider

Gli Internet Service Provider (ISP) o gli stati nazionali possono utilizzare il controllo dell'infrastruttura Internet sottostante per censurare l'accesso a Ethereum. Ad esempio, questi attacchi potrebbero includere:

• Blocco o limitazione del traffico verso le porte comuni di Ethereum
• Filtraggio delle richieste DNS che si risolvono in servizi correlati a Ethereum
• Geofencing o divieti IP contro nodi Ethereum noti
• Ispezione profonda dei pacchetti per identificare e censurare il traffico correlato al protocollo Ethereum

Molte di queste tecniche di base sono già utilizzate oggi da governi autoritari in tutto il mondo per sopprimere l'accesso alle informazioni, agli strumenti di protesta o alle criptovalute.

Il protocollo di consenso di Ethereum si è dimostrato robusto nella pratica, con zero tempi di inattività dal primo lancio nel 2015 e attraverso numerosi aggiornamenti. Tuttavia, rimangono aree di miglioramento a lungo termine per rendere il sistema più resiliente e sicuro.

4.1 Fragilità del consenso e rischi di recupero

Le regole di scelta della biforcazione e di finalità di Ethereum sono resilienti, ma non sono invulnerabili. Durante determinate condizioni limite (come disaccordo prolungato dei validatori, bug del client o partizioni di rete), il consenso potrebbe bloccarsi o divergere temporaneamente. In condizioni estreme, ciò potrebbe portare a penalità a cascata per i validatori attraverso perdite per inattività o punizioni, il che potrebbe ulteriormente portare a una fuga di capitali dai validatori.

4.2 Diversità dei client

La diversità dei client leader del settore di Ethereum protegge la rete dai bug in qualsiasi singolo client. Tuttavia, la diversità dei client potrebbe ancora essere migliorata con una maggiore adozione di client di minoranza per ridurre ulteriormente questi rischi.

4.3 Centralizzazione dello staking e predominio delle pool

Una quantità significativa del peso dei validatori è concentrata in protocolli di staking liquido, servizi di custodia e grandi operatori di nodi. Questa concentrazione può portare a rischi come:

• Cattura o influenza della governance. Se le entità che controllano grandi quantità di stake (o entità con potere legale di influenzare tali entità) si coordinassero insieme, potrebbero avere un'influenza smisurata su quali blocchi vengono proposti e attestati, censurando potenzialmente gli utenti o influenzando gli aggiornamenti del protocollo.
• Omogeneità nella scelta del client e nella configurazione dell'infrastruttura, che può aumentare i rischi di guasti correlati.

4.4 Punire sociale non definito e lacune di coordinamento

In alcune modalità di guasto estreme, Ethereum si affiderebbe al "punire sociale" per penalizzare i validatori che hanno agito in modo dannoso per attaccare la rete (vedi sezione 6.1). Tuttavia, l'infrastruttura, le norme e i processi previsti per questo tipo di punizione sono sottosviluppati. Non esiste un meccanismo stabilito che la comunità utilizzerebbe per impegnarsi in questo processo.

4.5 Vettori di attacco economici e basati sulla teoria dei giochi

Molti potenziali vettori di attacco economico rimangono poco studiati, tra cui:

• Attacchi di griefing o griefing di punizione. I validatori possono incorrere in costi o penalità di punizione non a causa di proprie colpe, ma a causa di comportamenti avversari intesi esclusivamente a danneggiare gli altri a un costo netto per l'aggressore.
• Uscite strategiche o inattività a tempo. I validatori potrebbero intenzionalmente andare offline o uscire in momenti critici per massimizzare i profitti o interrompere il consenso con penalità minime.
• Collusione tra validatori o relay. Il comportamento coordinato tra validatori o tra relay e validatori potrebbe ridurre la decentralizzazione o estrarre MEV.
• Sfruttamento di incentivi limite nel MEV, separazione tra proponente e costruttore o progettazione dello staking liquido. Gli attori possono manipolare rare condizioni del protocollo per ottenere ricompense smisurate.

4.6 Rischio quantistico

La crittografia principale di Ethereum (ad es., firme a curva ellittica come secp256k1) potrebbe un giorno essere violata dai computer quantistici. Sebbene questo non sia un rischio imminente, una minaccia credibile potrebbe rendere istantaneamente vulnerabili i portafogli, i contratti e le chiavi di staking esistenti. Questa sfida futura indebolisce le garanzie a lungo termine di Ethereum per gli utenti.

I percorsi di migrazione verso la crittografia resistente ai quanti (ad es., tramite schemi di firma post-quantistica) devono essere progettati, testati e possibilmente incorporati nel protocollo anni prima che siano necessari. Le organizzazioni in tutto l'ecosistema di Ethereum, inclusa la Ethereum Foundation, stanno esplorando attivamente queste opzioni e monitorando i rischi.

Anche un ecosistema blockchain idealizzato avrà rischi, attacchi e vulnerabilità. Quando le cose vanno male, devono esserci sistemi efficaci per mitigare, rilevare e rispondere. Le sfide qui includono:

• Raggiungere il team interessato. Può essere difficile mettersi in contatto con il team la cui applicazione è stata compromessa. Ciò può portare a ore di ritardo, limitando la capacità dei soccorritori di recuperare i fondi.
• Escalation dei problemi presso le organizzazioni correlate. Quando il problema coinvolge una piattaforma (come un social network o un exchange centralizzato) può essere difficile per i soccorritori intensificare il problema se non hanno un contatto preesistente.
• Coordinamento della risposta. Spesso non è chiaro quanti team di risposta agli incidenti stiano assistendo l'applicazione interessata, portando a problemi di comunicazione o sforzi sprecati quando uno sforzo di gruppo avrebbe potuto essere più efficace.
• Mancanza di capacità di monitoraggio. Può essere difficile monitorare i problemi on-chain e fuori catena, il che fornirebbe un preavviso e garantirebbe una rapida risposta alle minacce.
• Accesso all'assicurazione. L'assicurazione è uno strumento essenziale per mitigare le perdite nella maggior parte dei sistemi tradizionali che si occupano di denaro, sistemi finanziari, identità e altre informazioni preziose. Tuttavia, oggi sono disponibili poche opzioni assicurative dai servizi finanziari tradizionali per l'ecosistema crittografico.

Questi rischi tendono a essere più orientati a lungo termine e riguardano Ethereum nel suo insieme piuttosto che la sicurezza dei singoli utenti o applicazioni.

6.1 Centralizzazione dello stake

La centralizzazione di grandi quantità di stake può comportare rischi per Ethereum nel suo insieme se le entità che controllano tale stake decidono di colludere.
Questa centralizzazione economica crea il potenziale per la cattura della governance sociale. Se un piccolo gruppo di validatori controlla una supermaggioranza dello stake, potrebbe:

• Coordinarsi su o resistere alle biforcazioni.
• Censurare determinate transazioni o contratti.
• Minare il consenso della comunità minacciando l'uscita o l'opposizione.

Se questo scenario estremo dovesse verificarsi, la comunità di Ethereum ha suggerito che il "punire sociale" potrebbe essere la risposta. Il punire sociale è l'uso del consenso sociale fuori catena per decidere di punire i validatori che si comportano male, come controllo sul loro potere. Ma non esistono norme, procedure o strumenti chiari per attuare tali misure (vedi sezione 4.4).

6.2 Centralizzazione delle risorse fuori catena

Ethereum ospita quantità significative di risorse del mondo reale, in cui le risorse sono detenute fuori catena in conti bancari o altri depositi, che vengono poi scambiate on-chain tramite token che rappresentano un diritto sulle risorse fuori catena. Ad esempio, molte grandi stablecoin funzionano in questo modo.

Le istituzioni che detengono i depositi fuori catena possono avere influenza sull'ecosistema di Ethereum. Ad esempio, durante uno scenario estremo in cui c'è una biforcazione controversa o un aggiornamento della rete, i grandi depositanti possono influenzare quale catena diventa ampiamente accettata scegliendo solo di riconoscere i token su una catena o sull'altra.

6.3 Attacco o pressione normativa

Governi e regolatori potrebbero fare pressione su varie entità che controllano componenti importanti dello stack di Ethereum per censurare o altrimenti interferire con il protocollo Ethereum. Anche gli utenti istituzionali di Ethereum potrebbero essere colpitti da queste pressioni, il che avrebbe ulteriori conseguenze per i loro utenti (ad es., una banca che non può più offrire determinati prodotti crittografici a causa di divieti normativi).

6.4 Cattura organizzativa della governance

I processi di governance e sviluppo open source di Ethereum sono guidati da un insieme diversificato e globale di team e aziende che mantengono il software client principale, l'infrastruttura e gli strumenti.

Varie forme di influenza (acquisizioni aziendali, dipendenze dai finanziamenti, impiego di contributori chiave, conflitti di interesse all'interno delle organizzazioni esistenti) potrebbero spostare gradualmente la cultura e le priorità della governance di Ethereum. Ciò potrebbe portare all'allineamento con specifici interessi commerciali o esterni che divergono dall'etica guidata dalla comunità e dal piano d'azione stabilito, indebolendo potenzialmente la neutralità e la resilienza di Ethereum nel tempo.