Особая благодарность Феде, Данно Феррину, Джастину Дрейку, Ладислаусу и Тиму Бейко за их отзывы и обзор.

Цель Ethereum - стать глобальным реестром - платформой, которая несет человеческие активы и записи, и является базовым уровнем для приложений, таких как финансы, управление и верификация данных высокой ценности. Для достижения этой цели у нее должна быть как масштабируемость, так и устойчивость. План жесткого вилки Fusaka увеличит пространство доступности данных L2 в 10 раз, в то время какПредполагаемая дорожная карта на 2026 годТакже включает аналогичный масштаб расширения данных L1. Между тем, 'Слияние' обновило Ethereum до механизма консенсуса доказательства доли (PoS).Разнообразие клиентов быстро увеличивается, ZK (Zero-Knowledge Proof) верифицируемость и устойчивость к квантовым атакам также постепенно продвигаются, и экосистема приложений становится все болееЗрелый и крепкий.

Цель этой статьи - подчеркнуть равно важный, но часто недооцененныйУстойчивость (и, в конечном итоге, масштабируемость)Элементы:
Простота протокола.

Одним из самых похвальных аспектов Биткойна является его дизайн протокола, который чрезвычайно элегантен и прост:

Система представляет собой блокчейн, состоящий из серии блоков. Каждый блок связан с предыдущим блоком через хэш. Допустимость каждого блока проверяется с помощью доказательства работы (PoW), что означает… вам просто нужно проверить, начинаются ли ведущие цифры его хэша с нулей. Каждый блок содержит транзакции, которые либо тратят монеты, полученные через майнинг, либо тратят монеты, полученные из предыдущих транзакций. Вот в общем и все.
Даже умный старшеклассник способен полностью понять принципы работы биткоин-протокола. А программист даже может разработать клиент биткоина как хобби-проект.

Сохранение протокола простым приносит целый ряд ключевых преимуществ, что потенциально делает Bitcoin и EthereumДоверенная нейтральностьОсновополагающий уровень глобального доверия:

• Сделать логику протокола более понятной, расширить круг лиц, которые могут участвовать в исследованиях, разработке и управлении протоколом, снизить технические барьеры и избежать доминирования 'технократического класса' в протоколе.
• Значительно снизить затраты на разработку новой инфраструктуры, интегрированной с протоколами (такими как новые клиенты, новые проверяющие, новые инструменты регистрации и т. д.).
• Снизить долгосрочные затраты на обслуживание протокола.
• Снижение риска катастрофических уязвимостей, будь то в спецификациях протокола или коде реализации; это также упрощает проверку того, что протокол не содержит таких уязвимостей.
• Уменьшите социальную атаку: чем меньше компонентов, тем меньше мест, которые могут быть использованы и контролируемы определенными заинтересованными сторонами.

В прошлом Ethereum не проявлял себя хорошо в этом отношении (иногда даже из-за моих личных решений), что привело к нашим излишним расходам на развитие,@vbuterin/selfdestruct”>Различные риски безопасности и закрытая природа культуры НИОКР, и эти усилия часто приносят лишь иллюзорные результаты.
Эта статья объяснит, как Ethereum может достичь уровня простоты, близкого к уровню Bitcoin, за пять лет.

Упрощенный уровень консенсуса

Схема моделирования finality с 3 слотами — 3sf-mini

Новый дизайн слоя консенсуса (ранее известный как 'цепь луча') направлен на интеграцию опыта, накопленного в теории консенсуса, разработке ZK-SNARK, экономике стейкинга и других областях за последнее десятилетие, для создания долгосрочного оптимального слоя консенсуса Ethereum. Ожидается, что этот новый слой консенсуса по сравнению с существующей Цепью-Маяком достигнет большей простоты. Это особенно заметно в:

• Перестройка окончательности 3 слотов
  Этот дизайн устраняет различие между 'слотом' и 'эпохой', перемешивание комитетов и другие детали спецификации протокола, связанные с этими механизмами (например, синхронными комитетами). Базовая версия окончательности 3 слотов,Требуется всего около 200 строк кодаЭто можно достичь. По сравнению с текущим протоколом Gasper, 3-слотовая окончательность также имеет близкую к оптимальной безопасность.
• Количество активных валидаторов уменьшилось
  Делает более безопасным и целесообразным принятие более простого правила выбора вилки.
