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: