Il creatore di Ethereum, Vitalik Buterin, sta esplorando un nuovo concetto su come l'informatica moderna possa essere suddivisa in due parti: un componente "collante" e un "coprocessore".
L'idea qui è semplice: dividere il lavoro. La colla esegue i compiti generali, non così intensi, mentre il coprocessore si occupa dei calcoli pesanti e strutturati.
Vitalik ce lo spiega in dettaglio, dicendo che la maggior parte dei calcoli in sistemi come l'Ethereum Virtual Machine (EVM) sono già suddivisi in questo modo. Alcune parti del processo necessitano di elevata efficienza, mentre altre sono più flessibili ma meno efficienti.
Prendiamo Ethereum, ad esempio. In una recente transazione in cui Vitalik ha aggiornato l'hash IPFS del suo blog sull'Ethereum Name Service (ENS), il consumo di gas è stato distribuito su diverse attività. La transazione ha bruciato un totale di 46.924 gas.
La ripartizione è la seguente: 21.000 gas per il costo base, 1.556 per calldata e 24.368 per l'esecuzione EVM. Operazioni specifiche come SLOAD e SSTORE hanno consumato rispettivamente 6.400 e 10.100 gas. Le operazioni LOG hanno richiesto 2.149 gas e il resto è stato consumato da processi vari.
Vitalik afferma che circa l'85% del gas di quella transazione è stato impiegato per alcune operazioni pesanti, come letture e scritture di storage, registrazione e crittografia.
Il resto era ciò che lui chiama “logica aziendale”, le cose più semplici e di livello superiore, come l’elaborazione dei dati che determinano quale record aggiornare.
Vitalik sottolinea anche che è possibile vedere la stessa cosa nei modelli di intelligenza artificiale scritti in Python. Ad esempio, quando si esegue un passaggio in avanti in un modello di trasformatore, la maggior parte del lavoro viene eseguita da operazioni vettorializzate, come la moltiplicazione di matrici.
Queste operazioni sono solitamente scritte in codice ottimizzato, spesso CUDA in esecuzione su GPU. La logica di alto livello, tuttavia, è in Python, un linguaggio generico ma lento che tocca solo una piccola parte del costo computazionale totale.
Lo sviluppatore di Ethereum ritiene inoltre che questo schema stia diventando sempre più comune nella moderna crittografia programmabile, come SNARK.
Sottolinea le tendenze nella dimostrazione STARK, in cui i team stanno realizzando dimostratori generici per macchine virtuali minime come RISC-V.
Qualsiasi programma che necessita di dimostrazione può essere compilato in RISC-V, e il dimostratore dimostra l'esecuzione di RISC-V. Questa configurazione è comoda, ma comporta un sovraccarico. La crittografia programmabile è già costosa, e aggiungere il costo dell'esecuzione del codice all'interno di un interprete RISC-V è molto.
Quindi, cosa fanno gli sviluppatori? Aggirano il problema. Identificano le operazioni specifiche e costose che occupano la maggior parte del calcolo, come hash e firme, e creano moduli specializzati per dimostrare queste operazioni in modo efficiente.
Quindi combinano il sistema di verifica RISC-V generale con questi sistemi efficienti e specializzati, ottenendo il meglio di entrambi i mondi. Questo approccio, nota Vitalik, sarà probabilmente visto in altre aree della crittografia, come il calcolo multi-party (MPC) e la crittografia completamente omomorfica (FHE).
Dove entrano in gioco la colla e il coprocessore
Secondo Vitalik, ciò a cui stiamo assistendo è l'ascesa di un'architettura "colla e coprocessore" nell'informatica. La colla è generale e lenta, responsabile della gestione dei dati tra uno o più coprocessori, che sono specializzati e veloci. Le GPU e gli ASIC sono esempi perfetti di coprocessori.
Sono meno generali delle CPU, ma molto più efficienti per determinati compiti. La parte difficile è trovare il giusto equilibrio tra generalità ed efficienza.
In Ethereum, l'EVM non deve essere efficiente, deve solo essere familiare. Aggiungendo i coprocessori o le precompilazioni giuste, puoi rendere una VM inefficiente quasi efficace quanto una nativamente efficiente.
Ma se questo non avesse importanza? E se accettassimo che i chip aperti sarebbero più lenti e utilizzassimo l'architettura di colla e coprocessore per compensare?
L'idea è che si possa progettare un chip principale ottimizzato per la sicurezza e il design open source, utilizzando moduli ASIC proprietari per i calcoli più intensivi.
Le attività più delicate potrebbero essere gestite dal chip principale sicuro, mentre quelle più impegnative, come l'elaborazione AI o la verifica ZK, potrebbero essere scaricate sui moduli ASIC.
