Дорожная карта Ethereum изначально имела две стратегии масштабирования: шардирование и протоколы второго уровня. С углублением исследований эти два направления объединились, сформировав дорожную карту, сосредоточенную на Rollup, что по-прежнему является текущей стратегией расширения Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое разделение труда: Ethereum L1 сосредоточен на том, чтобы стать мощным и децентрализованным базовым слоем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель очень распространена в обществе: существование судебной системы (L1) не направлено на достижение эффективности, а на защиту контрактов и прав собственности, в то время как предприниматели (L2) строят на этой прочной основе, способствуя развитию человечества.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительного прогресса: запуск EIP-4844 blobs значительно увеличил пропускную способность данных Ethereum L1, несколько EVM Rollup вошли в первый этап. Каждый L2 существует как "шардинг" с собственными правилами и логикой, и разнообразие реализации шардирования теперь стало реальностью. Но этот путь также сталкивается с некоторыми уникальными проблемами. Наша текущая задача – завершить дорожную карту, сосредоточенную на Rollup, решить эти проблемы, сохраняя при этом уникальную надежность и децентрализацию Ethereum L1.
Треугольный парадокс масштабируемости считает, что между тремя характеристиками блокчейна — децентрализацией, масштабируемостью и безопасностью — существует противоречие. Это не теорема, а эвристическая точка зрения. На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что решили тройственный парадокс, но это часто бывает обманчивым.
Однако комбинация выборки доступности данных и SNARKs действительно решает треугольный парадокс: она позволяет клиенту проверять, что определенное количество данных доступно и что определенное количество вычислительных шагов выполнено правильно, при этом загружая лишь небольшое количество данных и выполняя очень мало вычислений.
Другим способом решения трех трудностей является архитектура Plasma, которая перекладывает ответственность за проверку доступности данных на пользователей в стимул-совместимом формате. С распространением SNARKs архитектура Plasma становится более жизнеспособной для более широких сценариев использования.
Дальнейшие достижения в выборке доступности данных
Мы решаем какую проблему?
После обновления Dencun 13 марта 2024 года, в Ethereum на каждый слот длиной 12 секунд будет 3 блоба размером около 125 кБ, или доступная пропускная способность данных на каждый слот составит около 375 кБ. Предполагая, что данные транзакций публикуются непосредственно в сети, перевод ERC20 составляет около 180 байт, следовательно, максимальная TPS Rollup в Ethereum составляет 173,6 TPS.
Добавив calldata Ethereum, это станет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Наша среднесрочная цель - 16 МБ на слот, и если объединить это с улучшениями сжатия данных Rollup, это приведет к ~58000 TPS.
PeerDAS является относительно простой реализацией "1D sampling". В Ethereum каждый blob представляет собой полином степени 4096 в поле простых чисел с 253 битами. Мы передаем доли полинома, где каждая доля содержит 16 оценок от 16 соседних координат из 8192 координат. Из этих 8192 оценок любые 4096 могут восстановить blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого блоба и запрашивает у одноранговых узлов в глобальной p2p сети необходимые ему блобы из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей, без дополнительных запросов к одноранговому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в механизме доказательства доли, использовали SubnetDAS, а остальные узлы использовали PeerDAS.
С теоретической точки зрения, мы можем значительно увеличить масштаб "1D sampling": если увеличить максимальное количество blob до 256, то мы сможем достичь цели в 16 МБ, при этом каждый узел в процессе выборки доступности данных требует всего лишь 1 МБ полосы пропускания на слот. Это едва укладывается в наши допустимые пределы: это осуществимо, но это означает, что клиенты с ограниченной пропускной способностью не смогут осуществлять выборку. Мы можем оптимизировать это, уменьшив количество blob и увеличив их размер, но это сделает стоимость восстановления выше.
Таким образом, в конечном итоге мы хотим продвинуться дальше и провести 2D выборку, которая будет осуществляться не только внутри blob, но и между blob. Используя линейные свойства KZG-призывов, мы расширяем набор blob в блоке с помощью новой группы виртуальных blob, которые избыточно кодируют одну и ту же информацию.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение в своей основе является дружелюбным к распределенному построению блоков. Узлы, фактически строящие блоки, должны только иметь blob KZG обязательства, и они могут полагаться на выборку доступности данных (DAS) для проверки доступности блока данных. Одномерная выборка доступности данных (1D DAS) также по своей сути дружелюбна к распределенному построению блоков.
Следующим шагом является завершение внедрения и запуска PeerDAS. После этого мы будем постоянно увеличивать количество блобов на PeerDAS, внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, что является постепенным процессом. В то же время мы надеемся на большее количество научных работ, чтобы стандартизировать PeerDAS и другие версии DAS, а также их взаимодействие с такими вопросами, как безопасность правил выбора разветвлений.
На более дальних этапах будущего нам нужно будет проделать больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативе, которая будет безопасна для квантовых вычислений и не потребует доверенной настройки. В настоящее время нам еще неясно, какие кандидаты являются дружелюбными к распределенному построению блоков.
Я считаю, что долгосрочный реальный путь таков:
Реализация идеальной 2D DAS;
Продолжайте использовать 1D DAS, жертвуя эффективностью полосы пропускания выборки, чтобы принять более низкий предел данных ради простоты и надежности.
Отказаться от 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 занимать меньше байтов в цепочке?
В сжатии нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, которые указывают, сколько нулевых байтов содержится. Более того, мы использовали специфические свойства транзакций:
Агрегация подписей: мы переключились с ECDSA подписей на BLS подписи. Особенность BLS подписей заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может доказать действительность всех оригинальных подписей. На уровне L1, даже если выполняется агрегация, вычислительная стоимость верификации остается высокой, поэтому использование BLS подписей не рассматривается. Но в L2, в среде с нехваткой данных, использование BLS подписей имеет смысл. Агрегационная особенность ERC-4337 предоставляет путь для реализации этой функции.
Замените адреса на указатели: если ранее использовался какой-либо адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в истории.
Пользовательская сериализация значений транзакций: большинство значений транзакций имеют небольшое количество знаков, например, 0,25 Эфир представляется как 250000000000000000 wei. Максимальная базовая комиссия и комиссия за приоритет также аналогичны. Поэтому мы можем использовать пользовательский десятичный формат с плавающей запятой для представления большинства валютных значений.
Следующим шагом будет фактическая реализация вышеуказанного плана. Основные компромиссы включают:
Переход на подпись BLS требует больших усилий и уменьшает совместимость с доверенными аппаратными чипами, которые могут повысить безопасность. Вместо этого можно использовать упаковку ZK-SNARK с другими схемами подписи.
Динамическое сжатие ( Например, замена адресов на указатели ) усложнит код клиента.
Публикация различий состояния в цепочке вместо транзакций снизит аудируемость и сделает многие программные обеспечения (, такие как блокчейн-браузеры ), неработоспособными.
Как взаимодействовать с другими частями дорожной карты?
Использование ERC-4337 и в конечном итоге интеграция его части в L2 EVM может значительно ускорить развертывание агрегирующих технологий. Размещение части содержимого ERC-4337 на L1 может ускорить его развертывание на L2.
Даже с использованием blob размером 16 МБ и сжатия данных, 58 000 TPS может оказаться недостаточным для полного удовлетворения потребностей потребительских платежей, децентрализованных социальных сетей или других областей с высокой пропускной способностью, особенно когда мы начинаем учитывать факторы конфиденциальности, что может снизить масштабируемость в 3-8 раз. Для сценариев с высокой торговлей и низкой стоимостью приложений на данный момент
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
8 Лайков
Награда
8
5
Репост
Поделиться
комментарий
0/400
MetadataExplorer
· 12ч назад
稳了,L2终于要 На луну?
Посмотреть ОригиналОтветить0
GameFiCritic
· 22ч назад
Подумаю и скажу, Алгоритм гарантирует сходимость, что позволяет увеличить пропускную способность, цель TPS стала ближе.
Посмотреть ОригиналОтветить0
ForkMaster
· 22ч назад
"Ай, L2 ловушка играется 6, разве это не набор для игры в семью твоего ребенка? Просто заплатите немного за защиту."
Ethereum The Surge: Цель расширения до 100000 TPS и технологические достижения
Возможное будущее Ethereum: всплеск
Дорожная карта Ethereum изначально имела две стратегии масштабирования: шардирование и протоколы второго уровня. С углублением исследований эти два направления объединились, сформировав дорожную карту, сосредоточенную на Rollup, что по-прежнему является текущей стратегией расширения Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое разделение труда: Ethereum L1 сосредоточен на том, чтобы стать мощным и децентрализованным базовым слоем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель очень распространена в обществе: существование судебной системы (L1) не направлено на достижение эффективности, а на защиту контрактов и прав собственности, в то время как предприниматели (L2) строят на этой прочной основе, способствуя развитию человечества.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительного прогресса: запуск EIP-4844 blobs значительно увеличил пропускную способность данных Ethereum L1, несколько EVM Rollup вошли в первый этап. Каждый L2 существует как "шардинг" с собственными правилами и логикой, и разнообразие реализации шардирования теперь стало реальностью. Но этот путь также сталкивается с некоторыми уникальными проблемами. Наша текущая задача – завершить дорожную карту, сосредоточенную на Rollup, решить эти проблемы, сохраняя при этом уникальную надежность и децентрализацию Ethereum L1.
! Новости Виталика: возможное будущее Ethereum, всплеск
Увеличение: ключевая цель
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Парадокс треугольника масштабируемости
Треугольный парадокс масштабируемости считает, что между тремя характеристиками блокчейна — децентрализацией, масштабируемостью и безопасностью — существует противоречие. Это не теорема, а эвристическая точка зрения. На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что решили тройственный парадокс, но это часто бывает обманчивым.
Однако комбинация выборки доступности данных и SNARKs действительно решает треугольный парадокс: она позволяет клиенту проверять, что определенное количество данных доступно и что определенное количество вычислительных шагов выполнено правильно, при этом загружая лишь небольшое количество данных и выполняя очень мало вычислений.
Другим способом решения трех трудностей является архитектура Plasma, которая перекладывает ответственность за проверку доступности данных на пользователей в стимул-совместимом формате. С распространением SNARKs архитектура Plasma становится более жизнеспособной для более широких сценариев использования.
Дальнейшие достижения в выборке доступности данных
Мы решаем какую проблему?
После обновления Dencun 13 марта 2024 года, в Ethereum на каждый слот длиной 12 секунд будет 3 блоба размером около 125 кБ, или доступная пропускная способность данных на каждый слот составит около 375 кБ. Предполагая, что данные транзакций публикуются непосредственно в сети, перевод ERC20 составляет около 180 байт, следовательно, максимальная TPS Rollup в Ethereum составляет 173,6 TPS.
Добавив calldata Ethereum, это станет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Наша среднесрочная цель - 16 МБ на слот, и если объединить это с улучшениями сжатия данных Rollup, это приведет к ~58000 TPS.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Что это? Как это работает?
PeerDAS является относительно простой реализацией "1D sampling". В Ethereum каждый blob представляет собой полином степени 4096 в поле простых чисел с 253 битами. Мы передаем доли полинома, где каждая доля содержит 16 оценок от 16 соседних координат из 8192 координат. Из этих 8192 оценок любые 4096 могут восстановить blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого блоба и запрашивает у одноранговых узлов в глобальной p2p сети необходимые ему блобы из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей, без дополнительных запросов к одноранговому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в механизме доказательства доли, использовали SubnetDAS, а остальные узлы использовали PeerDAS.
С теоретической точки зрения, мы можем значительно увеличить масштаб "1D sampling": если увеличить максимальное количество blob до 256, то мы сможем достичь цели в 16 МБ, при этом каждый узел в процессе выборки доступности данных требует всего лишь 1 МБ полосы пропускания на слот. Это едва укладывается в наши допустимые пределы: это осуществимо, но это означает, что клиенты с ограниченной пропускной способностью не смогут осуществлять выборку. Мы можем оптимизировать это, уменьшив количество blob и увеличив их размер, но это сделает стоимость восстановления выше.
Таким образом, в конечном итоге мы хотим продвинуться дальше и провести 2D выборку, которая будет осуществляться не только внутри blob, но и между blob. Используя линейные свойства KZG-призывов, мы расширяем набор blob в блоке с помощью новой группы виртуальных blob, которые избыточно кодируют одну и ту же информацию.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение в своей основе является дружелюбным к распределенному построению блоков. Узлы, фактически строящие блоки, должны только иметь blob KZG обязательства, и они могут полагаться на выборку доступности данных (DAS) для проверки доступности блока данных. Одномерная выборка доступности данных (1D DAS) также по своей сути дружелюбна к распределенному построению блоков.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Что еще нужно сделать? Какие есть компромиссы?
Следующим шагом является завершение внедрения и запуска PeerDAS. После этого мы будем постоянно увеличивать количество блобов на PeerDAS, внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, что является постепенным процессом. В то же время мы надеемся на большее количество научных работ, чтобы стандартизировать PeerDAS и другие версии DAS, а также их взаимодействие с такими вопросами, как безопасность правил выбора разветвлений.
На более дальних этапах будущего нам нужно будет проделать больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативе, которая будет безопасна для квантовых вычислений и не потребует доверенной настройки. В настоящее время нам еще неясно, какие кандидаты являются дружелюбными к распределенному построению блоков.
Я считаю, что долгосрочный реальный путь таков:
Пожалуйста, обратите внимание, что даже если мы решим непосредственно расширять выполнение на уровне L1, такой выбор все же существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их корректности, поэтому нам придется использовать на уровне L1 те же технологии, что и в Rollup(, такие как ZK-EVM и DAS).
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Как взаимодействовать с другими частями дорожной карты?
Если будет реализована сжатие данных, спрос на 2D DAS уменьшится, или, по крайней мере, будет отложен, если Plasma будет широко использоваться, спрос будет снижаться еще больше. DAS также ставит перед протоколами и механизмами распределенного построения блоков вызовы: хотя DAS теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включенных пакетов и механизмом выбора форков вокруг него.
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает большое количество пространства на блокчейне: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость Layer-протокола. Каждый слот 16 МБ, получаем:
16000000 / 12 / 180 = 7407 TPS
Что произойдет, если мы сможем не только решить проблемы с числителем, но и с знаменателем, позволив каждой транзакции в Rollup занимать меньше байтов в цепочке?
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Что это такое и как это работает?
В сжатии нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, которые указывают, сколько нулевых байтов содержится. Более того, мы использовали специфические свойства транзакций:
Агрегация подписей: мы переключились с ECDSA подписей на BLS подписи. Особенность BLS подписей заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может доказать действительность всех оригинальных подписей. На уровне L1, даже если выполняется агрегация, вычислительная стоимость верификации остается высокой, поэтому использование BLS подписей не рассматривается. Но в L2, в среде с нехваткой данных, использование BLS подписей имеет смысл. Агрегационная особенность ERC-4337 предоставляет путь для реализации этой функции.
Замените адреса на указатели: если ранее использовался какой-либо адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в истории.
Пользовательская сериализация значений транзакций: большинство значений транзакций имеют небольшое количество знаков, например, 0,25 Эфир представляется как 250000000000000000 wei. Максимальная базовая комиссия и комиссия за приоритет также аналогичны. Поэтому мы можем использовать пользовательский десятичный формат с плавающей запятой для представления большинства валютных значений.
! Новости Виталика: возможное будущее Ethereum, всплеск
что еще нужно сделать, какие есть компромиссы?
Следующим шагом будет фактическая реализация вышеуказанного плана. Основные компромиссы включают:
Переход на подпись BLS требует больших усилий и уменьшает совместимость с доверенными аппаратными чипами, которые могут повысить безопасность. Вместо этого можно использовать упаковку ZK-SNARK с другими схемами подписи.
Динамическое сжатие ( Например, замена адресов на указатели ) усложнит код клиента.
Публикация различий состояния в цепочке вместо транзакций снизит аудируемость и сделает многие программные обеспечения (, такие как блокчейн-браузеры ), неработоспособными.
Как взаимодействовать с другими частями дорожной карты?
Использование ERC-4337 и в конечном итоге интеграция его части в L2 EVM может значительно ускорить развертывание агрегирующих технологий. Размещение части содержимого ERC-4337 на L1 может ускорить его развертывание на L2.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Обобщенный Плазма
Мы решаем какую проблему?
Даже с использованием blob размером 16 МБ и сжатия данных, 58 000 TPS может оказаться недостаточным для полного удовлетворения потребностей потребительских платежей, децентрализованных социальных сетей или других областей с высокой пропускной способностью, особенно когда мы начинаем учитывать факторы конфиденциальности, что может снизить масштабируемость в 3-8 раз. Для сценариев с высокой торговлей и низкой стоимостью приложений на данный момент