Введение

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

(Снижение комиссии в OP Chains после обновления Dencun | Источник:Оптимизм X)

Однако по мере того, как dapps в экосистеме перешли на высокомасштабируемые rollups и альтернативные сети уровня 1 (L1), активность пользователей в самом Ethereum начала снижаться. Кроме того, по мере того, как rollups перестали выплачивать высокие комиссии в Ethereum, в сообществе начали возникать опасения.

Кроме того, 2024 год был годом, когда масштабируемые L1, такие как Solana и Sui, проявили значительную силу. Огромное количество транзакций в секунду (TPS), генерируемое этими сетями, сделало активность на роллапах относительно незначительной.

В этом контексте возникли критики, такие как "Центрическая дорожная карта Ethereum ошибочна" или "Развитие Ethereum слишком медленное, чтобы преуспеть". Действительно ли Ethereum идет по правильному пути? Каким будет Ethereum в 2025 году или даже в 2030 году?

Эта серия затрагивает части дорожной карты Ethereum по двум основным темам, анализируя его будущее на основе технических деталей. Первая тема - Beam Chain.

Что такое предложение Beam Chain, и почему это важно?

Если бы человек должен был выбрать самую обсуждаемую тему в сообществе Ethereum в этом году, это, вероятно, было бы объявление исследователя Ethereum Джастина Дрейка о блокчейн-маяке на конференции Devcon. Это объявление вызвало большой интерес и соответственно много шума. Давайте проанализируем, что означает это предложение.

Основная идея предложения Beam Chain заключается в полном переработке слоя консенсуса Ethereum. Джастин Дрейк представил следующие три причины, по которым текущий слой консенсуса, Beacon Chain, нуждается в переработке:

• Лучшее понимание MEV через прошлый опыт
• Быстрое развитие технологии SNARK (например, развитие zkVM продвигается с поразительной скоростью, более чем в 10 раз быстрее)
• Избавление от "технического долга", присутствующего в блокчейне-маяке

В настоящее время план развития консенсусного уровня Ethereum включает следующие элементы:

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

Кроме того, более быстрые слоты и более быстрая окончательность - это новые разработки, предлагаемые для достижения улучшения производительности при сохранении безопасности - фактор, которому не придавалось приоритетное значение в первоначальных разработках. Для их реализации требуются обширные изменения на уровне консенсуса.

Цепочка Beam предлагает достичь этих изменений через один жёсткий форк. Для краткости:

1. Реализация дорожной карты для слоя консенсуса Ethereum требует полной переработки слоя консенсуса.
2. В этом контексте основные изменения на дорожной карте будут объединены в хардфорк с названием Beam Chain.
3. Он включает в себя четыре элемента: более быстрые времена блоков, более быструю окончательность, снежение цепей и квантовую устойчивость.

Далее рассмотрим, как каждый из них реализуется и какие технические последствия они вызывают.

Технические детали дизайна Beam Chain

Более быстрые слоты и более быстрая окончательность

В настоящее время время слота Ethereum составляет 12 секунд, и для того чтобы блок, подключенный к слоту, достиг финальности, требуется 2-3 эпохи (приблизительно 15 минут). Улучшение этих времен положительно повлияет на пользователей Ethereum, приложения и rollups, работающие на Ethereum.

Более короткая окончательность (Orbit SSF)

Эта тема, известная среди исследователей Ethereum как SSF (Single Slot Finality), направлена на сокращение времени достижения окончательности блоков Ethereum с примерно 15 минут до 12 секунд, обеспечивая пользователям более быстрое подтверждение. Чтобы понять однослотовую окончательность, нам необходимо понять текущий алгоритм консенсуса Ethereum, Gasper.

Основным принципом проектирования Gasper является обеспечение определенного уровня экономической безопасности блока, предложенного в слоте, через определенное время, минимизируя при этом нагрузку на коммуникацию каждого валидатора. Для достижения этой цели Ethereum разделяет весь набор валидаторов на комитеты, распределенные по 32 слотам. Каждый слот может содержать до 64 комитетов, и цель состоит в том, чтобы составить каждый комитет из 128 валидаторов (хотя это число может увеличиться, если общее количество активных валидаторов превысит это значение).

