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

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

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

В этом году дорожная карта достигла важного прогресса: запуск EIP-4844 blobs значительно увеличил пропускную способность данных Ethereum L1, несколько EVM Rollup вошли в первый этап. Каждый 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.

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

Архитектура Plasma является еще одним решением, которое возлагает ответственность за доступность данных на пользователей в стимулирующем ключе. С распространением SNARKs, Plasma становится жизнеспособным для более широкого круга сценариев использования.

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

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

В настоящее время в Ethereum каждые 12 секунд слоты имеют 3 блоба размером около 125 кБ, а доступная полоса пропускания данных составляет около 375 кБ. Предполагая, что данные транзакций будут опубликованы непосредственно в цепочке, перевод ERC20 составляет около 180 байт, поэтому максимальная TPS для Rollup в Ethereum составляет 173,6. Вдобавок к этому, calldata может достичь 607 TPS. При использовании PeerDAS количество блобов может увеличиться до 8-16, предоставляя 463-926 TPS для calldata.

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

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

PeerDAS является простым реализованием "1D sampling". В Ethereum каждый blob представляет собой многочлен степени 4096 над полем 253-битных простых чисел. Мы передаем shares многочлена, каждый из которых содержит 16 оценок на 16 соседних координатах из 8192 координат. Любые 4096 оценок могут восстановить blob.

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

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

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

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

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

Следующим шагом является завершение реализации и запуска PeerDAS. Затем необходимо постоянно увеличивать количество blob на PeerDAS, одновременно тщательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности. Нам также нужно больше академических исследований для стандартизации PeerDAS и его взаимодействия с такими вопросами, как безопасность правил выбора форка.

В будущем нам нужно определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также хотим перейти от KZG к альтернативам, которые являются квантово-стойкими и не требуют доверенной настройки, но в настоящее время неясно, какие из кандидатов дружелюбны к распределенному построению блоков.

Я считаю, что долгосрочный реальный путь таков:

1. Реализация идеальной 2D DAS;
2. Продолжайте использовать 1D DAS, жертвуя эффективностью полосы пропускания выборки, чтобы принять более низкий предел данных ради простоты и надежности;
3. Отказаться от DA и полностью принять Plasma в качестве основной архитектуры Layer2.

Даже если мы решим непосредственно расширять выполнение на уровне L1, такой выбор также существует. Если L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, клиентам потребуется эффективно проверять их правильность, поэтому нам придется использовать ту же технику на уровне L1, что и в Rollup.

Как взаимодействовать с другими частями дорожной карты?

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

Замена адресов на указатели: если ранее использовался какой-либо адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в истории.

Кастомная сериализация значений транзакций: большинство значений транзакций имеют небольшое количество разрядов, например, 0,25 Эфир представляется как 250000000000000000 wei. Максимальная базовая комиссия и приоритетная комиссия также похожи. Поэтому мы можем использовать пользовательский десятичный формат с плавающей запятой для представления большинства валютных значений.

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

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

1. Переход на BLS-подписи требует значительных усилий и снизит совместимость с надежными аппаратными чипами. Можно использовать упаковку ZK-SNARK с другими схемами подписей в качестве замены.

2. Динамическое сжатие (, если заменить адреса ) на указатели, усложнит код клиента.

3. Публикация различий в состоянии на цепочке, а не в транзакциях, снизит аудируемость и сделает многие программные обеспечения (, такие как блокчейн-браузеры ), неработоспособными.

Как взаимодействовать с другими частями дорожной карты?

Применение ERC-4337 и конечное включение его части в EVM второго уровня может значительно ускорить развертывание агрегирующих технологий. Размещение части ERC-4337 на первом уровне может ускорить его развертывание на втором уровне.

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

Обобщенный Плазма

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

Даже при использовании 16 МБ блобов и сжатия данных, 58 000 TPS может не быть достаточно для полного удовлетворения потребностей потребителей в платежах, децентрализованном общении или других областях с высокой пропускной способностью, особенно если учитывать факторы конфиденциальности, что может снизить масштабируемость в 3-8 раз. Для сценариев с высокой торговой активностью и низкой ценностью в настоящее время одним из вариантов является использование Validium, который хранит данные вне цепи и использует интересную модель безопасности: операторы не могут украсть средства пользователей, но они могут временно или навсегда заморозить средства всех пользователей. Но мы можем сделать лучше.

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

Plasma – это решение для масштабирования, которое связано с тем, что операторы публикуют блоки вне цепи и помещают корень Меркла этих блоков в цепь. Для каждого блока операторы отправляют каждому пользователю ветку Меркла, подтверждающую изменения или отсутствие изменений в активах этого пользователя. Пользователи могут извлекать активы, предоставляя ветку Меркла. Важно отметить, что эта ветка не обязательно должна быть корнем последнего состояния. Таким образом, даже если возникают проблемы с доступностью данных, пользователи все равно могут восстановить свои активы, извлекая доступное последнее состояние. Если пользователь подает недействительную ветку, принадлежность активов может быть определена с помощью механизма оспаривания на цепи.

Ранние версии Plasma могли обрабатывать только платежные случаи, и их было трудно широко распространить. Однако, если требовать, чтобы каждый корень проверялся с помощью SNARK, Plasma станет гораздо мощнее. Каждая игра на вызов может быть значительно упрощена, поскольку мы исключаем большую часть возможных путей мошенничества со стороны операторов. В то же время открываются новые пути, позволяющие технологии Plasma расширяться на более широкий спектр классов активов. Наконец, в случае отсутствия мошенничества со стороны операторов пользователи могут немедленно выводить средства, не ожидая недельного периода оспаривания.

Один из способов создания Plasma-цепочки EVM ( не является единственным способом ): использование ZK-SNARK для построения параллельного дерева UTXO, отражающего изменения баланса, сделанные EVM, и определения уникального соответствия "одного и того же токена" в разные исторические моменты времени. Затем на его основе можно построить структуру Plasma.

Ключевое понимание заключается в том, что система Plasma не требует совершенства. Даже если вы можете защитить только подмножество активов (, как только в прошлом.