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

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

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

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

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

1. В будущем Ethereum с помощью L2 сможет достичь более 100000 TPS;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, что обеспечит 463-926 TPS для calldata.

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

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

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

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

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

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

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

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

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

Следующим этапом является завершение внедрения и запуска 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, всплеск

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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

Использовать po