Новая статья Виталика: возможное будущее Ethereum, The Surge
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы уровня 2. Эти два направления в конечном итоге объединились, образовав дорожную карту, сосредоточенную на Rollup, что по-прежнему является текущей стратегией масштабирования Ethereum. Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение задач: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы.
В этом году важные достижения были достигнуты в дорожной карте, сосредоточенной на Rollup: с запуском EIP-4844 блобов значительно увеличилась пропускная способность данных Ethereum L1, и несколько Ethereum виртуальных машин (EVM) Rollup вошли в первую стадию. Каждый L2 существует как "шард", обладая собственными внутренними правилами и логикой, и разнообразие и многообразие способов реализации шардов стало реальностью. Но, как мы видим, этот путь также сталкивается с некоторыми уникальными вызовами. Поэтому наша нынешняя задача заключается в том, чтобы завершить дорожную карту, сосредоточенную на Rollup, и решить эти проблемы, сохраняя при этом стойкость и децентрализацию, присущие Ethereum L1.
Всплеск: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Сохранять децентрализованность и надежность L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Эфира (: доверять, открытость, антицензурирование );
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 каждые 12 секунд будет 3 слота по 125 кБ блобов, или доступная пропускная способность данных для каждого слота составит примерно 375 кБ. Предполагая, что данные транзакций публикуются непосредственно в цепочке, то перевод ERC20 составляет около 180 байт, поэтому максимальная TPS Rollup на Ethereum составляет: 375000 / 12 / 180 = 173.6 TPS.
Если мы добавим теоретическую максимальную величину calldata Ethereum (: каждое слотов 30 миллионов Gas / каждый байт 16 gas = каждое слотов 1,875,000 байт ), то это станет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит для calldata 463-926 TPS.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель — 16 МБ на слот, если в сочетании с улучшениями сжатия данных Rollup, это приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS — это относительно простая реализация "1D sampling". В Эфире каждый blob представляет собой 4096-ю степень многочлена в 253-битом простом поле (prime field). Мы транслируем shares многочлена, где каждый share содержит 16 оценок на соседних 16 координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 ( могут быть восстановлены в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ).
Принцип работы 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-выборку, которая будет осуществляться не только внутри блоба, но и между блобами. Линейные свойства KZG-обязательства используются для расширения набора блобов в одном блоке, который содержит новый виртуальный список блобов с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислимых обязательств не требует наличия 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/social/moments-5d1a322bd6b6dfef0dbb780172226633d###
В нулевом байте сжатия используются два байта для замены каждой длинной последовательности нулевых байтов, чтобы указать, сколько нулевых байтов. Далее мы используем специфические свойства транзакций:
Подпись агрегирования: мы перешли от ECDSA-подписей к BLS-подписям. Особенность BLS-подписей заключается в том, что несколько подписей могут быть объединены в единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже при агрегировании, вычислительные затраты на проверку остаются высокими, поэтому использование BLS-подписей не рассматривается. Однако в L2, в такой среде с нехваткой данных, использование BLS-подписей имеет смысл. Агрегирующая функция ERC-4337 предоставляет способ реализации этой функции.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
6
Поделиться
комментарий
0/400
DeFiGrayling
· 07-27 07:00
L2 ставлю на большой Бычий рынок
Посмотреть ОригиналОтветить0
QuorumVoter
· 07-27 06:59
Смотрите, смотрите, это все старые методы.
Посмотреть ОригиналОтветить0
TestnetNomad
· 07-27 06:56
В очередной раз В-син (Vitalik Buterin) придумал что-то новое.
Виталик о будущем Ethereum: Как Surge обеспечит масштабирование до 100 000 TPS
Новая статья Виталика: возможное будущее Ethereum, The Surge
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы уровня 2. Эти два направления в конечном итоге объединились, образовав дорожную карту, сосредоточенную на Rollup, что по-прежнему является текущей стратегией масштабирования Ethereum. Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение задач: Ethereum L1 сосредотачивается на том, чтобы стать мощным и децентрализованным базовым уровнем, в то время как L2 берет на себя задачу помощи в расширении экосистемы.
В этом году важные достижения были достигнуты в дорожной карте, сосредоточенной на Rollup: с запуском 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% не может заставить плохой блок быть принятым сетью.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Другим способом решения тройной трудности является архитектура Plasma, которая использует умные технологии для передачи ответственности за доступность данных пользователям в совместимой с поощрениями манере. Еще в 2017-2019 годах, когда у нас был только механизм доказательства мошенничества для увеличения вычислительных мощностей, Plasma имела серьезные ограничения в безопасности выполнения, но с распространением SNARKs( и нулевых знаний компактных неинтерактивных доказательств) архитектура Plasma стала более жизнеспособной для гораздо более широких сценариев использования, чем когда-либо прежде.
Дальнейшие успехи в выборке доступности данных
Какую проблему мы решаем?
13 марта 2024 года, когда обновление Dencun будет запущено, в блокчейне Ethereum каждые 12 секунд будет 3 слота по 125 кБ блобов, или доступная пропускная способность данных для каждого слота составит примерно 375 кБ. Предполагая, что данные транзакций публикуются непосредственно в цепочке, то перевод ERC20 составляет около 180 байт, поэтому максимальная TPS Rollup на Ethereum составляет: 375000 / 12 / 180 = 173.6 TPS.
Если мы добавим теоретическую максимальную величину calldata Ethereum (: каждое слотов 30 миллионов Gas / каждый байт 16 gas = каждое слотов 1,875,000 байт ), то это станет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит для calldata 463-926 TPS.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель — 16 МБ на слот, если в сочетании с улучшениями сжатия данных Rollup, это приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS — это относительно простая реализация "1D sampling". В Эфире каждый blob представляет собой 4096-ю степень многочлена в 253-битом простом поле (prime field). Мы транслируем shares многочлена, где каждый share содержит 16 оценок на соседних 16 координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 ( могут быть восстановлены в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ).
Принцип работы 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-выборку, которая будет осуществляться не только внутри блоба, но и между блобами. Линейные свойства KZG-обязательства используются для расширения набора блобов в одном блоке, который содержит новый виртуальный список блобов с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислимых обязательств не требует наличия 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 теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включенных пакетов и механизмом выбора ответвлений вокруг него.
Сжатие данных
) Какую проблему мы решаем?
Каждая транзакция в Rollup занимает большое количество пространства данных в цепочке: передача ERC20 требует около 180 байт. Даже с идеальной выборкой доступности данных это ограничивает масштабируемость Layer-протокола. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Если мы сможем не только решить проблему числителя, но и решить проблему знаменателя, позволяя каждой транзакции в Rollup занимать на цепи меньше байт, что тогда будет?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение - это этот рисунок двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск]###https://img-cdn.gateio.im/social/moments-5d1a322bd6b6dfef0dbb780172226633d###
В нулевом байте сжатия используются два байта для замены каждой длинной последовательности нулевых байтов, чтобы указать, сколько нулевых байтов. Далее мы используем специфические свойства транзакций:
Подпись агрегирования: мы перешли от ECDSA-подписей к BLS-подписям. Особенность BLS-подписей заключается в том, что несколько подписей могут быть объединены в единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже при агрегировании, вычислительные затраты на проверку остаются высокими, поэтому использование BLS-подписей не рассматривается. Однако в L2, в такой среде с нехваткой данных, использование BLS-подписей имеет смысл. Агрегирующая функция ERC-4337 предоставляет способ реализации этой функции.
Использовать