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

Взлет: ключевая цель

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

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

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

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

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

1. Парадокс треугольника масштабируемости
2. Дальнейшие достижения в выборке доступности данных
3. Сжатие данных
4. Обобщенный Плазма
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 имела большие ограничения в безопасном исполнении, но с распространением SNARK (ноль-ведущих кратких неинтерактивных доказательств) архитектура Plasma стала более жизнеспособной для более широкого спектра сценариев использования, чем когда-либо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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