Relatore: Vitalik Buterin, fondatore di Ethereum Compilato da: 0xxz, Golden Finance EthCC7 si è recentemente tenuto a Bruxelles. L'organizzatore ha invitato Vitalik, fondatore di Ethereum, a tenere un discorso programmatico. Vale la pena notare che il 2024 segna il decimo anniversario dell'IC0 di Ethereum. Dopo il discorso di Vitalik, i tre principali fondatori 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 da Vitalik, il fondatore di Ethereum, recentemente all'EthCC7, compilato da Golden Finance 0xxz. Rafforzamento dell'argomento del discorso L1: ottimizzare 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 funge semplicemente da validatore di prova per tutto L2. Forse fornire anche la possibilità di trasferire ETH tra diversi L2. Ma a parte questo, fondamentalmente è tutto. Sul lato destro dello spettro, c’è fondamentalmente 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. Metto Ethereum come strato base di L2, secondo da 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, le opzioni più estreme sono a sinistra, e a destra potrebbe essere uno strato di base, ma prova 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ò è in realtà quello di rendere realizzabili i rollup basati come modalità principale di funzionamento L2. Quindi ora, se vuoi che L2 abbia un'esperienza utente di prim'ordine, devi avere la tua pre-convalida, il che significa un selezionatore centralizzato o il tuo selezionatore decentralizzato. Se il loro consenso accelera, L2 non avrà più bisogno di farlo. Se vuoi davvero aumentare la scalabilità di L1, ci sarà meno bisogno anche di L2. Quindi, questo è 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 della robustezza di Ethereum
Un grande vantaggio di Ethereum è che ha un ecosistema di staking ampio e relativamente decentralizzato.

Il lato sinistro dell'immagine sopra è il grafico dell'hash rate di tutti i pool minerari di Bitcoin, mentre il lato destro è il grafico dello 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. Il Lido blu è in realtà una struttura strana, 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 questo settore, ma penso che sia ancora utile riconoscerlo. Questo è uno dei punti di forza unici su cui possiamo davvero costruire.

