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

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

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

The Surge，2023 карты пути

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

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

Взрыв: Ключевые цели

1. В будущем Ethereum с использованием L2 сможет достигать TPS свыше 100 000.

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

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

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

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

1. Треугольник расширяемости

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

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

4. Обобщенный Plasma

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 стала более жизнеспособной для более широкого спектра применений.

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

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

В 13 марта 2024 года, когда Dencun будет обновлен, в блокчейне Ethereum каждый слот в 12 секунд будет содержать около 3 блобов по 125 кБ, или доступная пропускная способность данных для каждого слота будет около 375 кБ. Предположим, что данные транзакций публикуются непосредственно в блокчейне, тогда максимальная 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.

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

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

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 sampling» до довольно больших размеров: если мы увеличим максимальное количество блобов до 256 (цель - 128), то мы сможем достичь цели в 16 МБ, при этом доступность данных будет составлять 16 образцов * 128 блобов * 512 байт на каждый образец = 1 МБ пропускной способности данных на каждый слот. Это только находится в пределах нашей терпимости: это возможно, но это означает, что клиенты с ограниченной пропускной способностью не смогут выполнять выборки. Мы можем оптимизировать это до некоторой степени, уменьшив количество блобов и увеличив размер блобов, но это приведет к повышению стоимости восстановления.

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

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

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

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

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

1. Исходный пост о доступности данных (2018):

2.Следующая статья:

3. Объяснение DAS, парадигма:

4. Доступность 2D с обещанием KZG:

PeerDAS на 5.ethresear.ch: и доклады:

6.ЭИП-7594:

SubnetDAS на 7.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 вэи. Максимальная базовая комиссия и приоритетная комиссия также имеют сходные характеристики. Поэтому мы можем использовать настраиваемый формат десятичной дроби для представления большинства валютных значений.

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

1. Исследуйте sequence.xyz:

2. Оптимизация вызывающих данных L2 контракта:

3. Rollups, основанные на доказательстве действительности (также известные как ZK-роллапы), различаются по состоянию выпуска, а не по транзакциям:

4. Кошелек - 通过 ERC-4337 实现 BLS 聚合：

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

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

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 МБ, теоретически ограниченную примерно до 266 667 TPS (транзакций в секунду).

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

1. Оригинальная Plasma-статья:

2. Плазма Кеш:

3. Плазменный поток денежного обращения:

4.Интмакс (2023):

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

Основная задача заключается в том, чтобы внедрить систему Plasma в реальные производственные приложения. Как уже упоминалось, Plasma и Validium не являются взаимоисключающими: любой Validium может улучшить свои характеристики безопасности хотя бы в определенной степени, интегрируя черты Plasma в свой механизм выхода. Основное внимание уделяется достижению оптимальных свойств для EVM (учитывая потребности в доверии, затраты на газ на L1 в худшем случае и способность защищаться от атак 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: должна быть (недоверительная) система доказательств, чтобы гарантировать, что будут приняты только действительные транзакции. Комиссия по безопасности разрешает вмешательство только в случае доказанной ошибки в коде, например, если две избыточные системы доказательств несогласованы между собой, или если одна система доказательств принимает два разных пост-состояния одного и того же Блока (или не принимает вообще ничего в течение достаточно длительного времени, например, неделю). Разрешено использование механизма обновления, но с длительной задержкой.

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

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

2. Множественные доказательства (Multi-provers): создание нескольких систем доказательств и вложение средств в эти системы доказательств совместно с комитетом по безопасности (или другими доверенными устройствами, такими как TEE, с предположением о доверии). Если системы доказательств согласны, комитет по безопасности лишен права; если они не согласны, комитет по безопасности может только выбрать одну из них, он не может односторонне навязать свой ответ.

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

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

1. Семантика EVM K (формальная верификация работы с 2017 года):

2. О выступлении о многопрудовых мыслях (2022):

3. Планируется использование множественного подтверждения:

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

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

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

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

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

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

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

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

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

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

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 Workshop), но нам нужно распространить это недоверие на L2. ERC-3668 (CCIP-read) является стратегией для достижения этой цели.

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

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

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

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

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

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

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

2.ERC-7683:

3.РИП-7755:

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

5. Хелиос:

6.ERC-3668（иногда называемый CCIP Ready）：

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

8.L1SLOAD (РИП-7728):

9.REMOTESTATICCALL в Optimism:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.EOF: новый формат байт-кода EVM, более дружелюбный к статическому анализу, что позволяет достичь более быстрой реализации. Учитывая эти улучшения эффективности, байт-код EOF может получить более низкую Газовую плату.

2. Многоуровневая ценообразование газа: устанавливаются различные основные расходы и ограничения для вычислений, данных и хранения, что позволяет увеличить среднюю вместимость ETH блока L1 без увеличения максимальной ёмкости (тем самым избегая появления новых угроз безопасности).

3. Падение стоимости конкретных операционных кодов и предварительной компиляции газа - исторически для предотвращения атак типа «отказ в обслуживании» мы несколько раз увеличивали стоимость газа для некоторых операций с низкой ценой. Можно сделать ещё немного, чтобы Падение стоимости газа для операционных кодов с высокой ценой. Например, сложение гораздо дешевле, чем умножение, но в настоящее время стоимость операционных кодов ADD и MUL одинакова. Мы можем снизить стоимость ADD и даже сделать стоимость более простых операционных кодов, таких как PUSH, более низкой. EOF в целом более оптимизирован в этом отношении.

4.EVM-MAX и SIMD: EVM-MAX - это предложение, которое позволяет более эффективное вычисление модуля больших чисел в качестве отдельного модуля EVM. Значения, вычисленные с помощью EVM-MAX, могут быть доступны только для других операций EVM-MAX, если они явно экспортируются. Это позволяет использовать больше пространства для оптимизации хранения этих значений. SIMD (single instruction multiple data) - это предложение, которое позволяет эффективно выполнять одну и ту же инструкцию для массива значений. Вместе они могут создать мощный сопроцессор рядом с EVM, который может использоваться для более эффективной реализации операций шифрования. Это особенно полезно для протокола конфиденциальности и системы защиты L2, и поэтому оно будет способствовать расширению L1 и L2.

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

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

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

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, такие как увеличение количества пользователей, выполняющих проверку узла, и увеличение количества соло-стейкеров. В зависимости от способа реализации, сделать определенные операции в EVM (Ethereum Виртуальная машина) более дешевыми может увеличить общую сложность EVM.

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

Видение разделения труда между L1 и L2

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

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

Связанные статьи: «Новая статья Виталика: Что еще можно улучшить в PoS Ethereum? Как это сделать?»

Ссылка на оригинал