Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Эти два подхода в конечном итоге объединились в дорожную карту, сосредоточенную на Rollup, которая по-прежнему является текущей стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение обязанностей: Ethereum L1 сосредоточен на том, чтобы стать мощным и децентрализованным основным уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: существование судебной системы (L1) не для достижения эффективности, а для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этой прочной основе, способствуя человеческому развитию.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительного прогресса: с запуском блобов EIP-4844 пропускная способность данных Ethereum L1 значительно увеличилась, несколько виртуальных машин Ethereum (EVM) Rollup перешли в первую стадию. Каждый L2 существует как "шардинг" с собственными правилами и логикой, разнообразие и многообразие методов реализации шардинга теперь стали реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Поэтому наша текущая задача — завершить дорожную карту, сосредоточенную на Rollup, решить эти проблемы, сохраняя при этом присущую Ethereum L1 надежность и децентрализованность.
Взлет: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Поддерживайте децентрализованность и устойчивость L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Ethereum (: доверие, открытость, устойчивость к цензуре );
Ethereum должен ощущаться как единая экосистема, а не как 34 разные блокчейна.
Содержание этой главы
Парадокс треугольника масштабируемости
Дальнейшие достижения в области выборки доступности данных
Сжатие данных
Обобщенный Плазма
Зрелая система доказательства L2
Улучшение межоперабельности между L2
Расширение выполнения на L1
Треугольник противоречий масштабируемости
Треугольник масштабируемости — это концепция, предложенная в 2017 году, которая утверждает, что существует противоречие между тремя характеристиками блокчейна: децентрализация (, более конкретно: низкая стоимость работы узлов ), масштабируемость (, количество обрабатываемых транзакций велико ), и безопасность (, поскольку злоумышленнику нужно разрушить большую часть узлов в сети, чтобы сделать одну транзакцию неудачной ).
Стоит отметить, что треугольный парадокс не является теоремой, и статьи, представляющие треугольный парадокс, также не содержат математического доказательства. Он предлагает эвристический математический аргумент: если децентрализованный узел (, например, потребительский ноутбук ) может проверять N транзакций в секунду, и у вас есть цепочка, обрабатывающая k*N транзакций в секунду, то (i) каждая транзакция может быть увидена только 1/k узлами, что означает, что злоумышленнику достаточно разрушить несколько узлов, чтобы провести злонамеренную транзакцию, или (ii) ваши узлы станут мощными, а ваша цепочка не будет децентрализованной. Цель этой статьи вовсе не состоит в том, чтобы доказать, что разрушить треугольный парадокс невозможно; наоборот, она призвана показать, что разрушить тройственный парадокс сложно, и это требует в некоторой степени выйти за рамки мышления, подразумеваемого в этом аргументе.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройной парадокс, не меняя архитектуру в корне, обычно используя приемы программной инженерии для оптимизации узлов. Это всегда вводит в заблуждение, так как запуск узлов на этих цепочках намного сложнее, чем на Ethereum. В этой статье мы обсудим, почему это так и почему только программная инженерия клиентского ПО L1 не может масштабировать Ethereum.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольную парадокс: это позволяет клиентам проверять доступность определенного объема данных и правильность выполнения определенного объема вычислений, загружая лишь небольшое количество данных и выполняя минимальное количество вычислений. SNARKs не требуют доверия. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики нерасширяемой цепи, а именно, что даже атака в 51% не может заставить плохие блоки быть принятыми сетью.
Другим способом решения тройственной проблемы является архитектура Plasma, которая использует хитрые технологии, чтобы передать ответственность за доступность данных пользователям в совместимом с поощрением формате. Еще в 2017-2019 годах, когда у нас был только механизм доказательства мошенничества для расширения вычислительных возможностей, Plasma была очень ограничена в безопасном выполнении, но с распространением SNARKs( нулевых знаний, компактных, не интерактивных доказательств), архитектура Plasma стала более жизнеспособной для более широких сценариев использования, чем когда-либо.
Дальнейшие достижения в области выборки доступности данных
Какую проблему мы решаем?
13 марта 2024 года, когда обновление Dencun будет запущено, в блокчейне Ethereum будет три блоба размером около 125 кБ на слот каждые 12 секунд, или доступная ширина канала данных около 375 кБ на слот. Если предположить, что данные транзакций публикуются непосредственно в сети, то перевод ERC20 составляет около 180 байт, следовательно, максимальная TPS Rollup в Ethereum составляет: 375000 / 12 / 180 = 173.6 TPS
Если мы добавим теоретическое максимальное значение calldata Ethereum (: каждый слот 30000000 Gas / каждый байт 16 gas = каждый слот 1,875,000 байт ), то это приведет к 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 ) могут быть восстановлены в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов (.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у одноранговых узлов в глобальной p2p сети ), кто будет слушать разные подсети (, чтобы запросить необходимые ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсети, без дополнительных запросов к одноранговому слою. Текущая идея заключается в том, чтобы узлы, участвующие в механизме доказательства доли, использовали SubnetDAS, в то время как другие узлы ), то есть клиенты (, использовали PeerDAS.
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/social/moments-5d1a322bd6b6dfef0dbb780172226633d(
С теоретической точки зрения, мы можем значительно масштабировать "1D sampling": если мы увеличим максимальное количество blob до 256) с целью 128(, то мы сможем достичь цели в 16 МБ, при этом каждый узел в образце доступности данных будет иметь 16 образцов * 128 blob * 512 байт на каждый blob на образец = 1 МБ пропускной способности данных на слот. Это лишь едва укладывается в наши пределы терпимости: это выполнимо, но это означает, что клиенты с ограниченной пропускной способностью не смогут проводить выборку. Мы можем оптимизировать это в определенной степени, уменьшив количество blob и увеличив размер blob, но это повысит стоимость восстановления.
Таким образом, мы в конечном итоге хотим продвинуться дальше и провести 2D выборку )2D sampling(, этот метод не только проводит случайную выборку внутри blob, но и между blob. Используя линейные свойства KZG-коммитментов, расширить набор blob в блоке с помощью набора новых виртуальных blob, которые избыточно кодируют ту же информацию.
Таким образом, в конечном итоге мы хотим продвинуться дальше и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между 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 теоретически дружелюбен к распределенному восстановлению, на практике это требует сочетания с предложением о включении пакетов и механизмом выбора форков вокруг него.
Каждая транзакция в Rollup занимает значительное количество пространства данных в цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость Layer протоколов. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Если мы сможем решать не только проблемы с числителем, но и проблемы со знаменателем, и сделать так, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке, что тогда будет?
( Что это такое и как это работает?
На мой взгляд, лучшее объяснение - это этот рисунок двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp###
При сжатии нулевых байтов каждый длинный последовательность нулевых байтов заменяется двумя байтами, которые обозначают количество.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
18 Лайков
Награда
18
5
Поделиться
комментарий
0/400
AirdropNinja
· 07-11 05:04
rollup переехал на layer2?
Посмотреть ОригиналОтветить0
MetaverseVagabond
· 07-08 18:42
layer2 - это будущее, не так ли? Какой смысл делать l1?
Посмотреть ОригиналОтветить0
Layer2Observer
· 07-08 05:35
С технической точки зрения L2 действительно является оптимальным решением.
Ethereum The Surge: путь масштабирования и будущее видение
Будущее Эфира: The Surge
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Эти два подхода в конечном итоге объединились в дорожную карту, сосредоточенную на Rollup, которая по-прежнему является текущей стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение обязанностей: Ethereum L1 сосредоточен на том, чтобы стать мощным и децентрализованным основным уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: существование судебной системы (L1) не для достижения эффективности, а для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этой прочной основе, способствуя человеческому развитию.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительного прогресса: с запуском блобов EIP-4844 пропускная способность данных Ethereum L1 значительно увеличилась, несколько виртуальных машин Ethereum (EVM) Rollup перешли в первую стадию. Каждый L2 существует как "шардинг" с собственными правилами и логикой, разнообразие и многообразие методов реализации шардинга теперь стали реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Поэтому наша текущая задача — завершить дорожную карту, сосредоточенную на Rollup, решить эти проблемы, сохраняя при этом присущую Ethereum L1 надежность и децентрализованность.
Взлет: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Поддерживайте децентрализованность и устойчивость L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Ethereum (: доверие, открытость, устойчивость к цензуре );
Ethereum должен ощущаться как единая экосистема, а не как 34 разные блокчейна.
Содержание этой главы
Треугольник противоречий масштабируемости
Треугольник масштабируемости — это концепция, предложенная в 2017 году, которая утверждает, что существует противоречие между тремя характеристиками блокчейна: децентрализация (, более конкретно: низкая стоимость работы узлов ), масштабируемость (, количество обрабатываемых транзакций велико ), и безопасность (, поскольку злоумышленнику нужно разрушить большую часть узлов в сети, чтобы сделать одну транзакцию неудачной ).
Стоит отметить, что треугольный парадокс не является теоремой, и статьи, представляющие треугольный парадокс, также не содержат математического доказательства. Он предлагает эвристический математический аргумент: если децентрализованный узел (, например, потребительский ноутбук ) может проверять N транзакций в секунду, и у вас есть цепочка, обрабатывающая k*N транзакций в секунду, то (i) каждая транзакция может быть увидена только 1/k узлами, что означает, что злоумышленнику достаточно разрушить несколько узлов, чтобы провести злонамеренную транзакцию, или (ii) ваши узлы станут мощными, а ваша цепочка не будет децентрализованной. Цель этой статьи вовсе не состоит в том, чтобы доказать, что разрушить треугольный парадокс невозможно; наоборот, она призвана показать, что разрушить тройственный парадокс сложно, и это требует в некоторой степени выйти за рамки мышления, подразумеваемого в этом аргументе.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройной парадокс, не меняя архитектуру в корне, обычно используя приемы программной инженерии для оптимизации узлов. Это всегда вводит в заблуждение, так как запуск узлов на этих цепочках намного сложнее, чем на Ethereum. В этой статье мы обсудим, почему это так и почему только программная инженерия клиентского ПО L1 не может масштабировать Ethereum.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольную парадокс: это позволяет клиентам проверять доступность определенного объема данных и правильность выполнения определенного объема вычислений, загружая лишь небольшое количество данных и выполняя минимальное количество вычислений. SNARKs не требуют доверия. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики нерасширяемой цепи, а именно, что даже атака в 51% не может заставить плохие блоки быть принятыми сетью.
Другим способом решения тройственной проблемы является архитектура Plasma, которая использует хитрые технологии, чтобы передать ответственность за доступность данных пользователям в совместимом с поощрением формате. Еще в 2017-2019 годах, когда у нас был только механизм доказательства мошенничества для расширения вычислительных возможностей, Plasma была очень ограничена в безопасном выполнении, но с распространением SNARKs( нулевых знаний, компактных, не интерактивных доказательств), архитектура Plasma стала более жизнеспособной для более широких сценариев использования, чем когда-либо.
! Новости Виталика: Возможное будущее Ethereum, всплеск
Дальнейшие достижения в области выборки доступности данных
Какую проблему мы решаем?
13 марта 2024 года, когда обновление Dencun будет запущено, в блокчейне Ethereum будет три блоба размером около 125 кБ на слот каждые 12 секунд, или доступная ширина канала данных около 375 кБ на слот. Если предположить, что данные транзакций публикуются непосредственно в сети, то перевод ERC20 составляет около 180 байт, следовательно, максимальная TPS Rollup в Ethereum составляет: 375000 / 12 / 180 = 173.6 TPS
Если мы добавим теоретическое максимальное значение calldata Ethereum (: каждый слот 30000000 Gas / каждый байт 16 gas = каждый слот 1,875,000 байт ), то это приведет к 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 ) могут быть восстановлены в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов (.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у одноранговых узлов в глобальной p2p сети ), кто будет слушать разные подсети (, чтобы запросить необходимые ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсети, без дополнительных запросов к одноранговому слою. Текущая идея заключается в том, чтобы узлы, участвующие в механизме доказательства доли, использовали SubnetDAS, в то время как другие узлы ), то есть клиенты (, использовали PeerDAS.
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/social/moments-5d1a322bd6b6dfef0dbb780172226633d(
С теоретической точки зрения, мы можем значительно масштабировать "1D sampling": если мы увеличим максимальное количество blob до 256) с целью 128(, то мы сможем достичь цели в 16 МБ, при этом каждый узел в образце доступности данных будет иметь 16 образцов * 128 blob * 512 байт на каждый blob на образец = 1 МБ пропускной способности данных на слот. Это лишь едва укладывается в наши пределы терпимости: это выполнимо, но это означает, что клиенты с ограниченной пропускной способностью не смогут проводить выборку. Мы можем оптимизировать это в определенной степени, уменьшив количество blob и увеличив размер blob, но это повысит стоимость восстановления.
Таким образом, мы в конечном итоге хотим продвинуться дальше и провести 2D выборку )2D sampling(, этот метод не только проводит случайную выборку внутри blob, но и между blob. Используя линейные свойства KZG-коммитментов, расширить набор blob в блоке с помощью набора новых виртуальных blob, которые избыточно кодируют ту же информацию.
Таким образом, в конечном итоге мы хотим продвинуться дальше и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между 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.
Я считаю, что долгосрочный реалистичный путь таков:
Обратите внимание, что даже если мы решим напрямую расширять выполнение на уровне L1, такой выбор все равно существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их корректности, поэтому нам придется использовать на уровне L1 те же технологии, что и в Rollup), такие как ZK-EVM и DAS(.
) Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 2D DAS уменьшится или, по крайней мере, отложится, если Plasma будет широко использоваться, то потребность еще больше снизится. DAS также ставит перед протоколами и механизмами распределенного построения блоков вызовы: хотя DAS теоретически дружелюбен к распределенному восстановлению, на практике это требует сочетания с предложением о включении пакетов и механизмом выбора форков вокруг него.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает значительное количество пространства данных в цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость Layer протоколов. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Если мы сможем решать не только проблемы с числителем, но и проблемы со знаменателем, и сделать так, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке, что тогда будет?
( Что это такое и как это работает?
На мой взгляд, лучшее объяснение - это этот рисунок двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp###
При сжатии нулевых байтов каждый длинный последовательность нулевых байтов заменяется двумя байтами, которые обозначают количество.