Vitalik Buterin esplora la "colla e il coprocessore" per l'informatica

Il creatore 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 è semplice: dividere il lavoro. La colla esegue i compiti generali e meno impegnativi, mentre il coprocessore si occupa dei calcoli più complessi e strutturati. 

Vitalik ce lo spiega in dettaglio , affermando che la maggior parte dei calcoli in sistemi come l' Ethereum Virtual Machine (EVM) sono già suddivisi in questo modo. Alcune parti del processo richiedono un'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 Ethereum Name Service (ENS), il consumo di gas è stato distribuito su diverse attività. La transazione ha consumato 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 utilizzato 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 chiamava "logica aziendale", ovvero le cose più semplici e di livello superiore, come l'elaborazione dei dati che determinano quale record aggiornare. 

Vitalik sottolinea anche che lo stesso fenomeno si può osservare nei modelli di intelligenza artificiale scritti in Python. Ad esempio, quando si esegue un forward pass in un modello di trasformatore, la maggior parte del lavoro viene eseguita tramite operazioni vettoriali, come la moltiplicazione di matrici. 

Queste operazioni sono solitamente scritte in codice ottimizzato, spesso CUDA eseguito su GPU. La logica di alto livello, tuttavia, è in Python, un linguaggio generico ma lento che incide solo su una piccola parte del costo computazionale totale.

Lo sviluppatore Ethereum ritiene inoltre che questo schema stia diventando sempre più comune nella crittografia programmabile moderna, come SNARK.

Fa riferimento alle tendenze nella dimostrazione STARK, in cui i team stanno realizzando dimostratori generici per macchine virtuali minime come RISC-V.

Qualsiasi programma che necessiti di dimostrazione può essere compilato in RISC-V, e il dimostratore ne verifica l'esecuzione. 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 è un costo notevole.

Quindi, cosa fanno gli sviluppatori? Aggirano il problema.dentle 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 da entrambi i mondi. Questo approccio, osserva Vitalik, sarà probabilmente riscontrato in altre aree della crittografia, come il calcolo multi-partito (MPC) e la crittografia completamente omomorfica (FHE).

Dove entrano in gioco la colla e il coprocessore

Secondo Vitalik, stiamo assistendo all'ascesa di un'architettura "collante e coprocessore" nell'informatica. Il collante è generico e lento, responsabile della gestione dei dati tra uno o più coprocessori, specializzati e veloci. GPU e 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, è possibile rendere una VM inefficiente quasi efficace quanto una VM nativamente efficiente. 

Ma cosa succederebbe se tutto questo non importasse? Cosa succederebbe se accettassimo che i chip aperti sarebbero più lenti e utilizzassimo un'architettura basata su colla e coprocessori per compensare? 

L'idea è che si possa progettare un chip principale ottimizzato per la sicurezza e il design open source, utilizzando al contempo moduli ASIC proprietari per i calcoli più intensivi. 

Le attività sensibili potrebbero essere gestite dal chip principale sicuro, mentre le attività più impegnative, come l'elaborazione dell'intelligenza artificiale o la verifica ZK, potrebbero essere scaricate sui moduli ASIC.