Эфирная сеть нацелена на то, чтобы стать глобальной бухгалтерской книгой, требующей масштабируемости и устойчивости. Эта статья сосредоточена на важности простоты протокола, предлагая значительно снизить сложность за счет упрощения уровня консенсуса (финализация за 3 слота, агрегирование STARK) и уровня исполнения (замена EVM на RISC-V или аналогичную виртуальную машину), что уменьшает затраты на разработку, риск ошибок и поверхность атак. Рекомендуется плавный переход через стратегию обратной совместимости (например, интерпретатор EVM на цепочке) и унификация кода исправления, формата сериализации (SSZ) и структуры дерева для дальнейшего упрощения. Цель состоит в том, чтобы сделать ключевой код консенсуса Эфира близким к простоте Биткойна, повысив устойчивость и участие, при этом необходимо культурное внимание к простоте и установка максимальной цели по количеству строк кода.
Цель Ethereum заключается в том, чтобы стать глобальным реестром: платформой для хранения активов и записей человеческой цивилизации, обслуживающей такие области, как финансы, управление и сертификация высокоценных данных. Это требует поддержки с двух сторон: масштабируемости и устойчивости. Планы по жесткому форку Fusaka увеличат доступное пространство для данных L2 в 10 раз, а текущая предложенная дорожная карта на 2026 год также планирует аналогичное значительное повышение для уровня L1. В то же время Ethereum завершил переход на доказательство доли (PoS), разнообразие клиентов быстро увеличивается, исследования по нулевым знаниям (ZK) и квантовой стойкости также устойчиво продолжаются, а экосистема приложений становится все более прочной.
Данная статья направлена на внимание к одному не менее важному, но часто недооценённому элементу устойчивости (а также масштабируемости): простоте протокола.
Убедительность биткойн-протокола заключается в его элегантной простоте:
Существует цепочка, состоящая из блоков, каждый из которых связан с предыдущим блоком с помощью хэширования.
Эффективность блока проверяется с помощью доказательства выполнения работы (PoW), то есть проверяется, равны ли первые несколько цифр хэш-значения нулю.
Каждый блок содержит транзакции, средства для транзакций поступают либо из вознаграждения за майнинг, либо из предыдущих выходов транзакций.
И только! Даже умный старшеклассник может полностью понять, как работает протокол биткойна, а программист может даже написать клиент в качестве любительского проекта.
Простота протокола приносит множество ключевых преимуществ для Биткойна (а также Эфириума) как надежного, нейтрального глобального базового слоя:
Легко понять: снизить сложность протокола, чтобы больше людей могли участвовать в исследовании, разработке и управлении протоколом, уменьшив риски, связанные с доминированием технической элиты.
Снижение затрат на разработку: упрощение протокола значительно снижает стоимость создания новой инфраструктуры (например, новых клиентов, доказателей, инструментов для разработчиков и т.д.).
Снижение нагрузки на обслуживание: уменьшение затрат на поддержку долгосрочных соглашений.
Снижение риска ошибок: уменьшение вероятности возникновения катастрофических ошибок в спецификациях и реализации протокола, а также упрощение проверки отсутствия таких ошибок.
Сужение атакующей поверхности: снижение сложности компонентов протокола, уменьшение риска атак со стороны специальных интересов.
В истории Ethereum (иногда из-за моих личных решений) часто не удавалось сохранить простоту, что приводило к слишком высоким затратам на разработку, увеличению рисков безопасности и закрытости культуры исследований и разработок, в то время как выгоды от этой сложности часто оказывались иллюзорными. В этой статье будет рассмотрено, как через пять лет Ethereum приблизится к простоте Bitcoin.
Упрощенный уровень консенсуса
Новый дизайн уровня консенсуса (исторически известный как «Маяковая цепь») нацелен на использование опыта последних десяти лет в области теории консенсуса, разработки ZK-SNARK, стейкинговой экономики и других областей для создания долгосрочного оптимального и более простого уровня консенсуса. По сравнению с существующей маяковой цепью, новый дизайн значительно упрощает:
Дизайн с окончательной блокировкой на 3 слота: удаление концепций слота, эпохи и реорганизации комитета, а также связанных с ними эффективных механизмов обработки (таких как синхронизированный комитет). Основная реализация окончательной блокировки на 3 слота требует всего около 200 строк кода и по сравнению с Gasper обладает почти оптимальной безопасностью.
Сокращение числа активных валидаторов: разрешение использования более простых правил выбора ответвлений для повышения безопасности.
Протокол агрегирования на основе STARK: любой может стать агрегатором, не доверяя агрегатору или не оплачивая высокие расходы на повторные битовые поля. Сложность агрегирующей криптографии высока, но ее сложность высоко завернута, системные риски низки.
Упрощенная P2P архитектура: указанные выше факторы могут способствовать созданию более простой и надежной сети однорангового соединения.
Перепроектирование механизма валидаторов: включает механизмы входа, выхода, вывода средств, обмена ключами, утечки бездействия и т. д., упрощение количества строк кода и предоставление более ясных гарантий (например, период слабой субъективности).
Преимущества уровня консенсуса заключаются в его относительной независимости от уровня исполнения EVM, что дает больше возможностей для постоянного улучшения. Большая проблема заключается в том, как достичь подобного упрощения на уровне исполнения.
Упрощенный уровень исполнения
Сложность EVM продолжает расти, и многие из этих сложностей оказались ненужными (частично из-за моих личных ошибок в принятии решений): 256-битная виртуальная машина чрезмерно оптимизировала устаревшие формы криптографии, а предкомпилированные функции (precompiles) оптимизировались для единственного случая, но редко используются.
Постепенное решение этих проблем имеет ограниченный эффект. Например, удаление операции SELFDESTRUCT требует огромных усилий, но приносит лишь небольшие выгоды. Недавние споры о EOF (формат объектов EVM) также показывают аналогичные проблемы.
Недавно я предложил более радикальное решение: вместо того чтобы вносить изменения среднего масштаба (хотя и разрушительные) в EVM для получения 1,5-кратной выгоды, лучше перейти к более оптимальной и простой виртуальной машине для достижения 100-кратной выгоды. Похожим образом на "слияние" (The Merge) мы сокращаем количество разрушительных изменений, но делаем каждое изменение более значимым. В частности, я предлагаю заменить EVM на RISC-V или другую виртуальную машину, используемую Ethereum ZK-проказчиками. Это приведет к:
Существенное повышение эффективности: выполнение смарт-контрактов (в доказателе) не требует накладных расходов интерпретатора и выполняется напрямую. Данные Succinct показывают, что в многих сценариях производительность может увеличиться более чем в 100 раз.
Значительное упрощение: спецификация RISC-V чрезвычайно проста по сравнению с EVM, альтернативы (такие как Cairo) также просты.
Мотивы поддержки EOF: такие как разделение кода, более дружелюбный статический анализ, большие ограничения на размер кода и т.д.
Больше выбор разработчиков: Solidity и Vyper могут добавлять бэкэнд для компиляции в новую виртуальную машину. Если выбрать RISC-V, разработчики основных языков также смогут легко перенести код в эту виртуальную машину.
Удалить большую часть предкомпилированного: возможно, оставить только высоко оптимизированные операции эллиптических кривых (после распространения квантовых компьютеров даже они исчезнут).
Основным недостатком является то, что в отличие от готового EOF, выгоды от новой виртуальной машины потребуют больше времени, чтобы достичь разработчиков. Мы можем смягчить эту проблему за счет краткосрочной реализации высокоценного улучшения EVM (например, увеличения ограничения на размер кода контракта, поддержки DUP/SWAP17–32).
Это приведет к более простой виртуальной машине. Основная проблема заключается в том, как справиться с существующим EVM?
Стратегия обратной совместимости для перехода виртуальных машин
Основная задача упрощения (или улучшения без увеличения сложности) EVM заключается в том, как сбалансировать достижение целей и обратную совместимость с существующими приложениями.
Прежде всего, необходимо уточнить: кодовая база Ethereum (даже внутри одного клиента) не имеет единого способа определения.
Цель состоит в том, чтобы максимально сократить зеленую область: логика, необходимая для участия узлов в консенсусе Ethereum, включая вычисление текущего состояния, доказательство, верификацию, FOCIL (правило выбора разветвлений) и построение "обычных" блоков.
Оранжевая область не может быть уменьшена: если протокол удаляет или изменяет какую-либо функциональность уровня выполнения (например, виртуальная машина, предкомпиляция и т.д.), клиент, обрабатывающий исторические блоки, все равно должен сохранить соответствующий код. Однако новые клиенты, ZK-EVM или формализованные доказатели могут полностью игнорировать оранжевую область.
Новая желтая область: очень ценна для понимания текущей цепочки или оптимизации построения блоков, но не относится к логике консенсуса. Например, Etherscan и некоторые строители блоков поддерживают операции пользователей ERC-4337. Если мы заменим некоторые функции Ethereum (такие как EOA и поддерживаемые ими старые типы транзакций) реализацией RISC-V на цепочке, код консенсуса значительно упростится, но специализированные узлы могут продолжать использовать оригинальный код для анализа.
Сложность оранжевой и желтой зон заключается в упаковке сложности. Понимающие протокол могут пропустить эти части, Ethereum может игнорировать их, ошибки в этих областях не приведут к риску согласия. Поэтому кодовая сложность оранжевых и желтых зон гораздо менее опасна, чем сложность зеленой зоны.
Идея переноса кода из зеленой зоны в желтую зону схожа с стратегией Apple по обеспечению долгосрочной обратной совместимости через слой перевода Rosetta.
Вдохновленный недавней статьей команды Ipsilon, я предлагаю следующий процесс изменения виртуальной машины (на примере EVM на RISC-V, но также применимо для EVM на Cairo или RISC-V на более оптимальные виртуальные машины):
Требуется предоставить реализацию RISC-V на блокчейне в новом предварительно скомпилированном варианте: чтобы экосистема постепенно адаптировалась к виртуальной машине RISC-V.
Внедрение RISC-V как опции для разработчиков: протокол одновременно поддерживает RISC-V и EVM, контракты двух виртуальных машин могут свободно взаимодействовать.
Замена большинства предкомпилированных функций: кроме операций с эллиптическими кривыми и KECCAK (из-за необходимости в максимальной скорости), замена других предкомпилированных функций на RISC-V. Удаление предкомпилированных функций через хард-форк, одновременно изменяя код по этому адресу (аналогично форку DAO) с пустого на реализацию RISC-V. Виртуальная машина RISC-V крайне проста, даже если на этом остановиться, это значительно упрощает протокол.
Реализация интерпретатора EVM в RISC-V: в качестве внедрения смарт-контрактов в блокчейн (поскольку требуется ZK-продавец). После нескольких лет начального выпуска существующие контракты EVM работают через этот интерпретатор.
После завершения шага 4 многие "реализации EVM" по-прежнему будут использоваться для оптимизации построения блоков, инструментов для разработчиков и анализа цепочек, но больше не будут частью ключевых стандартов консенсуса. Консенсус Ethereum будет "натурально" понимать только RISC-V.
Упрощение через компоненты общего протокола
Третий способ снизить общую сложность протокола (также наиболее недооцененный) заключается в том, чтобы по возможности делиться едиными стандартами на разных уровнях протокола. Разные протоколы, выполняющие одни и те же задачи в разных сценариях, обычно не приносят пользы, но такая модель все же часто встречается, в основном из-за недостатка коммуникации между различными частями дорожной карты протокола. Вот несколько конкретных примеров упрощения Ethereum через совместное использование компонентов.
Единый код для исправления ошибок
Нам нужны коды коррекции и удаления в трех сценариях:
Сэмплирование доступности данных: клиент проверяет, что блок был опубликован.
Более быстрое P2P вещание: узлы могут принимать блоки после получения n/2 фрагментов, достигая баланса между задержкой и избыточностью.
Распределённое историческое хранилище: фрагментированное хранение исторических данных Ethereum, каждая группа из n/2 фрагментов может восстановить оставшиеся фрагменты, снижая риск потери отдельного фрагмента.
Если использовать одну и ту же кодовую схему (будь то код Рида-Соломона, случайные линейные коды и т. д.) в трех разных сценариях, вы получите следующие преимущества:
Минимизация объема кода: уменьшение общего количества строк кода.
Повышение эффективности: если узел загружает часть фрагментов для определенной сцены, эти данные могут быть использованы для других сцен.
Обеспечение проверки: все фрагменты сцен можно проверить на основе корня.
Если используются разные коды исправления ошибок, необходимо как минимум обеспечить совместимость, например, горизонтальные коды Рида-Соломона для выборки доступности данных и вертикальные случайные линейные коды должны работать в одной области.
Унифицированный формат сериализации
Сейчас формат сериализации Ethereum лишь частично закреплён, так как данные могут быть сериализованы и транслированы в любом формате. Исключение составляет хэш подписи транзакции, который необходимо хэшировать в стандартизированном формате. В будущем степень закрепления формата сериализации будет повышена по следующим причинам:
Полная абстракция учетной записи (EIP-7701): Полное содержание транзакции доступно для виртуальной машины.
Более высокий лимит Gas: данные уровня выполнения должны быть помещены в блоки данных (blobs).
В это время у нас есть возможность унифицировать три уровня сериализации Ethereum: уровень исполнения, уровень консенсуса, вызов ABI смарт-контрактов.
Я предлагаю использовать SSZ, потому что SSZ:
Легко декодировать: включает в себя смарт-контракты (из-за своего дизайна на основе 4 байт и меньшего количества крайних случаев).
Широко используется на уровне консенсуса.
Высокая степень сходства с существующим ABI: инструмент адаптировать относительно просто.
Уже предприняты усилия по полной миграции на SSZ, и нам следует учитывать и продолжать эти усилия при планировании будущих обновлений.
Унифицированная древовидная структура
Если перейти с EVM на RISC-V (или другую альтернативную минимальную виртуальную машину), шестнадцатеричное дерево Меркла-Патриции станет максимальным узким местом для доказательства выполнения блока, даже в среднем случае. Переход на двоичное дерево с более оптимальной хеш-функцией значительно повысит эффективность доказателя, одновременно снижая стоимость данных для таких сценариев, как легкие клиенты.
При миграции необходимо убедиться, что уровень консенсуса использует одинаковую структуру дерева. Это позволит уровню консенсуса Ethereum и уровню выполнения получить доступ и разобрать их с помощью одного и того же кода.
От настоящего до будущего
Простота во многом схожа с децентрализацией; оба являются верхними целями устойчивости. Явное внимание к простоте требует определенной культурной трансформации. Ее выгоды часто трудно количественно оценить, в то время как дополнительные усилия и затраты на отказ от некоторых блестящих функций дают мгновенный эффект. Однако со временем выгоды станут все более заметными — сам Биткойн является отличным примером.
Я предлагаю подражать tinygrad и установить четкую максимальную цель по количеству строк кода для долгосрочных стандартов Ethereum, чтобы ключевой код консенсуса Ethereum приближался к простоте Bitcoin. Код, обрабатывающий исторические правила Ethereum, продолжит существовать, но должен находиться вне ключевого пути консенсуса. В то же время, мы должны придерживаться концепции выбора более простых решений, отдавая предпочтение инкапсуляции сложности, а не системной сложности, и делать выбор в пользу проектирования, обеспечивающего четкие свойства и гарантии.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Виталик Бутерин: Как сделать Ethereum через 5 лет таким же простым, как Биткойн
Автор | Виталик Бутерин
Компиляция | GaryMa 吴 о блокчейне
Исходная ссылка:
Резюме
Эфирная сеть нацелена на то, чтобы стать глобальной бухгалтерской книгой, требующей масштабируемости и устойчивости. Эта статья сосредоточена на важности простоты протокола, предлагая значительно снизить сложность за счет упрощения уровня консенсуса (финализация за 3 слота, агрегирование STARK) и уровня исполнения (замена EVM на RISC-V или аналогичную виртуальную машину), что уменьшает затраты на разработку, риск ошибок и поверхность атак. Рекомендуется плавный переход через стратегию обратной совместимости (например, интерпретатор EVM на цепочке) и унификация кода исправления, формата сериализации (SSZ) и структуры дерева для дальнейшего упрощения. Цель состоит в том, чтобы сделать ключевой код консенсуса Эфира близким к простоте Биткойна, повысив устойчивость и участие, при этом необходимо культурное внимание к простоте и установка максимальной цели по количеству строк кода.
Цель Ethereum заключается в том, чтобы стать глобальным реестром: платформой для хранения активов и записей человеческой цивилизации, обслуживающей такие области, как финансы, управление и сертификация высокоценных данных. Это требует поддержки с двух сторон: масштабируемости и устойчивости. Планы по жесткому форку Fusaka увеличат доступное пространство для данных L2 в 10 раз, а текущая предложенная дорожная карта на 2026 год также планирует аналогичное значительное повышение для уровня L1. В то же время Ethereum завершил переход на доказательство доли (PoS), разнообразие клиентов быстро увеличивается, исследования по нулевым знаниям (ZK) и квантовой стойкости также устойчиво продолжаются, а экосистема приложений становится все более прочной.
Данная статья направлена на внимание к одному не менее важному, но часто недооценённому элементу устойчивости (а также масштабируемости): простоте протокола.
Убедительность биткойн-протокола заключается в его элегантной простоте:
Существует цепочка, состоящая из блоков, каждый из которых связан с предыдущим блоком с помощью хэширования.
Эффективность блока проверяется с помощью доказательства выполнения работы (PoW), то есть проверяется, равны ли первые несколько цифр хэш-значения нулю.
Каждый блок содержит транзакции, средства для транзакций поступают либо из вознаграждения за майнинг, либо из предыдущих выходов транзакций.
И только! Даже умный старшеклассник может полностью понять, как работает протокол биткойна, а программист может даже написать клиент в качестве любительского проекта.
Простота протокола приносит множество ключевых преимуществ для Биткойна (а также Эфириума) как надежного, нейтрального глобального базового слоя:
Легко понять: снизить сложность протокола, чтобы больше людей могли участвовать в исследовании, разработке и управлении протоколом, уменьшив риски, связанные с доминированием технической элиты.
Снижение затрат на разработку: упрощение протокола значительно снижает стоимость создания новой инфраструктуры (например, новых клиентов, доказателей, инструментов для разработчиков и т.д.).
Снижение нагрузки на обслуживание: уменьшение затрат на поддержку долгосрочных соглашений.
Снижение риска ошибок: уменьшение вероятности возникновения катастрофических ошибок в спецификациях и реализации протокола, а также упрощение проверки отсутствия таких ошибок.
Сужение атакующей поверхности: снижение сложности компонентов протокола, уменьшение риска атак со стороны специальных интересов.
В истории Ethereum (иногда из-за моих личных решений) часто не удавалось сохранить простоту, что приводило к слишком высоким затратам на разработку, увеличению рисков безопасности и закрытости культуры исследований и разработок, в то время как выгоды от этой сложности часто оказывались иллюзорными. В этой статье будет рассмотрено, как через пять лет Ethereum приблизится к простоте Bitcoin.
Упрощенный уровень консенсуса
Новый дизайн уровня консенсуса (исторически известный как «Маяковая цепь») нацелен на использование опыта последних десяти лет в области теории консенсуса, разработки ZK-SNARK, стейкинговой экономики и других областей для создания долгосрочного оптимального и более простого уровня консенсуса. По сравнению с существующей маяковой цепью, новый дизайн значительно упрощает:
Дизайн с окончательной блокировкой на 3 слота: удаление концепций слота, эпохи и реорганизации комитета, а также связанных с ними эффективных механизмов обработки (таких как синхронизированный комитет). Основная реализация окончательной блокировки на 3 слота требует всего около 200 строк кода и по сравнению с Gasper обладает почти оптимальной безопасностью.
Сокращение числа активных валидаторов: разрешение использования более простых правил выбора ответвлений для повышения безопасности.
Протокол агрегирования на основе STARK: любой может стать агрегатором, не доверяя агрегатору или не оплачивая высокие расходы на повторные битовые поля. Сложность агрегирующей криптографии высока, но ее сложность высоко завернута, системные риски низки.
Упрощенная P2P архитектура: указанные выше факторы могут способствовать созданию более простой и надежной сети однорангового соединения.
Перепроектирование механизма валидаторов: включает механизмы входа, выхода, вывода средств, обмена ключами, утечки бездействия и т. д., упрощение количества строк кода и предоставление более ясных гарантий (например, период слабой субъективности).
Преимущества уровня консенсуса заключаются в его относительной независимости от уровня исполнения EVM, что дает больше возможностей для постоянного улучшения. Большая проблема заключается в том, как достичь подобного упрощения на уровне исполнения.
Упрощенный уровень исполнения
Сложность EVM продолжает расти, и многие из этих сложностей оказались ненужными (частично из-за моих личных ошибок в принятии решений): 256-битная виртуальная машина чрезмерно оптимизировала устаревшие формы криптографии, а предкомпилированные функции (precompiles) оптимизировались для единственного случая, но редко используются.
Постепенное решение этих проблем имеет ограниченный эффект. Например, удаление операции SELFDESTRUCT требует огромных усилий, но приносит лишь небольшие выгоды. Недавние споры о EOF (формат объектов EVM) также показывают аналогичные проблемы.
Недавно я предложил более радикальное решение: вместо того чтобы вносить изменения среднего масштаба (хотя и разрушительные) в EVM для получения 1,5-кратной выгоды, лучше перейти к более оптимальной и простой виртуальной машине для достижения 100-кратной выгоды. Похожим образом на "слияние" (The Merge) мы сокращаем количество разрушительных изменений, но делаем каждое изменение более значимым. В частности, я предлагаю заменить EVM на RISC-V или другую виртуальную машину, используемую Ethereum ZK-проказчиками. Это приведет к:
Существенное повышение эффективности: выполнение смарт-контрактов (в доказателе) не требует накладных расходов интерпретатора и выполняется напрямую. Данные Succinct показывают, что в многих сценариях производительность может увеличиться более чем в 100 раз.
Значительное упрощение: спецификация RISC-V чрезвычайно проста по сравнению с EVM, альтернативы (такие как Cairo) также просты.
Мотивы поддержки EOF: такие как разделение кода, более дружелюбный статический анализ, большие ограничения на размер кода и т.д.
Больше выбор разработчиков: Solidity и Vyper могут добавлять бэкэнд для компиляции в новую виртуальную машину. Если выбрать RISC-V, разработчики основных языков также смогут легко перенести код в эту виртуальную машину.
Удалить большую часть предкомпилированного: возможно, оставить только высоко оптимизированные операции эллиптических кривых (после распространения квантовых компьютеров даже они исчезнут).
Основным недостатком является то, что в отличие от готового EOF, выгоды от новой виртуальной машины потребуют больше времени, чтобы достичь разработчиков. Мы можем смягчить эту проблему за счет краткосрочной реализации высокоценного улучшения EVM (например, увеличения ограничения на размер кода контракта, поддержки DUP/SWAP17–32).
Это приведет к более простой виртуальной машине. Основная проблема заключается в том, как справиться с существующим EVM?
Стратегия обратной совместимости для перехода виртуальных машин
Основная задача упрощения (или улучшения без увеличения сложности) EVM заключается в том, как сбалансировать достижение целей и обратную совместимость с существующими приложениями.
Прежде всего, необходимо уточнить: кодовая база Ethereum (даже внутри одного клиента) не имеет единого способа определения.
Цель состоит в том, чтобы максимально сократить зеленую область: логика, необходимая для участия узлов в консенсусе Ethereum, включая вычисление текущего состояния, доказательство, верификацию, FOCIL (правило выбора разветвлений) и построение "обычных" блоков.
Оранжевая область не может быть уменьшена: если протокол удаляет или изменяет какую-либо функциональность уровня выполнения (например, виртуальная машина, предкомпиляция и т.д.), клиент, обрабатывающий исторические блоки, все равно должен сохранить соответствующий код. Однако новые клиенты, ZK-EVM или формализованные доказатели могут полностью игнорировать оранжевую область.
Новая желтая область: очень ценна для понимания текущей цепочки или оптимизации построения блоков, но не относится к логике консенсуса. Например, Etherscan и некоторые строители блоков поддерживают операции пользователей ERC-4337. Если мы заменим некоторые функции Ethereum (такие как EOA и поддерживаемые ими старые типы транзакций) реализацией RISC-V на цепочке, код консенсуса значительно упростится, но специализированные узлы могут продолжать использовать оригинальный код для анализа.
Сложность оранжевой и желтой зон заключается в упаковке сложности. Понимающие протокол могут пропустить эти части, Ethereum может игнорировать их, ошибки в этих областях не приведут к риску согласия. Поэтому кодовая сложность оранжевых и желтых зон гораздо менее опасна, чем сложность зеленой зоны.
Идея переноса кода из зеленой зоны в желтую зону схожа с стратегией Apple по обеспечению долгосрочной обратной совместимости через слой перевода Rosetta.
Вдохновленный недавней статьей команды Ipsilon, я предлагаю следующий процесс изменения виртуальной машины (на примере EVM на RISC-V, но также применимо для EVM на Cairo или RISC-V на более оптимальные виртуальные машины):
Требуется предоставить реализацию RISC-V на блокчейне в новом предварительно скомпилированном варианте: чтобы экосистема постепенно адаптировалась к виртуальной машине RISC-V.
Внедрение RISC-V как опции для разработчиков: протокол одновременно поддерживает RISC-V и EVM, контракты двух виртуальных машин могут свободно взаимодействовать.
Замена большинства предкомпилированных функций: кроме операций с эллиптическими кривыми и KECCAK (из-за необходимости в максимальной скорости), замена других предкомпилированных функций на RISC-V. Удаление предкомпилированных функций через хард-форк, одновременно изменяя код по этому адресу (аналогично форку DAO) с пустого на реализацию RISC-V. Виртуальная машина RISC-V крайне проста, даже если на этом остановиться, это значительно упрощает протокол.
Реализация интерпретатора EVM в RISC-V: в качестве внедрения смарт-контрактов в блокчейн (поскольку требуется ZK-продавец). После нескольких лет начального выпуска существующие контракты EVM работают через этот интерпретатор.
После завершения шага 4 многие "реализации EVM" по-прежнему будут использоваться для оптимизации построения блоков, инструментов для разработчиков и анализа цепочек, но больше не будут частью ключевых стандартов консенсуса. Консенсус Ethereum будет "натурально" понимать только RISC-V.
Упрощение через компоненты общего протокола
Третий способ снизить общую сложность протокола (также наиболее недооцененный) заключается в том, чтобы по возможности делиться едиными стандартами на разных уровнях протокола. Разные протоколы, выполняющие одни и те же задачи в разных сценариях, обычно не приносят пользы, но такая модель все же часто встречается, в основном из-за недостатка коммуникации между различными частями дорожной карты протокола. Вот несколько конкретных примеров упрощения Ethereum через совместное использование компонентов.
Единый код для исправления ошибок
Нам нужны коды коррекции и удаления в трех сценариях:
Сэмплирование доступности данных: клиент проверяет, что блок был опубликован.
Более быстрое P2P вещание: узлы могут принимать блоки после получения n/2 фрагментов, достигая баланса между задержкой и избыточностью.
Распределённое историческое хранилище: фрагментированное хранение исторических данных Ethereum, каждая группа из n/2 фрагментов может восстановить оставшиеся фрагменты, снижая риск потери отдельного фрагмента.
Если использовать одну и ту же кодовую схему (будь то код Рида-Соломона, случайные линейные коды и т. д.) в трех разных сценариях, вы получите следующие преимущества:
Минимизация объема кода: уменьшение общего количества строк кода.
Повышение эффективности: если узел загружает часть фрагментов для определенной сцены, эти данные могут быть использованы для других сцен.
Обеспечение проверки: все фрагменты сцен можно проверить на основе корня.
Если используются разные коды исправления ошибок, необходимо как минимум обеспечить совместимость, например, горизонтальные коды Рида-Соломона для выборки доступности данных и вертикальные случайные линейные коды должны работать в одной области.
Унифицированный формат сериализации
Сейчас формат сериализации Ethereum лишь частично закреплён, так как данные могут быть сериализованы и транслированы в любом формате. Исключение составляет хэш подписи транзакции, который необходимо хэшировать в стандартизированном формате. В будущем степень закрепления формата сериализации будет повышена по следующим причинам:
Полная абстракция учетной записи (EIP-7701): Полное содержание транзакции доступно для виртуальной машины.
Более высокий лимит Gas: данные уровня выполнения должны быть помещены в блоки данных (blobs).
В это время у нас есть возможность унифицировать три уровня сериализации Ethereum: уровень исполнения, уровень консенсуса, вызов ABI смарт-контрактов.
Я предлагаю использовать SSZ, потому что SSZ:
Легко декодировать: включает в себя смарт-контракты (из-за своего дизайна на основе 4 байт и меньшего количества крайних случаев).
Широко используется на уровне консенсуса.
Высокая степень сходства с существующим ABI: инструмент адаптировать относительно просто.
Уже предприняты усилия по полной миграции на SSZ, и нам следует учитывать и продолжать эти усилия при планировании будущих обновлений.
Унифицированная древовидная структура
Если перейти с EVM на RISC-V (или другую альтернативную минимальную виртуальную машину), шестнадцатеричное дерево Меркла-Патриции станет максимальным узким местом для доказательства выполнения блока, даже в среднем случае. Переход на двоичное дерево с более оптимальной хеш-функцией значительно повысит эффективность доказателя, одновременно снижая стоимость данных для таких сценариев, как легкие клиенты.
При миграции необходимо убедиться, что уровень консенсуса использует одинаковую структуру дерева. Это позволит уровню консенсуса Ethereum и уровню выполнения получить доступ и разобрать их с помощью одного и того же кода.
От настоящего до будущего
Простота во многом схожа с децентрализацией; оба являются верхними целями устойчивости. Явное внимание к простоте требует определенной культурной трансформации. Ее выгоды часто трудно количественно оценить, в то время как дополнительные усилия и затраты на отказ от некоторых блестящих функций дают мгновенный эффект. Однако со временем выгоды станут все более заметными — сам Биткойн является отличным примером.
Я предлагаю подражать tinygrad и установить четкую максимальную цель по количеству строк кода для долгосрочных стандартов Ethereum, чтобы ключевой код консенсуса Ethereum приближался к простоте Bitcoin. Код, обрабатывающий исторические правила Ethereum, продолжит существовать, но должен находиться вне ключевого пути консенсуса. В то же время, мы должны придерживаться концепции выбора более простых решений, отдавая предпочтение инкапсуляции сложности, а не системной сложности, и делать выбор в пользу проектирования, обеспечивающего четкие свойства и гарантии.