I vantaggi di robustezza di Ethereum includono anche: ● Avere un ecosistema multi-client: ci sono client di esecuzione Geth e client di esecuzione non Geth, e la percentuale di client di esecuzione non Geth supera addirittura quella dei client di esecuzione Geth. Una situazione simile si verifica anche nel sistema di consenso del cliente; ● Comunità internazionale: le persone si trovano in molti paesi diversi, inclusi progetti, L2, team, ecc. ● Ecosistema di conoscenza multicentrico: c'è la Fondazione Ethereum e ci sono team di clienti; anche team come il team Reth di Paradigm hanno recentemente aumentato la loro leadership nell'open source; pertanto, l'ecosistema Ethereum come livello di base presenta già questi vantaggi molto potenti. Penso che questo sia qualcosa di molto prezioso a cui non si dovrebbe rinunciare facilmente. Direi addirittura che ci sono passi chiari che possono essere compiuti per promuovere questi punti di forza e persino affrontare le nostre debolezze. Dove Ethereum L1 non riesce a soddisfare standard elevati? 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 lo 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 non poter investire i propri ETH in un Protocollo DeFi 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 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 c'è un gran numero di persone che non utilizzano 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 32 ETH in deposito, 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 volessimo scendere a 100.000 validatori, il requisito minimo salirebbe probabilmente 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 principale difficoltà nella gestione di 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 questi due 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%, in ETH ridotto, è un terzo di 32 milioni di ETH, ovvero circa 11 milioni di ETH. Chi spenderebbe 11 milioni di ETH per rompere 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 così in una certa misura, 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 è rendere più semplice 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 come Poseidon, una funzione hash amichevole per Stark. Una volta ottenuto questo, per verificare i blocchi Ethereum, non avrai più bisogno di un disco rigido. Puoi anche aggiungere in seguito uno ZKVM di tipo 1 in grado di verificare con Stark interi blocchi 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. verrà tagliato da qualche parte, se abbiamo un client stateless 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 entrambi i problemi, ovvero la soglia dei 32 ETH e la difficoltà di far funzionare i nodi, possono essere tecnicamente risolti. 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 legati allo staking liquido e i rischi legati 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 incontrassimo effettivamente 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 l’acquisto del 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 pensino 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 un jet privato, ho effettuato un attacco del 51%, ho ripreso i miei bitcoin e ho anche tenuto il mio jet privato e ho volato in giro. Un attacco più realistico potrebbe comportare l’effettuazione di depositi sugli scambi e cose come la compromissione dei protocolli DeFi. Ma l’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, c'è una prova immediata e verificabile 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 un software scritto per fare questo controllo, un'altra sfida con la revisione è se qualcuno vuole agli attacchi, possono farlo, iniziano ritardando le transazioni e i blocchi che non gradiscono per 30 secondi, quindi ritardandoli di un minuto, quindi ritardandoli di due minuti, e non hai nemmeno il consenso su quando rispondere . Quindi, dico, la censura è in realtà il rischio maggiore. 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. Questo potrebbe essere vero oggi, ma si basa su molti presupposti 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 online almeno la maggioranza dei nodi in base ad alcuni presupposti sulle condizioni della rete. L'argomentazione che sto cercando di sostenere 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 si tratta di un risultato matematicamente impossibile, almeno chiunque fosse offline in quel momento non sarebbe 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 diventerà 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à, sarebbe il 21% dei nodi che vanno offline a fermare la definitività. Questo è rischioso. 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, si sono verificati incidenti in cui dal 20% al 33% dei nodi erano 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%, 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. Altri problemi di 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é al momento i portafogli smart contract non beneficiano realmente degli elenchi 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. Delle varie idee di cui ho discusso, circa la metà sono probabilmente specifiche per le soluzioni L2 per Ethereum, ma l'altra metà è fondamentalmente applicabile agli utenti Ethereum con L2 come livello di base e L1, o applicazioni dirette all'utente. Utilizza i client leggeri ovunque In molti modi, è un po' triste il modo in cui interagiamo con l'industria, 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, in realtà è positivo per Infura se non hai bisogno di fidarti di 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 di uno schema 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 è basato su Rollup, 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 che hai l'intestazione del blocco Ethereum, hai 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 di 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. , diciamo il 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. Strategia anti-quantistica
Il tempo necessario per l’informatica quantistica si sta accorciando. 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. L'alternativa quantistica resistente a Verkle Tree è Starked Poseidon Hash, o se vogliamo essere più conservatori, possiamo usare la firma di consenso Blake, attualmente usiamo la firma aggregata BLS, che può essere sostituita dalla firma aggregata Stark. Blob utilizza KZG, che può essere dimostrato utilizzando gli alberi Merkle Stark codificati per la separazione. 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 ottenuto questo, l'utente può impostare il proprio algoritmo di firma, utilizzando sostanzialmente 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 una roadmap aggressiva L1. Una delle cose di cui sono più soddisfatto di Ethereum, in particolare del processo di sviluppo principale, è 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 occuparsi di questi argomenti in realtà non influisce sulla capacità di migliorare l’ecosistema L1 e L2. Ad esempio, migliorando l'EVM L1 per rendere più semplice la crittografia. La convalida degli hash Poseidon nell'EVM è attualmente troppo costosa. 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é può essere più economico verificare le prove, ed è meglio per le applicazioni del Livello 1 perché i protocolli sulla privacy come zk SNARK sono più economici. Chi ha utilizzato l'accordo sulla privacy? Chi vuole pagare una commissione di $ 40 invece di $ 80? Molte più persone sceglieranno la prima. Un secondo gruppo di utenti può effettuare transazioni sul Livello 2, mentre il Livello 1 può ridurre significativamente i costi. ​