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: