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: