Эфириум стремится стать мировым реестром: платформой для хранения цивилизационных активов и записей, являющейся базовым уровнем для финансов, управления и сертификации высокоценных данных. Для этого необходимо выполнить два условия: масштабируемость и устойчивость. Хардфорк Fusaka нацелен на увеличение доступного пространства для данных второго уровня (L2) в 10 раз, текущая намеченная дорожная карта на 2026 год также предлагает аналогичное значительное расширение первого уровня (L1). В то же время Эфириум завершил обновление Merge до механизма доказательства доли (Proof of Stake), разнообразие его клиентов быстро увеличивается, работа по нулевым знаниям (ZK Verifiability) и квантовой устойчивости также продолжается, а различные приложения становятся все более надежными.
Данная статья направлена на изучение одного аспекта устойчивости (который в конечном итоге также повлияет на масштабируемость), который является столь же важным, но часто недооцененным, а именно простоты протокола.
Одним из основных преимуществ Биткойна является его чрезвычайно простой и красивый протокол.
Блокчейн состоит из серии блоков, каждый из которых связан с предыдущим блоком с помощью хеш-значения. Действительность блока проверяется с помощью механизма доказательства работы, то есть проверяется, равны ли первые несколько цифр его хеш-значения нулю. Каждый блок содержит несколько транзакций, криптовалюта для которых либо создается путем майнинга, либо поступает от выходов предыдущих транзакций. Основной механизм протокола Биткойн заключается в этом. Даже умный школьник может полностью понять этот протокол, программист даже может использовать его как проект для хобби.
Сохранение простоты протокола предоставляет ключевое преимущество для того, чтобы Биткойн или Эфириум стали глобально признанным нейтральным базовым уровнем:
Простые протоколы легче анализировать, что может привлечь больше участников к исследованию, разработке и управлению протоколом, одновременно снижая риск технологической монополии.
Упрощенная структура протокола значительно снижает затраты на разработку при интеграции с новой инфраструктурой (такой как клиент, доказатель, инструменты журналирования и другие инструменты разработки).
Простой дизайн соглашения эффективно снижает долгосрочные затраты на обслуживание.
Серьезные риски уязвимостей в спецификациях протоколов и их реализации значительно уменьшились, что облегчает проверку безопасности системы.
Сокращение социальной атакующей поверхности: минимизация компонентов делает систему более защищенной от проникновения специальных интересов, повышая общую безопасность.
В истории Ethereum часто не удавалось реализовать принцип простоты в дизайне протокола (частично из-за решений автора), что напрямую приводило к высоким затратам на разработку, частым угрозам безопасности и закрытости культур разработки. Корни этих проблем часто заключаются в погоне за краткосрочной выгодой, которая была признана неэффективной на практике. В этой статье будет изложено, как в течение следующих пяти лет Ethereum сможет достичь уровня простоты протокола, близкого к Bitcoin.
Упрощенный уровень консенсуса
Симуляция окончательности трех слотов в 3sf - mini (кодовое название тестовой сети Ethereum)
Новая схема уровня согласия (ранее называемая «Лучевая цепь») направлена на объединение результатов исследований за последние десять лет в области теории согласия, нулевых знаний (ZK-SNARK), экономики стекинга и других областях, чтобы создать оптимальный механизм согласия для Ethereum, ориентированный на долгосрочное развитие. По сравнению с существующей цепью маяка, эта схема обладает значительно упрощенными характеристиками, что конкретно проявляется в следующих аспектах:
Инновация архитектуры окончательности в три временных слота (3-slot finality): устранены концептуальные разделения между независимыми слотами и эпохами, отменен механизм ротации комитетов и сложные компоненты, такие как синхронные комитеты, что значительно упрощает спецификации протокола. Основная реализация требует всего около 200 строк кода, достигая почти оптимального уровня безопасности по сравнению с протоколом Gasper.
Оптимизация управления узлами верификации: ограничивая количество активных узлов верификации, правила выбора форков (fork choice rule) могут использовать более упрощенные схемы реализации, одновременно обеспечивая безопасность системы.
Обновление агрегированного протокола: основанный на STARK механизм агрегирования позволяет любому узлу выполнять роль агрегатора, избегая зависимости от доверия к агрегатору и проблему расточительства ресурсов повторяющихся битовых полей (bitfield). Несмотря на то, что криптография агрегирования сама по себе имеет высокую сложность, её высокая степень упаковки значительно снижает системные риски.
Улучшение архитектуры P2P-сети: вышеупомянутые два оптимизации предоставили возможность создать более простую и эффективную архитектуру одноранговой сети.
Реконструкция процесса верификации: повторное проектирование механизмов допуска, выхода, вывода средств, миграции ключей и наказания за неактивность узлов верификации, при этом снижая объем кода и четко определяя механизмы обеспечения основных параметров (таких как слабый субъективный период).
Технические преимущества: относительная декомпозиция уровня согласия и уровня выполнения EVM предоставляет больше технического пространства для постоянной оптимизации. В отличие от этого, аналогичные улучшения на уровне выполнения сталкиваются с большими вызовами.
Упрощенный уровень выполнения
Сложность виртуальной машины Ethereum (EVM) продолжает расти, при этом многие сложные конструкции оказались ненужными (в ряде случаев это моя ошибка в принятии решений): 256-битная виртуальная машина, чрезмерно оптимизированная для конкретного криптографического алгоритма, который в настоящее время постепенно теряет свою значимость; и предкомпилированные контракты, чрезмерно разработанные для одного сценария использования, который на практике используется крайне редко.
Попытки решить существующие проблемы с помощью разрозненных исправлений стали невозможными. Удаление операции SELFDESTRUCT требует огромных усилий, но приносит лишь ограниченные выгоды, а недавние споры о EOF еще больше подчеркивают трудности постепенных изменений виртуальной машины.
В качестве альтернативы я недавно предложил более радикальный путь трансформации: вместо того чтобы вносить средние (но все же разрушительные) изменения в EVM в обмен на 1,5-кратное увеличение производительности, лучше сразу перейти к совершенно новой и значительно более эффективной архитектуре виртуальных машин, чтобы достичь стократного повышения производительности. Как и в случае с объединением (The Merge), мы стремимся уменьшить количество разрушительных изменений, увеличивая стратегическую ценность каждого изменения. В частности, предлагается использовать архитектуру RISC-V или виртуальную машину, используемую программами ZK-доказательств Ethereum, в качестве замены существующему EVM. Эта трансформация приведет к:
Революционное повышение эффективности: в среде ZK-доказательств смарт-контракты могут напрямую выполняться на целевой архитектуре без накладных расходов на интерпретатор. Сжато данные показывают, что в большинстве случаев производительность может увеличиться более чем в сто раз.
Архитектура крайне упрощена: спецификация RISC-V значительно более лаконична по сравнению с EVM, другие рассматриваемые решения (например, Cairo) также обладают простыми характеристиками.
Наследование основных преимуществ EOF: включает управление сегментами кода, более дружелюбную поддержку статического анализа и более высокие ограничения на объем кода.
Расширение инструментов для разработчиков: Solidity и Vyper могут поддерживать новую архитектуру через добавление поддержки компиляции на заднем плане; если выбрать RISC-V, разработчики основных языков могут напрямую перенести существующий код.
Оптимизация предварительно скомпилированных контрактов: большая часть функций предварительной компиляции больше не будет необходима, останется только высоко оптимизированная операция эллиптической кривой (может быть устранена с развитием квантовых вычислений).
Основные проблемы заключаются в следующем: в отличие от немедленно реализуемых схем EOF, новой виртуальной машине потребуется больше времени, чтобы принести пользу разработчикам. В качестве краткосрочного переходного решения можно синхронно реализовать некоторые высокоценные улучшения EVM (например, увеличить ограничение на размер кода контракта, оптимизировать набор команд DUP/SWAP).
Эта трансформация значительно упростит архитектуру виртуальной машины. Основной вопрос заключается в том, как правильно обработать существующую экосистему EVM?
Стратегия обратной совместимости для миграции виртуальных машин
最大挑战 в упрощении (или оптимизации без увеличения сложности) любой части EVM заключается в том, как сбалансировать достижение ожидаемых целей и поддержание обратной совместимости с существующими приложениями.
Прежде всего необходимо четко определить: даже для одного клиента не существует единого стандарта для определения того, что такое «кодовая база Ethereum».
Цель состоит в минимизации зеленой зоны: то есть узел должен выполнять логику, необходимую для участия в консенсусе Ethereum, включая вычисление текущего состояния, генерацию и проверку доказательств, FOCIL (примечание: необходимо подтвердить, является ли это аббревиатурой профессионального термина) и процесс построения «базового» блока.
Оранжевая зона не может быть уменьшена: если функции слоя исполнения (независимо от того, является ли это виртуальной машиной, предварительно скомпилированным контрактом или другим механизмом) удаляются из спецификации протокола или их функции изменяются, клиент, обрабатывающий исторические блоки, должен сохранить эту функцию; однако новые клиенты (включая ZK-EVM или инструменты формальной верификации) могут полностью игнорировать эту часть.
Добавлена желтая зона: это относится к коду, который имеет большую ценность для анализа данных на текущей цепочке или оптимального построения блоков, но не относится к механизму согласия. Типичный пример — поддержка операций пользователей ERC-4337 со стороны Etherscan и некоторых строителей блоков. Если заменить основные функции Ethereum (такие как внешние счета EOA и их поддерживаемые различные старые типы транзакций) на реализацию RISC-V на цепочке, код согласия значительно упростится, но специализированные узлы могут все еще нуждаться в использовании оригинального кода для анализа.
Сложность оранжевой и желтой зон относится к сложности инкапсуляции, и любые лица, желающие понять протокол, могут пропустить эти части, а также реализующие решения Ethereum могут свободно выбирать игнорировать их. Кроме того, дефекты кода в этих зонах не приведут к рискам консенсуса. Это означает, что по сравнению со сложностью кода зеленой зоны, сложность оранжевой и желтой зон оказывает значительно меньшее негативное влияние на всю систему.
Перенос кода из зеленой зоны в желтую зону аналогичен технологическому решению компании Apple, реализующему долгосрочную обратную совместимость через переводческий слой Rosetta.
Требуется, чтобы все новые разработанные предкомпилированные контракты включали стандартную реализацию RISC-V на цепочке. Этот шаг направлен на постепенное приведение экосистемы к среде виртуальной машины RISC-V (например, миграция с EVM на RISC-V, это решение также подходит для миграции с EVM на Cairo или другие более совершенные виртуальные машины):
Двойная поддержка параллельных виртуальных машин: на уровне протокола одновременно нативно поддерживаются две виртуальные машины RISC-V и EVM. Разработчики могут свободно выбирать язык разработки, контракты, написанные для разных виртуальных машин, могут бесшовно взаимодействовать.
Этапная замена предкомпилированных контрактов: все предкомпилированные контракты, кроме операций с эллиптическими кривыми и алгоритма хэширования KECCAK (из-за их предельных требований к производительности), заменяются на реализацию RISC-V через жесткий форк.
Конкретные действия заключаются в следующем: одновременно с удалением оригинального предварительно скомпилированного контракта изменить код данного адреса (используя режим разветвления DAO) из пустого состояния на соответствующую реализацию RISC-V. Благодаря высокой простоте архитектуры RISC-V, даже если будет выполнен только этот шаг, общая сложность системы все равно снизится.
Развертывание интерпретатора EVM на блокчейне: интерпретатор EVM, реализованный на основе RISC-V (инструментальная цепочка ZK доказательств уже способствовала таким разработкам), будет развернут в виде смарт-контракта на блокчейне. Спустя несколько лет после выпуска начальной версии существующие контракты EVM будут выполняться с помощью этого интерпретатора, что обеспечит плавный переход к новой виртуальной машине.
Упрощение за счет компонентов протокола общего доступа
После завершения четвертого шага множество "EVM-реализаций" останется и будет использовано для оптимизации построения блоков, инструментов для разработчиков и анализа данных в цепочке, но эти реализации больше не будут частью основных норм консенсуса. В то время механизм консенсуса Ethereum будет "нативно" поддерживать только архитектуру RISC-V.
Упрощение с помощью компонентов протокола общего доступа
Третий способ уменьшить общую сложность протокола (также наиболее недооцененный) заключается в том, чтобы по возможности делиться едиными стандартами между различными уровнями протокольного стека. Как правило, использование различных реализаций протоколов для одной и той же функции в разных модулях не имеет смысла и не приносит выгоды, однако такая модель проектирования все еще широко распространена, главным образом из-за недостатка эффективной координации между различными частями дорожной карты протокола. Ниже приведены конкретные примеры упрощения Ethereum за счет усиления повторного использования компонентов между уровнями.
Унифицированная схема кодирования с возможностью удаления и восстановления
Три основных сценария применения кодов исправления ошибок:
Сэмплирование доступности данных: клиент должен использовать код исправления ошибок при проверке того, был ли опубликован блок, чтобы обеспечить целостность данных.
Эффективное P2P вещание: узлы могут подтвердить блок, получив n/2 из n фрагментов, достигая оптимального баланса между снижением задержки и избыточностью.
Распределенное историческое хранилище: исторические данные Ethereum разбиваются на несколько блоков данных, чтобы удовлетворить:
Каждый блок данных может быть независимо проверен.
В любой группе достаточно n/2 блоков данных, чтобы восстановить оставшиеся n/2 блоков данных.
Этот дизайн значительно снижает риск потери данных в одной точке.
Использование одинаковых кодов коррекции ошибок (таких как код Рида-Соломона, случайные линейные коды и т.д.) в следующих трех сценариях приведет к значительным преимуществам:
Сокращение кода;
Увеличение эффективности: когда узлу необходимо загрузить данные фрагмента (а не полный блок) из-за определенного сценария, эти данные могут быть непосредственно использованы в других сценариях, избегая повторной передачи;
Все блоки данных в любых сценариях могут быть единообразно проверены с помощью корневого хэша.
Если используются разные коды исправления ошибок, необходимо удовлетворить требования совместимости: например, в фрагментах выборки доступности данных (DAS) можно одновременно использовать горизонтальные коды Рида-Соломона и вертикальные случайные линейные коды, но оба кода должны работать на одной и той же конечной области.
Единый формат сериализации
Текущий формат сериализации Ethereum все еще находится в полунормализованном состоянии — данные могут быть пере сериализованы в любой формат и распространены, единственное исключение — это хэш подписи транзакции, для которого необходимо использовать нормализованный формат для обеспечения согласованности хэша. Однако в будущем степень нормализации формата сериализации будет усиливаться, в основном по следующим причинам:
Абстракция учетной записи (EIP-7701): Полное содержание транзакции будет полностью видимо для виртуальной машины (VM)
Сцена ограничения газа: с увеличением верхнего предела газа в блоках данные уровня исполнения необходимо хранить в структуре blob.
Когда произошли вышеупомянутые изменения, мы можем использовать эту возможность для унификации стандартов сериализации трех ключевых уровней Ethereum: (i) уровень выполнения (ii) уровень консенсуса (iii) ABI вызова смарт-контрактов.
Рекомендуется использовать формат сериализации SSZ, который имеет следующие преимущества:
Декодирование эффективно, сцены, включая смарт-контракты, могут быть быстро декодированы благодаря его дизайну на основе 4 байтов и меньшему количеству условий на границах.
Слой консенсуса широко используется и уже достиг глубокой интеграции на слое консенсуса.
Сильно схож с существующим ABI, что облегчает адаптацию и обновление инструментальных цепочек.
В настоящее время существует соответствующая техническая команда, занимающаяся полным переходом на SSZ. Рекомендуется продолжить эту технологическую линию в планах будущих обновлений и расширять ее на основе существующих достижений.
Единая共享树结构
После перехода с EVM на RISC-V (или другую архитектуру упрощенной виртуальной машины) шестиречная Меркле-Патриция-дерево станет крупнейшей производственной узкой местом доказательства выполнения блока (даже в обычных сценариях). Переход к двоичным деревьям, основанным на более оптимальных хеш-функциях, значительно повысит эффективность доказательства и снизит затраты на хранение данных для легких узлов и других приложений.
При осуществлении этой миграции необходимо синхронно использовать одинаковую древовидную структуру для достижения единства между уровнем консенсуса и уровнем исполнения. Этот шаг обеспечит использование одной и той же логики кода для доступа к данным и их анализа во всей стековой архитектуре Ethereum (включая уровень консенсуса и уровень исполнения).
Путь эволюции от текущего состояния к цели
Простота во многом схожа с децентрализацией; оба являются основными предпосылками для достижения устойчивости системы. Четкое определение простоты как основной ценности требует культурного изменения: ее преимущества часто сложно продемонстрировать немедленно, в то время как краткосрочные выгоды от сложных функций очевидны. Однако с течением времени преимущества простоты будут становиться все более значительными — развитие Биткойна является ярким подтверждением этой точки зрения.
Я предлагаю использовать опыт практики проекта TinyGrad в качестве референса для проектирования протокола Ethereum, чтобы установить четкую цель по ограничению количества строк кода для долгосрочных стандартов Ethereum, стремясь сделать уровень лаконичности ключевого кода консенсуса Ethereum близким к уровню Bitcoin. В частности, код, связанный с обработкой исторических правил Ethereum, может быть сохранен, но должен быть строго изолирован от ключевых путей консенсуса, чтобы гарантировать, что он не влияет на основную логику консенсуса; в то же время при выборе технических решений следует придерживаться концепции «приоритета выбора более простых решений», стремясь к инкапсуляции сложности, а не к распространению системной сложности, и обеспечивая, чтобы все проектные решения предоставляли четкие и проверяемые характеристики и гарантии, тем самым формируя в целом техническую культуру, ориентированную на простоту.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Виталик новая статья: как Ethereum реализует упрощенную архитектуру, сопоставимую с Биткойн?
Исходное название: Упрощение L1
Автор: Виталик
Состав: ленаксин, ChainCatcher
Эфириум стремится стать мировым реестром: платформой для хранения цивилизационных активов и записей, являющейся базовым уровнем для финансов, управления и сертификации высокоценных данных. Для этого необходимо выполнить два условия: масштабируемость и устойчивость. Хардфорк Fusaka нацелен на увеличение доступного пространства для данных второго уровня (L2) в 10 раз, текущая намеченная дорожная карта на 2026 год также предлагает аналогичное значительное расширение первого уровня (L1). В то же время Эфириум завершил обновление Merge до механизма доказательства доли (Proof of Stake), разнообразие его клиентов быстро увеличивается, работа по нулевым знаниям (ZK Verifiability) и квантовой устойчивости также продолжается, а различные приложения становятся все более надежными.
Данная статья направлена на изучение одного аспекта устойчивости (который в конечном итоге также повлияет на масштабируемость), который является столь же важным, но часто недооцененным, а именно простоты протокола.
Одним из основных преимуществ Биткойна является его чрезвычайно простой и красивый протокол.
Блокчейн состоит из серии блоков, каждый из которых связан с предыдущим блоком с помощью хеш-значения. Действительность блока проверяется с помощью механизма доказательства работы, то есть проверяется, равны ли первые несколько цифр его хеш-значения нулю. Каждый блок содержит несколько транзакций, криптовалюта для которых либо создается путем майнинга, либо поступает от выходов предыдущих транзакций. Основной механизм протокола Биткойн заключается в этом. Даже умный школьник может полностью понять этот протокол, программист даже может использовать его как проект для хобби.
Сохранение простоты протокола предоставляет ключевое преимущество для того, чтобы Биткойн или Эфириум стали глобально признанным нейтральным базовым уровнем:
Простые протоколы легче анализировать, что может привлечь больше участников к исследованию, разработке и управлению протоколом, одновременно снижая риск технологической монополии.
Упрощенная структура протокола значительно снижает затраты на разработку при интеграции с новой инфраструктурой (такой как клиент, доказатель, инструменты журналирования и другие инструменты разработки).
Простой дизайн соглашения эффективно снижает долгосрочные затраты на обслуживание.
Серьезные риски уязвимостей в спецификациях протоколов и их реализации значительно уменьшились, что облегчает проверку безопасности системы.
Сокращение социальной атакующей поверхности: минимизация компонентов делает систему более защищенной от проникновения специальных интересов, повышая общую безопасность.
В истории Ethereum часто не удавалось реализовать принцип простоты в дизайне протокола (частично из-за решений автора), что напрямую приводило к высоким затратам на разработку, частым угрозам безопасности и закрытости культур разработки. Корни этих проблем часто заключаются в погоне за краткосрочной выгодой, которая была признана неэффективной на практике. В этой статье будет изложено, как в течение следующих пяти лет Ethereum сможет достичь уровня простоты протокола, близкого к Bitcoin.
Упрощенный уровень консенсуса
Симуляция окончательности трех слотов в 3sf - mini (кодовое название тестовой сети Ethereum)
Новая схема уровня согласия (ранее называемая «Лучевая цепь») направлена на объединение результатов исследований за последние десять лет в области теории согласия, нулевых знаний (ZK-SNARK), экономики стекинга и других областях, чтобы создать оптимальный механизм согласия для Ethereum, ориентированный на долгосрочное развитие. По сравнению с существующей цепью маяка, эта схема обладает значительно упрощенными характеристиками, что конкретно проявляется в следующих аспектах:
Инновация архитектуры окончательности в три временных слота (3-slot finality): устранены концептуальные разделения между независимыми слотами и эпохами, отменен механизм ротации комитетов и сложные компоненты, такие как синхронные комитеты, что значительно упрощает спецификации протокола. Основная реализация требует всего около 200 строк кода, достигая почти оптимального уровня безопасности по сравнению с протоколом Gasper.
Оптимизация управления узлами верификации: ограничивая количество активных узлов верификации, правила выбора форков (fork choice rule) могут использовать более упрощенные схемы реализации, одновременно обеспечивая безопасность системы.
Обновление агрегированного протокола: основанный на STARK механизм агрегирования позволяет любому узлу выполнять роль агрегатора, избегая зависимости от доверия к агрегатору и проблему расточительства ресурсов повторяющихся битовых полей (bitfield). Несмотря на то, что криптография агрегирования сама по себе имеет высокую сложность, её высокая степень упаковки значительно снижает системные риски.
Улучшение архитектуры P2P-сети: вышеупомянутые два оптимизации предоставили возможность создать более простую и эффективную архитектуру одноранговой сети.
Реконструкция процесса верификации: повторное проектирование механизмов допуска, выхода, вывода средств, миграции ключей и наказания за неактивность узлов верификации, при этом снижая объем кода и четко определяя механизмы обеспечения основных параметров (таких как слабый субъективный период).
Технические преимущества: относительная декомпозиция уровня согласия и уровня выполнения EVM предоставляет больше технического пространства для постоянной оптимизации. В отличие от этого, аналогичные улучшения на уровне выполнения сталкиваются с большими вызовами.
Упрощенный уровень выполнения
Сложность виртуальной машины Ethereum (EVM) продолжает расти, при этом многие сложные конструкции оказались ненужными (в ряде случаев это моя ошибка в принятии решений): 256-битная виртуальная машина, чрезмерно оптимизированная для конкретного криптографического алгоритма, который в настоящее время постепенно теряет свою значимость; и предкомпилированные контракты, чрезмерно разработанные для одного сценария использования, который на практике используется крайне редко.
Попытки решить существующие проблемы с помощью разрозненных исправлений стали невозможными. Удаление операции SELFDESTRUCT требует огромных усилий, но приносит лишь ограниченные выгоды, а недавние споры о EOF еще больше подчеркивают трудности постепенных изменений виртуальной машины.
В качестве альтернативы я недавно предложил более радикальный путь трансформации: вместо того чтобы вносить средние (но все же разрушительные) изменения в EVM в обмен на 1,5-кратное увеличение производительности, лучше сразу перейти к совершенно новой и значительно более эффективной архитектуре виртуальных машин, чтобы достичь стократного повышения производительности. Как и в случае с объединением (The Merge), мы стремимся уменьшить количество разрушительных изменений, увеличивая стратегическую ценность каждого изменения. В частности, предлагается использовать архитектуру RISC-V или виртуальную машину, используемую программами ZK-доказательств Ethereum, в качестве замены существующему EVM. Эта трансформация приведет к:
Революционное повышение эффективности: в среде ZK-доказательств смарт-контракты могут напрямую выполняться на целевой архитектуре без накладных расходов на интерпретатор. Сжато данные показывают, что в большинстве случаев производительность может увеличиться более чем в сто раз.
Архитектура крайне упрощена: спецификация RISC-V значительно более лаконична по сравнению с EVM, другие рассматриваемые решения (например, Cairo) также обладают простыми характеристиками.
Наследование основных преимуществ EOF: включает управление сегментами кода, более дружелюбную поддержку статического анализа и более высокие ограничения на объем кода.
Расширение инструментов для разработчиков: Solidity и Vyper могут поддерживать новую архитектуру через добавление поддержки компиляции на заднем плане; если выбрать RISC-V, разработчики основных языков могут напрямую перенести существующий код.
Оптимизация предварительно скомпилированных контрактов: большая часть функций предварительной компиляции больше не будет необходима, останется только высоко оптимизированная операция эллиптической кривой (может быть устранена с развитием квантовых вычислений).
Основные проблемы заключаются в следующем: в отличие от немедленно реализуемых схем EOF, новой виртуальной машине потребуется больше времени, чтобы принести пользу разработчикам. В качестве краткосрочного переходного решения можно синхронно реализовать некоторые высокоценные улучшения EVM (например, увеличить ограничение на размер кода контракта, оптимизировать набор команд DUP/SWAP).
Эта трансформация значительно упростит архитектуру виртуальной машины. Основной вопрос заключается в том, как правильно обработать существующую экосистему EVM?
Стратегия обратной совместимости для миграции виртуальных машин
最大挑战 в упрощении (или оптимизации без увеличения сложности) любой части EVM заключается в том, как сбалансировать достижение ожидаемых целей и поддержание обратной совместимости с существующими приложениями.
Прежде всего необходимо четко определить: даже для одного клиента не существует единого стандарта для определения того, что такое «кодовая база Ethereum».
Цель состоит в минимизации зеленой зоны: то есть узел должен выполнять логику, необходимую для участия в консенсусе Ethereum, включая вычисление текущего состояния, генерацию и проверку доказательств, FOCIL (примечание: необходимо подтвердить, является ли это аббревиатурой профессионального термина) и процесс построения «базового» блока.
Оранжевая зона не может быть уменьшена: если функции слоя исполнения (независимо от того, является ли это виртуальной машиной, предварительно скомпилированным контрактом или другим механизмом) удаляются из спецификации протокола или их функции изменяются, клиент, обрабатывающий исторические блоки, должен сохранить эту функцию; однако новые клиенты (включая ZK-EVM или инструменты формальной верификации) могут полностью игнорировать эту часть.
Добавлена желтая зона: это относится к коду, который имеет большую ценность для анализа данных на текущей цепочке или оптимального построения блоков, но не относится к механизму согласия. Типичный пример — поддержка операций пользователей ERC-4337 со стороны Etherscan и некоторых строителей блоков. Если заменить основные функции Ethereum (такие как внешние счета EOA и их поддерживаемые различные старые типы транзакций) на реализацию RISC-V на цепочке, код согласия значительно упростится, но специализированные узлы могут все еще нуждаться в использовании оригинального кода для анализа.
Сложность оранжевой и желтой зон относится к сложности инкапсуляции, и любые лица, желающие понять протокол, могут пропустить эти части, а также реализующие решения Ethereum могут свободно выбирать игнорировать их. Кроме того, дефекты кода в этих зонах не приведут к рискам консенсуса. Это означает, что по сравнению со сложностью кода зеленой зоны, сложность оранжевой и желтой зон оказывает значительно меньшее негативное влияние на всю систему.
Перенос кода из зеленой зоны в желтую зону аналогичен технологическому решению компании Apple, реализующему долгосрочную обратную совместимость через переводческий слой Rosetta.
Требуется, чтобы все новые разработанные предкомпилированные контракты включали стандартную реализацию RISC-V на цепочке. Этот шаг направлен на постепенное приведение экосистемы к среде виртуальной машины RISC-V (например, миграция с EVM на RISC-V, это решение также подходит для миграции с EVM на Cairo или другие более совершенные виртуальные машины):
Двойная поддержка параллельных виртуальных машин: на уровне протокола одновременно нативно поддерживаются две виртуальные машины RISC-V и EVM. Разработчики могут свободно выбирать язык разработки, контракты, написанные для разных виртуальных машин, могут бесшовно взаимодействовать.
Этапная замена предкомпилированных контрактов: все предкомпилированные контракты, кроме операций с эллиптическими кривыми и алгоритма хэширования KECCAK (из-за их предельных требований к производительности), заменяются на реализацию RISC-V через жесткий форк.
Конкретные действия заключаются в следующем: одновременно с удалением оригинального предварительно скомпилированного контракта изменить код данного адреса (используя режим разветвления DAO) из пустого состояния на соответствующую реализацию RISC-V. Благодаря высокой простоте архитектуры RISC-V, даже если будет выполнен только этот шаг, общая сложность системы все равно снизится.
Развертывание интерпретатора EVM на блокчейне: интерпретатор EVM, реализованный на основе RISC-V (инструментальная цепочка ZK доказательств уже способствовала таким разработкам), будет развернут в виде смарт-контракта на блокчейне. Спустя несколько лет после выпуска начальной версии существующие контракты EVM будут выполняться с помощью этого интерпретатора, что обеспечит плавный переход к новой виртуальной машине.
Упрощение за счет компонентов протокола общего доступа
После завершения четвертого шага множество "EVM-реализаций" останется и будет использовано для оптимизации построения блоков, инструментов для разработчиков и анализа данных в цепочке, но эти реализации больше не будут частью основных норм консенсуса. В то время механизм консенсуса Ethereum будет "нативно" поддерживать только архитектуру RISC-V.
Упрощение с помощью компонентов протокола общего доступа
Третий способ уменьшить общую сложность протокола (также наиболее недооцененный) заключается в том, чтобы по возможности делиться едиными стандартами между различными уровнями протокольного стека. Как правило, использование различных реализаций протоколов для одной и той же функции в разных модулях не имеет смысла и не приносит выгоды, однако такая модель проектирования все еще широко распространена, главным образом из-за недостатка эффективной координации между различными частями дорожной карты протокола. Ниже приведены конкретные примеры упрощения Ethereum за счет усиления повторного использования компонентов между уровнями.
Унифицированная схема кодирования с возможностью удаления и восстановления
Три основных сценария применения кодов исправления ошибок:
Сэмплирование доступности данных: клиент должен использовать код исправления ошибок при проверке того, был ли опубликован блок, чтобы обеспечить целостность данных.
Эффективное P2P вещание: узлы могут подтвердить блок, получив n/2 из n фрагментов, достигая оптимального баланса между снижением задержки и избыточностью.
Распределенное историческое хранилище: исторические данные Ethereum разбиваются на несколько блоков данных, чтобы удовлетворить:
Каждый блок данных может быть независимо проверен.
В любой группе достаточно n/2 блоков данных, чтобы восстановить оставшиеся n/2 блоков данных.
Этот дизайн значительно снижает риск потери данных в одной точке.
Использование одинаковых кодов коррекции ошибок (таких как код Рида-Соломона, случайные линейные коды и т.д.) в следующих трех сценариях приведет к значительным преимуществам:
Сокращение кода;
Увеличение эффективности: когда узлу необходимо загрузить данные фрагмента (а не полный блок) из-за определенного сценария, эти данные могут быть непосредственно использованы в других сценариях, избегая повторной передачи;
Все блоки данных в любых сценариях могут быть единообразно проверены с помощью корневого хэша.
Если используются разные коды исправления ошибок, необходимо удовлетворить требования совместимости: например, в фрагментах выборки доступности данных (DAS) можно одновременно использовать горизонтальные коды Рида-Соломона и вертикальные случайные линейные коды, но оба кода должны работать на одной и той же конечной области.
Единый формат сериализации
Текущий формат сериализации Ethereum все еще находится в полунормализованном состоянии — данные могут быть пере сериализованы в любой формат и распространены, единственное исключение — это хэш подписи транзакции, для которого необходимо использовать нормализованный формат для обеспечения согласованности хэша. Однако в будущем степень нормализации формата сериализации будет усиливаться, в основном по следующим причинам:
Абстракция учетной записи (EIP-7701): Полное содержание транзакции будет полностью видимо для виртуальной машины (VM)
Сцена ограничения газа: с увеличением верхнего предела газа в блоках данные уровня исполнения необходимо хранить в структуре blob.
Когда произошли вышеупомянутые изменения, мы можем использовать эту возможность для унификации стандартов сериализации трех ключевых уровней Ethereum: (i) уровень выполнения (ii) уровень консенсуса (iii) ABI вызова смарт-контрактов.
Рекомендуется использовать формат сериализации SSZ, который имеет следующие преимущества:
Декодирование эффективно, сцены, включая смарт-контракты, могут быть быстро декодированы благодаря его дизайну на основе 4 байтов и меньшему количеству условий на границах.
Слой консенсуса широко используется и уже достиг глубокой интеграции на слое консенсуса.
Сильно схож с существующим ABI, что облегчает адаптацию и обновление инструментальных цепочек.
В настоящее время существует соответствующая техническая команда, занимающаяся полным переходом на SSZ. Рекомендуется продолжить эту технологическую линию в планах будущих обновлений и расширять ее на основе существующих достижений.
Единая共享树结构
После перехода с EVM на RISC-V (или другую архитектуру упрощенной виртуальной машины) шестиречная Меркле-Патриция-дерево станет крупнейшей производственной узкой местом доказательства выполнения блока (даже в обычных сценариях). Переход к двоичным деревьям, основанным на более оптимальных хеш-функциях, значительно повысит эффективность доказательства и снизит затраты на хранение данных для легких узлов и других приложений.
При осуществлении этой миграции необходимо синхронно использовать одинаковую древовидную структуру для достижения единства между уровнем консенсуса и уровнем исполнения. Этот шаг обеспечит использование одной и той же логики кода для доступа к данным и их анализа во всей стековой архитектуре Ethereum (включая уровень консенсуса и уровень исполнения).
Путь эволюции от текущего состояния к цели
Простота во многом схожа с децентрализацией; оба являются основными предпосылками для достижения устойчивости системы. Четкое определение простоты как основной ценности требует культурного изменения: ее преимущества часто сложно продемонстрировать немедленно, в то время как краткосрочные выгоды от сложных функций очевидны. Однако с течением времени преимущества простоты будут становиться все более значительными — развитие Биткойна является ярким подтверждением этой точки зрения.
Я предлагаю использовать опыт практики проекта TinyGrad в качестве референса для проектирования протокола Ethereum, чтобы установить четкую цель по ограничению количества строк кода для долгосрочных стандартов Ethereum, стремясь сделать уровень лаконичности ключевого кода консенсуса Ethereum близким к уровню Bitcoin. В частности, код, связанный с обработкой исторических правил Ethereum, может быть сохранен, но должен быть строго изолирован от ключевых путей консенсуса, чтобы гарантировать, что он не влияет на основную логику консенсуса; в то же время при выборе технических решений следует придерживаться концепции «приоритета выбора более простых решений», стремясь к инкапсуляции сложности, а не к распространению системной сложности, и обеспечивая, чтобы все проектные решения предоставляли четкие и проверяемые характеристики и гарантии, тем самым формируя в целом техническую культуру, ориентированную на простоту.