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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стоит отметить, что треугольный парадокс не является теоремой и не имеет математического доказательства. Он представляет собой эвристический математический аргумент: если децентрализованный дружественный узел может проверять 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 кБ. Предполагая, что данные транзакций публикуются непосредственно в цепочке, то перевод ERC20 составляет примерно 180 байт, таким образом, максимальная TPS для Rollup на Ethereum составляет: 375000 / 12 / 180 = 173.6 TPS

Если мы добавим теоретически максимальное значение calldata Ethereum (: каждый слот 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". В Ethereum каждый blob представляет собой 4096-ю многочлен на 253-битном простом поле (prime field). Мы транслируем shares многочлена, где каждый share содержит 16 оценок на 16 соседних координат из общего числа 8192 координат. Из этих 8192 оценок любые 4096 ( могут быть восстановлены blob на основе текущих предложенных параметров: любые 64 из 128 возможных образцов ).

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

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

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

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

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

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

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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

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