Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Шардирование позволяет каждому узлу проверять и хранить только часть транзакций, в то время как протоколы второго уровня строят сети поверх Ethereum, используя его безопасность, но оставляя большую часть данных и вычислений вне основной цепи. Эти два подхода в конечном итоге объединились в дорожную карту, сосредоточенную на Rollup, которая по сей день остается стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простую специализацию: Ethereum L1 сосредоточен на том, чтобы быть мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: судебная система (L1) существует для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этом, способствуя развитию человечества.
В этом году важные шаги были сделаны в дорожной карте, сосредоточенной на Rollup: запуск EIP-4844 blobs значительно увеличил пропускную способность данных Ethereum L1, несколько Ethereum Virtual Machine (EVM) Rollup уже вошли в первую стадию. Каждый L2 существует как "шардинг" с собственными правилами и логикой, и разнообразие способов реализации шардинга стало реальностью. Но этот путь также сталкивается с некоторыми уникальными проблемами. Наша задача сейчас заключается в завершении дорожной карты, сосредоточенной на Rollup, решении этих проблем, сохраняя при этом надежность и децентрализацию Ethereum L1.
Треугольник масштабируемости считает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, низкие затраты на работу узлов ), масштабируемость (, высокая пропускная способность для обработки большого количества транзакций ) и безопасность (, где злоумышленнику необходимо разрушить значительную часть узлов в сети, чтобы вызвать сбой одной транзакции ).
Треугольный парадокс не является теоремой, и пост, который его представляет, не содержит математического доказательства. Он предлагает эвристический математический аргумент: если децентрализованный дружелюбный узел может проверять N транзакций в секунду, а у вас есть цепочка, обрабатывающая k*N транзакций в секунду, то: (i) каждая транзакция может быть видна только 1/k узлам, что означает, что злоумышленнику достаточно уничтожить несколько узлов, чтобы провести вредоносную транзакцию, или (ii) ваши узлы станут мощными, а ваша цепочка не будет децентрализованной. Статья призвана показать, что преодолеть тройной парадокс сложно и требует, по сути, выхода за рамки подразумеваемой логики данного аргумента.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройственное противоречие, не изменяя архитектуру, обычно за счет оптимизации узлов. Это всегда вводит в заблуждение, так как запуск узлов на этих цепях намного сложнее, чем на 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, что обеспечит для calldata 463-926 TPS.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, и если объединить это с улучшениями сжатия данных Rollup, это приведет к ~58000 TPS.
PeerDAS является относительно простым реализацией "1D sampling". В Ethereum каждый blob представляет собой 4096-ю полиномиальную функцию на 253-ем простом поле (prime field). Мы транслируем shares полинома, где каждый share содержит 16 оценок на 16 соседних координат из общего числа 8192 координат. Из этих 8192 оценок любые 4096 из ( могут быть восстановлены в зависимости от текущих предложенных параметров: любой из 64 возможных образцов из 128 ) может восстановить blob.
Принцип работы PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить необходимые ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к одноранговому уровню. Текущая предложенная версия заключается в том, чтобы узлы, участвующие в доказательстве доли, использовали SubnetDAS, тогда как другие узлы (, т.е. клиенты ), использовали PeerDAS.
С теоретической точки зрения, мы можем масштабировать масштаб «1D sampling» довольно значительно: если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, а доступность данных при семплировании будет составлять 16 образцов на узел * 128 blob * 512 байт на каждый образец каждого blob = 1 МБ полосы пропускания данных на слот. Это едва укладывается в наши допустимые пределы: это возможно, но это означает, что клиенты с ограниченной пропускной способностью не могут проводить семплирование. Мы можем несколько оптимизировать это, уменьшая количество blob и увеличивая их размер, но это приведет к увеличению стоимости восстановления.
Таким образом, мы в конечном итоге хотим продвинуться дальше, провести 2D выборку (2D sampling). Этот метод не только осуществляет случайную выборку внутри blob, но и между blob. Используя линейные свойства KZG-призывов, мы расширяем набор blob в блоке с помощью набора новых виртуальных blob, которые избыточно кодируют ту же информацию.
Таким образом, в конечном итоге мы хотим пойти еще дальше и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между ними. Линейные свойства KZG-обязательства используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход в своей основе дружелюбен к распределенному построению блоков. Узлы, фактически строящие блоки, должны лишь обладать blob KZG обязательством, и они могут полагаться на выборку доступности данных (DAS) для проверки доступности блока данных. Одномерная выборка доступности данных (1D DAS) также по своей сути дружелюбна к распределенному построению блоков.
Далее следует завершение внедрения и запуска PeerDAS. После этого будет постоянно увеличиваться количество blob на PeerDAS, одновременно внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, это постепенный процесс. В то же время мы надеемся на большее количество академических работ, чтобы нормализовать PeerDAS и другие версии DAS, а также взаимодействие с проблемами безопасности, связанными с правилами выбора разделений.
На более дальних этапах в будущем нам нужно будет сделать больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативному решению, которое будет квантово безопасным и не требует доверенной настройки. В настоящее время нам не совсем ясно, какие кандидаты являются дружелюбными к распределенному построению блоков. Даже использование дорогостоящей "грубой" технологии, даже использование рекурсивного STARK для генерации доказательств корректности для восстановления строк и столбцов, не достаточно для удовлетворения требований, поскольку, хотя технически размер одного STARK равен O)log###n( * log(log)n(( хеш-значение ) с использованием STIR), на практике STARK практически такой же большой, как и весь blob.
Я считаю, что долгосрочный реалистичный путь таков:
Реализация идеального 2D DAS;
Продолжайте использовать 1D DAS, жертвуя эффективностью полосы пропускания выборки, принимая более низкие пределы данных ради простоты и надежности.
Отказаться от DA и полностью принять Plasma в качестве нашей основной архитектуры Layer2.
Пожалуйста, обратите внимание, что даже если мы решим непосредственно расширить выполнение на уровне L1, такой выбор все равно существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их корректности, поэтому нам придется использовать на уровне L1 такие же технологии, как Rollup(, такие как ZK-EVM и DAS).
( Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 2D DAS уменьшится или, по крайней мере, отложится, если Plasma будет широко использоваться, то потребность дополнительно снизится. DAS также бросает вызов протоколам и механизмам построения распределенного блока: хотя DAS теоретически дружелюбен к распределенному восстановлению, на практике это требует сочетания с предложением inclusion list и механизмами выбора разветвлений вокруг него.
![Vitalik новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp###
Сжатие данных
( Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много пространства на цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протокола Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Если мы сможем не только решить проблему числителя, но и решить проблему знаменателя, и сделать так, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке, что тогда будет?
) Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск]###https://img-cdn.gateio.im/webp-social/moments-a04daca8af5d6af3c06b77a97aae477d.webp###
В процессе сжатия нулевых байтов, каждый длинный последовательный нулевой байт заменяется двумя байтами, указывающими, сколько нулевых байтов было. Более того, мы использовали определенные свойства транзакции:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенностью подписей BLS является то, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить все оригинальные.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
6 Лайков
Награда
6
4
Поделиться
комментарий
0/400
FloorSweeper
· 08-04 04:06
Не спрашивай, почему L2 просто крут.
Посмотреть ОригиналОтветить0
RamenDeFiSurvivor
· 08-04 04:05
Валет L2 действительно хорош
Посмотреть ОригиналОтветить0
ShadowStaker
· 08-04 04:02
хмм, эффективность mev на l2 еще требует работы, если честно... топология сети еще не совсем на своем месте
Ethereum расширение нового этапа: Глубина анализа дорожной карты The Surge
Будущее Эфириума: Ускорение
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Шардирование позволяет каждому узлу проверять и хранить только часть транзакций, в то время как протоколы второго уровня строят сети поверх Ethereum, используя его безопасность, но оставляя большую часть данных и вычислений вне основной цепи. Эти два подхода в конечном итоге объединились в дорожную карту, сосредоточенную на Rollup, которая по сей день остается стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простую специализацию: Ethereum L1 сосредоточен на том, чтобы быть мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: судебная система (L1) существует для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этом, способствуя развитию человечества.
В этом году важные шаги были сделаны в дорожной карте, сосредоточенной на Rollup: запуск EIP-4844 blobs значительно увеличил пропускную способность данных Ethereum L1, несколько Ethereum Virtual Machine (EVM) Rollup уже вошли в первую стадию. Каждый L2 существует как "шардинг" с собственными правилами и логикой, и разнообразие способов реализации шардинга стало реальностью. Но этот путь также сталкивается с некоторыми уникальными проблемами. Наша задача сейчас заключается в завершении дорожной карты, сосредоточенной на Rollup, решении этих проблем, сохраняя при этом надежность и децентрализацию Ethereum L1.
! Новости Виталика: возможное будущее Ethereum, всплеск
Всплеск: ключевая цель
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Парадокс треугольника масштабируемости
Треугольник масштабируемости считает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, низкие затраты на работу узлов ), масштабируемость (, высокая пропускная способность для обработки большого количества транзакций ) и безопасность (, где злоумышленнику необходимо разрушить значительную часть узлов в сети, чтобы вызвать сбой одной транзакции ).
Треугольный парадокс не является теоремой, и пост, который его представляет, не содержит математического доказательства. Он предлагает эвристический математический аргумент: если децентрализованный дружелюбный узел может проверять N транзакций в секунду, а у вас есть цепочка, обрабатывающая k*N транзакций в секунду, то: (i) каждая транзакция может быть видна только 1/k узлам, что означает, что злоумышленнику достаточно уничтожить несколько узлов, чтобы провести вредоносную транзакцию, или (ii) ваши узлы станут мощными, а ваша цепочка не будет децентрализованной. Статья призвана показать, что преодолеть тройной парадокс сложно и требует, по сути, выхода за рамки подразумеваемой логики данного аргумента.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройственное противоречие, не изменяя архитектуру, обычно за счет оптимизации узлов. Это всегда вводит в заблуждение, так как запуск узлов на этих цепях намного сложнее, чем на Ethereum.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольную парадокс: оно позволяет клиентам проверять наличие определенного объема данных и правильность выполнения определенного количества вычислительных шагов, загружая лишь небольшое количество данных и выполняя минимальное количество вычислений. SNARKs являются доверительными без необходимости. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики цепочки, не подлежащей масштабированию, а именно, что даже атака в 51% не может заставить плохие блоки быть принятыми сетью.
Другим способом решения тройной проблемы является архитектура Plasma, которая использует хитроумные технологии, чтобы в стимулирующем совместимом формате переложить ответственность за доступность данных на пользователей. Еще в 2017-2019 годах, когда у нас был только механизм доказательства мошенничества для расширения вычислительных возможностей, Plasma была очень ограничена в безопасном исполнении, но с распространением SNARKs архитектура Plasma стала более жизнеспособной для более широких сценариев использования, чем когда-либо.
! Новости Виталика: Возможное будущее Ethereum, всплеск
Дальнейшие достижения в выборке доступности данных
Какую проблему мы решаем?
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, что обеспечит для calldata 463-926 TPS.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, и если объединить это с улучшениями сжатия данных Rollup, это приведет к ~58000 TPS.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Что это? Как это работает?
PeerDAS является относительно простым реализацией "1D sampling". В Ethereum каждый blob представляет собой 4096-ю полиномиальную функцию на 253-ем простом поле (prime field). Мы транслируем shares полинома, где каждый share содержит 16 оценок на 16 соседних координат из общего числа 8192 координат. Из этих 8192 оценок любые 4096 из ( могут быть восстановлены в зависимости от текущих предложенных параметров: любой из 64 возможных образцов из 128 ) может восстановить blob.
Принцип работы PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить необходимые ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к одноранговому уровню. Текущая предложенная версия заключается в том, чтобы узлы, участвующие в доказательстве доли, использовали SubnetDAS, тогда как другие узлы (, т.е. клиенты ), использовали PeerDAS.
С теоретической точки зрения, мы можем масштабировать масштаб «1D sampling» довольно значительно: если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, а доступность данных при семплировании будет составлять 16 образцов на узел * 128 blob * 512 байт на каждый образец каждого blob = 1 МБ полосы пропускания данных на слот. Это едва укладывается в наши допустимые пределы: это возможно, но это означает, что клиенты с ограниченной пропускной способностью не могут проводить семплирование. Мы можем несколько оптимизировать это, уменьшая количество blob и увеличивая их размер, но это приведет к увеличению стоимости восстановления.
Таким образом, мы в конечном итоге хотим продвинуться дальше, провести 2D выборку (2D sampling). Этот метод не только осуществляет случайную выборку внутри blob, но и между blob. Используя линейные свойства KZG-призывов, мы расширяем набор blob в блоке с помощью набора новых виртуальных blob, которые избыточно кодируют ту же информацию.
Таким образом, в конечном итоге мы хотим пойти еще дальше и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между ними. Линейные свойства KZG-обязательства используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход в своей основе дружелюбен к распределенному построению блоков. Узлы, фактически строящие блоки, должны лишь обладать blob KZG обязательством, и они могут полагаться на выборку доступности данных (DAS) для проверки доступности блока данных. Одномерная выборка доступности данных (1D DAS) также по своей сути дружелюбна к распределенному построению блоков.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
( Что еще нужно сделать? Какие есть компромиссы?
Далее следует завершение внедрения и запуска PeerDAS. После этого будет постоянно увеличиваться количество blob на PeerDAS, одновременно внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, это постепенный процесс. В то же время мы надеемся на большее количество академических работ, чтобы нормализовать PeerDAS и другие версии DAS, а также взаимодействие с проблемами безопасности, связанными с правилами выбора разделений.
На более дальних этапах в будущем нам нужно будет сделать больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативному решению, которое будет квантово безопасным и не требует доверенной настройки. В настоящее время нам не совсем ясно, какие кандидаты являются дружелюбными к распределенному построению блоков. Даже использование дорогостоящей "грубой" технологии, даже использование рекурсивного STARK для генерации доказательств корректности для восстановления строк и столбцов, не достаточно для удовлетворения требований, поскольку, хотя технически размер одного STARK равен O)log###n( * log(log)n(( хеш-значение ) с использованием STIR), на практике STARK практически такой же большой, как и весь blob.
Я считаю, что долгосрочный реалистичный путь таков:
Пожалуйста, обратите внимание, что даже если мы решим непосредственно расширить выполнение на уровне L1, такой выбор все равно существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их корректности, поэтому нам придется использовать на уровне L1 такие же технологии, как Rollup(, такие как ZK-EVM и DAS).
( Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 2D DAS уменьшится или, по крайней мере, отложится, если Plasma будет широко использоваться, то потребность дополнительно снизится. DAS также бросает вызов протоколам и механизмам построения распределенного блока: хотя DAS теоретически дружелюбен к распределенному восстановлению, на практике это требует сочетания с предложением inclusion list и механизмами выбора разветвлений вокруг него.
![Vitalik новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp###
Сжатие данных
( Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много пространства на цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протокола Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Если мы сможем не только решить проблему числителя, но и решить проблему знаменателя, и сделать так, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке, что тогда будет?
) Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск]###https://img-cdn.gateio.im/webp-social/moments-a04daca8af5d6af3c06b77a97aae477d.webp###
В процессе сжатия нулевых байтов, каждый длинный последовательный нулевой байт заменяется двумя байтами, указывающими, сколько нулевых байтов было. Более того, мы использовали определенные свойства транзакции:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенностью подписей BLS является то, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить все оригинальные.