Важным и постоянно недооцененным аспектом "без доверия", "прохождения теста на уход" и "самостоятельности" является простота протокола. Даже если протокол супер децентрализован с сотнями тысяч узлов, и у него 49% толерантности к византийским сбоям, и узлы полностью проверяют все с помощью квантово-устойчивых перд и старков, если протокол представляет собой неукротимый беспорядок из сотен тысяч строк кода и пяти форм криптографии на уровне PhD, в конечном итоге этот протокол не проходит все три теста: * Он не без доверия, потому что вам нужно доверять небольшой группе высокопреосвященных, которые говорят вам, какие свойства имеет протокол * Он не проходит тест на уход, потому что если существующие команды клиентов уйдут, новым командам будет крайне сложно достичь того же уровня качества * Он не является самостоятельным, потому что если даже самые технически подкованные люди не могут проверить и понять это, он не полностью ваш Он также менее безопасен, потому что каждая часть протокола, особенно если она может взаимодействовать с другими частями сложными способами, несет риск поломки протокола. Одно из моих опасений по поводу разработки протокола Ethereum заключается в том, что мы можем быть слишком стремительными в добавлении новых функций для удовлетворения очень специфических потребностей, даже если эти функции раздувают протокол или добавляют целые новые типы взаимодействующих компонентов или сложной криптографии в качестве критических зависимостей. Это может быть приятно для краткосрочных функциональных улучшений, но это крайне разрушительно для сохранения долгосрочной самостоятельности и создания столетней децентрализованной гиперструктуры, которая превосходит восход и падение империй и идеологий. Основная проблема заключается в том, что если изменения протокола оцениваются с точки зрения "насколько они велики как изменения существующего протокола", то желание сохранить обратную совместимость означает, что добавления происходят гораздо чаще, чем вычитания, и протокол неизбежно раздувается со временем. Чтобы противодействовать этому, процесс разработки Ethereum нуждается в явной функции "упрощения" / "сборки мусора". "Упрощение" имеет три метрики: * Минимизация общего количества строк кода в протоколе. Идеальный протокол помещается на одну страницу - или, по крайней мере, на несколько страниц * Избегание ненужных зависимостей от фундаментально сложных технических компонентов. Например, протокол, безопасность которого полностью зависит от хешей (еще лучше: от точно одной хеш-функции), лучше, чем тот, который зависит от хешей и решеток. Включение изогений - это худший вариант, потому что (извините, настоящие блестящие трудолюбивые гики, которые это выяснили) никто не понимает изогений. * Добавление большего количества _инвариантов_: основных свойств, на которые протокол может полагаться, например, EIP-6780 (удаление самоуничтожения) добавило свойство, что не более N слотов хранения могут быть изменены на слот, значительно упрощая разработку клиентов, а EIP-7825 (потолок газа на транзакцию) добавил максимум на стоимость обработки одной транзакции, что значительно помогает ZK-EVM и параллельному выполнению. Сборка мусора может быть поэтапной или крупномасштабной. Поэтапный подход пытается взять существующие функции и упростить их, чтобы они были проще и имели больше смысла. Один из примеров - реформы стоимости газа в Гламстаде, которые делают многие стоимости газа, которые ранее были произвольными, зависеть от небольшого числа параметров, которые явно связаны с потреблением ресурсов. Одной из крупномасштабных сборок мусора было замена PoW на PoS. Другая, вероятно, произойдет в рамках Lean consensus, открывая возможность исправить множество ошибок одновременно ( ). Другой подход - это "обратная совместимость в стиле Розетты", где функции, которые сложны, но малоиспользуемы, остаются доступными, но "понижаются" с обязательного протокола и вместо этого становятся кодом смарт-контракта, чтобы новые разработчики клиентов не беспокоились о них. Примеры: * После того как мы обновим до полной нативной абстракции аккаунтов, все старые типы транзакций могут быть выведены на пенсию, а EOAs могут быть преобразованы в смарт-контрактные кошельки, чей код может обрабатывать все эти типы транзакций * Мы можем заменить существующие предкомпили (за исключением тех, которые _действительно_ нужны) на код EVM или позже RISC-V * Мы можем в конечном итоге изменить VM с EVM на RISC-V (или другой более простой VM); EVM может быть превращен в смарт-контракт в новой VM. Наконец, мы хотим избавиться от необходимости разработчиков клиентов обрабатывать все старые версии протокола Ethereum. Это можно оставить старым версиям клиентов, работающим в контейнерах Docker. В долгосрочной перспективе я надеюсь, что скорость изменений в Ethereum может быть медленнее. Я думаю, что по различным причинам это в конечном итоге _должно_ произойти. Эти первые пятнадцать лет должны частично рассматриваться как стадия подросткового возраста, когда мы исследовали множество идей и увидели, что работает, что полезно, а что нет. Мы должны стремиться избежать того, чтобы бесполезные части стали постоянным бременем для протокола Ethereum. В основном, мы хотим улучшить Ethereum таким образом, чтобы это выглядело так:

2026 год — это год, когда мы восстановим утраченные позиции в плане самоуправления и доверия. Некоторые практические аспекты этого: Полные узлы: благодаря ZK-EVM и BAL снова станет проще запускать узел локально и проверять цепочку Ethereum на своем компьютере. Helios: фактически проверяйте данные, которые вы получаете от RPC, вместо того чтобы слепо им доверять. ORAM, PIR: запрашивайте данные у RPC, не раскрывая, какие данные вы запрашиваете, чтобы иметь доступ к dapps, не позволяя вашим паттернам доступа продаваться десяткам третьих сторон по всему миру. Кошельки с социальной восстановлением и таймлоки: кошельки, которые не заставят вас потерять все ваши деньги, если вы потеряете свою seedphrase, или если онлайн- или оффлайн-атакующий извлечет вашу seedphrase, и *также* не позволят Google получить доступ ко всем вашим деньгам. UX конфиденциальности: осуществляйте частные платежи из вашего кошелька с тем же пользовательским опытом, что и при осуществлении публичных платежей. Сопротивление цензуре конфиденциальности: частные платежи с использованием мемпула ERC-4337, и вскоре нативные AA + FOCIL, без зависимости от экосистемы публичных вещателей. UI приложений: используйте больше dapps из onchain UI с IPFS, не полагаясь на доверенные серверы, которые могут заблокировать вас от практического восстановления ваших активов, если они выйдут из строя, и которые могут предоставить вам захваченный UI, который украдет ваши средства, если они будут взломаны даже на миллисекунду. Во многих из этих областей за последние десять лет мы наблюдали серьезное отступление в Ethereum. Узлы стали сложнее запускать. Dapps превратились из статических страниц в сложные монстры, которые утечкуют все ваши данные на десятки серверов. Кошельки стали передавать все через RPC, который мог быть любым узлом на ваш выбор, включая ваш собственный компьютер, в утечку ваших данных на десятки серверов по их выбору. Создание блоков стало более централизованным, ставя гарантии включения транзакций Ethereum под каприз очень небольшого числа строителей. В 2026 году этого больше не будет. Каждая компрометация ценностей, которую Ethereum сделал до этого момента — каждый момент, когда вы могли подумать, стоит ли действительно так сильно размывать себя ради массового принятия — мы больше не будем делать этот компромисс. Это будет долгий путь. Мы не получим всего, что хотим, в следующем релизе Kohaku, или в следующем хардфорке, или в хардфорке после этого. Но это сделает Ethereum экосистемой, которая заслуживает не только своего текущего места во вселенной, но и гораздо большего. В мировом компьютере нет централизованного владыки. Нет единой точки отказа. Есть только любовь. Milady.