Новый документ Виталика: Возможное будущее Ethereum, The Surge

Автор: Виталик Бутерин

Составление: Карен, Новости предвидения

Особая благодарность Джастину Дрейку, Франческо, Сяо-вэй Вану, @antonttc и Георгиосу Константопулосу.

В начале в дорожной карте Ethereum было две стратегии масштабирования. Одна из них (см. раннюю статью 2015 года) - это ‘Шардинг’ (sharding): каждый Узел должен только проверять и хранить небольшую часть транзакций, а не все транзакции в цепи. Любая другая сеть peer-to-peer (например, BitTorrent) также работает таким образом, поэтому, конечно, мы можем заставить блокчейн работать таким же образом. Другая - это Протокол Layer2: эти сети будут находиться над Ethereum, что позволит им в полной мере использовать его безопасность, одновременно сохраняя большую часть данных и вычислений вне основной блокчейн. Протокол Layer2 означает state channels 2015 года, Plasma 2017 года, а затем Rollup 2019 года. Rollup сильнее, чем state channels или Plasma, но им требуется большая пропускная способность данных в блокчейне. К счастью, к 2019 году исследования Шардинга уже решили проблему ‘доступности данных’ при масштабировании. В результате два пути слились вместе, и мы получили дорожную карту, сосредоточенную на Rollup, которая остается стратегией масштабирования Ethereum по сегодняшний день.

The Surge, издание дорожной карты на 2023 год

Дорожная карта, сфокусированная на Rollup, предлагает простое разделение обязанностей: ETH L1 стремится стать мощным и Децентрализация базового слоя, в то время как L2 отвечает за расширение экосистемы. Эта модель повсюду в обществе: существование судебной системы (L1) не направлено на достижение сверхбыстрой и эффективной работы, а скорее на защиту контрактов и прав собственности, а предприниматели (L2) должны строить свой бизнес на этом прочном базовом уровне и вести человечество на (буквально или метафорически) Марс.

В этом году важные результаты достигнуты в рамках дорожной карты, сфокусированной на Rollup: с выпуском блобов EIP-4844 значительно увеличилась пропускная способность данных на уровне L1 ETH, несколько вариантов реализации Rollup для Ethereum Virtual Machine (EVM) на уровне L2 находятся в первой стадии. Каждый L2 существует как «ширдинг» с собственными внутренними правилами и логикой, и сегодня разнообразие и множественность вариантов реализации ширдинга становятся реальностью. Но, как мы видим, этот путь также встречает некоторые уникальные вызовы. Поэтому наша задача сейчас заключается в завершении дорожной карты, сфокусированной на Rollup, и решении этих проблем, сохраняя при этом надежность и децентрализацию L1 ETH.

Взрыв: Ключевая цель

1. В будущем Ethereum может достичь более 100 000 TPS через L2;

2. Сохранять Децентрализация и устойчивость L1;

3, по крайней мере, некоторые L2 полностью наследуют основные свойства Ethereum (Ненадежный, открытый, устойчивый к цензуре);

4. Ethereum должен ощущаться как единая экосистема, а не как 34 разных блокчейна.

Содержание главы

1. Треугольник противоречий масштабируемости
2. Дальнейшее развитие выборочной доступности данных
3. Сжатие данных
4. Обобщенная плазма
5. Зрелая система подтверждения L2
6. Улучшение межслоевой совместимости L2
7. Расширение выполнения на L1

Парадокс треугольника масштабируемости

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

Страница, которую нужно обратить внимание, не является теоремой, и сообщение, в котором представлен треугольник невозможности, не сопровождается математическим доказательством. Он действительно дает эвристический математический аргумент: если узел, дружественный к Децентрализация (например, потребительский ноутбук), может проверить N транзакций в секунду, и у вас есть цепь, которая обрабатывает k*N транзакций в секунду, то (i) каждая транзакция может быть увидена только 1/k узлом, что означает, что злоумышленнику достаточно разрушить небольшое количество узлов, чтобы провести злонамеренную транзакцию, или (ii) ваш узел станет мощным, а ваша цепь не будет Децентрализация. Цель этой статьи заключается не в доказательстве того, что невозможно разрушить треугольник невозможности; наоборот, она направлена на показ того, что разрушение треугольника невозможности трудно, и для этого нужно в некоторой степени выйти за пределы содержащейся в этом аргументе мыслительной рамки.

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

Однако комбинация выборочной доступности данных и SNARKs действительно решает треугольную парадоксу: она позволяет клиентам проверить доступность определенного количества данных и правильность выполнения определенного количества вычислительных шагов при загрузке только небольшого количества данных и выполнении минимального количества вычислений. SNARKs не требуют доверия. Выборочная доступность данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики не масштабируемой цепочки, то есть даже атака на 51% не может принудительно принять плохие блоки в сеть.

Другим способом преодоления трудностей является архитектура Plasma, которая использует изящные технологии для передачи ответственности за мониторинг доступности данных пользователям способом, совместимым с поощрениями. В период с 2017 по 2019 год, когда у нас было только доказательство мошенничества для расширения вычислительных возможностей, безопасность выполнения в Plasma была очень ограничена, но с распространением SNARKs (нулевых доказательств обозначений), архитектура Plasma стала более жизнеспособной для более широкого спектра применений, чем когда-либо прежде.

Дальнейшие шаги по образцовому обеспечению доступности данных

Мы решаем какую проблему?

В 2024 году 13 марта, когда Dencun будет обновлен, в блокчейне Ethereum каждый 12-секундный слот будет содержать около 3 блобов размером около 125 кБ, или доступная пропускная способность данных для каждого слота составит около 375 кБ. Предполагая, что данные транзакции будут непосредственно опубликованы в блокчейне, размер транзакции ERC20 составляет около 180 байт, следовательно, максимальная TPS для Rollup на Ethereum составит: 375000 / 12 / 180 = 173.6 TPS

Если мы добавим calldata ETH (теоретическое максимальное значение: 30 миллионов газов каждый слот / 16 газов на байт = 1,875,000 байт на слот), то это становится 607 TPS. Используя PeerDAS, количество блобов может увеличиться до 8-16, что обеспечит calldata 463-926 TPS.

Это значительное улучшение для L1 Ethereum, но недостаточно. Мы хотим большей масштабируемости. Наша среднесрочная цель - 16 МБ на каждый слот, что, в сочетании с улучшениями сжатия данных Rollup, приведет к ~58000 TPS.

Что это? Как это работает?

PeerDAS - относительно простая реализация ‘1D sampling’. В блокчейне Ethereum каждый blob представляет собой многочлен степени 4096 над 253-битовым простым полем. Мы транслируем shares многочлена, где каждый share содержит 16 оценочных значений на смежных 16 координатах из общего числа 8192 координат. Из этих 8192 оценочных значений любые 4096 (в соответствии с предлагаемыми параметрами: любые 64 из 128 возможных образцов) могут восстановить blob.

Принцип работы PeerDAS заключается в том, чтобы каждый клиент прослушивал небольшую подсеть, в которой i-я подсеть транслирует любой образец i-го блоба, и запрашивал другие блобы на других подсетях через опрос узлов в глобальной p2p сети (которые слушают другие подсети). Более консервативная версия SubnetDAS использует только механизм подсети, без дополнительного опроса на уровне пира. Текущее предложение заключается в том, чтобы узлы, участвующие в аттестации, использовали SubnetDAS, а другие узлы (т.е. клиенты) использовали PeerDAS.

В теории мы можем значительно расширить масштаб «1D сэмплирования»: если мы увеличим максимальное количество блобов до 256 (цель - 128), то мы сможем достичь цели в 16 МБ, при этом доступность данных будет состоять из 16 образцов * 128 блобов * 512 байт на образец = пропускная способность данных в 1 МБ на слот. Это только находится в пределах нашей терпимости: это возможно, но это означает, что ограниченная пропускная способность клиента не может сэмплировать. Мы можем оптимизировать это до некоторой степени, уменьшив количество блобов и увеличив размер блоба, но это повысит стоимость восстановления.

Поэтому, в конечном итоге мы хотим двигаться дальше и выполнять 2D-дискретизацию (2D sampling), которая не только выполняет случайную выборку внутри блоба, но и между блобами. Используя линейные свойства обязательства KZG, мы расширяем набор блобов в блоке через новый набор виртуальных блобов, которые избыточно кодируют ту же информацию.

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

2D выборка. Источник данных: a16z крипто

Важно, что расширение обязательства вычисления не требует наличия блоба, поэтому это решение в корне дружественно к построению децентрализованных Блок. Фактически, для построения Блоков Узлу требуется только обязательство KZG блоба, и он может полагаться на выборочную доступность данных (DAS) для проверки доступности блока данных. Отбор доступности данных в одномерном пространстве (1D DAS) в корне также дружественен к построению децентрализованных блоков.

Какие связи есть с существующими исследованиями?

1. Исходное сообщение о доступности данных (2018):
2. Следующая статья:
3. Статья о DAS, парадигма:
4. Доступность 2D с обязательством KZG:
5. PeerDAS о ethresear.ch: и доклады:
6. ЭИП-7594:
7. SubnetDAS на ethresear.ch:
8. 2D восстанавливаемые тонкие различия в выборке:

Что еще нужно сделать? Какие еще компромиссы?

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

На более поздних этапах мы должны проделать больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасность. Мы также надеемся в конечном итоге перейти от KZG к альтернативному решению, которое будет квантово-безопасным и не требует доверенной настройки. На данный момент нам неизвестно, какие кандидаты будут дружественны к построению распределенных блоков. Даже с использованием дорогостоящей техники «грубой силы», такой как рекурсивный STARK, для генерации доказательства действительности, которое будет использоваться для восстановления строк и столбцов, это недостаточно для удовлетворения требований, поскольку, хотя технически размер STARK составляет O(log(n) * log(log(n)) хеш-значений (с использованием STIR), на самом деле STARK почти такой же большой, как и весь блоб.

Мой долгосрочный путь к реальности:

1. Реализация идеальной 2D DAS;
2. Придерживайтесь использования 1D DAS, жертвуя эффективностью полосы частот для образца в пользу простоты и устойчивости, принимая более низкий предел данных
3. Отказаться от DA и полностью принять Plasma как основную архитектуру Layer2, которую мы будем следовать.

Обратите внимание, что даже если мы решим выполнять масштабирование непосредственно на уровне L1, такой выбор возможен. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, L1 Блок станет очень большим, и клиенты захотят иметь эффективный способ проверить его правильность, поэтому нам придется использовать на уровне L1 ту же технологию, что и Rollup (например, ZK-EVM и DAS).

Как взаимодействовать с другими частями дорожной карты?

Если реализовать сжатие данных, спрос на 2D DAS уменьшится, или по крайней мере будет задержка, если Plasma будет широко использоваться, спрос дополнительно уменьшится. DAS также представляет вызов для построения БлокПротокола и механизма: хотя с теоретической точки зрения DAS дружелюбен к распределенной реконструкции, практически это требует комбинации с предложением списка включения пакетов и окружающими механизмами выбора форков.

Сжатие данных

Что мы решаем?

Каждая транзакция в Rollup занимает большое пространство данных в блокчейне: передача ERC20 занимает около 180 байт. Даже с идеальной выборкой доступных данных это ограничивает масштабируемость протокола Layer. У нас есть каждый слот 16 МБ, и мы получаем:

16000000 / 12 / 180 = 7407 ТПС

Если мы не только можем решить проблему числителя, но и проблему знаменателя, чтобы каждая транзакция в Rollup занимала меньше байт в блокчейне, что произойдет?

Что это такое и как оно работает?

На мой взгляд, лучшее объяснение - это картина два года назад:

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

Агрегация подписей: Мы перешли от подписи ECDSA к подписи BLS, особенностью которой является возможность объединения нескольких подписей в одну, которая может подтверждать действительность всех исходных подписей. На уровне L1 из-за высокой вычислительной стоимости верификации, даже после агрегации, не рассматривается использование подписи BLS. Однако в среде L2, где данные редки, использование подписи BLS имеет смысл. ERC-4337 предоставляет путь к реализации этой функции благодаря возможности агрегации.

Замена указателя на адрес: Если ранее использовался адрес, мы можем заменить 20-байтовый адрес на указатель на позицию в истории длиной 4 байта.

Сериализация пользовательского значения транзакции - большинство значений транзакции имеют малое количество цифр, например, 0,25 ETH представляется как 250,000,000,000,000,000 wei. Максимальная базовая комиссия и приоритетная комиссия также аналогичны. Таким образом, мы можем использовать пользовательский десятичный формат с плавающей запятой для представления большинства валютных значений.

Какие связи есть с существующими исследованиями?

1. Исследование sequence.xyz:
2. Оптимизация контракта L2 Calldata:
3. Основанные на доказательстве действительности роллапы (также известные как ZK-роллапы) различаются по статусу выпуска, а не по транзакциям:
4. Кошелек BLS - реализация агрегации BLS через ERC-4337:

Что еще нужно сделать, какие компромиссы?

Следующим шагом будет осуществление вышеуказанной схемы. Основные компромиссы включают:

1、Переключение на подпись BLS требует значительных усилий и может быть связано с снижением совместимости с доверенными аппаратными чипами, способными усилить безопасность. Его можно заменить оберткой ZK-SNARK для других схем подписи.

2、Динамическое сжатие (например, замена указателей на 01928374656574839201) приведет к усложнению клиентского кода.

3、将状态差异发布到 блокчейне而不是交易，会Падение可审计性，并使很多软件（例如 проводник блокчейна）无法工作。

Как взаимодействовать с другими частями дорожной карты?

Используется ERC-4337 и в конечном итоге часть его контента будет включена в L2 EVM, что значительно ускорит развертывание агрегирующей технологии. Размещение части контента ERC-4337 на L1 позволит ускорить его развертывание на L2.

Обобщенная Плазма

Мы решаем какую проблему?

Даже с использованием 16 МБ блоба и сжатия данных, 58 000 TPS могут быть недостаточными для полного удовлетворения потребностей потребителей в платежах, Децентрализация социальных сетей или других областях с высокой пропускной способностью, особенно когда мы начинаем учитывать факторы конфиденциальности, что может привести к снижению масштабируемости в 3-8 раз. Для высокобъемных приложений с низкой стоимостью, в настоящее время одним из вариантов является использование Validium, который сохраняет данные вне блокчейна и использует интересную модель безопасности: операторы не могут воровать средства пользователей, но они могут временно или постоянно замораживать средства всех пользователей. Но мы можем сделать лучше.

Что это такое и как это работает?

Plasma - это решение масштабирования, которое включает в себя публикацию Блока оператором вне блокчейна и размещение корневых хэшей этих Блоков в блокчейне (в отличие от Rollup, который помещает полные Блоки в блокчейн). Для каждого Блока оператор отправляет каждому пользователю ветвь Меркля, чтобы доказать, что произошли изменения в его активе или не произошло никаких изменений. Пользователи могут извлечь свои активы, предоставив ветвь Меркля. Важно отметить, что эта ветвь не обязательно должна иметь последнее состояние в качестве корня. Поэтому, даже при проблемах доступности данных, пользователи всё равно могут восстановить свои активы, извлекая их последнее доступное состояние. Если пользователь предоставляет недействительную ветвь (например, извлекает активы, которые он уже передал другому лицу, или оператор самостоятельно создаёт активы), то легитимность передачи активов можно определить с помощью механизма проверки в блокчейне.

Цепь Plasma Cash. Транзакции, в которых тратится монета i, размещены на i-й позиции в дереве. В этом примере, предполагая, что все предыдущие деревья действительны, мы знаем, что у Ивы сейчас есть Токен 1, у Дэвида есть Токен 4, у Джорджа есть Токен 6.

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

Один из способов создания цепи EVM Plasma (не единственный способ): использование ZK-SNARK для построения параллельного дерева UTXO, которое отражает изменение баланса, сделанное EVM, и определяет уникальное отображение ‘Токен’ в разные моменты времени в истории. Затем на этом можно построить структуру Plasma.

Одним из ключевых пониманий является то, что система Plasma не требует быть идеальной. Даже если вы можете защитить только подмножество активов (например, только Токены, которые не перемещались за последнюю неделю), вы уже значительно улучшили текущее состояние сверхмасштабируемой EVM (т.е. Validium).

Другой тип структуры - это гибрид Plasma/Rollup, например Intmax. Эти конструкции помещают небольшое количество данных каждого пользователя в блокчейн (например, 5 байт), что позволяет получить определенные характеристики между Plasma и Rollup: в случае Intmax можно достичь очень высокой масштабируемости и конфиденциальности, хотя даже в 16 МБ теоретически ограничено примерно до 16,000,000 / 12 / 5 = 266,667 TPS.

Какие ссылки есть на связанные с текущими исследованиями?

1. Оригинальная статья о Плазме:
2. Плазма Кэш:
3. Поток наличности Plasma Cashflow:
4. Intmax (2023):

Что еще нужно сделать? Какие компромиссы?

Оставшаяся основная задача заключается в том, чтобы внедрить систему Plasma в реальные производственные приложения. Как уже упоминалось, Plasma и Validium не являются альтернативой друг другу: любой Validium может улучшить свои безопасностные характеристики хотя бы в определенной степени, интегрировав особенности Plasma в свой механизм выхода. Основное внимание уделяется получению лучших характеристик для EVM (учитывая потребности в доверии, затраты на L1 Gas в худшем случае и способность сопротивляться атакам DoS), а также альтернативной структуре конкретного применения. Кроме того, по сравнению с Rollup, Plasma имеет более высокую концептуальную сложность, которую необходимо преодолеть непосредственно через исследования и создание более эффективной общей структуры.

Основные компромиссы, связанные с использованием дизайна Plasma, заключаются в том, что они более зависят от операторов и сложнее внедряются, хотя смешанный дизайн Plasma/Rollup обычно может избежать этого недостатка.

Как взаимодействовать с другими частями дорожной карты?

Чем более эффективным становится решение Plasma, тем меньше давления на L1 с его высокопроизводительными возможностями доступности данных. Перенос активности на L2 также может снизить давление MEV на L1.

Зрелая система подтверждения L2

Мы решаем какую проблему?

В настоящее время большинство Rollup фактически не являются ненадежными. Существует комитет по безопасности, который имеет возможность переопределять поведение системы (оптимистический или действительный доказательства). В некоторых случаях система доказательств даже не работает, или даже если работает, то только в консультативном режиме. Среди самых продвинутых Rollup есть: (i) некоторые приложения с конкретными функциями Rollup, такие как FUEL; (ii) Optimism и Arbitrum, которые на момент написания этой статьи являются двумя полными EVM Rollup, реализующими частичный бездоверительный этап, известный как «фаза 1». Основная причина, по которой Rollup не продвинулся дальше, заключается в опасениях наличия ошибок в коде. Нам нужен бездоверительный Rollup, и поэтому мы должны столкнуться и решить эту проблему.

Что это такое и как это работает?

Во-первых, давайте вспомним систему “stage”, которая была введена в этой статье.

Этап 0: пользователь должен иметь возможность запустить Узел и синхронизировать цепь. Если проверка полностью доверенна / централизована, это тоже нормально.

Этап 1: Должна быть система подтверждений (без доверия), гарантирующая принятие только действительных транзакций. Разрешается наличие комитета безопасности, который может отменить систему подтверждений, но требуется пороговое голосование на уровне 75%. Кроме того, часть комитета, блокирующая кворум (т.е. 26%+), должна находиться за пределами основной компании, создающей Rollup. Разрешается использование менее мощного механизма обновления (например, DAO), но он должен иметь достаточно долгую задержку, чтобы пользователи могли вывести свои средства, если он утверждает вредоносное обновление, до включения средств.

Этап 2: Должна существовать (недоверительная) система подтверждения, чтобы гарантировать принятие только действительных транзакций. Комиссия по безопасности разрешает вмешательство только в случае наличия доказанных ошибок в коде, например, если две избыточные системы подтверждения несогласованы друг с другом или если одна система подтверждения принимает два разных post-state корня для одного и того же Блок (или не принимает ничего в течение достаточно длительного времени, например, неделю). Разрешается использование механизма обновления, но с длительной задержкой.

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

1. Формальная верификация: мы можем использовать современную математику и вычислительные технологии для доказательства (optimistic и validity) системы, принимающей только те Блоки, которые соответствуют спецификации EVM. Эти технологии существуют уже десятилетия, но последние достижения (такие как Lean 4) делают их более практичными, а прогресс в области AI-помощи в доказательствах может еще более ускорить эту тенденцию.
2. Мульти-доказательства (Multi-provers): создание нескольких систем доказательств и вложение средств в эти системы доказательств, а также в комиссию по безопасности (или другие доверенные устройства, такие как TEE, с предположением о доверии). Если системы доказательств согласны, комиссия по безопасности не имеет власти; если они не согласны, комиссия по безопасности может только выбрать одну из них, но не может односторонне навязывать свой ответ.

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

Какие связи есть с существующими исследованиями?

1. EVM K-семантика (формальная верификация работы с 2017 года):
2. Лекция о многопруверной мысли (2022):
3. Taiko планирует использовать множественное подтверждение:

Что еще нужно сделать? Какие компромиссы?

Для Формальная верификация, объем работы очень велик. Нам нужно создать формально проверенную версию SNARK-проверяющего для всей EVM. Это крайне сложный проект, хотя мы уже начали. Есть один трюк, который может значительно упростить эту задачу: мы можем создать проверяющий SNARK, который прошел Формальная верификация для минимальной Виртуальная машина (например, RISC-V или Cairo), а затем реализовать EVM в этой минимальной Виртуальная машина (и формально доказать ее эквивалентность с другими спецификациями Виртуальная машина для ETH-блокчейна).

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

Как взаимодействовать с другими частями дорожной карты?

Перенос активности на L2 может снизить давление MEV на L1.

Улучшение межоперационной способности между L2

Мы решаем какую проблему?

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

Что это? Как это работает?

Улучшения межуровневой совместимости имеют множество категорий. В теории Ethereum, основанный на Rollup, и выполнение Шардинг L1 - это одно и то же. В настоящее время экосистема L2 Ethereum на практике имеет некоторые недостатки по сравнению с идеальным состоянием:

1. Адрес специальной цепочки: Адрес должен содержать информацию о цепочке (L1, Optimism, Arbitrum и т.д.). Как только это будет реализовано, процесс отправки через L2 может быть осуществлен простым введением адреса в поле «отправить», после чего Кошелек самостоятельно обработает процесс отправки (включая Кроссчейн взаимодействие Протокола).

2、Запросы на оплату на конкретной цепочке: должны легко и стандартизированно создавать сообщения в форме “отправьте мне X единиц типа Y на цепочке Z”. Это имеет два основных сценария использования: (i) оплата между людьми или между людьми и услугами торговца; (ii) запросы на финансирование DApp.

3、Взаимодействие кросс-чейн обмена и оплата Газ: должен существовать стандартизированный открытый Протокол для выражения операций взаимодействия кросс-чейн, таких как “Я отправлю 1 ефириум (в Optimism) тому, кто отправил мне 0.9999 ефириума на Arbitrum”, а также “Я отправлю 0.0001 ефириума (в Optimism) тому, кто включил эту транзакцию на Arbitrum”. ERC-7683 - это попытка решения первой проблемы, в то время как RIP-7755 - попытка решения второй проблемы, хотя оба протокола имеют более широкий спектр применения, чем указанные конкретные случаи.

4、легкий клиент：пользователи должны иметь возможность фактически проверять цепь, с которой они взаимодействуют, а не просто доверять поставщику RPC. Helios от a16z crypto может справиться с этим (для самой сети ETH), но нам нужно расширить эту доверенность на уровень L2. ERC-3668 (CCIP-read) - это одна из стратегий достижения этой цели.

Как обновить представление цепочки заголовков Ethereum в легком клиенте. После того как у вас есть цепочка заголовков, вы можете использовать доказательство Merkle для проверки любого объекта состояния. Как только у вас есть правильный объект состояния L1, вы можете использовать доказательство Merkle (если вы хотите проверить предварительное подтверждение, также можно использовать подпись) для проверки любого объекта состояния на уровне L2. Helios уже сделал первое. Расширение до второго представляет собой стандартизационную задачу.

1, Keystore Кошелек: Сегодня, если вы хотите обновить Секретный ключ вашего Смарт-контракта Кошелека, вы должны обновить его на всех цепях, где этот Кошелек существует. Keystore Кошелек - это технология, которая позволяет Секретному ключу существовать только в одном месте (либо на L1, либо, возможно, в будущем, на L2), и любой L2 с копией Кошелька может читать Секретный ключ из него. Это означает, что обновление требуется только один раз. Для повышения эффективности Keystore Кошелька требуется, чтобы L2 имел стандартизированный способ бесплатного чтения информации с L1; для этого есть два предложения - L1SLOAD и REMOTESTATICCALL.

Принцип работы Keystore Кошелек

2. Более революционная концепция «Моста общего доступа к Токенам»: Представьте себе мир, где все L2 используют доказательство действительности Rollup и каждый слот отправляет данные на блокчейн ETH. Даже в таком мире, для перемещения активов с одного L2 на другой в их исходном состоянии все равно требуется вывод и ввод средств, что влечет значительные затраты на L1 Gas. Один из способов решить эту проблему - создать общий и простой Rollup, который будет отслеживать, какой L2 владеет каждым типом Токена и каковы их балансы, а также позволять обновлять эти балансы через серию операций по отправке средств между L2. Это позволит осуществлять переводы между L2 без необходимости оплаты комиссии за каждую транзакцию на L1 и без использования технологий, таких как ERC-7683, основанных на Поставщике ликвидности.

3、Совместная компоновка: позволяет синхронные вызовы между конкретными L2 и L1 или между несколькими L2. Это способствует увеличению финансовой эффективности Децентрализованные финансы Протокола. Первое можно реализовать без какой-либо координации между L2; для второго требуется совместное упорядочение. Технология на основе Rollup автоматически применима ко всем этим технологиям.

Какие связи есть с существующими исследованиями?

**链特定Адрес：ERC-3770：

**ERC-7683:

**RIP-7755:

**Scroll keystore Дизайн кошелька:

**Гелиос:

**ERC-3668（иногда называемый CCIP Read）：

Предложение Джастина Дрейка о ‘предварительном подтверждении (совместном)’.

**L1SLOAD (RIP-7728):

**REMOTESTATICCALL в Optimism:

**AggLayer, который включает в себя идею общего моста для токенов:

Что еще нужно сделать? Какие компромиссы?

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

Эти задачи - не только технические, но и (возможно, главным образом) социальные, требуют совместной работы L2 и Кошелек, а также L1.

Как взаимодействовать с другими частями дорожной карты?

Большинство из этих предложений являются структурами “более высокого уровня”, поэтому они не оказывают большого влияния на уровень L1. Исключение составляет общая сортировка, которая оказывает значительное влияние на максимально извлекаемую стоимость (MEV).

Расширение выполнения на L1

Мы решаем какую проблему?

Если L2 станет очень масштабируемым и успешным, но L1 по-прежнему сможет обрабатывать только очень небольшой объем, то у сети Ethereum могут возникнуть значительные риски:

1、Экономическое положение активов ETH станет более нестабильным, что в свою очередь повлияет на долгосрочную безопасность сети.

2. Многие L2 получают выгоду от тесной связи с развитой финансовой экосистемой на L1. Если эта экосистема значительно ослабевает, то стимулом является становление L2 (а не независимым L1).

3. Для достижения такой же степени безопасности, как у L1, L2 потребуется много времени.

4. Если L2 неудачен (например, из-за злонамеренных действий или исчезновения оператора), пользователю все равно нужно будет восстановить свои активы через L1. Поэтому L1 должен быть достаточно мощным, чтобы время от времени реально справиться с высоко сложными и хаотичными заключительными работами L2.

Поэтому продолжение расширения самого L1 и обеспечение его способности продолжать вмещать все больше и больше случаев использования очень ценно.

Что это такое? Как это работает?

Самым простым способом увеличения объема Gas является простое увеличение его верхнего предела. Однако это может привести к централизации L1, что, в свою очередь, ослабит еще одну важную характеристику L1 Ethereum: доверие в качестве надежного фундаментального уровня. По-прежнему существует дискуссия о том, насколько устойчиво увеличивать верхний предел Gas, и это будет зависеть от того, какие другие технологии будут внедрены для упрощения верификации больших блоков (например, историческое истечение, безсостояний, доказательство действительности L1 EVM). Еще одним важным аспектом, который требует постоянного улучшения, является эффективность программного обеспечения клиента Ethereum, которая сегодня значительно выше, чем пять лет назад. Эффективная стратегия увеличения верхнего предела Gas на L1 будет включать в себя ускорение развития этих технологий верификации.

1. EOF：новый формат байт-кода EVM, более дружелюбный к статическому анализу, что позволяет достичь более быстрой реализации. Учитывая эти улучшения производительности, байт-код EOF может получить более низкие Газ сборы.
2. Многомерная ценовая политика Gas: устанавливаются различные основные расходы и ограничения для вычислений, данных и хранения, которые позволяют повысить среднюю вместимость уровня L1 Ethereum без увеличения максимальной вместимости (тем самым избегая возникновения новых рисков для безопасности).
3. Падение конкретного кода операции и предварительно скомпилированных стоимостей газа - исторический опыт показывает, что для предотвращения атак типа «отказ в обслуживании» мы неоднократно повышали стоимость газа некоторых операций с слишком низкой ценой. Можно сделать еще немного и снизить стоимость газа для операций с завышенной ценой. Например, сложение гораздо дешевле умножения, но в настоящее время стоимость операций ADD и MUL одинакова. Мы можем снизить стоимость ADD и даже сделать более низкую стоимость для более простых операций, таких как PUSH. В целом, это лучшая оптимизация.
4. EVM-MAX и SIMD: EVM-MAX - это предложение, которое позволяет более эффективное вычисление больших чисел в модуле в качестве отдельного модуля EVM. Если вычислено с помощью EVM-MAX, значения могут быть доступны только другим операциям EVM-MAX, если они явно экспортируются. Это дает больше пространства для оптимизации формата хранения этих значений. SIMD (single instruction multiple data) - это предложение, которое позволяет эффективно выполнять одну и ту же инструкцию для массива значений. Вместе они могут создать мощный сопроцессор рядом с EVM, который может использоваться для более эффективной реализации операций шифрования. Это особенно полезно для протоколов конфиденциальности и систем защиты L2, поэтому это поможет расширению L1 и L2.

Эти усовершенствования будут более подробно обсуждаться в будущих статьях Splurge.

Наконец, третья стратегия - это нативные Rollups (или Протоколы роллапов): по сути, это создание множества параллельных копий EVM, что позволяет создать модель, эквивалентную тому, что может предложить Роллап, но более тесно интегрированную в Протокол.

Какие связи есть с существующими исследованиями?

1. План расширения ETH-сети Polynya L1:
2. Многомерное ценообразование газа:
3. ЭИП-7706:
4. ЭОФ:
5. ЭВМ-МАКС:
6. SIMD:
7. Родные роллапы:
8. Интервью Макса Резника о ценности расширения L1:
9. Justin Drake обсуждает расширение с использованием SNARK и нативных роллапов:

Что еще нужно сделать, какие компромиссы?

L1 расширение имеет три стратегии, которые могут выполняться отдельно или параллельно:

1. Улучшение технологий (например, клиентского кода, клиента без состояния, истекшие записи), чтобы сделать L1 более легким для верификации, а затем увеличить лимит Газа.
2. Падение стоимости конкретных операций, увеличение средней емкости без увеличения риска худшего случая;
3. Нативные роллапы (то есть создание N параллельных копий EVM).

При изучении этих различных технологий мы обнаружим, что у каждой из них есть свои сильные и слабые стороны. Например, у оригинальных Rollups есть много слабых мест в плане комбинаторики, которые схожи с обычными Rollups: вы не можете отправлять одну транзакцию для выполнения операций на нескольких Rollup, как вы можете делать это в контрактах на одном L1 (или L2). Увеличение лимита Gas ограничит другие преимущества, которые можно получить, упрощая проверку на L1, такие как увеличение количества пользователей, запускающих Узел верификации, и увеличение количества solo стейкингов. В зависимости от способа реализации, сделать определенные операции в EVM (Виртуальная машина Ethereum) более дешевыми может увеличить общую сложность EVM.

Один из основных вопросов, которые нужно решить при разработке любой стратегии масштабирования L1, - это конечные цели L1 и L2. Очевидно, что размещение всех данных на L1 является абсурдным: потенциальные сценарии использования могут включать в себя сотни тысяч транзакций в секунду, что сделает L1 полностью неспособным для проверки (за исключением того случая, если мы перейдем к использованию нативного метода Rollup). Однако нам действительно нужны некоторые руководящие принципы, чтобы убедиться, что мы не окажемся в ситуации, когда повышение верхнего предела газа в 10 раз серьезно ущемляет Децентрализация Ethereum на L1.

Один взгляд на разделение труда между L1 и L2

Как взаимодействовать с другими частями дорожной карты?

Привлечение большего числа пользователей на L1 означает не только улучшение масштабируемости, но и улучшение других аспектов L1. Это означает, что больше MEV будет оставаться на L1 (а не только станет проблемой L2), поэтому потребность в ясной работе с MEV станет еще более насущной. Это значительно повысит ценность быстрого слот-времени на L1. В то же время, это также сильно зависит от успешной проверки L1 (Verge).

Рекомендуемое чтение: “Возможное будущее ETH блокчейна: Объединение” Виталика