Важным и постоянно недооцененным аспектом "без доверия", "прохождения теста на уход" и "самостоятельности" является простота протокола. Даже если протокол супер децентрализован с сотнями тысяч узлов, и у него 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 таким образом, чтобы это выглядело так: