В изначальной дорожной карте Ethereum были предусмотрены две стратегии масштабирования: шардирование и протоколы второго уровня (Layer 2). Эти две стратегии в конечном итоге объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая до сих пор является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое разделение труда: Ethereum L1 сосредоточен на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель повсюду в обществе: существование судебной системы (L1) предназначено для защиты контрактов и прав собственности, тогда как предприниматели (L2) строят на этой основе, двигая человечество вперед.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных результатов: с введением блобов EIP-4844 пропускная способность данных Ethereum L1 значительно увеличилась, несколько EVM Rollup вошли в первую стадию. Каждый L2 существует как "шард", обладающий собственными правилами и логикой; разнообразие и многообразие способов реализации шардов теперь стали реальностью. Однако этот путь также сталкивается с некоторыми уникальными вызовами. Таким образом, наша текущая задача заключается в завершении дорожной карты, сосредоточенной на Rollup, решении этих проблем, одновременно сохраняя устойчивость и децентрализацию Ethereum L1.
Всплеск: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Сохранять децентрализованность и устойчивость L1;
По крайней мере, некоторые L2 полностью унаследовали ключевые свойства Ethereum (, такие как доверие, открытость, сопротивление цензуре );
Ethereum должен восприниматься как единая экосистема, а не как 34 разных блокчейна.
Треугольник противоречия масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация ( низкие затраты на узлы ) масштабируемость ( большое количество обрабатываемых транзакций ) и безопасность ( злоумышленник должен разрушить большую часть узлов в сети, чтобы сделать отдельную транзакцию неудачной ).
Стоит отметить, что треугольный парадокс не является теоремой, и посты, посвященные треугольному парадоксу, также не содержат математических доказательств. Он приводит эвристический математический аргумент: если децентрализованный узел может подтверждать N транзакций в секунду, и у вас есть цепь, обрабатывающая k*N транзакций в секунду, то (i) каждая транзакция может быть видна только 1/k узлам, что означает, что злоумышленнику нужно разрушить всего лишь несколько узлов, чтобы провести злонамеренную транзакцию, или (ii) ваши узлы станут мощными, в то время как ваша цепь не будет децентрализована. Цель этой статьи совсем не в том, чтобы доказать, что разрушить треугольный парадокс невозможно; скорее, она нацелена на то, чтобы показать, что разрушить тройной парадокс трудно, и что это требует, по крайней мере, некоторого выхода за рамки подразумеваемой в этом аргументе мыслительной структуры.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройной парадокс, не меняя кардинально архитектуру, обычно с помощью применения методов программной инженерии для оптимизации узлов. Это всегда было вводящим в заблуждение, так как запуск узлов на этих цепочках значительно сложнее, чем на Ethereum. В этой статье будет рассмотрено, почему это так, и почему только программная инженерия L1-клиентов сама по себе не может масштабировать Ethereum.
Тем не менее, сочетание выборки доступности данных и SNARK позволяет решить треугольный парадокс: оно позволяет клиенту проверять, что определенное количество данных доступно, а также что определенное количество вычислительных шагов выполнено правильно, при этом загружая лишь небольшое количество данных и выполняя крайне ограниченное количество вычислений. 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 миллионов газа / каждый байт 16 газа = каждый слот 1,875,000 байт ), это приведет к 607 TPS. Используя PeerDAS, количество блобов может увеличиться до 8-16, что обеспечит для calldata 463-926 TPS.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, что в сочетании с улучшениями сжатия данных Rollup приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS является относительно простой реализацией "1D sampling". В Ethereum каждый blob представляет собой 4096-й многочлен в поле простых чисел на 253 бита. Мы транслируем shares многочлена, где каждый share содержит 16 оценок на 16 соседних координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 ( могут быть восстановлены в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ).
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть передает любой blob i-го образца и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить необходимые ему blobs из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к одноранговому уровню. Текущая идея состоит в том, чтобы узлы, участвующие в подтверждении доли, использовали SubnetDAS, в то время как другие узлы (, то есть клиенты ), использовали PeerDAS.
С теоретической точки зрения, мы можем масштабировать "1D sampling" до довольно больших размеров: если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, а доступность данных в образцах включает в себя 16 образцов на каждый узел * 128 blob * по 512 байт на каждый blob за каждый образец = 1 МБ пропускной способности данных на каждый слот. Это лишь едва укладывается в наш предел терпимости: это возможно, но это означает, что клиенты с ограниченной пропускной способностью не могут выполнять выборку. Мы можем оптимизировать это до определенной степени, сократив количество blob и увеличив их размер, но это увеличит стоимость восстановления.
Таким образом, мы в конечном итоге хотим продвинуться дальше и провести 2D-выборку, этот метод не только выполняет случайную выборку внутри блоба, но и между блобами. Используя линейные свойства KZG-коммитментов, мы расширяем набор блобов в блоке с помощью набора новых виртуальных блобов, которые избыточно кодируют ту же информацию.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение в основном является дружелюбным к распределенному построению блоков. Узлы, фактически строящие блоки, просто должны иметь KZG-обязательства blob, и они могут полагаться на выборку доступности данных для проверки доступности блоков данных. Одномерная выборка доступности данных по сути также дружелюбна к распределенному построению блоков.
Далее следует завершить внедрение и запуск 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 занимала на цепочке меньше байт?
Что это такое и как это работает?
В процессе сжатия нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Более того, мы использовали определенные свойства транзакций:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенность подписей BLS заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже при выполнении агрегации, вычислительные затраты на проверку все равно высоки, поэтому использование подписей BLS не рассматривается. Однако в L2, в среде с дефицитом данных, использование подписей BLS имеет смысл. Агрегационные функции ERC-4337 предоставляют путь для реализации этой функции.
Замените адреса на указатели: если вы когда-либо использовали определенный адрес, мы можем заменить 20-байтный адрес на 4-байтный указатель, указывающий на определенное место в истории.
Кастомная сериализация значений транзакций------Большинство значений транзакций имеют небольшое количество разрядов, например, 0.25 Эфир представляется как 250
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
22 Лайков
Награда
22
4
Поделиться
комментарий
0/400
BrokeBeans
· 07-22 21:16
Все еще занимаетесь увеличением данных? Уже все устарело.
Посмотреть ОригиналОтветить0
BearMarketSurvivor
· 07-22 21:15
Задняя линия снабжения очень стабильна, боевые силы Ethereum продолжают усиливаться
Путь расширения Ethereum: Анализ стратегии масштабирования The Surge и будущие цели
Взрыв: будущее масштабируемости Ethereum
В изначальной дорожной карте Ethereum были предусмотрены две стратегии масштабирования: шардирование и протоколы второго уровня (Layer 2). Эти две стратегии в конечном итоге объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая до сих пор является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое разделение труда: Ethereum L1 сосредоточен на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель повсюду в обществе: существование судебной системы (L1) предназначено для защиты контрактов и прав собственности, тогда как предприниматели (L2) строят на этой основе, двигая человечество вперед.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных результатов: с введением блобов EIP-4844 пропускная способность данных Ethereum L1 значительно увеличилась, несколько EVM Rollup вошли в первую стадию. Каждый L2 существует как "шард", обладающий собственными правилами и логикой; разнообразие и многообразие способов реализации шардов теперь стали реальностью. Однако этот путь также сталкивается с некоторыми уникальными вызовами. Таким образом, наша текущая задача заключается в завершении дорожной карты, сосредоточенной на Rollup, решении этих проблем, одновременно сохраняя устойчивость и децентрализацию Ethereum L1.
Всплеск: ключевая цель
Содержание этой главы
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Парадокс треугольника масштабируемости
Треугольник противоречия масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация ( низкие затраты на узлы ) масштабируемость ( большое количество обрабатываемых транзакций ) и безопасность ( злоумышленник должен разрушить большую часть узлов в сети, чтобы сделать отдельную транзакцию неудачной ).
Стоит отметить, что треугольный парадокс не является теоремой, и посты, посвященные треугольному парадоксу, также не содержат математических доказательств. Он приводит эвристический математический аргумент: если децентрализованный узел может подтверждать N транзакций в секунду, и у вас есть цепь, обрабатывающая k*N транзакций в секунду, то (i) каждая транзакция может быть видна только 1/k узлам, что означает, что злоумышленнику нужно разрушить всего лишь несколько узлов, чтобы провести злонамеренную транзакцию, или (ii) ваши узлы станут мощными, в то время как ваша цепь не будет децентрализована. Цель этой статьи совсем не в том, чтобы доказать, что разрушить треугольный парадокс невозможно; скорее, она нацелена на то, чтобы показать, что разрушить тройной парадокс трудно, и что это требует, по крайней мере, некоторого выхода за рамки подразумеваемой в этом аргументе мыслительной структуры.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройной парадокс, не меняя кардинально архитектуру, обычно с помощью применения методов программной инженерии для оптимизации узлов. Это всегда было вводящим в заблуждение, так как запуск узлов на этих цепочках значительно сложнее, чем на Ethereum. В этой статье будет рассмотрено, почему это так, и почему только программная инженерия L1-клиентов сама по себе не может масштабировать Ethereum.
Тем не менее, сочетание выборки доступности данных и SNARK позволяет решить треугольный парадокс: оно позволяет клиенту проверять, что определенное количество данных доступно, а также что определенное количество вычислительных шагов выполнено правильно, при этом загружая лишь небольшое количество данных и выполняя крайне ограниченное количество вычислений. 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 миллионов газа / каждый байт 16 газа = каждый слот 1,875,000 байт ), это приведет к 607 TPS. Используя PeerDAS, количество блобов может увеличиться до 8-16, что обеспечит для calldata 463-926 TPS.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, что в сочетании с улучшениями сжатия данных Rollup приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS является относительно простой реализацией "1D sampling". В Ethereum каждый blob представляет собой 4096-й многочлен в поле простых чисел на 253 бита. Мы транслируем shares многочлена, где каждый share содержит 16 оценок на 16 соседних координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 ( могут быть восстановлены в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ).
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть передает любой blob i-го образца и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить необходимые ему blobs из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к одноранговому уровню. Текущая идея состоит в том, чтобы узлы, участвующие в подтверждении доли, использовали SubnetDAS, в то время как другие узлы (, то есть клиенты ), использовали PeerDAS.
С теоретической точки зрения, мы можем масштабировать "1D sampling" до довольно больших размеров: если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, а доступность данных в образцах включает в себя 16 образцов на каждый узел * 128 blob * по 512 байт на каждый blob за каждый образец = 1 МБ пропускной способности данных на каждый слот. Это лишь едва укладывается в наш предел терпимости: это возможно, но это означает, что клиенты с ограниченной пропускной способностью не могут выполнять выборку. Мы можем оптимизировать это до определенной степени, сократив количество blob и увеличив их размер, но это увеличит стоимость восстановления.
Таким образом, мы в конечном итоге хотим продвинуться дальше и провести 2D-выборку, этот метод не только выполняет случайную выборку внутри блоба, но и между блобами. Используя линейные свойства KZG-коммитментов, мы расширяем набор блобов в блоке с помощью набора новых виртуальных блобов, которые избыточно кодируют ту же информацию.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение в основном является дружелюбным к распределенному построению блоков. Узлы, фактически строящие блоки, просто должны иметь KZG-обязательства blob, и они могут полагаться на выборку доступности данных для проверки доступности блоков данных. Одномерная выборка доступности данных по сути также дружелюбна к распределенному построению блоков.
! Виталик Новая статья: Возможное будущее 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 теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включения пакетов и механизмом выбора веток вокруг него.
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много пространства на цепочке данных: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протокола Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблемы с числителем, но и с знаменателем, чтобы каждая транзакция в Rollup занимала на цепочке меньше байт?
Что это такое и как это работает?
В процессе сжатия нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Более того, мы использовали определенные свойства транзакций:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенность подписей BLS заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже при выполнении агрегации, вычислительные затраты на проверку все равно высоки, поэтому использование подписей BLS не рассматривается. Однако в L2, в среде с дефицитом данных, использование подписей BLS имеет смысл. Агрегационные функции ERC-4337 предоставляют путь для реализации этой функции.
Замените адреса на указатели: если вы когда-либо использовали определенный адрес, мы можем заменить 20-байтный адрес на 4-байтный указатель, указывающий на определенное место в истории.
Кастомная сериализация значений транзакций------Большинство значений транзакций имеют небольшое количество разрядов, например, 0.25 Эфир представляется как 250