Tärkeä ja jatkuvasti aliarvostettu piirre "luottamuksettomuudessa", "läpäisytestissä" ja "itsemääräämisoikeudessa" on protokollan yksinkertaisuus. Vaikka protokolla olisi erittäin hajautettu, jossa on satojatuhansia solmuja, ja sillä on 49 % bysanttimainen vikasietokyky, ja solmut varmistaisivat kaiken täysin kvanttiturvallisilla Peerda- ja Starkeilla, jos protokolla on kömpelö sekamelska, jossa on satojatuhansia koodirivejä ja viisi tohtoritason kryptografiamuotoa, lopulta protokolla epäonnistuu kaikissa kolmessa testissä: * Se ei ole luottamuksetonta, koska sinun täytyy luottaa pieneen ylipappien luokkaan, joka kertoo sinulle, mitä ominaisuuksia protokollalla on * Se ei läpäise walkaway-testiä, koska jos olemassa olevat asiakastiimit katoavat, uusien tiimien on erittäin vaikea päästä samaan laatutasoon * Se ei ole itseään hallitseva, koska jos edes teknisimmät ihmiset eivät pysty tutkimaan ja ymmärtämään sitä, se ei ole täysin sinun Se on myös vähemmän turvallinen, koska jokainen protokollan osa, erityisesti jos se voi olla vuorovaikutuksessa muiden osien kanssa monimutkaisilla tavoilla, sisältää riskin protokollan rikkoutumisesta. Yksi peloistani Ethereum-protokollan kehityksessä on, että saatamme olla liian innokkaita lisäämään uusia ominaisuuksia vastaamaan hyvin tarkkoja tarpeita, vaikka ne paisuttaisivat protokollaa tai lisäisivät kokonaan uusia vuorovaikuttavia komponentteja tai monimutkaista kryptografiaa kriittisinä riippuvuuksina. Tämä voi olla mukavaa lyhyen aikavälin toiminnallisuuden saavuttamiseksi, mutta se on erittäin tuhoisaa pitkän aikavälin itsehallinnon säilyttämiselle ja sadan vuoden hajautetun hyperrakenteen luomiselle, joka ylittää imperiumien ja ideologioiden nousun ja tuhon. Ydinongelma on, että jos protokollan muutokset arvioidaan "kuinka suuria ne ovat nykyisen protokollan muutoksina", halu säilyttää taaksepäin yhteensopivuus tarkoittaa, että lisäyksiä tapahtuu paljon useammin kuin vähennyksiä, ja protokolla väistämättä paisuu ajan myötä. Tämän torjumiseksi Ethereum-kehitysprosessi tarvitsee nimenomaisen "yksinkertaistamisen" / "roskien keräys"-toiminnon. "Yksinkertaistamisella" on kolme mittaria: * Protokollan koodirivien määrän minimoiminen. Ihanteellinen protokolla mahtuu yhdelle sivulle – tai ainakin muutamalle sivulle * Välttää tarpeettomia riippuvuuksia perustavanlaatuisesti monimutkaisista teknisistä komponenteista. Esimerkiksi protokolla, jonka turvallisuus riippuu yksinomaan hajautusarvoista (vielä parempi: täsmälleen yhdestä hajautusfunktiosta), on parempi kuin protokolla, joka perustuu hajautusarvoihin ja hiloihin. Isogeenien lisääminen on pahinta, koska (pahoittelut todella loistaville ahkerille nörteille, jotka keksivät tuon) kukaan ei ymmärrä isogeeniä. * Lisäämällä lisää _invariantteja_: ydinominaisuuksia, joihin protokolla voi luottaa, esimerkiksi EIP-6780 (itsetuhon poisto), lisäsi ominaisuuden, että korkeintaan N tallennuspaikkaa voidaan vaihtaa per paikka, mikä yksinkertaistaa merkittävästi asiakaskehitystä, ja EIP-7825 (per TX gas cap) lisäsi maksimimäärän yhden transaktion käsittelykustannuksiin, mikä auttaa merkittävästi ZK-EVM:iä ja rinnakkaista suoritusta. Roskien keräys voi olla joko pala kerrallaan tai laajamittaista. Palapalainen lähestymistapa pyrkii virtaviivaistamaan olemassa olevia ominaisuuksia niin, että ne ovat yksinkertaisempia ja järkevämpiä. Yksi esimerkki on Glamsterdamin kaasukustannusuudistukset, joissa monet aiemmin mielivaltaiset kaasukustannukset perustuvat pieneen määrään parametreja, jotka ovat selvästi sidoksissa resurssien kulutukseen. Yksi laajamittainen jätekeräys oli korvaamassa PoW PoS:lla. Toinen todennäköisesti tapahtuu osana Lean-konsensusta, mikä avaa tilaa korjata suuri määrä virheitä samanaikaisesti ( ). Toinen lähestymistapa on "Rosetta-tyylinen taaksepäin yhteensopivuus", jossa monimutkaiset mutta vähän käytetyt ominaisuudet pysyvät käyttökelpoisina, mutta ne "pudotetaan" pakollisen protokollan osasta ja muuttuvat älysopimuskoodiksi, jolloin uusien asiakaskehittäjien ei tarvitse vaivautua niiden kanssa. Esimerkkejä: * Kun päivitämme täyteen natiivitilien abstraktioon, kaikki vanhat tx-tyypit voidaan poistaa käytöstä, ja EOA:t voidaan muuntaa älykkäiksi sopimuslompakoiksi, joiden koodi pystyy käsittelemään kaikki nämä tapahtumatyypit * Voimme korvata olemassa olevat esikäännökset (paitsi ne, jotka ovat _todella_ tarpeellisia) EVM:llä tai myöhemmällä RISC-V-koodilla * Voimme lopulta vaihtaa virtuaalikoneen EVM:stä RISC-V:hen (tai muuhun yksinkertaisempaan virtuaalikoneen); EVM voitaisiin muuttaa älysopimukseksi uudessa virtuaalikoneessa. Lopuksi haluamme siirtyä pois siitä, että asiakaskehittäjät kokevat tarvetta käsitellä kaikkia vanhempia Ethereum-protokollan versioita. Sen voi jättää vanhemmille asiakasversioille, jotka toimivat docker-kontteissa. Pitkällä aikavälillä toivon, että siirtyminen Ethereumiin voi olla hitaampaa. Uskon, että monista syistä se lopulta _täytyy_ tapahtua. Nämä ensimmäiset viisitoista vuotta tulisi osittain nähdä nuoruuden vaiheena, jolloin tutkimme monia ideoita ja näimme, mikä toimii ja mikä on hyödyllistä ja mikä ei. Meidän tulisi pyrkiä välttämään ne osat, jotka eivät ole hyödyllisiä, jäämästä pysyväksi taakaksi Ethereum-protokollalle. Periaatteessa haluamme parantaa Ethereumia tavalla, joka näyttää tältä: