Ho chiesto a Justin come vede l'evoluzione del ruolo dei rollup in questo mondo snello di Ethereum? La sua risposta riflette un ottimismo sulla tecnologia dei rollup nativi. Ecco cosa ha detto @drakefjustin sul futuro dei rollup in @ethereum: "I rollup di oggi hanno due problemi principali. Il primo è che sono piuttosto complessi e probabilmente pieni di bug. Quindi, potenzialmente, questo potrebbe significare che l'intero rollup potrebbe essere drenato. Il secondo grande problema riguarda la manutenzione dell'EVM. La maggior parte dei rollup sta cercando di essere rollup equivalenti all'EVM, il che significa che quando l'L1 cambia, l'EVM dell'L1 cambia, anche gli L2 devono cambiare in unisono. E per fare ciò, è necessario avere una sorta di processo di governance per far evolvere il rollup. Ma sfortunatamente, il processo di governance stesso, il percorso di aggiornamento, è esso stesso una vulnerabilità di sicurezza. Non sarebbe bello avere rollup che per costruzione siano privi di bug e non necessitino di essere aggiornati ogni volta che l'L1 viene aggiornato? E questa è l'idea di base dei rollup nativi, dove puoi costruire un rollup in cui la funzione di transizione dello stato di esecuzione è una copia esatta di ciò che è disponibile all'L1. Per costruzione, poiché è una copia esatta dell'L1, è definizionalmente corretto. E ogni volta che l'L1 cambia, durante un hard fork, tutti i rollup cambierebbero automaticamente con esso. Per implementare questo precompilato per i rollup nativi, è piuttosto conveniente prima eseguire l'aggiornamento ZKVM EVM... ...effettivamente, ciò che i rollup nativi ci offrono è ⁓ una quantità illimitata di esecuzione L1 attraverso questi rollup nativi. E l'unico vero collo di bottiglia è il layer di disponibilità dei dati." Ascolta l'episodio completo per ulteriori dettagli.