La roadmap di Interop "accelera": dopo l'aggiornamento Fusaka, l'interoperabilità di Ethereum potrebbe raggiungere un punto cruciale

Chainfeeds Guida alla lettura:

Senza ZK in tempo reale, è molto difficile avere una vera esperienza utente Interop utilizzabile.

Fonte dell'articolo:

Autore dell'articolo:

imToken Labs

Punto di vista:

imToken Labs: Il 4 dicembre, l’aggiornamento Fusaka di Ethereum è stato ufficialmente attivato sulla mainnet, anche se non ha avuto la stessa risonanza dell’aggiornamento Dencun di qualche tempo fa, e i riflettori del mercato si sono concentrati principalmente sull’espansione dei Blob e su PeerDAS, con grande entusiasmo per l’ulteriore riduzione dei costi dei dati su L2. Tuttavia, al di là di questo clamore, c’è una proposta apparentemente insignificante, EIP-7825, che ha eliminato il più grande ostacolo alla realizzazione di L1 zkEVM e delle prove in tempo reale su Ethereum, e si può persino dire che stia silenziosamente preparando la strada per l’epilogo di Interop. In questo aggiornamento Fusaka, l’attenzione di tutti si è quasi completamente concentrata sull’espansione: la capacità dei Blob è stata aumentata di 8 volte, e insieme alla verifica di campionamento casuale di PeerDAS, la narrazione dei costi nel settore DA (disponibilità dei dati) è ormai storia. Certamente, L2 più economici sono una buona cosa, ma per la roadmap ZK a lungo termine di Ethereum, EIP-7825 è il vero game changer, perché imposta un limite di Gas per ogni singola transazione su Ethereum (circa 16,78 milioni di Gas). Come è noto, quest’anno il Gas Limit per i blocchi di Ethereum è stato aumentato a 60 milioni, ma anche se il limite continua a salire, teoricamente, se qualcuno fosse disposto a pagare un Gas Price estremamente alto, potrebbe comunque inviare una “Mega-Transaction” estremamente complessa che occupa l’intera capacità di 60 milioni di Gas del blocco, bloccando così l’intero blocco. Perché allora limitare la dimensione della singola transazione? In realtà, questa modifica non ha alcun impatto sulle normali transazioni degli utenti, ma per i ZK Prover (generatori di prove), è una questione di vita o di morte, ed è strettamente legata al modo in cui i sistemi ZK generano le prove. Facciamo un esempio semplice: prima di EIP-7825, se in un blocco era inclusa una “Mega-Transaction” che consumava 60 milioni di Gas, il ZK Prover doveva elaborare questa transazione estremamente complessa in sequenza, senza poterla suddividere o parallelizzare, come se su un’autostrada a una sola corsia ci fosse un enorme camion che va molto lentamente, e tutte le auto dietro (le altre transazioni) devono aspettare che finisca il suo percorso. Questo, senza dubbio, condannava a morte le “prove in tempo reale” — perché il tempo necessario per generare la prova diventava completamente imprevedibile, potendo richiedere decine di minuti o anche di più. Dopo EIP-7825, anche se in futuro la capacità del blocco dovesse aumentare a 100 milioni di Gas, poiché ogni transazione è obbligatoriamente limitata a meno di 16,78 milioni di Gas, ogni blocco viene suddiviso in “piccole unità di lavoro” prevedibili, delimitate e parallelizzabili, il che significa che la generazione delle prove su Ethereum passa da un “problema logico” difficile a un semplice “problema di potenza di calcolo (Money Problem)”: basta investire abbastanza potenza di calcolo parallela per poter elaborare contemporaneamente questi piccoli compiti suddivisi in tempi molto brevi, generando così prove ZK per blocchi di grandi dimensioni. Tuttavia, sebbene EIP-7825, limitando la dimensione delle singole transazioni, abbia spianato la strada fisica (parallelizzabile) per le prove in tempo reale, questa è solo una faccia della medaglia; l’altra riguarda come la mainnet di Ethereum possa sfruttare questa capacità. Questo ci porta alla narrazione più tecnica della roadmap di Ethereum — L1 zkEVM. Da tempo, zkEVM è considerato il “Santo Graal” per l’espansione di Ethereum, non solo perché può risolvere i colli di bottiglia delle prestazioni, ma anche perché ridefinisce il meccanismo di fiducia della blockchain. Il suo concetto centrale è dotare la mainnet di Ethereum della capacità di generare e verificare prove ZK. In altre parole, in futuro, ogni blocco eseguito su Ethereum potrà produrre una prova matematica verificabile, consentendo agli altri nodi (in particolare i light node e L2) di confermare la correttezza del risultato senza dover ricalcolare tutto — se la capacità di generare prove ZK viene integrata direttamente nel protocollo di Ethereum (L1), ogni volta che un proponente (Proposer) impacchetta un blocco e genera una prova ZK, i nodi di verifica non dovranno più rieseguire le transazioni, ma solo verificare questa piccola prova matematica.