Бутерин готовит радикальное упрощение протокола Ethereum

Основатель Ethereum Виталик Бутерин опубликовал подробный план по радикальному упрощению архитектуры Ethereum. Цель — сделать протокол максимально простым и устойчивым, снизив системные риски и повысив доступность разработки. Он предлагает отказаться от текущей виртуальной машины EVM в пользу RISC-V или другой минималистичной VM. Это потенциально даст 100-кратный прирост производительности и позволит значительно упростить консенсусный код. На фоне масштабируемости через сети 2-го уровня (L2) и прогресса в области доказательств с нулевым разглашением (ZK), Бутерин подчеркнул важность простоты как основы устойчивости. Он сравнивает архитектуру Ethereum с Bitcoin, отмечая, что излишняя сложность привела к увеличению затрат на разработку, безопасности и фрагментации экосистемы. Его цель — сделать Эфириум ближе к Биткоину по уровню понятности и предсказуемости. Виталик предлагает внедрение новой модели консенсуса с финализацией за 3 слота, которая убирает понятия эпох и комитета, снижает количество валидаторов и использует STARK-агрегации. Эта архитектура может быть реализована всего в 200 строках кода и обеспечит максимальную безопасность при минимальной сложности. Также она позволит упростить p2p-сеть и устранить лишние механизмы, такие как sync committee. В исполнении смарт-контрактов предлагается заменить EVM на RISC-V, поддерживаемый верификаторами и компилятором Solidity. На 1-м этапе EVM и RISC-V будут сосуществовать, а затем все прекомпайлы, кроме криптографических, заменят on-chain реализациями. В будущем же старые контракты EVM начнут исполняться через интерпретатор внутри RISC-V. Также предлагается унифицировать используемые компоненты протокола: один формат сериализации (SSZ), единый код восстановления данных (erasure code) и общее дерево состояний на основе бинарного Merkle-древа с оптимизированным хешем. Это позволит сократить количество кода, снизить нагрузку на узлы и ускорить работу ZK-доказательств. Наконец, Виталик предлагает ввести целевые ограничения на размер критически важного кода протокола, аналогично подходу проекта tinygrad. Весь устаревший код должен быть вынесен за пределы консенсусной области, чтобы новые реализации Ethereum могли игнорировать его без потерь в корректности.