Маршрутная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. С углублением исследований эти два направления объединились и сформировали маршрутную карту, сосредоточенную на Rollup, что по-прежнему является текущей стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение труда: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: существование судебной системы (L1) не направлено на достижение сверхвысокой скорости и эффективности, а для защиты контрактов и прав собственности, в то время как предприниматели (L2) должны строить на этой прочной базовой платформе, способствуя развитию человечества.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных результатов: с запуском blob-ов EIP-4844 значительно увеличилась пропускная способность данных Ethereum L1, несколько Ethereum виртуальных машин (EVM) Rollup перешли в первую стадию. Каждый L2 существует как "шард", имеющий свои внутренние правила и логику, разнообразие и многообразие способов реализации шардов стало реальностью. Но, как мы видим, этот путь также сталкивается с некоторыми уникальными вызовами. Таким образом, наша текущая задача заключается в завершении дорожной карты с акцентом на Rollup и решении этих проблем, при этом сохраняя уникальную устойчивость и децентрализацию Ethereum L1.
Всплеск: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Поддержание децентрализованности и надежности L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Эфира (: доверие, открытость, сопротивляемость цензуре );
Ethereum должен восприниматься как единая экосистема, а не как 34 различных блокчейна.
Содержимое главы
Треугольный парадокс масштабируемости
Дальнейшие достижения в области выборки доступности данных
Треугольник масштабируемости — это идея, предложенная в 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 будет 3 блоба объемом около 125 кБ в каждом слоте каждые 12 секунд, или доступная полоса пропускания данных на слот составит около 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". В Эфире каждый blob представляет собой 4096-ую многочлен в 253-ем простом поле (. Мы транслируем shares многочлена, каждый из которых содержит 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 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-71424e26868ad99f2adda7a27447820a.webp(
Сжатие данных
) Какую проблему мы решаем?
Каждая транзакция в Rollup занимает большое количество пространства данных на цепочке: передача ERC20 требует около 180 байт. Даже с идеальной выборкой доступности данных это ограничивает масштабируемость протокола Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблему числителя, но и решить проблему знаменателя, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение – это изображение двухлетней давности:
В сжатии нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Дальше мы использовали специфические свойства транзакций:
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
3
Репост
Поделиться
комментарий
0/400
RuntimeError
· 07-14 20:38
Отличная работа eth
Посмотреть ОригиналОтветить0
ChainMelonWatcher
· 07-14 20:34
Бегает довольно надежно~
Посмотреть ОригиналОтветить0
DegenWhisperer
· 07-14 20:27
Здесь играем в архитектурную многослойность, звучит неплохо.
Ethereum The Surge: от 100000 TPS до пути масштабирования единой экосистемы
Будущее Ethereum: всплеск
Маршрутная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. С углублением исследований эти два направления объединились и сформировали маршрутную карту, сосредоточенную на Rollup, что по-прежнему является текущей стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение труда: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе: существование судебной системы (L1) не направлено на достижение сверхвысокой скорости и эффективности, а для защиты контрактов и прав собственности, в то время как предприниматели (L2) должны строить на этой прочной базовой платформе, способствуя развитию человечества.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных результатов: с запуском blob-ов EIP-4844 значительно увеличилась пропускная способность данных Ethereum L1, несколько Ethereum виртуальных машин (EVM) Rollup перешли в первую стадию. Каждый L2 существует как "шард", имеющий свои внутренние правила и логику, разнообразие и многообразие способов реализации шардов стало реальностью. Но, как мы видим, этот путь также сталкивается с некоторыми уникальными вызовами. Таким образом, наша текущая задача заключается в завершении дорожной карты с акцентом на Rollup и решении этих проблем, при этом сохраняя уникальную устойчивость и децентрализацию Ethereum L1.
Всплеск: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Поддержание децентрализованности и надежности L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Эфира (: доверие, открытость, сопротивляемость цензуре );
Ethereum должен восприниматься как единая экосистема, а не как 34 различных блокчейна.
Содержимое главы
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Парадокс треугольника масштабируемости
Треугольник масштабируемости — это идея, предложенная в 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 будет 3 блоба объемом около 125 кБ в каждом слоте каждые 12 секунд, или доступная полоса пропускания данных на слот составит около 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". В Эфире каждый blob представляет собой 4096-ую многочлен в 253-ем простом поле (. Мы транслируем shares многочлена, каждый из которых содержит 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 sampling), этот метод не только выполняет случайное выборочное извлечение внутри blob, но и между blob. Используя линейные свойства KZG-коммитмента, расширяем набор blob в блоке с помощью группы новых виртуальных blob, которые избыточно кодируют ту же информацию.
Таким образом, в конечном итоге мы хотим продвинуться дальше и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между 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 теоретически дружелюбен к распределенному восстановлению, на практике это требует сочетания с предложением списка включения пакетов и механизмом выбора разветвлений вокруг него.
![Виталик новая статья: возможное будущее Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Сжатие данных
) Какую проблему мы решаем?
Каждая транзакция в Rollup занимает большое количество пространства данных на цепочке: передача ERC20 требует около 180 байт. Даже с идеальной выборкой доступности данных это ограничивает масштабируемость протокола Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблему числителя, но и решить проблему знаменателя, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение – это изображение двухлетней давности:
В сжатии нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Дальше мы использовали специфические свойства транзакций:
Подпись агрегирования: мы из