Ethereum возможное будущее: The Surge

Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Шардирование позволяет каждому узлу проверять и хранить только небольшую часть транзакций, в то время как протоколы второго уровня строят сети поверх Ethereum, используя его безопасность, в то время как большая часть данных и вычислений остается за пределами основной цепи. С углублением исследований эти два пути в конечном итоге объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая до сих пор является стратегией масштабирования Ethereum.

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

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

Увеличение: ключевая цель

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

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

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

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

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

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

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

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

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

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

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

Принцип работы 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, которые избыточно кодируют одну и ту же информацию.

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

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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

Подпись агрегирования: мы переходим от ECDSA-подписей к BLS-подписям