Un aspetto importante, e perennemente sottovalutato, di "trustlessness", "superare il test del walkaway" e "autosufficienza" è la semplicità del protocollo. Anche se un protocollo è super decentralizzato con centinaia di migliaia di nodi, e ha una tolleranza ai guasti byzantini del 49%, e i nodi verificano completamente tutto con peerdas e starks a prova di quantum, se il protocollo è un pasticcio ingombrante di centinaia di migliaia di righe di codice e cinque forme di crittografia a livello di dottorato, alla fine quel protocollo fallisce tutti e tre i test: * Non è trustless perché devi fidarti di una piccola classe di alti sacerdoti che ti dicono quali proprietà ha il protocollo * Non supera il test del walkaway perché se i team di client esistenti scompaiono, è estremamente difficile per i nuovi team raggiungere lo stesso livello di qualità * Non è autosufficiente perché se anche le persone più tecniche non possono ispezionare e comprendere la cosa, non è completamente tua È anche meno sicuro, perché ogni parte del protocollo, specialmente se può interagire con altre parti in modi complicati, comporta un rischio di rottura del protocollo. Una delle mie paure con lo sviluppo del protocollo Ethereum è che possiamo essere troppo ansiosi di aggiungere nuove funzionalità per soddisfare esigenze altamente specifiche, anche se quelle funzionalità gonfiano il protocollo o aggiungono interi nuovi tipi di componenti interattivi o crittografia complicata come dipendenze critiche. Questo può essere utile per guadagni funzionali a breve termine, ma è altamente distruttivo per preservare l'autosufficienza a lungo termine e creare una hyperstruttura decentralizzata di cento anni che trascende l'ascesa e la caduta di imperi e ideologie. Il problema centrale è che se le modifiche al protocollo vengono giudicate dalla prospettiva di "quanto sono grandi come cambiamenti rispetto al protocollo esistente", allora il desiderio di preservare la compatibilità retroattiva significa che le aggiunte avvengono molto più spesso delle sottrazioni, e il protocollo inevitabilmente si gonfia nel tempo. Per contrastare questo, il processo di sviluppo di Ethereum ha bisogno di una funzione esplicita di "semplificazione" / "raccolta di rifiuti". "Semplificazione" ha tre metriche: * Minimizzare il numero totale di righe di codice nel protocollo. Un protocollo ideale si adatta a una singola pagina - o almeno a poche pagine * Evitare dipendenze non necessarie da componenti tecnici fondamentalmente complessi. Ad esempio, un protocollo la cui sicurezza dipende esclusivamente da hash (ancora meglio: da esattamente una funzione hash) è migliore di uno che dipende da hash e reticoli. Aggiungere isogenie è il peggiore di tutti, perché (scusate i veri brillanti nerd laboriosi che hanno scoperto quelle cose) nessuno capisce le isogenie. * Aggiungere più _invarianti_: proprietà fondamentali su cui il protocollo può fare affidamento, ad esempio EIP-6780 (rimozione dell'autodistruzione) ha aggiunto la proprietà che al massimo N slot di archiviazione possono essere cambiati per slot, semplificando notevolmente lo sviluppo del client, e EIP-7825 (cappuccio del gas per transazione) ha aggiunto un massimo sul costo di elaborazione di una transazione, il che aiuta notevolmente gli ZK-EVM e l'esecuzione parallela. La raccolta di rifiuti può essere a pezzi, o può essere su larga scala. L'approccio a pezzi cerca di prendere funzionalità esistenti e semplificarle in modo che siano più semplici e abbiano più senso. Un esempio sono le riforme dei costi del gas a Glamsterdam, che fanno sì che molti costi del gas che erano precedentemente arbitrari, dipendano invece da un piccolo numero di parametri chiaramente legati al consumo di risorse. Una raccolta di rifiuti su larga scala è stata la sostituzione di PoW con PoS. Un'altra è probabile che accada come parte del consenso Lean, aprendo la possibilità di correggere un gran numero di errori contemporaneamente ( ). Un altro approccio è la "compatibilità retroattiva in stile Rosetta", dove funzionalità che sono complesse ma poco utilizzate rimangono utilizzabili ma vengono "declassate" da parte del protocollo obbligatorio e diventano invece codice di smart contract, in modo che i nuovi sviluppatori di client non debbano preoccuparsene. Esempi: * Dopo aver aggiornato a una piena astrazione degli account nativi, tutti i vecchi tipi di transazione possono essere ritirati, e gli EOA possono essere convertiti in portafogli di smart contract il cui codice può elaborare tutti quei tipi di transazione * Possiamo sostituire le precompilazioni esistenti (eccetto quelle che sono _veramente_ necessarie) con codice EVM o successivamente RISC-V * Possiamo eventualmente cambiare la VM da EVM a RISC-V (o un'altra VM più semplice); l'EVM potrebbe essere trasformato in uno smart contract nella nuova VM. Infine, vogliamo allontanarci dal fatto che gli sviluppatori di client sentano la necessità di gestire tutte le versioni precedenti del protocollo Ethereum. Questo può essere lasciato alle versioni più vecchie dei client che girano in contenitori docker. A lungo termine, spero che il tasso di cambiamento di Ethereum possa essere più lento. Penso che per vari motivi alla fine _deve_ succedere. Questi primi quindici anni dovrebbero essere visti in parte come una fase adolescenziale in cui abbiamo esplorato molte idee e visto cosa funziona e cosa è utile e cosa non lo è. Dobbiamo sforzarci di evitare che le parti che non sono utili siano un peso permanente sul protocollo Ethereum. Fondamentalmente, vogliamo migliorare Ethereum in un modo che assomiglia a questo:

Il 2026 è l'anno in cui recupereremo terreno perso in termini di autosufficienza e assenza di fiducia. Alcuni dei significati pratici di questo: Nodi completi: grazie a ZK-EVM e BAL, sarà di nuovo più facile eseguire localmente un nodo e verificare la catena di Ethereum sul proprio computer. Helios: verifica effettivamente i dati che ricevi dagli RPC invece di fidarti ciecamente. ORAM, PIR: chiedi dati agli RPC senza rivelare quali dati stai richiedendo, così puoi accedere a dapp senza che i tuoi schemi di accesso vengano venduti a decine di terze parti in tutto il mondo. Wallet di recupero sociale e timelock: wallet che non ti fanno perdere tutti i tuoi soldi se smarrisci la tua seedphrase, o se un attaccante online o offline estrae la tua seedphrase, e *anche* non fanno sì che tutti i tuoi soldi siano compromessi da Google. Privacy UX: effettua pagamenti privati dal tuo wallet, con la stessa esperienza utente dei pagamenti pubblici. Resistenza alla censura della privacy: pagamenti privati con il mempool ERC-4337, e presto nativi AA + FOCIL, senza fare affidamento sull'ecosistema dei broadcaster pubblici. Interfacce utente delle applicazioni: utilizza più dapp da un'interfaccia utente onchain con IPFS, senza fare affidamento su server fidati che ti escluderebbero dal recupero pratico dei tuoi beni se andassero offline, e che ti darebbero un'interfaccia utente compromessa che ruba i tuoi fondi se vengono hackerati anche solo per un millisecondo. In molte di queste aree, negli ultimi dieci anni abbiamo visto un serio regresso in Ethereum. I nodi sono passati da facili da eseguire a difficili da eseguire. Le dapp sono passate da pagine statiche a complicati colossi che perdono tutti i tuoi dati a una dozzina di server. I wallet sono passati dal reindirizzare tutto attraverso l'RPC, che poteva essere qualsiasi nodo di tua scelta, incluso il tuo computer, a perdere i tuoi dati a una dozzina di server di loro scelta. La costruzione dei blocchi è diventata più centralizzata, mettendo le garanzie di inclusione delle transazioni di Ethereum sotto il capriccio di un numero molto ridotto di costruttori. Nel 2026, non più. Ogni compromesso di valori che Ethereum ha fatto fino a questo punto - ogni momento in cui potresti aver pensato, ne vale davvero la pena diluirci così tanto in nome dell'adozione mainstream - non faremo più quel compromesso. Sarà una lunga strada. Non otterremo tutto ciò che vogliamo nel prossimo rilascio di Kohaku, o nel prossimo hard fork, o nell'hard fork successivo. Ma trasformerà Ethereum in un ecosistema che merita non solo il suo attuale posto nell'universo, ma uno molto più grande. Nel computer mondiale, non c'è un sovrano centralizzato. Non c'è un singolo punto di fallimento. C'è solo amore. Milady.