Et viktig, og evig undervurdert, aspekt ved «tillitsløshet», «å bestå walkaway-testen» og «selv-suverenitet» er protokollens enkelhet. Selv om en protokoll er superdesentralisert med hundretusener av noder, og har 49 % bysantinsk feiltoleranse, og noder verifiserer alt fullt ut med kvantesikre peerdas og starks, hvis protokollen er et uhåndterlig rot av hundretusener av kodelinjer og fem former for PhD-nivå kryptografi, feiler protokollen til slutt alle tre testene: * Det er ikke tillitsløst fordi du må stole på en liten klasse yppersteprester som forteller deg hvilke egenskaper protokollen har * Det består ikke walkaway-testen fordi hvis eksisterende kundeteam forsvinner, er det ekstremt vanskelig for nye team å nå samme kvalitetsnivå * Den er ikke selvsuveren, for hvis selv de mest tekniske ikke kan inspisere og forstå den, er den ikke helt din Det er også mindre sikkert, fordi hver del av protokollen, spesielt hvis den kan samhandle med andre deler på kompliserte måter, innebærer en risiko for at protokollen brytes. En av mine frykter med utviklingen av Ethereum-protokoller er at vi kan være for ivrige etter å legge til nye funksjoner for å møte svært spesifikke behov, selv om disse funksjonene blåser opp protokollen eller legger til helt nye typer interagerende komponenter eller komplisert kryptografi som kritiske avhengigheter. Dette kan være fint for kortsiktige funksjonsgevinster, men det er svært ødeleggende for å bevare langsiktig selvsuverenitet og skape en hundreårig desentralisert hyperstruktur som overskrider opp- og nedgang av imperier og ideologier. Kjerneproblemet er at hvis protokollendringer vurderes ut fra perspektivet «hvor store er de som endringer i den eksisterende protokollen», betyr ønsket om å bevare bakoverkompatibilitet at tillegg skjer mye oftere enn subtraksjoner, og protokollen blåser uunngåelig opp over tid. For å motvirke dette trenger Ethereum-utviklingsprosessen en eksplisitt «forenkling» / «søppelrydding»-funksjon. "Forenkling" har tre måleparametere: * Minimerer totale kodelinjer i protokollen. En ideell protokoll passer på én side – eller i det minste noen få sider * Unngå unødvendige avhengigheter av fundamentalt komplekse tekniske komponenter. For eksempel er en protokoll hvis sikkerhet utelukkende avhenger av hasher (enda bedre: på nøyaktig én hashfunksjon) bedre enn en som er avhengig av hasher og gitter. Å legge til isogenier er verst av alt, fordi (beklager til de virkelig briljante, hardtarbeidende nerdene som fant ut av det) ingen forstår isogenier. * Ved å legge til flere _invarianter_: kjerneegenskaper som protokollen kan stole på, for eksempel la EIP-6780 (selvdestruksjonsfjerning) til egenskapen at maksimalt N lagringsplasser kan endres per plass, noe som betydelig forenkler klientutvikling, og EIP-7825 (per behandling gasskapsel) la til en maksimal kostnad for å behandle én transaksjon, noe som i stor grad hjelper ZK-EVM-er og parallell utførelse. Søppelsamling kan være stykkevis, eller det kan være storskala. Den stykkevise tilnærmingen prøver å ta eksisterende funksjoner og strømlinjeforme dem slik at de blir enklere og gir mer mening. Et eksempel er gasskostnadsreformene i Glamsterdam, som gjør at mange gasskostnader som tidligere var vilkårlige, i stedet avhenger av et lite antall parametere som tydelig er knyttet til ressursforbruk. En storskala søppelsamling erstattet PoW med PoS. En annen vil sannsynligvis skje som en del av Lean-konsensus, som åpner rommet for å rette opp et stort antall feil samtidig ( ). En annen tilnærming er «Rosetta-stil bakoverkompatibilitet», hvor funksjoner som er komplekse, men lite brukte, fortsatt kan brukes, men blir «nedgradert» fra å være en del av den obligatoriske protokollen og i stedet blir smart contract-kode, slik at nye klientutviklere slipper å bry seg om dem. Eksempler: * Etter at vi oppgraderer til full native kontoabstraksjon, kan alle gamle transaksjonstyper pensjoneres, og EOA-er kan konverteres til smartkontrakt-lommebøker hvor koden kan behandle alle disse transaksjonstypene * Vi kan erstatte eksisterende prekompileringer (bortsett fra de som _reelt_ trengs) med EVM eller senere RISC-V-kode * Vi kan etter hvert endre VM-en fra EVM til RISC-V (eller en enklere VM); EVM kunne gjøres om til en smart kontrakt i den nye VM-en. Til slutt ønsker vi å bevege oss bort fra at kundeutviklere føler behov for å håndtere alle eldre versjoner av Ethereum-protokollen. Det kan overlates til eldre klientversjoner som kjører i docker-containere. På lang sikt håper jeg at endringshastigheten til Ethereum kan bli lavere. Jeg tror av ulike grunner at det _må_ skje. Disse første femten årene bør delvis sees på som en ungdomsfase hvor vi utforsket mange ideer og så hva som fungerer, hva som er nyttig og hva som ikke er det. Vi bør forsøke å unngå at de delene som ikke er nyttige blir en permanent belastning på Ethereum-protokollen. I bunn og grunn ønsker vi å forbedre Ethereum på en måte som ser slik ut:

