Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Эти два направления в конечном итоге объединились, образовав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum. Дорожная карта, сосредоточенная на Rollup, предлагает простое разделение труда: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым слоем, в то время как L2 берет на себя задачу помощи в расширении экосистемы.
В этом году маршрутная карта, сосредоточенная на Rollup, достигла важных результатов: с запуском блобов EIP-4844, пропускная способность данных Ethereum L1 значительно увеличилась, несколько Rollup на виртуальной машине Ethereum перешли на первый этап. Каждый L2 существует как "шар" с собственными внутренними правилами и логикой, разнообразие и множественность способов реализации шаров теперь стали реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Поэтому наша текущая задача состоит в том, чтобы завершить маршрутную карту, сосредоточенную на Rollup, и решить эти проблемы, сохраняя при этом присущую Ethereum L1 устойчивость и децентрализованность.
Увеличение: ключевые цели
В будущем Ethereum через L2 сможет достичь более 100000 TPS;
Поддерживать децентрализацию и устойчивость L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Ethereum (: доверие, открытость, устойчивость к цензуре );
Ethereum должен восприниматься как единая экосистема, а не как 34 разные блокчейна.
Содержание главы
Парадокс треугольника масштабируемости
Дальнейшие достижения в выборке доступности данных
Сжатие данных
Обобщенный Плазма
Зрелая система доказательства L2
Улучшение межоперабельности между L2
Расширение исполнения на L1
Парадокс треугольника масштабируемости
Треугольник масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, более конкретно: низкая стоимость работы узлов ), масштабируемость (, количество обрабатываемых транзакций ) и безопасность (, злоумышленнику необходимо разрушить значительную часть узлов в сети, чтобы сделать одну транзакцию неудачной ).
Стоит отметить, что треугольный парадокс не является теоремой, и посты, представляющие треугольный парадокс, также не содержат математического доказательства. Он действительно предлагает эвристический математический аргумент: если децентрализованный дружелюбный узел (, например, потребительский ноутбук ) может проверять 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 каждые 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, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для 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 и увеличив размер 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 теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включения пакетов и механизмом выбора ветки вокруг него.
![Виталик новая статья: возможное будущее Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp###
Сжатие данных
( Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много места на цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протоколов Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Если мы сможем не только решить проблемы с числителем, но и с знаменателем, и позволить каждой сделке в Rollup занимать меньше байтов в цепочке, что тогда?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение – это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp###
В сжатии нулевых байтов каждый длинный нулевой байтовый последователь заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Дальше мы использовали транзакции
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
4
Поделиться
комментарий
0/400
Ser_Liquidated
· 12ч назад
Какое расширение, все равно я уже в ловушке.
Посмотреть ОригиналОтветить0
ThatsNotARugPull
· 19ч назад
Редкость, что эта статья не рисует иллюзий~
Посмотреть ОригиналОтветить0
SellTheBounce
· 19ч назад
Еще один план по разыгрыванию неудачников. История уже научила нас, что следует продавать.
Ethereum The Surge: путь к расширению до 100000 TPS и вызовы
Будущее Эфира: The Surge
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Эти два направления в конечном итоге объединились, образовав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum. Дорожная карта, сосредоточенная на Rollup, предлагает простое разделение труда: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым слоем, в то время как L2 берет на себя задачу помощи в расширении экосистемы.
В этом году маршрутная карта, сосредоточенная на Rollup, достигла важных результатов: с запуском блобов EIP-4844, пропускная способность данных Ethereum L1 значительно увеличилась, несколько Rollup на виртуальной машине Ethereum перешли на первый этап. Каждый L2 существует как "шар" с собственными внутренними правилами и логикой, разнообразие и множественность способов реализации шаров теперь стали реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Поэтому наша текущая задача состоит в том, чтобы завершить маршрутную карту, сосредоточенную на Rollup, и решить эти проблемы, сохраняя при этом присущую Ethereum L1 устойчивость и децентрализованность.
Увеличение: ключевые цели
В будущем Ethereum через L2 сможет достичь более 100000 TPS;
Поддерживать децентрализацию и устойчивость L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Ethereum (: доверие, открытость, устойчивость к цензуре );
Ethereum должен восприниматься как единая экосистема, а не как 34 разные блокчейна.
Содержание главы
Парадокс треугольника масштабируемости
Треугольник масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, более конкретно: низкая стоимость работы узлов ), масштабируемость (, количество обрабатываемых транзакций ) и безопасность (, злоумышленнику необходимо разрушить значительную часть узлов в сети, чтобы сделать одну транзакцию неудачной ).
Стоит отметить, что треугольный парадокс не является теоремой, и посты, представляющие треугольный парадокс, также не содержат математического доказательства. Он действительно предлагает эвристический математический аргумент: если децентрализованный дружелюбный узел (, например, потребительский ноутбук ) может проверять N транзакций в секунду, и у вас есть цепочка, обрабатывающая k*N транзакций в секунду, тогда (i) каждая транзакция может быть видна только 1/k узлам, что означает, что злоумышленнику нужно разрушить лишь несколько узлов, чтобы провести вредоносную транзакцию, или (ii) ваши узлы станут мощными, в то время как ваша цепь не будет децентрализованной. Цель этой статьи вовсе не заключается в том, чтобы доказать, что разрушение треугольного парадокса невозможно; наоборот, она направлена на то, чтобы показать, что разрушение тройного парадокса сложно, и это требует в какой-то степени выйти за рамки мыслительных рамок, подразумеваемых этим аргументом.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждают, что они решают тройное противоречие без фундаментального изменения архитектуры, обычно используя методы программной инженерии для оптимизации узлов. Это всегда вводит в заблуждение, так как запуск узлов на этих цепочках значительно сложнее, чем на Ethereum. В этой статье будет исследовано, почему это так, и почему только программная инженерия L1-клиента сама по себе не может масштабировать 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, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для 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 и увеличив размер 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, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp###
Сжатие данных
( Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много места на цепочке: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протоколов Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Если мы сможем не только решить проблемы с числителем, но и с знаменателем, и позволить каждой сделке в Rollup занимать меньше байтов в цепочке, что тогда?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение – это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp###
В сжатии нулевых байтов каждый длинный нулевой байтовый последователь заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Дальше мы использовали транзакции