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

Оригинальный автор: Виталик Бутерин

Исходный текст: Карен, новости предвидения

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

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

The Surge, версия 2023 карты маршрута

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

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

The Surge: ключевые цели

1、В будущем Ethereum с помощью L2 может достигнуть более 10 тысяч транзакций в секунду;

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

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

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

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

• Треугольник расширяемости
• Дальнейшие успехи в выборке доступности данных
• Сжатие данных
• Обобщенная Плазма
• Зрелая система подтверждения L2
• Улучшение интероперабельности между L2
• Расширение выполнения на уровне L1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2D сэмплирование. Источник данных: a16z crypto

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

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

• Исходное сообщение о доступности данных (2018):
• Следующая статья:
• Объяснение статьи о DAS, парадигма:
• 2D доступность с обещанием KZG:
• PeerDAS на ethresear.ch: и статьи:
• EIP-7594:
• SubnetDAS на ethresear.ch:
• Незначительные различия в восстановлении в 2D-образцах:

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

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

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

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

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

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

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

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

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

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

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

16000000 / 12 / 180 = 7407 ТПС

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

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

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

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

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

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

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

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

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

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

Далее главное - это фактическая реализация вышеприведенной схемы. Основные компромиссы включают:

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

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

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

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

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

Обобщенный Plasma

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте сначала вспомним систему «stage», которую мы впервые представили в этой статье.

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

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

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

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

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

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

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

• Семантика EVM K (формальная верификация работы с 2017 года):
• О выступлении о концепции мульти-доказательства (2022):
• Taiko планирует использовать множественное подтверждение:

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

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

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

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

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

Улучшение межсетевой совместимости L2

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

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

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

Улучшение межслоевой совместимости имеет множество категорий. В теории, основанный на Rollup Ethereum и выполнение Шардинг L1 - это одно и то же. В настоящее время экосистема межслоевого решения 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 легкому клиенту. После получения цепочки заголовков можно использовать доказательство Меркла для проверки любого объекта состояния. Как только у вас есть правильный объект состояния L1, вы можете использовать доказательство Меркла (или подпись, если вы хотите проверить предварительное подтверждение) для проверки любого объекта состояния на L2. Helios уже справился с первым. Расширение до второго является стандартизационной задачей.

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

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

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

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

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

Специфический адрес:

ERC-3770 :

ERC-7683:

РИП-7755:

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

Гелиос:

ERC-3668 (иногда называемый CCIP чтением):

Предложение Джастина Дрейка о «основе (общего) предварительного подтверждения»:

L1S ЗАГРУЗКА (RIP-7728): предварительная компиляция загрузки/20388

REMOTESTATICCALL в оптимизме:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Дорожная карта расширения L1 Polynya для ETH
• Многомерная Газовая ценовая политика:
• EIP-7706:
• EOF:
• EVM-MAX:
• SIMD:
• Native роллапы:
• Макс Резник рассказал о ценности расширения L1 в интервью.
• Джастин Дрейк обсуждает расширение с использованием SNARK и оригинальных роллапов:

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

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

• Улучшение технологии (например, клиентский код, безсостоятельный клиент, истекший история) для упрощения проверки L1, а затем увеличение лимита Газа.
• Увеличение средней емкости за счет снижения затрат на конкретные операции без увеличения риска в худшем случае;
• Оригинальные роллапы (т. е. создание N параллельных копий EVM).

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

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

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

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

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