• Протокол агрегации на основе STARK
  Означает, что любой может стать агрегатором, не беспокоясь о доверии к агрегатору, избыточных комиссиях за повторяющиеся битовые поля и т. д. Хотя сама агрегация шифрования имеет определенную сложность, этоВысокоинкапсулированная сложностьОбщий систематический риск протокола намного ниже.
• Оба вышеуказанных пункта также вероятно поддержат более простую и надежную архитектуру равноправных участников (p2p).
• У нас есть возможность пересмотреть механизмы входа, выхода, вывода, переключения ключей, штрафа за инерцию и т. д. валидаторов и упростить их — не только сократив количество строк кода (LoC), но и обеспечив более ясные гарантии механизма, такие как более явный крайний срок 'слабой субъективности'.

Преимущество уровня консенсуса заключается в том, что он относительно отделен от выполнения EVM, поэтому у нас есть много места для продолжения внедрения этих улучшений.
Более сложная задача заключается в том, как достичь той же самой упрощенности на уровне выполнения.

Упростить уровень выполнения

Сложность Виртуальной Машины Ethereum (EVM) постоянно увеличивается, и многое из этой сложности было признано излишним (часто также связано с моими личными решениями): у нас есть 256-битная виртуальная машина, которая слишком оптимизирована для очень конкретных криптографических форм, которые сейчас постепенно вытесняются на задний план; и некоторые предварительно скомпилированные контракты слишком сосредоточены на очень немногих отдельных случаях использования.

Попытка постепенно устранить эти практические проблемы невозможна.Удалить @vbuterinИнструкция SELFDESTRUCT потребляет огромное количество энергии, но результаты ограничены. Недавняя дискуссия об EOF (EVM Object Format) дополнительно демонстрирует сложность внесения подобных изменений в виртуальную машину.

Поэтому в качестве альтернативы я недавно выдвинул более радикальную идею: вместо пошаговых (но все еще разрушительных) изменений для улучшения в 1,5 раза, лучше сразу перейти к совершенно новой, значительно более совершенной и простой виртуальной машине, стремясь к увеличению в 100 раз. Точно так же, как и «Слияние», мы сокращаем количество трансформаций, но каждая из них имеет значение. Конкретно, я предлагаю заменить существующую EVM на RISC-V (или другую виртуальную машину, которая будет использоваться ZK-доказателем Ethereum). Таким образом, мы достигнем:

• Значительное улучшение эффективности: поскольку смарт-контракты могут выполняться непосредственно в prover без накладных расходов на интерпретатор. Краткие данные показывают, что производительность может быть улучшена более чем в 100 раз во многих сценариях.
• Окончательная простота: по сравнению с EVM, спецификация RISC-VОчень простоДругие альтернативные решения (например, Каир) также являются краткими.
• Наследуя ожидаемые преимущества EOF: такие как сегментация кода, более дружественный статический анализ, больший предел ёмкости кода и т. д.
• Разработчики имеют больше выбора: Solidity и Vyper могут быть скомпилированы в новую виртуальную машину. Если выбран RISC-V, разработчики языков общего назначения также могут легко портировать свой код.
• Значительно снизить необходимость предварительной компиляции: возможно, оставив только несколько высокооптимизированных операций с эллиптическими кривыми (хотя они перестанут существовать, как только квантовые вычисления станут популярными).

Основным недостатком этого подхода является то, что, в отличие от EOF (немедленно развертываемого), новая виртуальная машина требует большего времени для получения преимуществ разработчиками. Чтобы смягчить это, мы можем ввести некоторые небольшие, но высокоэффективные улучшения EVM в краткосрочной перспективе.Увеличить лимит размера кода контрактаУвеличение инструкций DUP/SWAP17-32 и т. д.)

В конечном итоге это даст нам значительно упрощенную виртуальную машину. Но самый большой вопрос: что будет с существующим EVM?

Стратегия обратной совместимости переходного VM

При смысловом упрощении (или даже простом улучшении без добавления сложности) любой части Виртуальной Машины Ethereum (EVM) самая большая проблема заключается в том, как сохранить обратную совместимость с существующими приложениями, достигая поставленной цели.

Прежде всего, следует понимать, что нет единого способа определить область "кодовой базы Ethereum" (даже в пределах одного и того же клиента).

