Compilato da: 0xxz, Golden Finance
Recentemente si è tenuto EthCC7 a Bruxelles e gli organizzatori hanno invitato Vitalik, il fondatore di Ethereum, a tenere un discorso programmatico.
Vale la pena notare che il 2024 segna il decimo anniversario dell'ICO di Ethereum. Dopo il discorso di Vitalik, i tre ex fondatori principali di Ethereum, Vitalik Buterin, Joseph Lubin e Gavin Wood, hanno scattato ancora una volta una foto di gruppo insieme per commemorare l'occasione.
Questo articolo è il discorso principale tenuto recentemente da Vitalik, il fondatore di Ethereum, all'EthCC7.
l'argomento del discorso
Rafforzamento di L1: ottimizzazione di Ethereum per diventare uno strato di base Layer 2 altamente affidabile, affidabile e senza autorizzazione
Spettro di visione di Ethereum
Penso che esista uno spettro di possibili diverse divisioni del lavoro riguardo al ruolo che lo strato base di Ethereum potrebbe svolgere nell’ecosistema nei prossimi cinque-dieci anni. Puoi pensarlo come uno spettro da sinistra a destra.
Sul lato sinistro dello spettro, fondamentalmente cerca di essere uno strato di base molto minimalista che sostanzialmente funge solo da verificatore di prova per tutti gli L2. Forse fornire anche la possibilità di trasferire ETH tra diversi L2. Ma a parte questo, fondamentalmente è tutto.
Sul lato destro dello spettro, c'è sostanzialmente una rifocalizzazione sulle dApp che funzionano principalmente su L1, con L2 utilizzato solo per alcune transazioni molto specifiche e ad alte prestazioni.
Ci sono alcune opzioni interessanti nel mezzo dello spettro. Ho messo Ethereum come strato base di L2 nel secondo a sinistra. Ho messo una versione estrema all'estrema sinistra. La versione estrema è che abbandoniamo completamente la parte client di esecuzione di Ethereum, manteniamo solo la parte di consenso e aggiungiamo alcuni validatori a conoscenza zero, trasformando sostanzialmente l'intero livello di esecuzione in un Rollup.
Voglio dire, opzioni molto estreme sono a sinistra e a destra potrebbe essere uno strato di base ma provare anche a dare a L2 più funzionalità. Un’idea in questa direzione è ridurre ulteriormente il tempo di scambio di Ethereum, attualmente 12 secondi, possibilmente fino a 2-4 secondi. Lo scopo di ciò è rendere effettivamente praticabili i rollup di base come il modo principale in cui opera L2. Quindi ora, se vuoi che L2 abbia un'esperienza utente di prim'ordine, devi avere la tua pre-conferma, il che significa un selezionatore centralizzato o il tuo selezionatore decentralizzato. Se il loro consenso accelera, L2 non avrà più bisogno di farlo. Se si vuole davvero migliorare la scalabilità di L1, anche la necessità di L2 sarà ridotta.
Quindi è uno spettro. Al momento mi sto concentrando principalmente sulla versione due da sinistra, ma le cose che suggerisco qui valgono anche per altre visioni, e i consigli qui in realtà non ostacolano altre visioni. Questo è qualcosa che penso sia molto importante.
Il vantaggio in termini di robustezza di Ethereum
Un grande vantaggio di Ethereum è che ha un ecosistema di staking ampio e relativamente decentralizzato.
Il lato sinistro dell'immagine sopra è un grafico della potenza di calcolo di tutti i pool minerari di Bitcoin, mentre il lato destro è un grafico degli staker di Ethereum.
La distribuzione della potenza di calcolo di Bitcoin attualmente non è molto buona. Due pool minerari ammontano a oltre il 50% della potenza di calcolo e quattro pool minerari ammontano a oltre il 75%.
E la situazione di Ethereum è in realtà migliore di quanto mostri il grafico, perché la seconda grande parte della parte grigia in realtà non è identificata, il che significa che potrebbe essere una combinazione di molte persone e potrebbero esserci anche molti stakeholder indipendenti. La parte blu, Lido, è in realtà una strana struttura vagamente coordinata composta da 37 diversi validatori. Quindi, Ethereum ha in realtà un ecosistema di staking relativamente decentralizzato che funziona abbastanza bene.
Possiamo apportare molti miglioramenti in quest'area, ma penso che sia ancora utile riconoscerlo. Questo è uno dei vantaggi unici su cui possiamo davvero basarci.
I vantaggi di robustezza di Ethereum includono anche:
Ha un ecosistema multi-client: ci sono client di esecuzione Geth e client di esecuzione non Geth. La percentuale di client di esecuzione non Geth supera addirittura quella dei client di esecuzione Geth. Una situazione simile si verifica nei sistemi basati sul consenso;
Comunità internazionale: persone provenienti da molti paesi diversi, inclusi progetti, L2, team, ecc.;
Ecosistema di conoscenza multicentrico: c’è la Ethereum Foundation, c’è il team cliente e persino il team Reth di Paradigm ha recentemente aumentato la sua leadership nell’open source;
Culture che valorizzano questi attributi
Quindi, l’ecosistema Ethereum come livello base presenta già questi vantaggi molto potenti. Penso che questo sia qualcosa di molto prezioso a cui non si dovrebbe rinunciare facilmente. Oserei dire che ci sono passi chiari che possono essere compiuti per promuovere questi punti di forza e anche per affrontare le nostre debolezze.
Dove Ethereum L1 non soddisfa standard elevati e come può essere migliorato?
Ecco un sondaggio che ho fatto su Farcaster circa sei mesi fa: se non stai facendo staking in Solo, cosa ti impedisce di fare staking in Solo?
Posso ripetere la domanda in questa sede: chi sta effettuando lo staking in Solo? Senza staking Solo, chi di voi ritiene che la soglia di 32 ETH sia l'ostacolo più grande, chi ritiene che gestire un nodo sia troppo difficile sia l'ostacolo più grande e chi ritiene che l'ostacolo più grande sia che non è possibile investire i propri ETH nella DeFi protocollo allo stesso tempo? Chi ritiene che l’ostacolo più grande sia la paura di dover mettere le chiavi private su un nodo in esecuzione dove possono essere rubate più facilmente?
Si può vedere che i primi due ostacoli concordati all’unanimità sono: il requisito minimo di 32 ETH e la difficoltà di funzionamento del nodo. È sempre importante rendersene conto.
Molte volte, quando iniziamo a indagare su come massimizzare la capacità delle persone di duplice utilizzo del proprio collaterale nei protocolli DeFi, scopriamo che un gran numero di persone non utilizza nemmeno i protocolli DeFi. Concentriamoci quindi sui problemi principali e su cosa possiamo fare per cercare di risolverli.
Inizia eseguendo un nodo validatore, o in altre parole, partendo dalla soglia di 32 ETH. In effetti, queste due domande sono correlate perché sono entrambe funzioni del numero di validatori nella Proof of Stake di Ethereum.
Oggi abbiamo circa 1 milione di entità validatrici, ciascuna con un deposito di 32 ETH, quindi se il requisito minimo fosse cambiato in 4 ETH, allora avremmo 8 milioni o forse più di 8 milioni, forse 9 milioni o 10 milioni di validatori. Se vogliamo ridurlo a 100.000 validatori, il requisito minimo potrebbe dover salire a circa 300 ETH.
Quindi è un compromesso. Ethereum ha storicamente cercato di trovarsi nel mezzo del compromesso. Tuttavia, se riusciamo a trovare un modo per migliorarlo, avremo punti statistici aggiuntivi che potremo opzionalmente utilizzare per ridurre i requisiti minimi o per rendere più semplice la gestione di un nodo.
In effetti, ora penso che l'aggregazione delle firme non sia nemmeno la difficoltà principale nel gestire un nodo. All'inizio potremmo concentrarci maggiormente sulla riduzione dei requisiti minimi, ma alla fine ciò coinvolgerà entrambi.
Quindi, ci sono due tecniche che possono migliorare entrambi questi aspetti.
Una tecnica è consentire lo staking o consentire la definitività senza richiedere la firma di ogni validatore. Fondamentalmente, è necessario una sorta di campionamento casuale di un numero sufficiente di nodi per ottenere una sicurezza economica significativa.
In questo momento, penso che abbiamo una sicurezza economica più che sufficiente. Il costo per condurre un attacco del 51%, calcolato in termini di quantità di ETH tagliato, è un terzo di 32 milioni di ETH, ovvero circa 11 milioni di ETH. Chi spenderebbe 11 milioni di ETH per distruggere la blockchain di Ethereum. Nessuno, nemmeno il governo americano, vuole farlo.
Queste tecniche di campionamento sono simili a quelle che si avrebbero se si avesse una casa e la porta d'ingresso fosse protetta da quattro strati di acciaio, ma la finestra fosse solo un pezzo di vetro di bassa qualità che qualcuno potrebbe facilmente rompere con una mazza da baseball. Penso che Ethereum sia in una certa misura così, se vuoi fare un attacco del 51%, devi perdere 11 milioni di ETH. Ma in realtà ci sono molti altri modi per attaccare il protocollo e dovremmo rafforzare maggiormente queste difese. Quindi, se si dispone di un sottoinsieme di validatori che eseguono finalità, il protocollo è ancora abbastanza sicuro e si può davvero aumentare il livello di decentralizzazione.
La seconda tecnica è una migliore aggregazione delle firme. Potresti fare qualcosa di avanzato come Starks e, invece di supportare 30.000 firme per slot, alla fine potremmo essere in grado di supportare più firme. Questa è la prima parte.
La seconda parte semplifica l'esecuzione dei nodi.
Il primo passo è la scadenza della cronologia. In effetti, EIP-4444 ha fatto molti progressi in questo senso.
Il secondo passo è il client senza stato. Verkle esiste da molto tempo, un'altra opzione possibile è creare un hash tree binario simile a Poseidon con una funzione hash compatibile con Stark. Una volta ottenuto questo, per verificare i blocchi Ethereum, non avrai più bisogno di un disco rigido. Puoi quindi aggiungere uno ZKVM di tipo 1 in grado di verificare Stark l'intero blocco Ethereum, in modo da poter verificare blocchi Ethereum arbitrariamente grandi scaricando dati o anche dati di campionamento sulla disponibilità dei dati, e quindi devi verificare solo una prova.
Se lo fai, l'esecuzione del nodo diventerà più semplice. Una delle cose molto fastidiose attualmente con i client stateless è che se vuoi modificare le impostazioni hardware o software, di solito devi iniziare da zero e perdere un giorno, oppure devi fare qualcosa di molto pericoloso e mettere le chiavi in due. sarebbe uno Slah, se abbiamo clienti apolidi non avrai più bisogno di farlo.
Puoi semplicemente avviare un nuovo client autonomo, chiudere quello vecchio, spostare le chiavi e avviare quello nuovo. Perdi solo un'epoca.
Una volta ottenuto ZKVM, i requisiti hardware scendono praticamente quasi a zero.
Pertanto sia la soglia di 32 ETH che la difficoltà di funzionamento del nodo possono essere risolte tecnicamente. Penso che ci siano molti altri vantaggi nel farlo, migliorerà davvero la nostra capacità di aumentare lo staking individuale delle persone, ci darà un migliore ecosistema di staking individuale ed eviterà i rischi della centralizzazione dello staking.
La Proof of Stake presenta altre sfide, come i rischi relativi allo staking di liquidità e i rischi relativi al MEV. Anche queste sono domande importanti da continuare a considerare. I nostri ricercatori stanno pensando a questo.
Recupera dall'attacco del 51%.
Ho davvero iniziato a pensare seriamente e rigorosamente. È sorprendente quante persone non pensino affatto a questo argomento e lo trattino semplicemente come una scatola nera.
Cosa accadrebbe se ci trovassimo davvero di fronte ad un attacco del 51%?
Ethereum potrebbe subire un attacco del 51%, Bitcoin potrebbe subire un attacco del 51% e anche un governo potrebbe subire un attacco del 51%, come ad esempio acquistare il 51% dei politici.
Un problema è che non vuoi fare affidamento esclusivamente sulla prevenzione, vuoi anche avere un piano di recupero.
Un malinteso comune è che le persone pensano che gli attacchi del 51% riguardino l’inversione della finalità. Le persone prestano attenzione a questo perché è ciò che Satoshi Nakamoto ha sottolineato nel Libro bianco. Puoi spendere due volte, dopo aver acquistato il mio jet privato, ho effettuato un attacco del 51%, ho recuperato i miei bitcoin e ho potuto tenere il mio jet privato e volare in giro.
Un attacco più realistico potrebbe comportare l’effettuazione di depositi sugli scambi e cose come la compromissione dei protocolli DeFi.
Ma un’inversione non è in realtà la cosa peggiore. Il rischio più grande di cui dovremmo preoccuparci è in realtà la censura. Il 51% dei nodi ha smesso di accettare blocchi dal restante 49% dei nodi o da qualsiasi nodo che tenta di contenere qualche tipo di transazione.
Perché questo è il rischio più grande? Poiché l'inversione della finalità ha Slash, ci sono prove immediate e verificabili sulla catena che almeno un terzo dei nodi ha fatto qualcosa di molto, molto sbagliato e sono stati puniti.
E in un attacco di censura, non è proceduralmente attribuibile, non ci sono prove procedurali immediate per dire chi ha fatto qualcosa di male. Ora, se sei un nodo online, se vuoi vedere che una certa transazione non è stata inclusa entro 100 blocchi, ma non abbiamo nemmeno scritto un software per fare questo controllo,
Un'altra sfida con la censura è che se qualcuno vuole attaccare, può farlo ritardando le transazioni e i blocchi che non gli piacciono di 30 secondi, poi ritardandoli di un minuto, poi ritardandoli di due minuti, e nemmeno avere consenso su quando rispondere.
Quindi, dico, in realtà la censura è il rischio più grande.
Nella cultura blockchain si sostiene che se si verifica un attacco, la comunità si unirà e ovviamente faranno alcuni soft fork ed elimineranno gli aggressori.
Ciò potrebbe essere vero oggi, ma si basa su molte ipotesi sul coordinamento, sull’ideologia, su ogni genere di altre cose, e non è chiaro quanto sarà vero qualcosa del genere tra 10 anni. Quindi quello che molte altre comunità blockchain stanno iniziando a fare è, dicono, che abbiamo cose come la censura, abbiamo questi errori che sono di natura più non attribuibile. Pertanto, dobbiamo fare affidamento sul consenso sociale. Affidiamoci quindi esclusivamente al consenso sociale e siamo orgogliosi di ammettere che lo useremo per risolvere i nostri problemi.
In realtà, io sostengo di andare nella direzione opposta. Sappiamo che coordinare completamente le risposte automatizzate e dividere automaticamente la maggior parte degli aggressori sotto esame è matematicamente impossibile. Ma possiamo avvicinarci il più possibile a questo.
È possibile creare un fork che porti effettivamente almeno la maggioranza dei nodi online in base ad alcuni presupposti sulle condizioni della rete. L'argomento che sto cercando di trasmettere qui è che ciò che in realtà vogliamo è provare a rendere la risposta a un attacco del 51% il più automatizzata possibile.
Se sei un validatore, allora il tuo nodo dovrebbe eseguire un software che se rileva transazioni censurate o alcuni validatori censurati, decensurerà automaticamente la maggior parte della catena e tutti i nodi onesti lo faranno automaticamente a causa del loro Il codice in esecuzione è coordinato su le stesse poche forchette morbide.
Naturalmente, anche in questo caso il risultato è matematicamente impossibile, almeno chiunque fosse offline in quel momento non sarebbe stato in grado di dire chi aveva ragione e chi aveva torto.
Ci sono molte limitazioni, ma più ci si avvicina a questo obiettivo, meno lavoro dovrà fare il consenso sociale.
Se immagini cosa accade realmente con un attacco del 51%. Non sarà come, di seguito, all'improvviso ad un certo punto, Lido, Coinbase e Kraken pubblicheranno un post sul blog alle 5:46 dicendo sostanzialmente: ehi ragazzi, stiamo facendo una revisione adesso.
Ciò che in realtà potrebbe accadere è che assisterete contemporaneamente ad una guerra sui social media e ad ogni tipo di altro attacco contemporaneamente. Se effettivamente si verificasse un attacco del 51%, a proposito, non dovremmo dare per scontato che Lido, Coinbase e Kraken saranno al potere tra 10 anni. L’ecosistema Ethereum diventerà sempre più mainstream e dovrà essere altamente adattabile a questo. Vogliamo che il peso sul livello sociale sia il più leggero possibile, il che significa che abbiamo bisogno che il livello tecnico trovi almeno un chiaro candidato vincente e, se vogliono sborsare da una catena che è in fase di revisione, dovrebbero mobilitarsi intorno una manciata di forchette morbide superiori.
Sostengo di effettuare ulteriori ricerche e di formulare una raccomandazione molto specifica.
Proposta: aumentare la soglia del quorum al 75% o all'80%
Penso che la soglia per il Quorum (Nota: il meccanismo del Quorum è un algoritmo di voto comunemente utilizzato nei sistemi distribuiti per garantire la ridondanza dei dati e l'eventuale coerenza) possa essere aumentata dai due terzi di oggi al 75% o all'80% circa.
L'argomento di base è che se una catena dannosa come una catena di censura attacca, il ripristino diventa molto, molto difficile. Ma d’altro canto, se si aumenta la quota del Quorum, quali sono i rischi? Se il Quorum è dell'80%, invece del 34% dei nodi che vanno offline a fermare la definitività, è il 21% dei nodi che vanno offline a fermare la definitività.
Ci sono dei rischi. Vediamo come appare nella pratica? Da quello che ho capito, penso che solo una volta la finalità sia rimasta bloccata per circa un'ora perché più di un terzo dei nodi erano offline. E poi, ci sono incidenti in cui dal 20% al 33% dei nodi sono offline? Penso una volta al massimo e zero volte almeno. Dato che in pratica pochissimi validatori vanno offline, in realtà penso che il rischio di farlo sia piuttosto basso. I vantaggi consistono fondamentalmente nel fatto che il livello che un utente malintenzionato deve raggiungere è notevolmente aumentato e la gamma di scenari in cui la catena entra in modalità provvisoria in caso di vulnerabilità lato client è notevolmente aumentata, in modo che le persone possano effettivamente collaborare per capire cosa è andato storto.
Se la soglia del Quorum aumenta dal 67% all’80%, allora, supponendo che la proporzione che un cliente deve raggiungere aumenti dal 67% all’80%, allora il valore di un piccolo numero di clienti, o il valore che un piccolo numero di i clienti possono fornire, inizia davvero ad aumentare.
Altre preoccupazioni sulla censura
Altre preoccupazioni relative alla censura riguardano gli elenchi di inclusione o qualche alternativa agli elenchi di inclusione. Quindi, l’intera faccenda del proponente multi-parallelo, se funziona, potrebbe persino diventare un sostituto delle liste di inclusione. Hai bisogno dell'astrazione dell'account, hai bisogno dell'astrazione dell'account all'interno di un qualche tipo di protocollo.
Il motivo per cui ne hai bisogno è perché in questo momento i portafogli smart contract non beneficiano realmente dell’elenco di inclusione. I portafogli smart contract non beneficiano realmente di alcun tipo di garanzia di resistenza alla censura a livello di protocollo.
Trarrebbero vantaggio se ci fosse l’astrazione dell’account all’interno del protocollo. Quindi, ci sono molte cose, in realtà molte di queste cose sono preziose nella visione del centro L2 e nella visione del centro L1.
Penso che delle diverse idee di cui ho parlato, probabilmente circa la metà erano specifiche per Ethereum focalizzate su L2, ma l'altra metà era fondamentalmente per L2 come livello base per gli utenti di Ethereum e L1, o, come, direttamente per l'applicazione degli utenti come utente.
Utilizza i light client ovunque
In molti modi, è un po' triste il modo in cui interagiamo con lo spazio, siamo decentralizzati, siamo senza fiducia, chi in questa stanza sta eseguendo un client leggero sul suo computer che convalida il consenso? raro. Chi usa Ethereum fidandosi del portafoglio del browser di Infura? Tra cinque anni mi piacerebbe vedere invertito il numero delle mani alzate. Mi piacerebbe vedere portafogli che non si fidano di Infura per nulla. Dobbiamo integrare i light client.
Infura può continuare a fornire dati. Voglio dire, se non hai bisogno di fidarti di Infura, in realtà è un bene per Infura perché rende più semplice per loro costruire e distribuire l'infrastruttura, ma disponiamo di strumenti per rimuovere il requisito di fiducia.
Quello che possiamo fare è avere un sistema in cui l'utente finale esegue qualcosa di simile a un client leggero Helios. In realtà dovrebbe essere eseguito direttamente nel browser, convalidando direttamente il consenso di Ethereum. Se vuole verificare qualcosa sulla catena, come interagire con la catena, allora devi semplicemente verificare direttamente la prova Merkle.
Se lo fai, otterrai effettivamente un certo grado di mancanza di fiducia nelle tue interazioni con Ethereum. Questo è per L1. Inoltre, abbiamo bisogno anche di una soluzione equivalente per L2.
Sulla catena L1 ci sono intestazioni di blocco, stati, comitati di sincronizzazione e consenso. Se verifichi il consenso, se sai qual è l'intestazione del blocco, puoi attraversare il ramo Merkle e vedere qual è lo stato. Quindi, come possiamo fornire garanzie di sicurezza light client per L2? La radice dello stato di L2 è lì. Se si tratta di un Rollup di base, esiste uno smart contract e tale smart contract memorizza l'intestazione del blocco di L2. Oppure, se hai la pre-conferma, allora hai un contratto intelligente che memorizza chi è la pre-conferma, quindi determini chi è la pre-conferma e poi ascolti un sottoinsieme di due terzi delle loro firme.
Quindi, una volta ottenuta l'intestazione del blocco Ethereum, c'è una catena di fiducia abbastanza semplice, l'hash, il ramo Merkle e la firma che puoi verificare e puoi ottenere la verifica del client leggero. Lo stesso vale per qualsiasi L2.
Ne ho parlato con le persone in passato, e molte volte la risposta è stata, Oh mio Dio, è interessante, ma qual è il punto? Gran parte di L2 è multi-firma. Perché non ci fidiamo delle multi-firme per verificare le multi-firme?
Fortunatamente, dallo scorso anno, questo non è più vero. Optimism e Arbitrum sono nella prima fase del Rollup, il che significa che in realtà dispongono di sistemi di prova in esecuzione sulla catena e di un comitato di sicurezza che può coprirli in caso di vulnerabilità, ma il comitato di sicurezza deve superare una soglia di voto molto alta. , pari al 75% di 8 persone, la dimensione di Arbitrum aumenterà a 15 persone. Quindi, nel caso di Optimism e Arbitrum, non sono solo multisig, hanno sistemi di prova reali e quei sistemi di prova hanno effettivamente un ruolo, almeno in termini di avere la maggioranza del potere nel decidere quale catena è corretta o sbagliata .
EVM va anche oltre, credo che non abbia nemmeno un comitato di sicurezza, quindi è completamente trustless. Stiamo davvero iniziando a fare progressi in questo senso, e so che anche molti altri L2 stanno facendo progressi. Quindi L2 è molto più che un semplice multisig, quindi il concetto di light client per L2 inizia effettivamente ad avere senso.
Oggi possiamo già verificare il ramo Merkle, basta scrivere il codice. Domani potremo anche convalidare ZKVM, così potrai convalidare completamente Ethereum e L2 nel tuo portafoglio del browser.
Chi vuole essere un utente Ethereum senza fiducia in un portafoglio del browser? meravigliosa. Chi preferirebbe essere un utente Ethereum senza fiducia sul proprio cellulare? Che ne dici di un Raspberry Pi? Che ne dici di un orologio intelligente? Dalla stazione spaziale? Sistemeremo anche quello. Quindi, ciò di cui abbiamo bisogno è l'equivalente di una configurazione RPC che contenga non solo i server con cui stai parlando, ma anche le istruzioni effettive di autenticazione del light client. Questo è qualcosa su cui possiamo lavorare.
Strategie di resistenza quantistica
Il tempo per l’informatica quantistica si sta restringendo. Metaculous ritiene che i computer quantistici arriveranno all’inizio degli anni ’30, e alcuni pensano prima.
Quindi abbiamo bisogno di una strategia resistente ai quanti. Abbiamo una strategia resistente ai quanti. Ci sono quattro parti di Ethereum che sono vulnerabili al calcolo quantistico e ognuna ha alternative naturali.
Un'alternativa quantistica resistente a Verkle Tree è Starked Poseidon Hash, o se vogliamo essere più conservatori, possiamo usare le firme di consenso Blake, attualmente utilizziamo firme aggregate BLS, che possono essere sostituite con firme aggregate Stark. Blob utilizza KZG e può essere dimostrato utilizzando la codifica separata Merkle tree Stark. Gli account utente attualmente utilizzano ECDSA SECP256K1, che può essere sostituito con firme basate su hash e astrazione e aggregazione di account, portafogli di contratti intelligenti ERC 4337, ecc.
Una volta ottenuti questi, l'utente può impostare il proprio algoritmo di firma, utilizzando essenzialmente una firma basata su hash. Penso che dobbiamo davvero iniziare a pensare alla creazione effettiva di firme basate su hash in modo che i portafogli degli utenti possano facilmente aggiornarsi alle firme basate su hash.
Semplificazione del protocollo
Se desideri un livello di base robusto, il protocollo deve essere semplice. Non dovrebbe avere 73 hook casuali e una certa compatibilità con le versioni precedenti che esiste a causa di un'idea stupida e casuale che un ragazzo a caso di nome Vitalik ha avuto nel 2014.
Quindi è utile cercare di semplificare davvero e iniziare a eliminare davvero il debito tecnico. I log sono attualmente basati su filtri Bloom, che non funzionano bene e non sono abbastanza veloci, quindi sono necessari miglioramenti ai log per aggiungere una maggiore immutabilità, cosa che già facciamo sul lato stateless, limitando sostanzialmente lo stato di ogni blocco Visualizzazioni.
Ethereum è una collezione incredibile in questo momento, c'è RLP, c'è SSZ, c'è API e idealmente dovremmo usare semplicemente SSZ, ma almeno sbarazzarci di RLP, stato e dell'albero binario Merkle, una volta che hai l'albero binario Merkle, quindi tutto Ethereum è su un albero Merkle binario.
Fast Finality, Single Slot Finality (SSF), ripulisce i precompilatori inutilizzati, come il precompilatore ModX, che spesso causa errori di consenso, sarebbe bello se potessimo rimuoverlo e sostituirlo con codice di solidità ad alte prestazioni.
Riassumere
Essendo un robusto livello di base, Ethereum presenta vantaggi davvero unici, inclusi alcuni che Bitcoin non ha, come la decentralizzazione del consenso e una ricerca significativa sul recupero degli attacchi del 51%.
Penso che sia necessario rafforzare davvero questi punti di forza. Inoltre, riconosciamo e correggiamo i nostri difetti per garantire il rispetto di standard molto elevati. Queste idee sono pienamente compatibili con la roadmap aggressiva L1.
Una delle cose di cui sono più soddisfatto di Ethereum e del processo di sviluppo principale in particolare è che la nostra capacità di lavorare in parallelo è migliorata in modo significativo. Questo è un punto di forza, possiamo effettivamente lavorare su molte cose in parallelo. Quindi prendersi cura di questi argomenti non influisce effettivamente sulla capacità di migliorare l’ecosistema L1 e L2. Ad esempio, migliorando l'EVM L1 per rendere più semplice la crittografia. Attualmente è troppo costoso verificare gli hash Poseidon nell'EVM. Anche la crittografia a 384 bit è troppo costosa.
Quindi ci sono alcune idee su EOF, come i codici operativi SIMD, EVM max, ecc. Esiste la possibilità di collegare questo coprocessore ad alte prestazioni all'EVM. Questo è meglio per il Livello 2 perché possono verificare le prove in modo più economico, ed è meglio per le applicazioni del Livello 1 perché i protocolli sulla privacy come zk SNARK sono più economici.
Chi ha utilizzato i protocolli sulla privacy? Chi vuole pagare 40 canoni invece di 80 con un accordo sulla privacy? più persone. Il secondo gruppo può essere utilizzato sul Livello 2 e il Livello 1 può ottenere notevoli risparmi sui costi.
I “Tre Grandi” di Ethereum si riuniscono
Il 2024 è il decimo anniversario dell'Ethereum IC0. L'EthCC del 2024 ha invitato tutti e tre gli ex fondatori principali di Ethereum, Vitalik Buterin, Joseph Lubin e Gavin Wood, a partecipare all'incontro.
Dopo il discorso di Vitalik, sono stati invitati a fare una foto di gruppo insieme:
I Tre Grandi si stringono ancora la mano
