Důležitým, a často podceňovaným aspektem "nedůvěry", "úspěšného prostupování testem odchodu" a "sebesuverenity" je jednoduchost protokolu. I když je protokol extrémně decentralizovaný se stovkami tisíc uzlů, má 49% byzantskou odolnost vůči chybám a uzly vše plně ověřují pomocí kvantově bezpečných peerdů a starků, pokud je protokol neobratný chaos stovek tisíc řádků kódu a pěti forem kryptografie na úrovni PhD, nakonec protokol neprojde všemi třemi testy: * Není to bezpečné, protože musíte důvěřovat malé skupině velekněží, kteří vám řeknou, jaké vlastnosti protokolu má * Neprojde testem odchodu, protože pokud stávající klientské týmy zmizí, je extrémně těžké, aby nové týmy dosáhly stejné úrovně kvality * Není to samosprávné, protože pokud ani ti nejtechnicštější lidé nedokážou věci prohlédnout a pochopit, není to plně vaše Je také méně bezpečný, protože každá část protokolu, zvláště pokud může složitě interagovat s ostatními částmi, nese riziko porušení protokolu. Jedním z mých obav při vývoji protokolu Ethereum je, že můžeme být příliš ochotní přidávat nové funkce, abychom splnili vysoce specifické potřeby, i když tyto funkce protokol přetěžují nebo přidávají zcela nové typy interagujících komponent či složitou kryptografii jako kritické závislosti. To může být příjemné pro krátkodobé zlepšení funkčnosti, ale je to vysoce destruktivní pro zachování dlouhodobé suverenity a vytváření stoleté decentralizované hyperstruktury, která přesahuje vzestupy a pády impérií a ideologií. Jádrem problému je, že pokud jsou změny protokolu posuzovány z pohledu "jak velké jsou jako změny stávajícího protokolu", pak snaha zachovat zpětnou kompatibilitu znamená, že přidávání se děje mnohem častěji než odečítání a protokol se nevyhnutelně časem nafoukne. Aby se tomu vyvážilo, vývojový proces Etherea potřebuje explicitní funkci "zjednodušení" / "sběru odpadu". "Zjednodušení" má tři metriky: * Minimalizace celkového počtu řádků kódu v protokolu. Ideální protokol se vejde na jednu stránku – nebo alespoň na pár – * Vyhýbání se zbytečným závislostem na zásadně složitých technických komponentách. Například protokol, jehož bezpečnost závisí výhradně na hashích (ještě lépe: na přesně jedné hashovací funkci), je lepší než ten, který závisí na hashích a mřížkách. Nejhorší ze všeho je házet do izogení, protože (promiňte těm opravdu brilantním, pracovitým nerdům, kteří na to přišli) nikdo izogením nerozumí. * Přidání více _invariantů_: základních vlastností, na které se protokol může spoléhat, například EIP-6780 (odstranění samodestructu) přidalo vlastnost, že maximálně N úložných slotů lze změnit na slot, což výrazně zjednodušilo vývoj klienta, a EIP-7825 (limit na přenos plynu) přidal maximální náklady na zpracování jedné transakce, což výrazně pomáhá ZK-EVM a paralelnímu provádění. Sběr odpadu může být postupný, nebo rozsáhlý. Postupný přístup se snaží vzít stávající prvky a zjednodušit je tak, aby byly jednodušší a dávaly větší smysl. Příkladem jsou reformy cen plynu v Glamsterdamu, které způsobují, že mnohé dříve svévolné ceny plynu závisí na malém počtu parametrů, které jsou jasně spjaty se spotřebou zdrojů. Jedna velká sběr odpadu nahrazovala Zajatce PoS PoS. Další se pravděpodobně stane jako součást Lean konsenzu, kdy se otevře prostor pro opravu velkého množství chyb najednou ( ). Dalším přístupem je "zpětná kompatibilita ve stylu Rosetty", kdy funkce složité, ale málo používané zůstávají použitelné, ale jsou "degradovány" z povinného protokolu a místo toho se stávají kódem chytrých kontraktů, takže noví vývojáři klientů se s nimi nemusí zabývat. Příklady: * Po upgradu na plnou nativní abstrakci účtů lze všechny staré typy převodů vyřadit a EOA převést na peněženky s chytrými kontrakty, jejichž kód zvládne všechny tyto typy transakcí * Můžeme nahradit existující předkompilace (kromě těch, které jsou _opravdu_ potřebné) kódem EVM nebo novějším RISC-V * Postupně můžeme VM změnit z EVM na RISC-V (nebo jiný jednodušší VM); EVM by se v novém VM mohl přeměnit na chytrý kontrakt. Nakonec chceme odejít od toho, aby klientští vývojáři cítili potřebu spravovat všechny starší verze protokolu Ethereum. To lze nechat starším klientským verzím běžícím v docker kontejnerech. Dlouhodobě doufám, že tempo změn na Ethereum bude pomalejší. Myslím, že z různých důvodů se to nakonec _musí_ stát. Těchto prvních patnáct let by mělo být částečně vnímáno jako období dospívání, kdy jsme zkoumali spoustu myšlenek a viděli, co funguje, co je užitečné a co ne. Měli bychom se snažit vyhnout tomu, aby části, které nejsou užitečné, byly trvalou zátěží pro protokol Ethereum. V podstatě chceme vylepšit Ethereum takto: