En viktig och ständigt underskattad aspekt av "förtroendelöshet", "att klara walkaway-testet" och "självsuveränitet" är protokollets enkelhet. Även om ett protokoll är superdecentraliserat med hundratusentals noder, och har 49 % bysantinsk felresistens, och noder verifierar allt fullt ut med kvantsäkra peerdas och starks, om protokollet är en otymplig röra av hundratusentals rader kod och fem former av doktorandnivåkryptografi, misslyckas protokollet i slutändan med alla tre testerna: * Det är inte litlöst eftersom du måste lita på en liten klass av överstepräster som berättar vilka egenskaper protokollet har * Det klarar inte walkaway-testet eftersom om befintliga kundteam försvinner är det extremt svårt för nya team att nå samma kvalitetsnivå * Det är inte självbestämt för om inte ens de mest tekniska personerna kan inspektera och förstå saken, är den inte helt din Det är också mindre säkert, eftersom varje del av protokollet, särskilt om den kan interagera med andra delar på komplicerade sätt, innebär en risk att protokollet bryter mot protokollet. En av mina farhågor med utvecklingen av Ethereum-protokoll är att vi kan vara för ivriga att lägga till nya funktioner för att möta mycket specifika behov, även om dessa funktioner blåser upp protokollet eller lägger till helt nya typer av interagerande komponenter eller komplicerad kryptografi som kritiska beroenden. Detta kan vara trevligt för kortsiktiga funktionsvinster, men det är mycket destruktivt för att bevara långsiktig självständighet och skapa en hundraårig decentraliserad hyperstruktur som överskrider imperiers och ideologiers uppgång och fall. Kärnproblemet är att om protokolländringar bedöms utifrån perspektivet "hur stora är de som ändringar i det befintliga protokollet", så innebär viljan att bevara bakåtkompatibilitet att tillägg sker mycket oftare än subtraktioner, och protokollet sväller oundvikligen över tid. För att motverka detta behöver Ethereum-utvecklingsprocessen en explicit funktion för "förenkling" / "skräpsamling". "Förenkling" har tre mått: * Minimera totala rader kod i protokollet. Ett idealiskt protokoll får plats på en enda sida – eller åtminstone några sidor * Undviker onödiga beroenden av fundamentalt komplexa tekniska komponenter. Till exempel är ett protokoll vars säkerhet enbart beror på hashar (ännu bättre: på exakt en hashfunktion) bättre än ett som är beroende av hashar och gitter. Att lägga till isogenier är värst av allt, för (ursäkta till de riktigt briljanta, hårt arbetande nördarna som listade ut det där) ingen förstår isogenier. * Att lägga till fler _invarianter_: kärnegenskaper som protokollet kan förlita sig på, till exempel lade EIP-6780 (självförstörelse) till egenskapen att högst N lagringsplatser kan bytas ut per plats, vilket avsevärt förenklar klientutvecklingen, och EIP-7825 (per leverans gastak) lade till ett maximum på kostnaden för att hantera en transaktion, vilket i hög grad hjälper ZK-EVM och parallell exekvering. Sophämtning kan vara styckvis eller storskalig. Den fragmentariska metoden försöker ta befintliga funktioner och effektivisera dem så att de blir enklare och mer meningsfulla. Ett exempel är gaskostnadsreformerna i Glamsterdam, som gör att många gaskostnader som tidigare var godtyckliga istället beror på ett fåtal parametrar som tydligt är kopplade till resursförbrukning. En storskalig sophämtning ersatte PoW med PoS. En annan är sannolik att ske som en del av Lean-konsensus, vilket öppnar rummet för att rätta till ett stort antal misstag samtidigt ( ). Ett annat tillvägagångssätt är "Rosetta-liknande bakåtkompatibilitet", där funktioner som är komplexa men lite använda förblir användbara men "nedgraderas" från att vara en del av det obligatoriska protokollet och istället blir smart kontraktskod, så att nya klientutvecklare slipper bry sig om dem. Exempel: * Efter att vi uppgraderat till full inbyggd kontoabstraktion kan alla gamla transaktionstyper pensioneras, och EOA:er kan konverteras till smarta kontraktsplånböcker vars kod kan hantera alla dessa transaktionstyper * Vi kan ersätta befintliga prekompileringar (förutom de som _verkligen_ behövs) med EVM eller senare RISC-V-kod * Vi kan så småningom ändra VM från EVM till RISC-V (eller annan enklare VM); EVM skulle kunna göras om till ett smart kontrakt i den nya VM:n. Slutligen vill vi gå ifrån att klientutvecklare känner behovet av att hantera alla äldre versioner av Ethereum-protokollet. Det kan lämnas till äldre klientversioner som körs i docker-containrar. På lång sikt hoppas jag att förändringstakten till Ethereum kan bli långsammare. Jag tror att av olika skäl måste det i slutändan hända. Dessa första femton år bör delvis ses som en ungdomsfas där vi utforskade många idéer och såg vad som fungerar, vad som är användbart och vad som inte är det. Vi bör sträva efter att undvika att de delar som inte är användbara blir en permanent belastning på Ethereum-protokollet. I grund och botten vill vi förbättra Ethereum på ett sätt som ser ut så här:

2026 är året då vi tar tillbaka förlorad mark när det gäller självständighet och förtroendelöshet. Några av vad detta praktiskt betyder: Fullständiga noder: tack vare ZK-EVM och BAL blir det återigen enklare att lokalt köra en nod och verifiera Ethereum-kedjan på din egen dator. Helios: verifiera faktiskt datan du får från RPC:er istället för att blint lita på den. ORAM, PIR: be om data från RPC:er utan att avslöja vilken data du efterfrågar, så att du kan komma åt dappar utan att dina åtkomstmönster säljs till dussintals tredje parter över hela världen. Social återställningsplånböcker och tidslås: plånböcker som inte gör att du förlorar alla dina pengar om du tappar bort din seedphrase, eller om en online- eller offline-angripare extraherar din seedphrase, och som *också* inte gör att alla dina pengar backdooras av Google. Integritets-UX: gör privata betalningar från din plånbok, med samma användarupplevelse som vid offentliga betalningar. Motstånd mot integritetscensur: privata betalningar med ERC-4337-mempoolen, och snart inhemsk AA + FOCIL, utan att förlita sig på public service-ekosystemet. Applikationsgränssnitt: använd fler dapps från ett onchain-gränssnitt med IPFS, utan att förlita dig på betrodda servrar som skulle låsa dig från praktisk återställning av dina tillgångar om de gick offline, och som skulle ge dig ett kapat gränssnitt som stjäl dina pengar om de hackas ens en millisekund. Inom många av dessa områden har vi under de senaste tio åren sett allvarliga tillbakagångar för Ethereum. Noderna gick från lätta att köra till svåra att köra. Dapps gick från statiska sidor till komplicerade jättar som läcker all din data till ett dussin servrar. Plånböcker gick från att routa allt genom RPC, som kunde vara vilken nod du valde inklusive på din egen dator, till att läcka din data till ett dussin servrar efter eget val. Blockbyggandet blev mer centraliserat, vilket satte garantier för Ethereum-transaktionsinkludering under nycker hos ett mycket litet antal byggare. År 2026 är det inte längre. Varje kompromiss av värderingar som Ethereum har gjort hittills – varje ögonblick där du kanske funderat på om det verkligen är värt att späda ut oss själva så mycket i mainstream-antagandets namn – vi gör inte längre den kompromissen. Det kommer att bli en lång väg. Vi kommer inte att få allt vi vill ha i nästa Kohaku-släpp, eller nästa hard fork, eller hard fork efter det. Men det kommer att göra Ethereum till ett ekosystem som inte bara förtjänar sin nuvarande plats i universum, utan en mycket större sådan. I världens datorvärld finns det ingen centraliserad överherre. Det finns ingen enskild felpunkt. Det finns bara kärlek. Milady.