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: