Стратегия масштабирования Ethereum изначально имела два направления: шардирование и Layer2. Шардирование позволяет каждому узлу проверять и хранить лишь небольшую часть транзакций, в то время как Layer2 перемещает большую часть данных и вычислений за пределы основной цепи. Эти два направления в конечном итоге объединились, сформировав дорожную карту, ориентированную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение обязанностей: Ethereum L1 фокусируется на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: судебная система (L1) существует для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этой основе, способствуя развитию человечества.
В этом году важные достижения были достигнуты в дорожной карте, сосредоточенной на Rollup: запуск EIP-4844 blobs значительно увеличил пропускную способность данных Ethereum L1, несколько EVM Rollup вошли в первую стадию. Каждый L2 существует как "шардинг" с внутренними правилами и логикой, разнообразие способов реализации шардирования стало реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Наша текущая задача - завершить эту дорожную карту и решить эти проблемы, при этом сохраняя надежность и децентрализацию Ethereum L1.
Всплеск: ключевая цель
В будущем Ethereum через L2 сможет достичь более 100000 TPS
Поддержание децентрализованности и надежности L1
По крайней мере, некоторые L2 полностью унаследуют основные свойства Ethereum (: доверие, открытость, устойчивость к цензуре ).
Ethereum должен ощущаться как единая экосистема, а не 34 разных блокчейна
Содержание этой главы
Треугольник парадокса масштабируемости
Дальнейшие достижения в выборке доступности данных
Сжатие данных
Обобщённая Плазма
Зрелая система доказательств L2
Улучшение межоперабельности между L2
Расширение исполнения на L1
Парадокс треугольника масштабируемости
Треугольный парадокс масштабируемости утверждает, что между тремя характеристиками блокчейна — децентрализацией, масштабируемостью и безопасностью — существует противоречие. Это не теорема, а эвристический аргумент: если децентрализованный узел может проверять N транзакций в секунду, а у вас есть цепочка, обрабатывающая k*N транзакций в секунду, то либо каждая транзакция может быть видна только 1/k узлам, либо ваши узлы станут мощными, и цепочка не будет децентрализованной.
Некоторые высокопроизводительные цепочки утверждают, что решают тройной парадокс, обычно оптимизируя программное обеспечение узлов. Но это часто вводит в заблуждение, поскольку запуск узлов на этих цепочках сложнее, чем на Ethereum. Только на основе программной инженерии L1 клиентского ПО нельзя масштабировать Ethereum.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольную парадокс: оно позволяет клиентам проверять доступность большого объема данных и правильность выполнения вычислительных шагов, скачивая лишь небольшое количество данных и выполняя минимальное количество вычислений. SNARKs не требуют доверия. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики цепей с ограниченной масштабируемостью.
Архитектура Plasma является другим решением, которое перекладывает ответственность за доступность данных на пользователей. С распространением SNARKs Plasma становится жизнеспособным для более широких сценариев.
Дальнейшие достижения в выборке доступности данных
Какую проблему мы решаем?
После обновления Dencun 13 марта 2024 года в Эфире будет 3 блоба размером около 125 кБ каждые 12 секунд, а доступная полоса пропускания данных составит около 375 кБ/слот. Предполагая, что данные транзакций публикуются непосредственно в цепочке, перевод ERC20 занимает около 180 байтов, максимальная TPS для Rollup в Эфире составит 173,6.
С добавлением calldata, возможно достичь 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, обеспечивая для calldata 463-926 TPS.
Это значительное улучшение для L1, но этого недостаточно. Наша среднесрочная цель — 16 МБ на каждый слот, в сочетании с сжатием данных Rollup, что приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS — это простая реализация "1D sampling". В Ethereum каждый blob представляет собой многочлен степени 4096 над полем простых чисел в 253. Мы транслируем shares многочлена, каждый из которых содержит 16 оценок на 16 соседних координатах из 8192 координат в общей сложности. Из этих 8192 оценок любые 4096 могут восстановить blob.
PeerDAS позволяет каждому клиенту прослушивать небольшое количество подсетей, i-я подсеть транслирует i-й образец любого blob и запрашивает другие blobs в подсетях у пиров в глобальной p2p сети. SubnetDAS использует только механизм подсетей, без дополнительных запросов к пиринговому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в доказательстве доли, использовали SubnetDAS, а другие узлы использовали PeerDAS.
Теоретически мы можем значительно увеличить масштаб "1D sampling"; если увеличить максимальное количество blob до 256, можно достичь цели в 16 МБ, при этом каждому узлу потребуется 1 МБ пропускной способности данных на слот. Это едва осуществимо, но клиенты с ограниченной пропускной способностью не могут проводить выборку. Мы можем оптимизировать, уменьшив количество blob и увеличив их размер, но это повысит стоимость восстановления.
Таким образом, мы в конечном итоге хотим проводить 2D-выборку, не только внутри blob, но и производить случайную выборку между blob. Используя линейные свойства KZG-коммитмента, мы расширяем набор blob в блоке с помощью новых виртуальных blob, которые избыточно кодируют одну и ту же информацию.
2D выборка дружественна к распределенному построению блоков. Узлы, фактически строящие блоки, требуют только blob KZG обязательства и могут полагаться на DAS для проверки доступности. 1D DAS по сути также дружественен к распределенному построению блоков.
Какие существуют связи с существующими исследованиями?
Введение в оригинальный пост о доступности данных (2018)
Последующая работа
Статья с объяснением DAS
Доступность в 2D с обязательствами KZG
PeerDAS и статьи по ethresear.ch
ЭИП-7594
SubnetDAS на ethresear.ch
Нюансы восстанавливаемости в 2D-семплировании
Что еще нужно сделать? Какие есть компромиссы?
Далее будет завершена реализация и запуск PeerDAS. Затем количество blob на PeerDAS будет постепенно увеличиваться, при этом внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности. Мы надеемся на большее количество научных работ, которые будут стандартизировать PeerDAS и его взаимодействие с вопросами безопасности, такими как правила выбора ответвлений.
В будущем необходимо определить идеальную версию 2D DAS и доказать ее свойства безопасности. Мы надеемся в конечном итоге перейти от KZG к альтернативам, которые безопасны для квантовых вычислений и не требуют доверенной настройки. В настоящее время неясно, какие кандидатные решения дружелюбны к распределенному строительству блоков.
Я считаю, что долгосрочный реальный путь таков:
Реализация идеального 2D DAS
Продолжайте использовать 1D DAS, жертвуя эффективностью полосы пропускания выборки, принимая более низкий предел данных ради простоты и надежности.
Отказаться от DA и полностью принять Plasma в качестве основной архитектуры Layer2
Даже если мы решим напрямую расширить выполнение на уровне L1, такой вариант существует. Потому что если L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный метод проверки, поэтому нам придется использовать ту же технологию на уровне L1, что и в Rollup.
Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 2D DAS уменьшится или задержится, если Plasma будет широко использоваться, то потребность еще больше уменьшится. DAS также ставит перед протоколами и механизмами распределенного построения блоков вызовы: хотя DAS теоретически дружелюбен к распределенному восстановлению, на практике необходимо сочетать его с предложением о списке включения пакетов и механизмами выбора разветвлений вокруг него.
Каждая транзакция в Rollup занимает много места на цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протоколов Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем сделать так, чтобы транзакции в Rollup занимали меньше байтов в цепочке?
Что это такое и как это работает?
Лучшее объяснение - это эта картинка двухлетней давности:
В процессе сжатия нулевых байтов каждый длинный последовательность нулевых байтов заменяется двумя байтами, которые указывают, сколько нулевых байтов. Более того, мы использовали специфические свойства транзакций:
Подпись агрегирования: переход от ECDSA к BLS-подписи, несколько подписей могут быть объединены в одну единую подпись, подтверждающую действительность всех оригинальных подписей. В L1 не рассматривается использование BLS из-за высокой вычислительной стоимости проверки, но в L2, в среде с дефицитом данных, использование BLS имеет смысл. Агрегирующая функция ERC-4337 предоставляет возможность для реализации этой функции.
Замените адреса на указатели: если ранее использовался определенный адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в исторических записях.
Кастомная сериализация торговых значений: количество знаков большинства торговых значений невелико, например, 0.25 Эфир представляется как 250000000000000000 wei. Максимальная базовая комиссия и приоритетная комиссия также похожи. Поэтому мы можем использовать кастомный десятичный формат с плавающей запятой для представления большинства валютных значений.
Какие существуют связи с существующими исследованиями?
Исследуйте sequence.xyz
Оптимизация контракта L2 Calldata
Различия в состоянии Rollups на основе доказательства эффективности, а не транзакций.
BLS-кошелек - реализация агрегирования BLS через ERC-4337
что еще нужно сделать, какие есть компромиссы?
Следующим шагом является практическая реализация вышеуказанного плана. Основные компромиссы включают:
Переход на подпись BLS требует больших усилий и снизит совместимость с надежными аппаратными чипами. Можно использовать другие схемы подписи с упаковкой ZK-SNARK в качестве замены.
Динамическое сжатие (, если заменить адреса ) на указатели, приведет к усложнению клиентского кода.
Публикация различий в состоянии в цепочке, а не транзакциях, снизит возможность аудита, что сделает многие программы (, такие как блокчейн-браузеры ), непригодными для работы.
Как взаимодействовать с другими частями дорожной карты?
Используя ERC-4337 и в конечном итоге интегрировав его часть в L2 EVM, можно значительно ускорить развертывание агрегированных технологий. Размещение части ERC-4337 на L1 может ускорить его развертывание на L2.
Даже с использованием 16MB blob и сжатия данных, 58,000 TPS может не полностью удовлетворить потребности в высоких пропускных способностях, таких как потребительские платежи и децентрализованные социальные сети, особенно с учетом того, что факторы конфиденциальности могут снизить масштабируемость в 3-8 раз. В настоящее время выбор для сценариев с высокой транзакционной нагрузкой и низкой стоимостью — это Validium, который сохраняет данные вне цепи, используя модель безопасности: операторы не могут украсть средства пользователей, но могут временно или навсегда заморозить все средства пользователей. Но мы можем сделать это лучше.
Что это такое и как это работает?
Plasma является решением для масштабирования, операторы публикуют блоки вне цепи, только размещая корень Merkle этих блоков в цепи. Для каждого блока оператор отправляет пользователю ветвь Merkle, подтверждающую изменения или неизменность активов этого пользователя. Пользователи могут извлекать активы, предоставляя ветвь Merkle. Важно отметить, что эта ветвь не обязательно должна быть с последнего состояния в качестве корня. Поэтому, даже если возникают проблемы с доступностью данных, пользователи все равно могут восстановить активы, извлекая доступное последнее состояние. Если пользователь отправляет недействительную ветвь, можно определить право собственности на активы с помощью механизма вызова в цепи.
Ранние версии Plasma могли обрабатывать только платежные случаи, и не могли эффективно распространяться. Но
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Ethereum The Surge: Цели и вызовы расширения до 100000 TPS через L2
Будущее Эфириума: The Surge
Стратегия масштабирования Ethereum изначально имела два направления: шардирование и Layer2. Шардирование позволяет каждому узлу проверять и хранить лишь небольшую часть транзакций, в то время как Layer2 перемещает большую часть данных и вычислений за пределы основной цепи. Эти два направления в конечном итоге объединились, сформировав дорожную карту, ориентированную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение обязанностей: Ethereum L1 фокусируется на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: судебная система (L1) существует для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этой основе, способствуя развитию человечества.
В этом году важные достижения были достигнуты в дорожной карте, сосредоточенной на Rollup: запуск EIP-4844 blobs значительно увеличил пропускную способность данных Ethereum L1, несколько EVM Rollup вошли в первую стадию. Каждый L2 существует как "шардинг" с внутренними правилами и логикой, разнообразие способов реализации шардирования стало реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Наша текущая задача - завершить эту дорожную карту и решить эти проблемы, при этом сохраняя надежность и децентрализацию Ethereum L1.
Всплеск: ключевая цель
Содержание этой главы
Парадокс треугольника масштабируемости
Треугольный парадокс масштабируемости утверждает, что между тремя характеристиками блокчейна — децентрализацией, масштабируемостью и безопасностью — существует противоречие. Это не теорема, а эвристический аргумент: если децентрализованный узел может проверять N транзакций в секунду, а у вас есть цепочка, обрабатывающая k*N транзакций в секунду, то либо каждая транзакция может быть видна только 1/k узлам, либо ваши узлы станут мощными, и цепочка не будет децентрализованной.
Некоторые высокопроизводительные цепочки утверждают, что решают тройной парадокс, обычно оптимизируя программное обеспечение узлов. Но это часто вводит в заблуждение, поскольку запуск узлов на этих цепочках сложнее, чем на Ethereum. Только на основе программной инженерии L1 клиентского ПО нельзя масштабировать Ethereum.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольную парадокс: оно позволяет клиентам проверять доступность большого объема данных и правильность выполнения вычислительных шагов, скачивая лишь небольшое количество данных и выполняя минимальное количество вычислений. SNARKs не требуют доверия. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики цепей с ограниченной масштабируемостью.
Архитектура Plasma является другим решением, которое перекладывает ответственность за доступность данных на пользователей. С распространением SNARKs Plasma становится жизнеспособным для более широких сценариев.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Дальнейшие достижения в выборке доступности данных
Какую проблему мы решаем?
После обновления Dencun 13 марта 2024 года в Эфире будет 3 блоба размером около 125 кБ каждые 12 секунд, а доступная полоса пропускания данных составит около 375 кБ/слот. Предполагая, что данные транзакций публикуются непосредственно в цепочке, перевод ERC20 занимает около 180 байтов, максимальная TPS для Rollup в Эфире составит 173,6.
С добавлением calldata, возможно достичь 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, обеспечивая для calldata 463-926 TPS.
Это значительное улучшение для L1, но этого недостаточно. Наша среднесрочная цель — 16 МБ на каждый слот, в сочетании с сжатием данных Rollup, что приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS — это простая реализация "1D sampling". В Ethereum каждый blob представляет собой многочлен степени 4096 над полем простых чисел в 253. Мы транслируем shares многочлена, каждый из которых содержит 16 оценок на 16 соседних координатах из 8192 координат в общей сложности. Из этих 8192 оценок любые 4096 могут восстановить blob.
PeerDAS позволяет каждому клиенту прослушивать небольшое количество подсетей, i-я подсеть транслирует i-й образец любого blob и запрашивает другие blobs в подсетях у пиров в глобальной p2p сети. SubnetDAS использует только механизм подсетей, без дополнительных запросов к пиринговому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в доказательстве доли, использовали SubnetDAS, а другие узлы использовали PeerDAS.
Теоретически мы можем значительно увеличить масштаб "1D sampling"; если увеличить максимальное количество blob до 256, можно достичь цели в 16 МБ, при этом каждому узлу потребуется 1 МБ пропускной способности данных на слот. Это едва осуществимо, но клиенты с ограниченной пропускной способностью не могут проводить выборку. Мы можем оптимизировать, уменьшив количество blob и увеличив их размер, но это повысит стоимость восстановления.
Таким образом, мы в конечном итоге хотим проводить 2D-выборку, не только внутри blob, но и производить случайную выборку между blob. Используя линейные свойства KZG-коммитмента, мы расширяем набор blob в блоке с помощью новых виртуальных blob, которые избыточно кодируют одну и ту же информацию.
2D выборка дружественна к распределенному построению блоков. Узлы, фактически строящие блоки, требуют только blob KZG обязательства и могут полагаться на DAS для проверки доступности. 1D DAS по сути также дружественен к распределенному построению блоков.
Какие существуют связи с существующими исследованиями?
Что еще нужно сделать? Какие есть компромиссы?
Далее будет завершена реализация и запуск PeerDAS. Затем количество blob на PeerDAS будет постепенно увеличиваться, при этом внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности. Мы надеемся на большее количество научных работ, которые будут стандартизировать PeerDAS и его взаимодействие с вопросами безопасности, такими как правила выбора ответвлений.
В будущем необходимо определить идеальную версию 2D DAS и доказать ее свойства безопасности. Мы надеемся в конечном итоге перейти от KZG к альтернативам, которые безопасны для квантовых вычислений и не требуют доверенной настройки. В настоящее время неясно, какие кандидатные решения дружелюбны к распределенному строительству блоков.
Я считаю, что долгосрочный реальный путь таков:
Даже если мы решим напрямую расширить выполнение на уровне L1, такой вариант существует. Потому что если L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный метод проверки, поэтому нам придется использовать ту же технологию на уровне L1, что и в Rollup.
Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 2D DAS уменьшится или задержится, если Plasma будет широко использоваться, то потребность еще больше уменьшится. DAS также ставит перед протоколами и механизмами распределенного построения блоков вызовы: хотя DAS теоретически дружелюбен к распределенному восстановлению, на практике необходимо сочетать его с предложением о списке включения пакетов и механизмами выбора разветвлений вокруг него.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много места на цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протоколов Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем сделать так, чтобы транзакции в Rollup занимали меньше байтов в цепочке?
Что это такое и как это работает?
Лучшее объяснение - это эта картинка двухлетней давности:
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
В процессе сжатия нулевых байтов каждый длинный последовательность нулевых байтов заменяется двумя байтами, которые указывают, сколько нулевых байтов. Более того, мы использовали специфические свойства транзакций:
Подпись агрегирования: переход от ECDSA к BLS-подписи, несколько подписей могут быть объединены в одну единую подпись, подтверждающую действительность всех оригинальных подписей. В L1 не рассматривается использование BLS из-за высокой вычислительной стоимости проверки, но в L2, в среде с дефицитом данных, использование BLS имеет смысл. Агрегирующая функция ERC-4337 предоставляет возможность для реализации этой функции.
Замените адреса на указатели: если ранее использовался определенный адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в исторических записях.
Кастомная сериализация торговых значений: количество знаков большинства торговых значений невелико, например, 0.25 Эфир представляется как 250000000000000000 wei. Максимальная базовая комиссия и приоритетная комиссия также похожи. Поэтому мы можем использовать кастомный десятичный формат с плавающей запятой для представления большинства валютных значений.
Какие существуют связи с существующими исследованиями?
что еще нужно сделать, какие есть компромиссы?
Следующим шагом является практическая реализация вышеуказанного плана. Основные компромиссы включают:
Переход на подпись BLS требует больших усилий и снизит совместимость с надежными аппаратными чипами. Можно использовать другие схемы подписи с упаковкой ZK-SNARK в качестве замены.
Динамическое сжатие (, если заменить адреса ) на указатели, приведет к усложнению клиентского кода.
Публикация различий в состоянии в цепочке, а не транзакциях, снизит возможность аудита, что сделает многие программы (, такие как блокчейн-браузеры ), непригодными для работы.
Как взаимодействовать с другими частями дорожной карты?
Используя ERC-4337 и в конечном итоге интегрировав его часть в L2 EVM, можно значительно ускорить развертывание агрегированных технологий. Размещение части ERC-4337 на L1 может ускорить его развертывание на L2.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Обобщённый Плазма
Какую проблему мы решаем?
Даже с использованием 16MB blob и сжатия данных, 58,000 TPS может не полностью удовлетворить потребности в высоких пропускных способностях, таких как потребительские платежи и децентрализованные социальные сети, особенно с учетом того, что факторы конфиденциальности могут снизить масштабируемость в 3-8 раз. В настоящее время выбор для сценариев с высокой транзакционной нагрузкой и низкой стоимостью — это Validium, который сохраняет данные вне цепи, используя модель безопасности: операторы не могут украсть средства пользователей, но могут временно или навсегда заморозить все средства пользователей. Но мы можем сделать это лучше.
Что это такое и как это работает?
Plasma является решением для масштабирования, операторы публикуют блоки вне цепи, только размещая корень Merkle этих блоков в цепи. Для каждого блока оператор отправляет пользователю ветвь Merkle, подтверждающую изменения или неизменность активов этого пользователя. Пользователи могут извлекать активы, предоставляя ветвь Merkle. Важно отметить, что эта ветвь не обязательно должна быть с последнего состояния в качестве корня. Поэтому, даже если возникают проблемы с доступностью данных, пользователи все равно могут восстановить активы, извлекая доступное последнее состояние. Если пользователь отправляет недействительную ветвь, можно определить право собственности на активы с помощью механизма вызова в цепи.
Ранние версии Plasma могли обрабатывать только платежные случаи, и не могли эффективно распространяться. Но