Een belangrijk, en voortdurend ondergewaardeerd, aspect van "trustlessness", "het doorstaan van de walkaway-test" en "zelfsoevereiniteit" is de eenvoud van het protocol. Zelfs als een protocol super gedecentraliseerd is met honderden duizenden knooppunten, en het heeft 49% Byzantijnse fouttolerantie, en knooppunten verifiëren alles volledig met quantum-veilige peerdas en starks, als het protocol een onhandelbare rommel is van honderden duizenden regels code en vijf vormen van PhD-niveau cryptografie, faalt dat protocol uiteindelijk op alle drie de tests: * Het is niet trustless omdat je een kleine groep hoge priesters moet vertrouwen die je vertellen welke eigenschappen het protocol heeft * Het doorstaat de walkaway-test niet omdat als bestaande klantenteams weggaan, het extreem moeilijk is voor nieuwe teams om hetzelfde kwaliteitsniveau te bereiken * Het is niet zelfsoeverein omdat als zelfs de meest technische mensen het ding niet kunnen inspecteren en begrijpen, het niet volledig van jou is Het is ook minder veilig, omdat elk onderdeel van het protocol, vooral als het op ingewikkelde manieren met andere onderdelen kan interageren, een risico met zich meebrengt dat het protocol kapot gaat. Een van mijn angsten met de ontwikkeling van het Ethereum-protocol is dat we te gretig kunnen zijn om nieuwe functies toe te voegen om aan zeer specifieke behoeften te voldoen, zelfs als die functies het protocol opblazen of hele nieuwe soorten interactiecomponenten of ingewikkelde cryptografie als kritische afhankelijkheden toevoegen. Dit kan leuk zijn voor kortetermijnfunctionaliteitswinsten, maar het is zeer destructief voor het behoud van langetermijnzelfsoevereiniteit, en het creëren van een honderdjarige gedecentraliseerde hyperstructuur die de opkomst en ondergang van rijken en ideologieën overstijgt. Het kernprobleem is dat als protocolwijzigingen worden beoordeeld vanuit het perspectief van "hoe groot zijn ze als wijzigingen in het bestaande protocol", dan betekent de wens om achterwaartse compatibiliteit te behouden dat toevoegingen veel vaker plaatsvinden dan verwijderingen, en het protocol onvermijdelijk in de loop van de tijd opblaast. Om dit tegen te gaan, heeft het Ethereum-ontwikkelingsproces een expliciete functie voor "vereenvoudiging" / "garbage collection" nodig. "Vereenvoudiging" heeft drie metrics: * Minimaliseren van het totale aantal regels code in het protocol. Een ideaal protocol past op een enkele pagina - of in ieder geval een paar pagina's * Vermijden van onnodige afhankelijkheden van fundamenteel complexe technische componenten. Bijvoorbeeld, een protocol waarvan de beveiliging uitsluitend afhankelijk is van hashes (nog beter: van precies één hashfunctie) is beter dan een dat afhankelijk is van hashes en lattices. Het toevoegen van isogenieën is het slechtste van allemaal, omdat (sorry tegen de werkelijk briljante hardwerkende nerds die dat uitvonden) niemand isogenieën begrijpt. * Meer _invarianten_ toevoegen: kern eigenschappen waarop het protocol kan vertrouwen, bijvoorbeeld EIP-6780 (verwijdering van selfdestruct) voegde de eigenschap toe dat maximaal N opslagslots per slot kunnen worden gewijzigd, wat de ontwikkeling van klanten aanzienlijk vereenvoudigt, en EIP-7825 (per-transactie gaslimiet) voegde een maximum toe aan de kosten van het verwerken van één transactie, wat ZK-EVM's en parallelle uitvoering enorm helpt. Garbage collection kan geleidelijk zijn, of het kan op grote schaal zijn. De geleidelijke aanpak probeert bestaande functies te nemen en ze te stroomlijnen zodat ze eenvoudiger zijn en meer zin hebben. Een voorbeeld zijn de gasprijsreformen in Glamsterdam, die veel gasprijzen die voorheen willekeurig waren, in plaats daarvan afhankelijk maken van een klein aantal parameters die duidelijk zijn gekoppeld aan het verbruik van middelen. Een grootschalige garbage collection was het vervangen van PoW door PoS. Een andere zal waarschijnlijk plaatsvinden als onderdeel van Lean consensus, waardoor de ruimte wordt geopend om een groot aantal fouten tegelijkertijd te corrigeren ( ). Een andere aanpak is "Rosetta-stijl achterwaartse compatibiliteit", waarbij functies die complex maar weinig gebruikt zijn bruikbaar blijven maar "gedemoteerd" worden van onderdeel van het verplichte protocol en in plaats daarvan smart contractcode worden, zodat nieuwe klantontwikkelaars zich er niet mee hoeven te bemoeien. Voorbeelden: * Nadat we zijn geüpgraded naar volledige native accountabstractie, kunnen alle oude tx-types worden gepensioneerd, en kunnen EOAs worden omgezet in smart contract wallets waarvan de code al die transactie-types kan verwerken * We kunnen bestaande precompiles vervangen (behalve diegene die _echt_ nodig zijn) door EVM of later RISC-V code * We kunnen uiteindelijk de VM veranderen van EVM naar RISC-V (of een andere eenvoudigere VM); EVM kan worden omgezet in een smart contract in de nieuwe VM. Ten slotte willen we weg van het gevoel dat klantontwikkelaars de behoefte hebben om alle oudere versies van het Ethereum-protocol te behandelen. Dat kan worden overgelaten aan oudere klantversies die in docker-containers draaien. Op de lange termijn hoop ik dat de snelheid van verandering in Ethereum langzamer kan zijn. Ik denk om verschillende redenen dat dat uiteindelijk _moet_ gebeuren. Deze eerste vijftien jaar moeten deels worden gezien als een adolescentiefase waarin we veel ideeën hebben verkend en hebben gezien wat werkt en wat nuttig is en wat niet. We moeten proberen te voorkomen dat de delen die niet nuttig zijn een permanente last voor het Ethereum-protocol worden. In wezen willen we Ethereum verbeteren op een manier die er als volgt uitziet:

2026 is het jaar waarin we verloren terrein terugwinnen op het gebied van zelfsoevereiniteit en vertrouwenloosheid. Een deel van wat dit praktisch betekent: Volledige knooppunten: dankzij ZK-EVM en BAL zal het weer gemakkelijker worden om lokaal een knooppunt te draaien en de Ethereum-keten op je eigen computer te verifiëren. Helios: verifieer daadwerkelijk de gegevens die je ontvangt van RPC's in plaats van ze blindelings te vertrouwen. ORAM, PIR: vraag om gegevens van RPC's zonder te onthullen welke gegevens je vraagt, zodat je toegang kunt krijgen tot dapps zonder dat je toegangspatronen worden verkocht aan tientallen derden over de hele wereld. Sociale herstelportemonnees en tijdsloten: portemonnees die je niet al je geld laten verliezen als je je seedphrase kwijtraakt, of als een online of offline aanvaller je seedphrase steelt, en *ook* niet al je geld door Google laten terugdraaien. Privacy UX: maak privébetalingen vanuit je portemonnee, met dezelfde gebruikerservaring als het doen van openbare betalingen. Privacy censuurweerstand: privébetalingen met de ERC-4337 mempool, en binnenkort native AA + FOCIL, zonder afhankelijk te zijn van het ecosysteem van openbare omroepen. Toepassing UIs: gebruik meer dapps vanuit een on-chain UI met IPFS, zonder afhankelijk te zijn van vertrouwde servers die je zouden uitsluiten van praktische herstel van je activa als ze offline gaan, en die je een gekaapte UI zouden geven die je fondsen steelt als ze zelfs maar een milliseconde worden gehackt. In veel van deze gebieden hebben we de afgelopen tien jaar ernstige achteruitgang gezien in Ethereum. Knooppunten gingen van gemakkelijk te draaien naar moeilijk te draaien. Dapps gingen van statische pagina's naar ingewikkelde reuzen die al je gegevens naar een dozijn servers lekken. Portemonnees gingen van het routeren van alles via de RPC, wat elk knooppunt van je keuze kon zijn, inclusief op je eigen computer, naar het lekken van je gegevens naar een dozijn servers van hun keuze. Het bouwen van blokken werd meer gecentraliseerd, waardoor de garanties voor transactie-inclusie van Ethereum onder de grillen van een zeer klein aantal bouwers kwamen te staan. In 2026, niet meer. Elke compromis van waarden die Ethereum tot nu toe heeft gemaakt - elk moment waarop je misschien dacht, is het echt de moeite waard om ons zo veel te verdunnen in naam van mainstream adoptie - maken we dat compromis niet langer. Het zal een lange weg zijn. We zullen niet alles krijgen wat we willen in de volgende Kohaku-release, of de volgende hard fork, of de hard fork daarna. Maar het zal Ethereum transformeren in een ecosysteem dat niet alleen zijn huidige plaats in het universum verdient, maar een veel grotere. In de wereldcomputer is er geen gecentraliseerde heerser. Er is geen enkel punt van falen. Er is alleen liefde. Milady.