Ważnym, a nieustannie niedocenianym aspektem "braku zaufania", "zdania testu odejścia" i "suwerenności osobistej" jest prostota protokołu. Nawet jeśli protokół jest super zdecentralizowany z setkami tysięcy węzłów, ma 49% tolerancji na błędy bizantyjskie, a węzły w pełni weryfikują wszystko za pomocą bezpiecznych kwantowo peerdas i starks, jeśli protokół jest nieporęcznym chaosem setek tysięcy linii kodu i pięciu form kryptografii na poziomie doktoranckim, ostatecznie ten protokół nie przechodzi wszystkich trzech testów: * Nie jest bez zaufania, ponieważ musisz ufać małej grupie wysokich kapłanów, którzy mówią ci, jakie właściwości ma protokół * Nie przechodzi testu odejścia, ponieważ jeśli istniejące zespoły klientów odejdą, niezwykle trudno jest nowym zespołom osiągnąć ten sam poziom jakości * Nie jest suwerenny, ponieważ jeśli nawet najbardziej techniczne osoby nie mogą zbadać i zrozumieć tego, to nie jest w pełni twoje Jest również mniej bezpieczny, ponieważ każda część protokołu, szczególnie jeśli może wchodzić w interakcje z innymi częściami w skomplikowany sposób, niesie ryzyko, że protokół się zepsuje. Jednym z moich obaw związanych z rozwojem protokołu Ethereum jest to, że możemy być zbyt chętni do dodawania nowych funkcji, aby zaspokoić bardzo specyficzne potrzeby, nawet jeśli te funkcje powiększają protokół lub dodają całkowicie nowe typy interakcji lub skomplikowane kryptografie jako krytyczne zależności. Może to być korzystne dla krótkoterminowych zysków funkcjonalnych, ale jest to bardzo destrukcyjne dla zachowania długoterminowej suwerenności osobistej i stworzenia stuleci zdecentralizowanej hiperstruktury, która transcendentuje wzloty i upadki imperiów i ideologii. Podstawowym problemem jest to, że jeśli zmiany protokołu są oceniane z perspektywy "jak duże są to zmiany w istniejącym protokole", to pragnienie zachowania zgodności wstecznej oznacza, że dodatki zdarzają się znacznie częściej niż odejmowania, a protokół nieuchronnie powiększa się z czasem. Aby temu przeciwdziałać, proces rozwoju Ethereum potrzebuje wyraźnej funkcji "uproszczenia" / "zbierania śmieci". "Uproszczenie" ma trzy metryki: * Minimalizowanie całkowitej liczby linii kodu w protokole. Idealny protokół mieści się na jednej stronie - lub przynajmniej na kilku stronach * Unikanie niepotrzebnych zależności od fundamentalnie skomplikowanych komponentów technicznych. Na przykład protokół, którego bezpieczeństwo zależy wyłącznie od hashy (jeszcze lepiej: od dokładnie jednej funkcji haszującej) jest lepszy niż ten, który zależy od hashy i krat. Wrzucenie izogenii jest najgorsze, ponieważ (przepraszam naprawdę genialnych, pracowitych nerdów, którzy to wymyślili) nikt nie rozumie izogenii. * Dodawanie większej liczby _inwariantów_: podstawowych właściwości, na których protokół może polegać, na przykład EIP-6780 (usunięcie selfdestruct) dodało właściwość, że maksymalnie N slotów pamięci może być zmienianych na slot, co znacznie upraszcza rozwój klientów, a EIP-7825 (maksymalny koszt gazu na transakcję) dodał maksymalny koszt przetwarzania jednej transakcji, co znacznie pomaga ZK-EVM i równoległemu wykonaniu. Zbieranie śmieci może być fragmentaryczne lub może być na dużą skalę. Fragmentaryczne podejście stara się wziąć istniejące funkcje i uprościć je, aby były prostsze i bardziej sensowne. Przykładem są reformy kosztów gazu w Glamsterdam, które sprawiają, że wiele kosztów gazu, które wcześniej były arbitralne, zamiast tego zależy od małej liczby parametrów, które są wyraźnie związane z zużyciem zasobów. Jednym z dużych zbierania śmieci było zastąpienie PoW przez PoS. Inne prawdopodobnie wydarzy się jako część Lean consensus, otwierając możliwość naprawienia dużej liczby błędów jednocześnie ( ). Innym podejściem jest "kompatybilność wsteczna w stylu Rosetty", gdzie funkcje, które są skomplikowane, ale mało używane, pozostają użyteczne, ale są "zdemonetowane" z bycia częścią obowiązkowego protokołu i zamiast tego stają się kodem inteligentnego kontraktu, więc nowi deweloperzy klientów nie muszą się nimi przejmować. Przykłady: * Po aktualizacji do pełnej natywnej abstrakcji kont, wszystkie stare typy transakcji mogą zostać wycofane, a EOAs mogą być przekształcone w portfele inteligentnych kontraktów, których kod może przetwarzać wszystkie te typy transakcji * Możemy zastąpić istniejące prekompilacje (z wyjątkiem tych, które są _naprawdę_ potrzebne) kodem EVM lub później RISC-V * Możemy ostatecznie zmienić VM z EVM na RISC-V (lub inny prostszy VM); EVM mogłoby zostać przekształcone w inteligentny kontrakt w nowym VM. ...