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