Hoskinson potrebbe sbagliarsi sul futuro del calcolo decentralizzato

Il dibattito sul blockchain trilemma è riemerso alla conferenza Consensus tenutasi a Hong Kong a febbraio, mettendo in difficoltà in parte Charles Hoskinson, fondatore di Cardano, che ha dovuto rassicurare i partecipanti sul fatto che i hyperscaler come Google Cloud e Microsoft Azure non rappresenterebbero una minaccia insormontabile per la decentralizzazione.

Charles Hoskinson ha detto:

“Se il cloud non può vedere i dati, il cloud non può controllare il sistema.”

MPC e Confidential Computing riducono l’esposizione

Una delle argomentazioni centrali portate da Hoskinson è che tecnologie come la MPC (multi-party computation) e il Confidential Computing impediscono ai fornitori di hardware di accedere ai dati sottostanti, mitigando così il rischio di un singolo punto di fallimento.

La MPC consente di distribuire il materiale chiave tra più partecipanti in modo che nessun singolo nodo possa ricostruire un segreto, riducendo la probabilità che l’acquisizione di un nodo comprometta l’intero sistema. Tuttavia, questa riduzione del rischio su un asse ne crea di nuovi: lo strato di coordinamento, i canali di comunicazione e la governance dei nodi partecipanti diventano elementi critici per la sicurezza complessiva.

Allo stesso modo, il Confidential Computing, in particolare le Trusted Execution Environments (TEE), cifra i dati mentre vengono elaborati, limitando l’esposizione al provider che ospita l’esecuzione. Ma le TEE si basano su assunzioni hardware — isolamento microarchitetturale, integrità del firmware e corretta implementazione — e la letteratura tecnica ha più volte mostrato come vulnerabilità di tipo side-channel e architetturali possano emergere anche in questi contesti.

Inoltre, sia la MPC sia le TEE vengono spesso eseguite su infrastrutture fornite da hyperscaler. La concentrazione fisica dell’hardware, il layer di virtualizzazione e la catena di fornitura restano punti di leva operativa: controllare l’accesso alle macchine, alla larghezza di banda o alle regioni geografiche conferisce poteri che la crittografia da sola non elimina, come limitazioni di throughput, spegnimenti o interventi politici.

Il tema: “Nessun Layer 1 può gestire il calcolo globale”

Un altro argomento sollevato è che i hyperscaler sono essenziali perché nessun singolo Layer 1 è progettato per sostenere i carichi computazionali di portata globale, in particolare per lavori intensivi come l’addestramento di modelli di intelligenza artificiale o pipeline analitiche aziendali.

Questa osservazione è corretta rispetto al ruolo primario di un Layer 1, che è mantenere consenso, verificare transizioni di stato e garantire disponibilità duratura dei dati. Tuttavia, nelle architetture moderne della crittografia, le elaborazioni pesanti vengono sempre più svolte off-chain: ciò che conta è che i risultati siano dimostrabili e verificabili onchain.

Questo principio costituisce la base dei rollup, dei sistemi zero-knowledge e delle reti di verifiable compute: la computazione può svolgersi altrove, purché la prova del lavoro sia pubblicabile e verificabile sulla catena principale. Il problema reale diventa quindi chi controlla l’infrastruttura di esecuzione e di storage che genera quelle prove, non tanto la capacità computazionale teorica di un Layer 1.

Neutralità crittografica non equivale a neutralità di partecipazione

La neutralità crittografica — l’idea che le regole del protocollo non possano essere cambiate arbitrariamente e che non siano possibili backdoor nascoste — è un obiettivo cruciale, ma opera su uno strato matematico che necessita di supporto hardware.

Il livello fisico determina chi può partecipare, chi può permettersi di farlo e chi viene escluso: produzione hardware, distribuzione e hosting concentrati creano barriere economiche che limitano la partecipazione reale anche quando il protocollo è imparziale sulla carta. In sistemi ad alto fabbisogno computazionale, l’hardware definisce struttura dei costi, scalabilità e resilienza sotto pressione censoria.

Per questo motivo la priorità dovrebbe spostarsi verso una combinazione di crittografia robusta e proprietà hardware diversificate: senza diversificazione dell’infrastruttura, la neutralità diventa fragile e soggetta all’influenza di pochi attori in grado di imporre limiti operativi o politiche di conformità.

Specializzazione vince sulla generalizzazione nei mercati del calcolo

La competizione con fornitori come AWS viene spesso vista in termini di scala, ma l’approccio dei hyperscaler punta all’elasticità e alla flessibilità: virtualizzazione, orchestrazione, strumenti per la conformità aziendale e garanzie di elasticità sono vantaggi per carichi generici, ma introducono anche livelli di costo non necessari per workload specialistici.

I carichi tipici della prova a conoscenza zero o della computazione verificabile sono deterministici, intensivi in calcolo, limitati dalla memoria e sensibili a latenze di pipeline: tali caratteristiche premiano la specializzazione. Reti di proving progettate ad hoc competono sul rapporto prova/dollaro, prova/watt e prova/latency, con efficienze che emergono quando hardware, software per i prover, progettazione dei circuiti e logica di aggregazione sono verticalmente integrati.

In pratica, cluster persistenti e ottimizzati per questo tipo di lavoro superano in efficienza soluzioni generaliste elastiche. Anche la struttura economica cambia: un network orientato agli incentivi di protocollo può ammortizzare l’hardware in modo diverso, puntando su utilizzo sostenuto anziché su modelli di noleggio a breve termine.

Usare gli hyperscaler, ma non diventarne dipendenti

Gli hyperscaler non sono il nemico: offrono infrastrutture efficienti, affidabili e geograficamente distribuite. La questione centrale è la dipendenza. Un’architettura resiliente sfrutta i grandi fornitori per capacità di picco, ridondanza geografica e distribuzione edge, ma non lega funzioni critiche a un singolo fornitore o a un piccolo insieme di essi.

Funzioni come lo settlement, la verifica finale e la disponibilità degli artefatti critici devono poter sopravvivere al fallimento di una regione cloud, all’uscita di un fornitore dal mercato o all’inasprimento di vincoli politici. Per questo le soluzioni di storage e compute decentralizzate rappresentano un’alternativa praticabile: gli artefatti di prova, i registri storici e gli input di verifica non dovrebbero poter essere rimossi a discrezione di un singolo provider, ma risiedere su infrastrutture economicamente allineate al protocollo e difficili da disattivare.

In tale modello gli hyperscaler diventano acceleratori opzionali anziché elementi fondanti. Il cloud resta utile per raggiungere ampiezza di copertura e per picchi di domanda, ma la capacità del sistema di produrre prove e preservare gli elementi necessari alla verifica non deve essere vincolata a un fornitore unico. Se un hyperscaler dovesse scomparire, la rete rallenterebbe, non si spegnerebbe, perché le parti più rilevanti sarebbero possedute e gestite da una rete più ampia.

Questa è la via per rafforzare l’etos della decentralizzazione: combinare strumenti crittografici avanzati con diversificazione e allineamento economico dell’infrastruttura, privilegiando la resilienza strutturale rispetto alla sola efficienza immediata.