Il creatore di Ethereum Vitalik Buterin sta esplorando un nuovo concetto su come l'informatica moderna possa essere divisa in due parti: un componente "collante" e un "coprocessore".
L’idea qui è semplice: dividere il lavoro. La colla svolge i compiti generali, non così intensi, mentre il coprocessore si occupa dei calcoli pesanti e strutturati.
Vitalik spiega per noi il concetto, 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.
Prendi 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 tra diverse attività. La transazione ha bruciato un totale di 46.924 gas.
La ripartizione è simile alla seguente: 21.000 gas per il costo base, 1.556 per i dati delle chiamate 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 in quella transazione è stato destinato ad alcune operazioni pesanti, come letture e scritture di archiviazione, 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 determina quale record aggiornare.
Vitalik sottolinea anche che puoi vedere la stessa cosa nei modelli AI scritti in Python. Ad esempio, quando si esegue un passaggio in avanti in un modello di trasformatore, la maggior parte del lavoro viene svolto da operazioni vettorizzate, 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 generale ma lento che tocca solo una piccola parte del costo computazionale totale.
Lo sviluppatore di Ethereum ritiene inoltre che questo modello stia diventando più comune nella moderna crittografia programmabile, come SNARK.
Indica le tendenze nel proving STARK, in cui i team stanno costruendo prover generici per macchine virtuali minime come RISC-V.
Qualsiasi programma che necessita di essere dimostrato può essere compilato in RISC-V e il prover dimostra l'esecuzione di RISC-V. Questa configurazione è conveniente, 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.
Allora, cosa fanno gli sviluppatori? Risolvono 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 prova generale RISC-V con questi sistemi efficienti e specializzati, ottenendo il meglio da entrambi i mondi. Questo approccio, osserva Vitalik, sarà probabilmente visto in altre aree della crittografia, come il calcolo multipartito (MPC) e la crittografia completamente omomorfica (FHE).
Dove entrano in gioco colla e coprocessore
Secondo Vitalik, ciò a cui stiamo assistendo è l'ascesa di un'architettura “collante e coprocessore” nell'informatica. Il collante è generale e lento, responsabile della gestione dei dati tra uno o più coprocessori, che sono specializzati e veloci. GPU e ASIC sono esempi perfetti di coprocessori.
Sono meno generali delle CPU ma molto più efficienti per determinate attività. 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 corretti, è possibile rendere una VM inefficiente efficace quasi quanto una efficiente in modo nativo.
Ma cosa succederebbe se questo non avesse importanza? Cosa accadrebbe se accettassimo che i chip aperti sarebbero più lenti e utilizzassimo l'architettura di colla e coprocessore per compensare?
L'idea è che potresti progettare un chip principale ottimizzato per la sicurezza e la progettazione open source utilizzando moduli ASIC proprietari per i calcoli più intensivi.
Le attività sensibili potrebbero essere gestite dal chip principale sicuro, mentre il lavoro pesante, come l'elaborazione dell'intelligenza artificiale o il collaudo ZK, potrebbe essere scaricato sui moduli ASIC.