2026 er året hvor vi tar tilbake tapt terreng når det gjelder selvkontroll og tillitsløshet. Noe av hva dette praktisk betyr: Fullstendige noder: takket være ZK-EVM og BAL vil det igjen bli enklere å lokalt kjøre en node og verifisere Ethereum-kjeden på din egen datamaskin. Helios: verifiser faktisk dataene du mottar fra RPC-er i stedet for å stole blindt på dem. ORAM, PIR: Be om data fra RPC-er uten å avsløre hvilke data du ber om, slik at du kan få tilgang til dapps uten at tilgangsmønstrene dine blir solgt til dusinvis av tredjeparter over hele verden. Sosiale gjenopprettingslommebøker og tidslåser: lommebøker som ikke gjør at du mister alle pengene dine hvis du mister seedphrasen din, eller hvis en online eller offline angriper henter seedphrasen din, og *også* ikke gjør at alle pengene dine blir bakdørs av Google. Personvern-UX: gjør private betalinger fra lommeboken din, med samme brukeropplevelse som offentlige betalinger. Motstand mot personvernsensur: private betalinger med ERC-4337-mempoolen, og snart native AA + FOCIL, uten å være avhengig av det offentlige kringkasterøkosystemet. Applikasjonsgrensesnitt: bruk flere dapps fra et onchain-grensesnitt med IPFS, uten å være avhengig av pålitelige servere som ville låse deg ut av praktisk gjenoppretting av eiendelene dine hvis de gikk offline, og som ville gi deg et kapret brukergrensesnitt som stjeler pengene dine hvis de blir hacket i bare et millisekund. I mange av disse områdene har vi de siste ti årene sett alvorlig tilbakegang i Ethereum. Nodene gikk fra lett å kjøre til vanskelig å kjøre. Dapps gikk fra statiske sider til kompliserte kjemper som lekker all data til et dusin servere. Lommebøker gikk fra å rute alt gjennom RPC, som kunne være hvilken som helst node du ønsket, inkludert på din egen datamaskin, til å lekke dataene dine til et dusin servere etter eget valg. Blokkbygging ble mer sentralisert, og satte garantier for inkludering av Ethereum-transaksjoner under innfallene til et svært lite antall byggere. I 2026, ikke lenger. Hver kompromiss av verdier Ethereum har gjort til nå – hvert øyeblikk hvor du kanskje har tenkt på om det virkelig er verdt å vanne ut oss selv så mye i navnet til mainstream-adopsjon – vi inngår ikke lenger det kompromisset. Det blir en lang vei. Vi får ikke alt vi ønsker oss i neste Kohaku-utgivelse, eller neste hard fork, eller hard fork etter det. Men det vil gjøre Ethereum til et økosystem som ikke bare fortjener sin nåværende plass i universet, men en mye større en. I verdensdatamaskinen finnes det ingen sentralisert overherre. Det finnes ikke noe enkelt feilpunkt. Det finnes bare kjærlighet. Milady.