Валидаторы внутри каждого комитета независимо проверяют блок и голосуют за него с использованием BLS-подписей. Механизм BLS-подписей позволяет объединять несколько подписей в одну, то есть определенный узел внутри комитета собирает эти подписи и компилирует их в один компактный пакет данных. Путем передачи этой объединенной подписи, следующий предлагающий блок может подтвердить с минимальными данными, что блок был правильно проверен.

(Агрегация подписи BLS между валидаторами Ethereum | Источник: eth2book)

В итоге, Gasper Ethereum достигает как масштабируемости, так и экономической безопасности через следующие механизмы:

• Валидаторы распределены по слотам в комитетах в течение 6,4-минутного периода, что исключает необходимость прямого общения между всеми валидаторами.
• Процесс агрегированной подписи гарантирует, что голоса валидаторов за блок могут быть проверены с использованием небольшого объема данных.

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

Это приводит к следующему диаграмматическому представлению:

(Экономическая окончательность на Gasper | Источник:Orbit SSF)

Это создает различные проблемы и ухудшает UX. Например:

• При выводе средств с CEX (централизованной биржи) на Ethereum, или наоборот, период подтверждения может составлять около 10 минут, что является относительно избыточным.
• Роллапы Ethereum и dApps сталкиваются с риском того, что блоки L1, от которых они зависят, могут не быть завершены и могут быть аннулированы. Если не будут приняты соответствующие контрмеры, это может вызвать проблемы.

Например, в марте 2024 года Polygon zkEVM столкнулся с остановкой цепи, которая продолжалась более двух дней из-за неправильной обработки реорганизации Ethereum.

Сокращение времени до окончательности не является невозможным, как это демонстрируют алгоритмы консенсуса, такие как Tendermint, которые уже применяются в нескольких протоколах. Однако вызовом при принятии механизма Tendermint является частая P2P-коммуникация между узлами, что вводит ограничения масштабируемости.

В Tendermint, если количество узлов равно N, его сложность сообщений составляет O(N^3). Это означает, что с увеличением количества узлов частота общения между ними растет экспоненциально, ограничивая масштабируемость. Таким образом, протоколы, подобные Ethereum, с многими валидаторами, не могут напрямую принять Tendermint так, как он есть.

Для применения консенсуса в стиле Tendermint к Ethereum необходимо выполнить дополнительную работу по решению этих проблем.

Обзор предложения Orbit SSF

Orbit SSF нацелен на модификацию механизма комитета Gasper для сокращения времени окончательной фиксации слота при сохранении высокой экономической безопасности.

Предложение заключается в уменьшении размера эпохи с 32 слотов до одного слота (~12 секунд). Однако, как уже упоминалось ранее, это приведет к увеличению использования ресурсов для коммуникации между валидаторами, негативно сказываясь на децентрализации Ethereum.

Для решения этой проблемы Orbit SSF предлагает следующие идеи:

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

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

Следующее обновление Ethereum, Pectra, включает EIP-7251, которое предлагает увеличить максимальную сумму стейкинга (MaxEB) для валидаторов с 32 ETH до 2048 ETH. Хотя это предложение привлекательно для операторов инфраструктуры узлов Ethereum, оно также является предпосылкой для Orbit SSF.

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

(Вознаграждение и вероятность попадания в комитет в Orbit SSF | Источник:Orbit SSF)

Кроме того, Orbit SSF переходит к «комитетной окончательности». В Gasper комитеты могли вносить вклад в окончательность только после прохождения двух или более эпох, но Orbit SSF позволяет каждому комитету, назначенному на слот, вносить вклад в окончательность в режиме реального времени. Он стремится сделать комитеты более активными участниками окончательности и достичь масштабируемости быстрее.

(Finality in Orbit SSF using Cap-and-slow-rotate | Источник:Orbit SSF)

Ключ здесь заключается в составе членов комитета. Orbit SSF предлагает механизм «медленного вращения», при котором валидаторы с большими ставками практически фиксируются в комитетах, а меньшие валидаторы вращаются туда-сюда. Это позволяет установить очень высокое значение F, представляющее экономический порог безопасности, при минимальных затратах на коммуникацию между валидаторами и обеспечении низких времен финальности.

Например, установка n = 3 и значительно большого значения F позволило бы Ethereum достичь окончательности примерно за три слота, тем самым осуществляя видение Джастина Дрейка о 3-слотовом FFG.

Однако повышение F до уровня всего набора проверяющих Ethereum не так просто. Это может снизить стоимость проведения атаки на 51% на Ethereum. Таким образом, основным вызовом для Orbit SSF в будущем является определение того, как технически увеличить F, чтобы обеспечить надежность безопасности Ethereum, не жертвуя децентрализацией.

Короткие времена слотов (слоты длительностью 4 секунды) Даже если достигнута SSF (или окончательность в 3 слота), пользователи Ethereum по-прежнему будут испытывать минимальное время подтверждения транзакции в 12 секунд. Это приводит к двум основным недостаткам для пользователей:

1. Долгая задержка по сравнению с другими L1, такими как Solana и Sui
2. Более высокая уязвимость к MEV (MEV уменьшается с укорачиванием времени блока, что делает пользователей Ethereum более подверженными MEV)

Кроме того, особенно неблагоприятное влияние на роллапы, особенно на основе роллапов, оказывает 12-секундное время блока. Например, Taiko реализует основной роллап, публикуя каждый блок L2 на L1. В результате время блока Taiko может достигать минимума в 12 секунд и иногда превышать 24 секунды.

Были предложены два решения для решения этой проблемы:

a. Уменьшить время блока Ethereum до 4 или 8 секунд

b. Используйте предварительные подтверждения

Сокращение времени блока Ethereum

Сокращение времени блока Ethereum является темой активных обсуждений. Оно было официально формализовано как EIP-7782, который предлагает уменьшить время слота с 12 секунд до 8 секунд, тем самым увеличивая масштабируемость Ethereum на 33%. Однако, время слота в 8 секунд может не быть оптимальным для пользовательского опыта или основанных на rollups. Достижение более короткого времени слота кажется более желательным.

Тем не менее, более короткое время блока может привести к увеличению централизации набора валидаторов. Из-за физических ограничений валидаторы, находящиеся на большом расстоянии друг от друга, сталкиваются с более длительным временем связи, и время слота в 4 секунды может сделать связь невозможной в определенных сценариях.

Статистика времени распространения блока основной сети Ethereum дает представление о возможности времени блока в 4 секунды. Ниже приведен график распределения времени распространения блоков.

(CDF времени прибытия сообщений | Источник: Задержка распространения сообщений Gossipsub)

Примерно 98% блоков распространяются в пределах 4 секунд, в то время как около 2% требуют большего времени. Исходя из этих данных, время блока в 4 секунды может показаться выполнимым. Однако время блока учитывает не только коммуникацию, но и выполнение и голосование. Принимая во внимание эти факторы, только около 2 секунд из 4 секунд времени блока будут доступны для коммуникации. При таких условиях достижение времени блока в 4 секунды является сложной задачей.

Для решения этой проблемы необходимо сократить объем передаваемых данных, максимально увеличить производительность компонентов P2P в клиентах или сделать физическую коммуникацию более эффективной.

Использование предварительного подтверждения

Тем временем предварительные подтверждения могут улучшить опыт пользователей. Предварительные подтверждения позволяют сущностям, создающим блоки, обещать пользователям: «Ваша транзакция будет включена в следующий блок», доставляя результаты пользователям быстрее, чем время слота.

Преимущество предварительного подтверждения заключается в том, что валидаторы L1 могут использовать его, не требуя форка или модификаций клиента. Например, Commit-Boost - это программное обеспечение, которое позволяет валидаторам Ethereum генерировать и распространять предварительные подтверждения безопасно.

Commit-Boost, как и MEV-Boost, является дополнительным модулем для валидаторов, позволяющим им безопасно генерировать и передавать «обязательства». В зависимости от конкретного случая использования, эти обязательства могут принимать различные формы:

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

Однако эффективность Commit-Boost зависит от принятия валидаторами. Если им пользуется только несколько валидаторов, влияние на UX будет минимальным. Тем не менее, Commit-Boost получил сильную поддержку от сообщества Ethereum и имеет потенциал стать широкоиспользуемым промежуточным ПО, аналогичным MEV-Boost. Он получил поддержку от известных операторов валидаторов, таких как Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 и Figment. Кроме того, он получил гранты от EF, Lido и Eigenlayer, а также наслаждается сильной поддержкой от блок-строителя Titan.

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

Роль Beam Chain в более быстрых слотах

Как обсуждалось в презентации Джастина Дрейка, цель Beam Chain - сократить время блока. Таким образом, исследование и реализация, вероятно, будут сосредоточены на сокращении времени слота до 4 секунд без ущерба децентрализации. Это может быть решено с помощью полной снежной бурки Ethereum, что будет объяснено во второй части этой статьи.

Снеженицы цепи и квантовая устойчивость

Джастин заявил в своей презентации, что цель Beam Chain - сделать консенсус-клиент более эффективным с использованием технологии ZK. Что это означает, как это можно достичь и почему это необходимо?

Преобразование цепи снарка

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

Цепь Beam стремится заменить этот процесс повторного выполнения на «проверку» с использованием технологии ZK. Это значительно снизит аппаратные требования для валидаторов и позволит любому запускать узел Ethereum откуда угодно. Для достижения этой цели цепь Beam и Ethereum будут использовать ZK SNARKs.

ZK в протоколе Ethereum

ZK SNARKs имеют следующие два свойства:

1. Они позволяют проверить, что определенное вычисление было выполнено, не требуя повторного выполнения вычисления
2. Размер доказательства компактен по сравнению с исходными данными

Идея заключается в применении ZK к вычислениям и данным, необходимым для достижения консенсуса в Ethereum, генерируя доказательство того, что предписанная логика была соблюдена. Это означает, что валидаторы могут достигать консенсуса, проверяя ZK-доказательство, вместо повторного выполнения всего блока и сохранения обновленного состояния. Проверка ZK-доказательства значительно более эффективна с точки зрения размера данных и масштабируемости, чем повторное выполнение.

В результате аппаратные требования для валидаторов Ethereum могут быть радикально снижены. Например, Виталик выразил в статье The Verge, что целью является обеспечить возможность валидаторам работать даже в ресурсоемких средах, таких как умные часы.

Что нужно сделать?

Первым шагом является снежность функции перехода состояния. Функция перехода состояния обычно имеет следующую форму:

f(S,B)=S’

Здесь:

• S: Предварительное состояние блокчейна
• B: Указанный блок
• S': пост-состояние блокчейна после выполнения блока
• f: Функция перехода состояния

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

В Beam Chain целью является снорковафикация функции перехода состояния слоя консенсуса. В настоящее время функция перехода состояния внутри слоя консенсуса Ethereum выполняется в каждом слоте и выполняет следующие действия:

• Обновляет информацию о слоте и заголовке блока после получения блока
• Проверяет подпись валидатора, который предложил блок
• Проверяет транзакции внутри блока
• Обрабатывает выводы, сокращения, завершение блока и другую информацию при каждом переходе эпохи

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

В этом случае кто генерирует доказательство ZK? Обычно можно предположить, что предлагающий блок также несет ответственность за генерацию доказательства ZK. Однако важно отметить, что не все валидаторы могут генерировать доказательства ZK.

Beam Chain стремится достичь производительности, при которой ZK-доказательство может быть сгенерировано за 3 секунды на обычном ноутбуке. Однако, даже если этой цели будет достигнуто, валидаторы, работающие на устройствах, таких как умные часы или смартфоны, могут не иметь достаточных ресурсов для генерации ZK-доказательств.

Здесь сеть может полагаться на альтруизм. Нужно только одно ZK-доказательство для перехода состояния слоя консенсуса на блок, и оно не обязательно должно быть сгенерировано предложителем блока. Другими словами, пока хотя бы один субъект в сети генерирует ZK-доказательство для каждого блока, это может гарантировать, что блоки Beam Chain будут правильно производиться.

Будущее: полная снаркификация Ethereum

Это изменение само по себе, возможно, не существенно улучшит производительность валидатора. Функция перехода состояния уровня консенсуса включает в себя относительно легкие действия по сравнению с функцией перехода состояния уровня выполнения. Однако основное узкое место заключается не в ресурсах, необходимых для выполнения функции перехода состояния, а в пропускной способности сети. Валидаторы борются за достижение консенсуса в выделенное время, когда размер данных (блоков), которые они обмениваются, увеличивается. Вот почему Ethereum сохраняет предельное значение газа в 30M в течение последних трех лет.

Если эти изменения будут реализованы вместе с снэркификацией слоя выполнения, валидаторам будет нужно обмениваться гораздо меньшими объемами данных, чем целыми блоками. Это происходит потому, что доказательства SNARK значительно компактнее исходных данных. Полностью снэркифицированные Ethereum валидаторы будут обмениваться меньшими объемами данных, что позволит уменьшить требования к сети по сравнению с текущей системой.

В заключение, следующие преимущества полной снежности Ethereum для валидаторов.

1. Валидаторам нужно только проверять доказательства, а не повторно выполнять вычисления, что снижает вычислительные требования
2. Валидаторы обмениваются доказательствами вместо полных данных блоков, что снижает требования к пропускной способности сети

В результате экосистема Ethereum может существенно измениться. Например:

• Такие вещи, как «Приложения узлов Ethereum», могут позволить валидаторам работать на мобильных устройствах.
• Любой, удовлетворяющий минимальным требованиям по стейкингу, может запустить узел Ethereum, значительно снизив барьер для становления валидатором.

Это сделает участие валидаторов намного более доступным и децентрализованным.

Квантовоустойчивые подписи

Достаточно ли применения механизма снарк для функции перехода состояния в качестве консенсусного слоя Beam Chain?

С какими проблемами столкнется Ethereum в пост-квантовом мире?

Есть еще одна область, на которую направлена Beam Chain: генерация подписей. Консенсусный уровень Ethereum в настоящее время использует подписи проверяющего в качестве данных аттестации для завершения блоков и определения правильной цепи в случае вилок.

На данный момент Ethereum использует подписи BLS для этой цели, которые, как уже объяснялось ранее, имеют свойство агрегации, позволяя объединять несколько подписей в одну. Эта агрегация значительно улучшает эффективность процесса консенсуса в Ethereum. Однако у этого механизма подписей есть фундаментальная проблема: он уязвим перед квантовыми компьютерами.

Используемые в блокчейне-маяке Ethereum подписи BLS основаны на эллиптических кривых. Безопасность механизмов подписей на основе эллиптических кривых зависит от проблемы дискретного логарифма (DLP), которую высокая вычислительная мощность квантовых компьютеров может подорвать. Это делает подписи на основе эллиптических кривых уязвимыми по своей сути перед квантовыми компьютерами.

Квантовые вычисления быстро развиваются, что подтверждается последними достижениями Google в области квантовых чипов, таких как Willow. Google утверждает, что Willow может выполнять вычисления за 5 минут, на выполнение которых суперкомпьютеру понадобится 10^25 лет. Хотя это пока не угрожает безопасности эллиптических кривых в корне, продолжающиеся достижения в таком темпе могут поставить под угрозу блокчейн-системы в течение нескольких лет.

(Переход к стандартам криптографии после квантовых вычислений | Источник: NIST IR 8547)

Американский Национальный институт стандартов и технологий (NIST) уже начал работы по стандартизации квантово-устойчивых алгоритмов подписи для решения предполагаемого разрушения существующих систем из-за квантовых компьютеров.

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

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

Проблемы и роль ZK

Основной проблемой является отсутствие свойства агрегации в подписях, основанных на хэшах, присутствующем в подписях BLS. Ethereum полагается на агрегацию подписей во время консенсуса для достижения эффективности. Без агрегации Ethereum больше не сможет вместить большой набор валидаторов.

ZK можно использовать для решения этой проблемы. Это включает использование агрегирования доказательств, технологии, которая объединяет несколько ZK-доказательств в одно доказательство. Механизм работает следующим образом:

(Диаграмма агрегации доказательств | Источник: Figment Capital)

1. Валидаторы подписывают блок с использованием квантовоустойчивого алгоритма.
2. Подписи отправляются агрегатору**или комитет агрегации.
3. Агрегатор генерирует ZK-доказательство, проверяющее правильность подписей.
4. С помощью техник агрегации доказательств агрегатор комбинирует новые доказательства с существующими по мере получения новых подписей.

Этот подход позволяет Ethereum достигать такой же эффективности, как агрегация подписей BLS, при этом обеспечивая квантовую устойчивость на уровне консенсуса.

Роли ZK в цепочке Beam

В итоге, блокчейн Beam с ZK принесет следующие преимущества:

1. Предоставление валидаторам возможности выполнять проверку доказательств вместо повторного выполнения функции перехода состояния уровня консенсуса, что способствует упрощенным требованиям к валидаторам.
2. Служа как основа для алгоритма агрегации квантово-устойчивых подписей, улучшая эффективность уровня консенсуса.

zkVM как основа для ZK в цепи Beam

Система подтверждения, лежащая в основе ZK в Beam Chain, будет zkVM. Основанный на Risc-V zkVM позволяет доказать любую программу на любом языке, что обеспечивает большую гибкость.

(Переход состояния Beam для компиляции в Risc-V и проверки в zkVMs | Источник: Объявление о сети Beam Chain от Джастина Дрейка)

Это хорошо соответствует существующей клиентской экосистеме Ethereum, разработанной на нескольких языках, сохраняя разнообразие и отказоустойчивость Ethereum. В будущем Beam Chain различные клиенты будут писать функцию перехода состояния на нескольких языках программирования, компилировать ее в Risc-V и допускать ее проверку в любых Risc-V-основанных zkVMs. По этой причине zkVM является естественным выбором для Beam Chain.

Заключение

Если Beam Chain успешно реализован, Ethereum, скорее всего, будет иметь следующие функции:

1. Пользователи будут испытывать подтверждения транзакций в течение 4 секунд, с окончательностью, достигнутой в течение 12 секунд.
2. Валидаторы будут проверять переходы состояний в слое консенсуса с использованием ZK-доказательств. Если слой выполнения также приводится в форму snarkified, валидаторам потребуется только минимальное количество данных для участия в консенсусе.
3. Подписи валидаторов будут устойчивы к квантовым вычислениям
4. t, предотвращая взлом квантовыми компьютерами консенсус Ethereum.

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

Этим завершается наше исследование того, каким может быть Ethereum через пять лет через призму блокчейна Beam. В следующей статье мы рассмотрим, каким может быть Ethereum в 2025 году с двух точек зрения: пользовательский опыт и устойчивость к цензуре.

Приложение: Часто задаваемые вопросы о Beam Chain

(В): Предложение Джастина Дрейка обсуждалось конфиденциально. Не противоречит ли это основной ценности Ethereum быть «открытым»?

(A): Нет, это не так. Предложение по созданию цепи Beam просто предполагает реализацию определенных частей существующего плана развития Ethereum сразу. Будет ли оно реализовано, пока еще требует обсуждения сообщества. Все вышеупомянутые темы уже имеют соответствующие EIP или публикации на Ethresear.ch. Это в большей или меньшей степени показывает, что цепь Beam не является предложением о новом, ранее не разглашенном направлении для Ethereum. Более того, обсуждения плана развития Ethereum проводятся публично во время двухнедельного звонка всех основных разработчиков, в котором может участвовать любой желающий. Если кто-то не согласен с планом развития или имеет новые идеи, он может высказать свое мнение во время этих звонков или представить новые предложения в форме EIP или публикаций на Ethresear.ch.

В заключение, предложение Джастина о цепочке Beam не заключается в изменении дорожной карты, а скорее в группировке частей дорожной карты под одним именем или мемом.

(В): Разве 5 лет не слишком долго для внедрения Beam Chain?

(A): Пять лет могут показаться долгим временем, но нужно учесть два фактора:

1. Ethereum построен на многоклиентской архитектуре.
2. Ethereum имеет наибольшее количество валидаторов среди всех блокчейнов.

(Разнообразие клиентов консенсуса | Источник: Разнообразие клиентов Ethereum)

Механизм консенсуса Ethereum следует протоколу, основанному на BFT, где, если более трети валидаторов действуют по-разному от остальных, блоки не могут быть окончательно подтверждены. Если бы Ethereum был создан только одним или двумя клиентами, любая ошибка в этих клиентах могла бы нарушить производство блоков. Поэтому Ethereum всегда стремился к много клиентской архитектуре, разработанной на нескольких языках программирования. Это разнообразие явно проявляется в текущей клиентской экосистеме Ethereum.

Как показано на изображении, консенсусный уровень Ethereum в настоящее время работает с как минимум четырьмя клиентами. Чтобы заменить Beacon Chain цепочкой Beam, все четыре команды клиентов должны сотрудничать в разработке. Учитывая это и большое количество проверяющих Ethereum, процесс разработки цепочки Beam должен приоритезировать стабильность и не может быть ускорен до временного интервала нескольких месяцев или 1-2 лет.

Отказ от ответственности:

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