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. Na koniec chcemy odejść od tego, że deweloperzy klientów czują potrzebę obsługi wszystkich starszych wersji protokołu Ethereum. To można pozostawić starszym wersjom klientów działającym w kontenerach docker. W dłuższej perspektywie mam nadzieję, że tempo zmian w Ethereum może być wolniejsze. Myślę, że z różnych powodów ostatecznie _musi_ się to zdarzyć. Te pierwsze piętnaście lat powinno być częściowo postrzegane jako etap dorastania, w którym eksplorowaliśmy wiele pomysłów i zobaczyliśmy, co działa, co jest użyteczne, a co nie. Powinniśmy dążyć do unikania części, które nie są użyteczne, aby nie były trwałym obciążeniem dla protokołu Ethereum. W zasadzie chcemy poprawić Ethereum w sposób, który wygląda tak:

2026 to rok, w którym odzyskamy utraconą ziemię w zakresie suwerenności i braku zaufania. Niektóre z praktycznych znaczeń tego: Pełne węzły: dzięki ZK-EVM i BAL ponownie stanie się łatwiej lokalnie uruchomić węzeł i zweryfikować łańcuch Ethereum na własnym komputerze. Helios: rzeczywiście weryfikuj dane, które otrzymujesz z RPC, zamiast ślepo im ufać. ORAM, PIR: żądaj danych z RPC bez ujawniania, jakich danych potrzebujesz, aby móc uzyskać dostęp do dapps bez sprzedawania twoich wzorców dostępu dziesiątkom stron trzecich na całym świecie. Portfele z odzyskiwaniem społecznym i blokady czasowe: portfele, które nie sprawią, że stracisz wszystkie swoje pieniądze, jeśli zgubisz swoją frazę seed, lub jeśli atakujący online lub offline wyciągnie twoją frazę seed, a *także* nie sprawią, że wszystkie twoje pieniądze będą dostępne dla Google. UX prywatności: dokonuj prywatnych płatności z portfela, z tym samym doświadczeniem użytkownika, co przy dokonywaniu publicznych płatności. Oporność na cenzurę prywatności: prywatne płatności z mempoola ERC-4337, a wkrótce natywne AA + FOCIL, bez polegania na ekosystemie publicznych nadawców. Interfejsy aplikacji: korzystaj z większej liczby dapps z interfejsu onchain z IPFS, bez polegania na zaufanych serwerach, które zablokowałyby cię w praktycznym odzyskiwaniu twoich aktywów, jeśli by się wyłączyły, i które dałyby ci przejęty interfejs, który kradnie twoje fundusze, jeśli zostaną zhakowane nawet na milisekundę. W wielu z tych obszarów, w ciągu ostatnich dziesięciu lat byliśmy świadkami poważnego cofnięcia w Ethereum. Węzły przeszły od łatwych do uruchomienia do trudnych do uruchomienia. Dapps przeszły od statycznych stron do skomplikowanych behemotów, które wyciekają wszystkie twoje dane do dziesiątek serwerów. Portfele przeszły od routingu wszystkiego przez RPC, który mógł być dowolnym węzłem według twojego wyboru, w tym na twoim własnym komputerze, do wycieku twoich danych do dziesiątek serwerów według ich wyboru. Budowanie bloków stało się bardziej scentralizowane, co postawiło gwarancje włączenia transakcji Ethereum pod kaprysy bardzo małej liczby budowniczych. W 2026 roku, już nie. Każdy kompromis wartości, który Ethereum poczyniło do tego momentu - każda chwila, w której mogłeś myśleć, czy naprawdę warto tak bardzo się rozcieńczać w imię mainstreamowej adopcji - nie będziemy już tego kompromisu czynić. Będzie to długa droga. Nie dostaniemy wszystkiego, czego chcemy w następnej wersji Kohaku, ani w następnej hard forku, ani w hard forku po tym. Ale uczyni to Ethereum ekosystemem, który zasługuje nie tylko na swoje obecne miejsce w uniwersum, ale na znacznie większe. W komputerze świata nie ma scentralizowanego władcy. Nie ma jednego punktu awarii. Jest tylko miłość. Milady.