Будущее Эфириума: The Surge

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

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

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

Всплеск: ключевая цель

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

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

3. По крайней мере, некоторые L2 полностью унаследовали основные свойства Эфира (: доверие, открытость, устойчивость к цензуре );

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

! Виталик Новая статья: Возможное будущее Ethereum, всплеск

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

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

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

Я считаю, что долгосрочный реалистичный путь заключается в том, что:

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

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

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

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

! [Новости Виталика: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp###

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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

Используйте указатели для замены адреса: если Эфир