В первоначальной дорожной карте Ethereum было две стратегии масштабирования: шардирование и протоколы второго уровня. Эти два направления в конечном итоге объединились, образовав дорожную карту, сосредоточенную на 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 различных блокчейна.
Треугольник парадокса масштабируемости
Треугольник масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, а именно: низкие затраты на работу узлов ), масштабируемость (, количество обрабатываемых транзакций ) и безопасность (, злоумышленник должен уничтожить значительную часть узлов в сети, чтобы сделать одну транзакцию неудачной ).
Важно отметить, что треугольный парадокс не является теоремой, и посты, представляющие треугольный парадокс, не сопровождаются математическим доказательством. Он действительно предлагает эвристический математический аргумент: если децентрализованный узел (, например, потребительский ноутбук ) может проверять 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 миллионов газа / каждый байт 16 газа = каждый слот 1,875,000 байт ), то это станет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, и если совместить это с улучшением сжатия данных Rollup, это даст ~58000 TPS.
Что это? Как это работает?
PeerDAS является относительно простым реализацией "1D sampling". В Ethereum каждый blob представляет собой 4096-ю степень многочлена в 253-ем простом поле (. Мы транслируем доли многочлена, каждая из которых содержит 16 оценок на соседних 16 координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 ) в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ( могут восстановить blob.
Работа PeerDAS заключается в том, что каждый клиент прослушивает небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у пиров в глобальной p2p сети ), кто будет слушать разные подсети (, чтобы запросить необходимые ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к уровню пиров. ТекущаяProposal заключается в том, чтобы узлы, участвующие в доказательстве доли, использовали SubnetDAS, тогда как другие узлы ), то есть клиенты (, использовали PeerDAS.
Теоретически, мы можем значительно увеличить масштаб "1D sampling": если мы увеличим максимальное количество blob до 256), а цель составит 128(, то мы сможем достичь цели в 16 МБ, где доступность данных для выборки на каждом узле составляет 16 образцов * 128 blob * 512 байт на образец для каждого blob = 1 МБ пропускной способности данных на слот. Это едва укладывается в наши пределы терпимости: это возможно, но это означает, что клиенты с ограниченной пропускной способностью не смогут проводить выборку. Мы можем оптимизировать это до некоторой степени, уменьшив количество blob и увеличив их размер, но это приведет к более высоким затратам на восстановление.
Таким образом, мы в конечном итоге хотим продвинуться дальше и провести 2D выборку )2D sampling(. Этот метод не только выполняет случайную выборку внутри blob, но и между blob. Используя линейные свойства KZG-обязательства, мы расширяем набор blob в блоке за счет набора новых виртуальных blob, которые избыточно кодируют одну и ту же информацию.
Таким образом, в конечном итоге мы хотим сделать шаг вперед, провести 2D-образцы, которые будут случайно отбираться не только внутри blob, но и между blob. Линейные свойства KZG-обязательства используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение в корне дружелюбно к распределенному строительству блоков. Узлы, фактически строящие блоки, должны обладать blob KZG обязательством, и они могут полагаться на выборку доступности данных )DAS( для проверки доступности блоков данных. Одномерная выборка доступности данных )1D DAS( также в сущности дружелюбна к распределенному строительству блоков.
![Виталик новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) Что еще нужно сделать? Какие есть компромиссы?
Следующим шагом является завершение реализации и запуска 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 занимала меньше байт в цепочке?
( Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это эта картинка двухлетней давности:
![Виталик новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
В процессе сжатия нулевых байтов каждый длинный нулевой байтовый последователь заменяется двумя байтами, которые указывают, сколько нулевых байтов содержится. Более того, мы воспользовались определенными свойствами транзакции:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенность подписей BLS заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже с агрегацией, вычислительная стоимость проверки остается высокой, поэтому использование подписей BLS не рассматривается. Однако в L2, где данные ограничены, использование подписей BLS имеет смысл. Агрегационная функция ERC-4337 предоставляет путь для реализации этой возможности.
Замена адресов на указатели: если мы раньше использовали какой-то адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в истории.
Пользовательская последовательность значения транзакции
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
19 Лайков
Награда
19
9
Поделиться
комментарий
0/400
HashBard
· 07-19 15:02
сер... роллапы как поэзия в движении fr fr. бычий на этом скачке нарратива ngl
Посмотреть ОригиналОтветить0
FUDwatcher
· 07-19 07:32
Чонг Я наконец-то сможет получить дешевый Газ.
Посмотреть ОригиналОтветить0
MemeCurator
· 07-17 19:11
Эта волна l2 снова собирается На луну.
Посмотреть ОригиналОтветить0
ImpermanentPhobia
· 07-17 03:56
v确实猛 L2На луну了属于是
Посмотреть ОригиналОтветить0
DAOdreamer
· 07-17 03:56
Rollup пришел, и ты все еще не На луну?
Посмотреть ОригиналОтветить0
GateUser-5854de8b
· 07-17 03:54
Этот брат В снова выпустил что-то новое.
Посмотреть ОригиналОтветить0
SelfRugger
· 07-17 03:53
Виталик действительно прав, что придерживается L2.
Ethereum Взрыв: новая стратегия масштабирования, сосредоточенная на Rollup
Будущее Эфира: The Surge
В первоначальной дорожной карте Ethereum было две стратегии масштабирования: шардирование и протоколы второго уровня. Эти два направления в конечном итоге объединились, образовав дорожную карту, сосредоточенную на 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 различных блокчейна.
Треугольник парадокса масштабируемости
Треугольник масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, а именно: низкие затраты на работу узлов ), масштабируемость (, количество обрабатываемых транзакций ) и безопасность (, злоумышленник должен уничтожить значительную часть узлов в сети, чтобы сделать одну транзакцию неудачной ).
Важно отметить, что треугольный парадокс не является теоремой, и посты, представляющие треугольный парадокс, не сопровождаются математическим доказательством. Он действительно предлагает эвристический математический аргумент: если децентрализованный узел (, например, потребительский ноутбук ) может проверять 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 миллионов газа / каждый байт 16 газа = каждый слот 1,875,000 байт ), то это станет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, и если совместить это с улучшением сжатия данных Rollup, это даст ~58000 TPS.
Что это? Как это работает?
PeerDAS является относительно простым реализацией "1D sampling". В Ethereum каждый blob представляет собой 4096-ю степень многочлена в 253-ем простом поле (. Мы транслируем доли многочлена, каждая из которых содержит 16 оценок на соседних 16 координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 ) в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ( могут восстановить blob.
Работа PeerDAS заключается в том, что каждый клиент прослушивает небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у пиров в глобальной p2p сети ), кто будет слушать разные подсети (, чтобы запросить необходимые ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к уровню пиров. ТекущаяProposal заключается в том, чтобы узлы, участвующие в доказательстве доли, использовали SubnetDAS, тогда как другие узлы ), то есть клиенты (, использовали PeerDAS.
Теоретически, мы можем значительно увеличить масштаб "1D sampling": если мы увеличим максимальное количество blob до 256), а цель составит 128(, то мы сможем достичь цели в 16 МБ, где доступность данных для выборки на каждом узле составляет 16 образцов * 128 blob * 512 байт на образец для каждого blob = 1 МБ пропускной способности данных на слот. Это едва укладывается в наши пределы терпимости: это возможно, но это означает, что клиенты с ограниченной пропускной способностью не смогут проводить выборку. Мы можем оптимизировать это до некоторой степени, уменьшив количество blob и увеличив их размер, но это приведет к более высоким затратам на восстановление.
Таким образом, мы в конечном итоге хотим продвинуться дальше и провести 2D выборку )2D sampling(. Этот метод не только выполняет случайную выборку внутри blob, но и между blob. Используя линейные свойства KZG-обязательства, мы расширяем набор blob в блоке за счет набора новых виртуальных blob, которые избыточно кодируют одну и ту же информацию.
Таким образом, в конечном итоге мы хотим сделать шаг вперед, провести 2D-образцы, которые будут случайно отбираться не только внутри blob, но и между blob. Линейные свойства KZG-обязательства используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому это решение в корне дружелюбно к распределенному строительству блоков. Узлы, фактически строящие блоки, должны обладать blob KZG обязательством, и они могут полагаться на выборку доступности данных )DAS( для проверки доступности блоков данных. Одномерная выборка доступности данных )1D DAS( также в сущности дружелюбна к распределенному строительству блоков.
![Виталик новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) Что еще нужно сделать? Какие есть компромиссы?
Следующим шагом является завершение реализации и запуска PeerDAS. После этого необходимо постоянно увеличивать количество blob на PeerDAS, внимательно следя за сетью и улучшая программное обеспечение для обеспечения безопасности; это постепенный процесс. В то же время мы надеемся на большее количество научных работ, направленных на нормализацию PeerDAS и других версий DAS, а также их взаимодействие с такими вопросами, как безопасность правил выбора ветвления.
На более дальних этапах в будущем нам потребуется проделать больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к квантово-безопасной альтернативе, не требующей доверенной настройки. В настоящее время нам неясно, какие кандидаты являются дружелюбными к распределенному строительству блоков. Даже использование дорогостоящей технологии "грубой силы", то есть использование рекурсивного STARK для генерации доказательств действительности, необходимых для воссоздания строк и столбцов, не хватает, поскольку, хотя технически размер одного STARK составляет O(log)n### * log(log(n)( хэш-значение ( с использованием STIR), на самом деле STARK почти такого же размера, как весь blob.
Я думаю, что долгосрочный реалистичный путь таков:
Обратите внимание, что даже если мы решим непосредственно расширить выполнение на уровне L1, этот выбор все равно существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их корректности, поэтому нам придется использовать на уровне L1 те же технологии, что и в Rollup), такие как ZK-EVM и DAS(.
) Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 2D DAS уменьшится или, по крайней мере, будет отложена. Если Plasma будет широко использоваться, потребность еще больше снизится. DAS также ставит перед протоколами и механизмами распределенного построения блоков определенные вызовы: хотя DAS теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включения пакетов и механизмом выбора форков вокруг него.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много места в цепочке: передача ERC20 требует примерно 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость Layer-протоколов. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблему числителя, но и проблему знаменателя, чтобы каждая транзакция в Rollup занимала меньше байт в цепочке?
( Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это эта картинка двухлетней давности:
![Виталик новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
В процессе сжатия нулевых байтов каждый длинный нулевой байтовый последователь заменяется двумя байтами, которые указывают, сколько нулевых байтов содержится. Более того, мы воспользовались определенными свойствами транзакции:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенность подписей BLS заключается в том, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже с агрегацией, вычислительная стоимость проверки остается высокой, поэтому использование подписей BLS не рассматривается. Однако в L2, где данные ограничены, использование подписей BLS имеет смысл. Агрегационная функция ERC-4337 предоставляет путь для реализации этой возможности.
Замена адресов на указатели: если мы раньше использовали какой-то адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в истории.
Пользовательская последовательность значения транзакции