Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня (Layer2). Шардирование позволяет каждому узлу проверять и хранить лишь небольшую часть транзакций, в то время как Layer2 сохраняет большую часть данных и вычислений вне основной цепи. Эти два подхода в конечном итоге объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является текущей стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение задач: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: судебная система (L1) существует для защиты контрактов и имущественных прав, в то время как предприниматели (L2) строят на этой основе.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных успехов: внедрение EIP-4844 blobs значительно увеличило пропускную способность данных Ethereum L1, несколько EVM Rollup перешли в первую стадию. Каждый L2 существует как независимый "шар", и разнообразие способов реализации шаров стало реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Наша текущая задача заключается в завершении дорожной карты, сосредоточенной на Rollup, решении этих проблем, одновременно сохраняя устойчивость и децентрализацию Ethereum L1.
Треугольник парадокса масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация, масштабируемость и безопасность. Он приводит эвристический математический аргумент: если децентрализованный узел может проверять N транзакций в секунду, и у вас есть цепочка, которая обрабатывает k*N транзакций в секунду, тогда (i) каждая транзакция может быть увидена только 1/k узлами, что означает, что злоумышленнику достаточно разрушить несколько узлов, чтобы провести вредоносную транзакцию, или (ii) ваши узлы станут мощными, а ваша цепочка не будет децентрализованной.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольную парадокс: оно позволяет клиентам проверять, доступно ли определенное количество данных, и правильно ли выполнено определенное количество вычислительных шагов, загружая лишь небольшое количество данных и выполняя минимальное количество вычислений. Другим решением является архитектура Plasma, которая перекладывает ответственность за мониторинг доступности данных на пользователей. С распространением SNARKs архитектура Plasma становится более жизнеспособной для более широких сценариев использования.
Дальнейшие достижения в выборке доступности данных
В настоящее время каждые 12 секунд в сети Ethereum создается 3 слота по 125 кБ, доступная полоса пропускания данных составляет около 375 кБ. Предполагая, что данные транзакций публикуются непосредственно в цепочке, перевод ERC20 составляет около 180 байт, поэтому максимальная пропускная способность TPS для Rollup в Ethereum составляет 173,6. Наша промежуточная цель — 16 МБ на слот, и если объединить это с улучшениями сжатия данных Rollup, это приведет к примерно 58000 TPS.
PeerDAS — это относительно простая реализация "1D sampling". В Ethereum каждый blob представляет собой 4096-ю многочлен в поле 253-простых чисел. Мы транслируем shares многочлена, каждый из которых содержит 16 оценочных значений на 16 соседних координатах из общего числа 8192 координат. Из этих 8192 оценочных значений любые 4096 могут восстановить blob.
Принцип работы PeerDAS заключается в том, что каждый клиент прослушивает небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob и запрашивает blob из других подсетей у пиров в глобальной p2p-сети. Более консервативная версия SubnetDAS использует только механизм подсетей, без дополнительных запросов к пировому уровню.
С теоретической точки зрения, мы можем значительно масштабировать "1D sampling"; если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, а в образцах доступности данных каждый узел должен обрабатывать 1 МБ полосы пропускания на каждый слот. Это едва укладывается в наши пределы, что означает, что клиенты с ограниченной полосой пропускания не могут участвовать в выборке.
Таким образом, в конечном итоге мы хотим сделать шаг вперед и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между blob. Линейные свойства KZG-промисса используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием для одной и той же информации.
Ключевым моментом является то, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение с точки зрения построения распределенного блока является дружелюбным. Узлы, фактически строящие блоки, должны просто иметь KZG-обязательства blob, и они могут полагаться на выборку доступности данных (DAS) для проверки доступности блоков данных.
Далее следует завершение реализации и запуска PeerDAS. Затем будет постепенно увеличиваться количество blob на PeerDAS, одновременно внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, это постепенный процесс. Мы также надеемся на большее количество академических работ для стандартизации PeerDAS и других версий DAS, а также их взаимодействия с безопасностью правил выбора форков и т.д.
На более поздних этапах в будущем нам нужно будет провести больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативе, безопасной для квантовых вычислений и не требующей доверенной настройки.
Я считаю, что долгосрочный реальный путь заключается в:
Реализация идеальной 2D DAS;
Продолжайте использовать 1D DAS, жертвуя эффективностью полосы пропускания выборки ради простоты и надежности, принимая более низкий предел данных.
Отказаться от DA и полностью принять Plasma в качестве нашей основной архитектуры Layer2.
Обратите внимание, что даже если мы решим расширить выполнение непосредственно на уровне L1, этот выбор также существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их корректности, поэтому нам придется использовать на уровне L1 те же технологии, что и Rollup(, такие как ZK-EVM и DAS).
Каждая транзакция в Rollup занимает много пространства данных на блокчейне: передача ERC20 требует около 180 байт. Даже при идеальной доступности данных это ограничивает масштабируемость протокола Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблемы с числителем, но и решить проблемы со знаменателем, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Существует несколько методов сжатия данных:
Сжатие нулевых байтов: заменяет каждую длинную последовательность нулевых байтов двумя байтами, указывая, сколько нулевых байтов.
Аггрегация подписей: переход от подписи ECDSA к подписи BLS. Особенность подписи BLS заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей.
Заменить адреса на указатели: если мы ранее использовали какой-либо адрес, мы можем заменить 20-байтный адрес на 4-байтный указатель, указывающий на определенное место в истории.
Пользовательская сериализация торговых значений: большинство значений сделок имеют небольшое количество разрядов, например, 0.25 Эфир представляется как 250,000,000,000,000,000 wei. Максимальная базовая комиссия и приоритетная комиссия также аналогичны. Таким образом, мы можем использовать пользовательский десятичный формат с плавающей запятой для представления большинства валютных значений.
Различия в состоянии Rollups, основанных на доказательствах эффективности, а не на транзакциях.
Далее основное, что нужно сделать, это фактическая реализация вышеуказанного плана. Основные компромиссы включают:
Переход на подпись BLS требует больших усилий и снижает совместимость с доверенными аппаратными чипами, которые могут повысить безопасность. Можно использовать упаковку ZK-SNARK с другими схемами подписи в качестве замены.
Динамическое сжатие ( Например, замена адресов на указатели ) усложнит клиентский код.
Публикация различий в состоянии в цепочке вместо транзакций снизит аудируемость и сделает многие программы (, такие как блокчейн-обозреватели ), невозможными для работы.
Использование ERC-4337 и окончательное включение его части в L2 EVM может значительно ускорить развертывание агрегирующих технологий. Размещение части ERC-4337 на L1 может ускорить его развертывание на L2.
Даже с использованием блоба размером 16 МБ и сжатия данных, 58 000 TPS может быть недостаточно для полного удовлетворения потребностей потребительских платежей, децентрализованных социальных сетей или других областей с высокой пропускной способностью, особенно когда мы начинаем учитывать факторы конфиденциальности, что может снизить масштабируемость в 3-8 раз. Для сценариев с высокой транзакционной нагрузкой и низкой стоимостью одним из текущих решений является использование Validium, который хранит данные вне цепи и использует интересную модель безопасности: операторы не могут украсть средства пользователей, но они могут временно или навсегда заморозить все средства пользователей. Но мы можем сделать лучше.
Plasma является решением для масштабирования, которое включает оператора, публикующего блоки вне цепи, и размещающего корень Merkle этих блоков в цепи (. В отличие от Rollup, Rollup помещает полные блоки в цепь ). Для каждого блока оператор отправляет каждому пользователю ветвь Merkle, чтобы подтвердить, какие изменения произошли с активами этого пользователя или не произошли. Пользователи могут извлекать свои активы, предоставляя ветвь Merkle. Важно, что эта ветвь не обязательно должна быть с корнем в последнем состоянии. Таким образом, даже если возникают проблемы с доступностью данных, пользователи все равно могут восстановить свои активы, извлекая свое доступное последнее состояние. Если пользователь отправляет недействительную ветвь (, например, извлекая активы, которые они уже отправили другим, или оператор сам создает актив из ниоткуда ), легитимность активов может быть определена с помощью механизма оспаривания в цепи.
Ранние версии Plasma могли обрабатывать только платежные случаи и не могли эффективно развиваться дальше. Однако, если мы потребуем, чтобы каждый корень проверялся с помощью SNARK, то Plasma станет гораздо более мощной. Каждая игра на вызовах может быть значительно упрощена, поскольку мы исключаем большинство возможных путей мошенничества операторов. В то же время это открывает новые пути для расширения технологии Plasma на более широкий спектр классов активов. Наконец, если оператор не обманывает, пользователи могут немедленно выводить средства, не дожидаясь недельного срока оспаривания.
Ключевое понимание заключается в том, что система Plasma не требует совершенства. Даже если вы сможете защитить лишь подмножество активов (, например, только токены, которые не перемещались за последнюю неделю ), вы уже значительно улучшили текущее состояние сверхмасштабируемого EVM (, а именно Validium ).
Другой класс структуры - это смешанный Plasma/Rollup, например Intmax. Эти конструкции помещают на цепочку очень небольшое количество данных каждого пользователя (, например, 5 байт ), что позволяет получить некоторые характеристики между Plasma и Rollup: в случае Intmax вы можете достичь очень высокой масштабируемости и конфиденциальности, хотя даже при емкости 16 МБ теоретически это ограничено примерно 16.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
5
Поделиться
комментарий
0/400
DeFiCaffeinator
· 17ч назад
L2 новые неудачники разыгрывайте людей как лохов
Посмотреть ОригиналОтветить0
BlockchainTherapist
· 17ч назад
eth это король горы
Посмотреть ОригиналОтветить0
CryptoHistoryClass
· 17ч назад
*проверяет исторические паттерны* еще одна нарратив о масштабировании eth... как и хайп вокруг plasma в 2018 году, на мой взгляд
Посмотреть ОригиналОтветить0
Rugman_Walking
· 18ч назад
Экосистема Eth - это истинный путь, не нужно слишком много думать.
Посмотреть ОригиналОтветить0
MidnightTrader
· 18ч назад
Игроки экосистемы L2 действительно зарабатывают много.
Ethereum The Surge: Видение 100000 TPS и решение проблемы масштабирования
Будущее Эфириума: The Surge
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня (Layer2). Шардирование позволяет каждому узлу проверять и хранить лишь небольшую часть транзакций, в то время как Layer2 сохраняет большую часть данных и вычислений вне основной цепи. Эти два подхода в конечном итоге объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является текущей стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение задач: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: судебная система (L1) существует для защиты контрактов и имущественных прав, в то время как предприниматели (L2) строят на этой основе.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных успехов: внедрение EIP-4844 blobs значительно увеличило пропускную способность данных Ethereum L1, несколько EVM Rollup перешли в первую стадию. Каждый L2 существует как независимый "шар", и разнообразие способов реализации шаров стало реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Наша текущая задача заключается в завершении дорожной карты, сосредоточенной на Rollup, решении этих проблем, одновременно сохраняя устойчивость и децентрализацию Ethereum L1.
! Новости Виталика: возможное будущее Ethereum, всплеск
The Surge: ключевая цель
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Парадокс треугольника масштабируемости
Треугольник парадокса масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация, масштабируемость и безопасность. Он приводит эвристический математический аргумент: если децентрализованный узел может проверять N транзакций в секунду, и у вас есть цепочка, которая обрабатывает k*N транзакций в секунду, тогда (i) каждая транзакция может быть увидена только 1/k узлами, что означает, что злоумышленнику достаточно разрушить несколько узлов, чтобы провести вредоносную транзакцию, или (ii) ваши узлы станут мощными, а ваша цепочка не будет децентрализованной.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольную парадокс: оно позволяет клиентам проверять, доступно ли определенное количество данных, и правильно ли выполнено определенное количество вычислительных шагов, загружая лишь небольшое количество данных и выполняя минимальное количество вычислений. Другим решением является архитектура Plasma, которая перекладывает ответственность за мониторинг доступности данных на пользователей. С распространением SNARKs архитектура Plasma становится более жизнеспособной для более широких сценариев использования.
Дальнейшие достижения в выборке доступности данных
В настоящее время каждые 12 секунд в сети Ethereum создается 3 слота по 125 кБ, доступная полоса пропускания данных составляет около 375 кБ. Предполагая, что данные транзакций публикуются непосредственно в цепочке, перевод ERC20 составляет около 180 байт, поэтому максимальная пропускная способность TPS для Rollup в Ethereum составляет 173,6. Наша промежуточная цель — 16 МБ на слот, и если объединить это с улучшениями сжатия данных Rollup, это приведет к примерно 58000 TPS.
PeerDAS — это относительно простая реализация "1D sampling". В Ethereum каждый blob представляет собой 4096-ю многочлен в поле 253-простых чисел. Мы транслируем shares многочлена, каждый из которых содержит 16 оценочных значений на 16 соседних координатах из общего числа 8192 координат. Из этих 8192 оценочных значений любые 4096 могут восстановить blob.
Принцип работы PeerDAS заключается в том, что каждый клиент прослушивает небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob и запрашивает blob из других подсетей у пиров в глобальной p2p-сети. Более консервативная версия SubnetDAS использует только механизм подсетей, без дополнительных запросов к пировому уровню.
С теоретической точки зрения, мы можем значительно масштабировать "1D sampling"; если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, а в образцах доступности данных каждый узел должен обрабатывать 1 МБ полосы пропускания на каждый слот. Это едва укладывается в наши пределы, что означает, что клиенты с ограниченной полосой пропускания не могут участвовать в выборке.
Таким образом, в конечном итоге мы хотим сделать шаг вперед и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между blob. Линейные свойства KZG-промисса используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием для одной и той же информации.
Ключевым моментом является то, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение с точки зрения построения распределенного блока является дружелюбным. Узлы, фактически строящие блоки, должны просто иметь KZG-обязательства blob, и они могут полагаться на выборку доступности данных (DAS) для проверки доступности блоков данных.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Далее следует завершение реализации и запуска PeerDAS. Затем будет постепенно увеличиваться количество blob на PeerDAS, одновременно внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, это постепенный процесс. Мы также надеемся на большее количество академических работ для стандартизации PeerDAS и других версий DAS, а также их взаимодействия с безопасностью правил выбора форков и т.д.
На более поздних этапах в будущем нам нужно будет провести больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативе, безопасной для квантовых вычислений и не требующей доверенной настройки.
Я считаю, что долгосрочный реальный путь заключается в:
Обратите внимание, что даже если мы решим расширить выполнение непосредственно на уровне L1, этот выбор также существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их корректности, поэтому нам придется использовать на уровне L1 те же технологии, что и Rollup(, такие как ZK-EVM и DAS).
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Сжатие данных
Каждая транзакция в Rollup занимает много пространства данных на блокчейне: передача ERC20 требует около 180 байт. Даже при идеальной доступности данных это ограничивает масштабируемость протокола Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблемы с числителем, но и решить проблемы со знаменателем, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Существует несколько методов сжатия данных:
Сжатие нулевых байтов: заменяет каждую длинную последовательность нулевых байтов двумя байтами, указывая, сколько нулевых байтов.
Аггрегация подписей: переход от подписи ECDSA к подписи BLS. Особенность подписи BLS заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей.
Заменить адреса на указатели: если мы ранее использовали какой-либо адрес, мы можем заменить 20-байтный адрес на 4-байтный указатель, указывающий на определенное место в истории.
Пользовательская сериализация торговых значений: большинство значений сделок имеют небольшое количество разрядов, например, 0.25 Эфир представляется как 250,000,000,000,000,000 wei. Максимальная базовая комиссия и приоритетная комиссия также аналогичны. Таким образом, мы можем использовать пользовательский десятичный формат с плавающей запятой для представления большинства валютных значений.
Различия в состоянии Rollups, основанных на доказательствах эффективности, а не на транзакциях.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Далее основное, что нужно сделать, это фактическая реализация вышеуказанного плана. Основные компромиссы включают:
Переход на подпись BLS требует больших усилий и снижает совместимость с доверенными аппаратными чипами, которые могут повысить безопасность. Можно использовать упаковку ZK-SNARK с другими схемами подписи в качестве замены.
Динамическое сжатие ( Например, замена адресов на указатели ) усложнит клиентский код.
Публикация различий в состоянии в цепочке вместо транзакций снизит аудируемость и сделает многие программы (, такие как блокчейн-обозреватели ), невозможными для работы.
Использование ERC-4337 и окончательное включение его части в L2 EVM может значительно ускорить развертывание агрегирующих технологий. Размещение части ERC-4337 на L1 может ускорить его развертывание на L2.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Обобщенный Плазма
Даже с использованием блоба размером 16 МБ и сжатия данных, 58 000 TPS может быть недостаточно для полного удовлетворения потребностей потребительских платежей, децентрализованных социальных сетей или других областей с высокой пропускной способностью, особенно когда мы начинаем учитывать факторы конфиденциальности, что может снизить масштабируемость в 3-8 раз. Для сценариев с высокой транзакционной нагрузкой и низкой стоимостью одним из текущих решений является использование Validium, который хранит данные вне цепи и использует интересную модель безопасности: операторы не могут украсть средства пользователей, но они могут временно или навсегда заморозить все средства пользователей. Но мы можем сделать лучше.
Plasma является решением для масштабирования, которое включает оператора, публикующего блоки вне цепи, и размещающего корень Merkle этих блоков в цепи (. В отличие от Rollup, Rollup помещает полные блоки в цепь ). Для каждого блока оператор отправляет каждому пользователю ветвь Merkle, чтобы подтвердить, какие изменения произошли с активами этого пользователя или не произошли. Пользователи могут извлекать свои активы, предоставляя ветвь Merkle. Важно, что эта ветвь не обязательно должна быть с корнем в последнем состоянии. Таким образом, даже если возникают проблемы с доступностью данных, пользователи все равно могут восстановить свои активы, извлекая свое доступное последнее состояние. Если пользователь отправляет недействительную ветвь (, например, извлекая активы, которые они уже отправили другим, или оператор сам создает актив из ниоткуда ), легитимность активов может быть определена с помощью механизма оспаривания в цепи.
Ранние версии Plasma могли обрабатывать только платежные случаи и не могли эффективно развиваться дальше. Однако, если мы потребуем, чтобы каждый корень проверялся с помощью SNARK, то Plasma станет гораздо более мощной. Каждая игра на вызовах может быть значительно упрощена, поскольку мы исключаем большинство возможных путей мошенничества операторов. В то же время это открывает новые пути для расширения технологии Plasma на более широкий спектр классов активов. Наконец, если оператор не обманывает, пользователи могут немедленно выводить средства, не дожидаясь недельного срока оспаривания.
Ключевое понимание заключается в том, что система Plasma не требует совершенства. Даже если вы сможете защитить лишь подмножество активов (, например, только токены, которые не перемещались за последнюю неделю ), вы уже значительно улучшили текущее состояние сверхмасштабируемого EVM (, а именно Validium ).
Другой класс структуры - это смешанный Plasma/Rollup, например Intmax. Эти конструкции помещают на цепочку очень небольшое количество данных каждого пользователя (, например, 5 байт ), что позволяет получить некоторые характеристики между Plasma и Rollup: в случае Intmax вы можете достичь очень высокой масштабируемости и конфиденциальности, хотя даже при емкости 16 МБ теоретически это ограничено примерно 16.