Будущее Ethereum: всплеск

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

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

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

The Surge: Ключевая цель

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

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

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

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

![Виталик новая статья: возможное будущее Ethereum, The Surge])lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg(

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

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

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

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

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

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

Следующим шагом является завершение реализации и запуска PeerDAS. После этого будет постепенно увеличено количество блобов на 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 занимала на цепи меньше байт, что тогда будет?

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

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

![Vitalik новая статья: будущее Ethereum, The Surge])