Цель - минимизировать объем зеленой зоны насколько это возможно: то есть логику, которую узлы должны выполнять для участия в консенсусе Ethereum, включая вычисление текущего состояния, доказательства, валидацию, FOCIL (First-Order Consensus Integrity Layer), базовую конструкцию блоков и т. д.

Оранжевая область не может быть уменьшена: если определенная функция слоя выполнения (будь то виртуальная машина, предварительная компиляция или другой механизм) удаляется из спецификации протокола или ее функциональность изменяется, клиент, занимающийся обработкой исторических блоков, все равно должен сохранить ее, но, что важно, новые клиенты (такие как ZK-EVM или формальные верификаторы) могут полностью игнорировать оранжевую область.

Новая категория - желтая зона: этот тип кода очень важен для понимания и анализа текущего состояния цепочки и построения лучших блоков, но он не является частью консенсуса. Пример - Etherscan(И некоторыеСтроитель блоков) Поддержка операций пользователя ERC-4337. Если мы используем реализацию RISC-V on-chain для замены определенных больших функций Ethereum (таких как учетные записи EOA и их поддержка для различных старых типов транзакций), то несмотря на значительное упрощение кода согласования, некоторые профессиональные узлы все еще могут продолжать использовать исходный код для разбора этих функций.

Важно, чтобы оранжевая и желтая зоны принадлежали к «Gate»Сложность инкапсуляцииЛюбой, кто хочет понять протокол, может пропустить их, клиенты Ethereum также могут не реализовывать их, и ошибки в этих областях не представляют риска консенсуса. Это означает, что сложность кода и негативное воздействие, вызванное оранжевыми и желтыми областями, намного меньше, чем зеленая область.

Перенесите код из зеленой зоны в желтую зону, этот подход аналогичен Apple Inc.Перевод через слой трансляции RosettaДля обеспечения долгосрочной совместимости.

Я предложил (заимствовано из@ипсилон/eof-ethereums-gateway-to-risc-v”> Команда Ipsilon недавно высказала свои взгляды) Процесс миграции виртуальной машины (используя миграцию EVM на RISC-V в качестве примера, но также применимый к миграции EVM на Каиро, и даже будущей миграции на более оптимальную ВМ):

1. Все новые предварительные компиляции должны быть написаны в стандартной ончейн реализации RISC-V, чтобы экосистема могла начать знакомиться и использовать RISC-V виртуальную машину.
2. Введение RISC-V в качестве варианта для разработки контрактов параллельно с EVM для разработчиков. Протокол поддерживает как RISC-V, так и EVM, позволяя контрактам, написанным на обоих языках, свободно взаимодействовать.
3. Заменить все предварительные компиляции (кроме операций с эллиптическими кривыми и KECCAK) на реализацию RISC-V. Мы удаляем эти предварительные компиляции через хардфорк и одновременно изменяем код по соответствующему адресу (в стиле форка DAO) на реализацию RISC-V. Поскольку виртуальная машина RISC-V чрезвычайно лаконична, даже просто это упрощает общую структуру.
4. Реализовать интерпретатор EVM, написанный на RISC-V, и развернуть его в качестве смарт-контракта на цепи. Через несколько лет после первоначального выпуска существующие EVM-контракты будут обрабатываться через этот интерпретатор.

После завершения шага 4 многие 'реализации EVM' все еще будут использоваться для оптимизации построения блоков, инструментов разработки и анализа on-chain, но они больше не будут частью ключевых спецификаций консенсуса. В то время консенсус Ethereum 'естественным образом' будет понимать только RISC-V.

Упростите, делясь компонентами протокола

Третий, а возможно, самый недооцененный метод упрощения - это использование единого стандарта в различных частях стека протоколов насколько это возможно. Обычно нет причин использовать разные протоколы для одной и той же цели в разных сценариях, однако такая ситуация все еще часто встречается на практике, в основном из-за недостатка коммуникации между различными частями дорожной карты протокола. Вот некоторые конкретные примеры упрощения Ethereum через 'максимизацию общего использования компонентов':

Объединенный код стирания

Нам необходимо исправить код удаления в трех сценариях:

• Выборочное сэмплирование доступности данных - Клиент проверяет, был ли опубликован блок
• Более быстрое P2P-распространение - Узлы могут принимать блоки после получения n/2 из n блоков, тем самым обеспечивая оптимальный баланс между снижением задержки и избыточностью.
• Распределенное хранилище истории - каждый кусочек истории Ethereum хранится во многих блоках, поэтому (i) эти блоки могут быть независимо проверены, и (ii) половина блоков в каждой группе может восстановить оставшуюся половину, что значительно снижает риск потери любого отдельного блока.

Если мы используем один и тот же код стирания (будь то код Рида-Соломона, случайный линейный код или другой) в трех случаях использования, мы получим некоторые важные преимущества:

1. Минимизировать общее количество строк кода
2. Повысить эффективность, потому что если каждый узел должен загружать различные части блока для одного случая использования (вместо всего блока), данные могут быть использованы для другого случая использования
3. Гарантировать Проверяемость: Все три блока в контексте могут быть проверены на основе корня

Если действительно требуются различные коды исправления ошибок, необходимо обеспечить 'совместимость' как минимум: например, в сценарии DAS горизонтально используется код Рида-Соломона, а вертикально - случайный линейный код, но оба они основаны на одном и том же математическом поле.

Единый формат сериализации

В настоящее время формат сериализации Ethereum строго говоря, только «полустандартизированный», так как данные могут быть повторно сериализованы и переданы в любом формате. Единственным исключением является хэш подписи транзакции, где требуется стандартизированный формат для расчета хэша.
Но стандартизация будущих форматов сериализации будет дополнительно улучшена, по двум причинам:

• Комплексная абстракция учетной записи (EIP-7701): Виртуальная машина сможет видеть полное содержимое транзакции
• Увеличение предела газа: Данные выполнения блока должны быть упакованы в блоб

В то время у нас есть возможность объединить решения по сериализации, необходимые для трех текущих аспектов: 1) уровень выполнения; 2) уровень консенсуса; 3) ABI вызова смарт-контракта.

Я предлагаю принятьSSZ(Простая сериализация), потому что SSZ имеет следующие преимущества:

• Легко декодировать: включая внутри умных контрактов (на основе дизайна из 4 байтов, несколько граничных случаев)
• Широко используется в консенсусе
• Высокая степень сходства с существующим ABI: низкая стоимость миграции инструментов

В настоящее время добавлено больше компонентовМиграцияTo SSZработаПланируя будущие обновления, мы должны полностью учитывать и использовать эти разработки.

Единая структура дерева

После того, как мы перейдем от EVM к RISC-V (или другой минималистской ВМ), шестнадцатеричное дерево Меркля Патриции станет самым большим узким местом в доказательстве выполнения блока, даже в средних сценариях. Переход к хеш-функцииБинарное дерево, значительно повысит эффективность верификатора и снизит стоимость данных для легких узлов и других сценариев.

При завершении миграции структуры дерева также следует обеспечить, чтобы уровень согласования использовал ту же структуру дерева, чтобы гарантировать, что весь Ethereum - как уровень согласования, так и исполнения - можно получить доступ и разобрать, используя тот же набор кода.

Отныне и в будущем

Упрощение и децентрализация имеют много общего. Оба являются предварительными требованиями, необходимыми для достижения более высокой цели устойчивости системы. Уделять явное внимание упрощению требует культурного сдвига. Выгоды от упрощения часто трудно увидеть на ранних этапах, но возможные издержки и дополнительная нагрузка отказа от этих «блестящих новых функций» сразу же становятся очевидными. Однако со временем долгосрочная ценность упрощения становится все более очевидной — сам Биткойн отличный пример.

Я предлагаю, чтобы мыИзучите подход tinygradДля установки четкой цели лимита строк кода для долгосрочной спецификации Ethereum целью является сделать критический код консенсуса Ethereum как можно ближе к минималистическому стилю Bitcoin. Код, работающий с историческими правилами Ethereum, все еще будет существовать, но должен быть изолирован от критического пути консенсуса. В то же время мы должны сформировать универсальный принцип проектирования: выбирать более простые решения всегда, отдавать предпочтение инкапсулированной сложности перед системной сложностью и склоняться к дизайнерским решениям, которые обеспечивают четкие проверяемые свойства и гарантии.

Отказ:

1. Эта статья перепечатана из [vitalik]. Все авторские права принадлежат оригинальному автору [виталикAll. Если у вас есть возражения по поводу этой перепечатки, пожалуйста, свяжитесьGate LearnКоманда обработает это своевременно.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционным советом.
3. Команда Gate Learn переводит статьи на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, за исключением случаев, указанных иным образом.