Новая статья Виталика: возможное будущее Ethereum, The Surge
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Шардирование позволяет каждому узлу проверять и хранить только часть транзакций, в то время как протоколы второго уровня строят сети поверх Ethereum, используя его безопасность, при этом большая часть данных и вычислений остается вне основной цепи. С углублением исследований эти два пути объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение труда: Ethereum L1 фокусируется на том, чтобы стать мощным и децентрализованным основным слоем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель повсюду в обществе: существование судебной системы (L1) не для достижения сверхвысокой скорости и эффективности, а для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этой прочной основе, ведя человечество к Марсу.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных результатов: с запуском EIP-4844 blobs значительно увеличена пропускная способность данных Ethereum L1, несколько виртуальных машин Ethereum (EVM) Rollup вошли в первую стадию. Каждый L2 существует как "шар", обладающий собственными внутренними правилами и логикой, разнообразие и многообразие способов реализации шаров теперь стали реальностью. Но, как мы видим, этот путь также сталкивается с некоторыми уникальными вызовами. Таким образом, нашей текущей задачей является завершение дорожной карты, сосредоточенной на Rollup, и решение этих проблем, одновременно сохраняя уникальную надежность и децентрализованность Ethereum L1.
Всплеск: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Сохраняйте децентрализованность и устойчивость L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Эфира (: доверие, открытость, устойчивость к цензуре );
Эфир должен ощущаться как единая экосистема, а не 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 будет три блоба размером около 125 кБ на каждый слот каждые 12 секунд, или доступная ширина канала данных около 375 кБ на слот. Предполагая, что данные транзакций публикуются напрямую в цепочке, перевод ERC20 составляет около 180 байт, поэтому максимальная TPS Rollup на Ethereum составит: 375000 / 12 / 180 = 173.6 TPS
Если мы добавим теоретически максимальное значение calldata Эфира (: каждый слот 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". В Ethereum каждый blob представляет собой 4096-ую полином на 253-битом простом поле (prime field). Мы транслируем доли полинома, каждая из которых содержит 16 оценочных значений от соседних 16 координат из общего числа 8192 координат. Из этих 8192 оценочных значений любые 4096 из ( на основе текущих предложенных параметров: любые 64 из 128 возможных образцов ) могут восстановить blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить нужные ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей, без дополнительных запросов к одноранговому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в механизме доказательства доли, использовали SubnetDAS, тогда как другие узлы (, то есть клиенты ), использовали PeerDAS.
С теоретической точки зрения, мы можем значительно увеличить масштаб "1D sampling": если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, при этом каждый узел в выборке доступности данных будет иметь 16 образцов * 128 blob * 512 байт на каждый blob на каждый образец = 1 МБ полосы пропускания данных на каждый слот. Это едва укладывается в наши пределы терпимости: это возможно, но это означает, что клиенты с ограниченной полосой пропускания не смогут выполнять выборку. Мы можем оптимизировать это до некоторой степени, уменьшив количество blob и увеличив размер blob, но это повысит стоимость восстановления.
Поэтому мы в конечном итоге хотим пойти дальше и провести 2D выборку (2D sampling), этот метод не только выполняет случайную выборку внутри blob, но и выполняет случайную выборку между blob. Используя линейные свойства KZG-коммитментов, мы расширяем набор blob в блоке с помощью набора новых виртуальных blob, которые избыточно кодируют ту же информацию.
Таким образом, в конечном итоге мы хотим сделать шаг дальше и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между blob. Линейные свойства KZG-подписей используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход по своей сути дружелюбен к распределенному строительству блоков. Узлы, фактически строящие блоки, просто должны иметь KZG-обязательства blob и могут полагаться на выборку доступности данных (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 теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включенных пакетов и механизмом выбора ветки вокруг него.
![Виталик новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp###
Сжатие данных
( Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много места на цепочке данных: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость Layer протокола. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблему числителя, но и решить проблему знаменателя, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/social/moments-5d1a322bd6b6dfef0dbb780172226633d###
В процессе сжатия нулевых байтов каждый длинный последовательность нулевых байтов заменяется двумя байтами, которые указывают, сколько нулевых байтов содержится. Более того, мы использовали специфические свойства транзакций:
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
15 Лайков
Награда
15
4
Поделиться
комментарий
0/400
CryptoTarotReader
· 07-22 16:59
Эта волна L2 должна На луну啊
Посмотреть ОригиналОтветить0
NightAirdropper
· 07-22 05:24
Ган Ди V Шэнь снова начал рисовать BTC.
Посмотреть ОригиналОтветить0
LayerZeroHero
· 07-19 20:54
Данные не могут убежать. Стратегия разделения труда неизбежно приведет к rollup.
Посмотреть ОригиналОтветить0
SilentObserver
· 07-19 20:50
Что может изменить V-бог, если только говорить и не практиковаться
Виталик интерпретирует будущее Ethereum: Прорыв стратегии The Surge и тройной трудности масштабирования
Новая статья Виталика: возможное будущее Ethereum, The Surge
Дорожная карта Ethereum изначально включала две стратегии масштабирования: шардирование и протоколы второго уровня. Шардирование позволяет каждому узлу проверять и хранить только часть транзакций, в то время как протоколы второго уровня строят сети поверх Ethereum, используя его безопасность, при этом большая часть данных и вычислений остается вне основной цепи. С углублением исследований эти два пути объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простое распределение труда: Ethereum L1 фокусируется на том, чтобы стать мощным и децентрализованным основным слоем, в то время как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель повсюду в обществе: существование судебной системы (L1) не для достижения сверхвысокой скорости и эффективности, а для защиты контрактов и прав собственности, в то время как предприниматели (L2) строят на этой прочной основе, ведя человечество к Марсу.
В этом году дорожная карта, сосредоточенная на Rollup, достигла значительных результатов: с запуском EIP-4844 blobs значительно увеличена пропускная способность данных Ethereum L1, несколько виртуальных машин Ethereum (EVM) Rollup вошли в первую стадию. Каждый L2 существует как "шар", обладающий собственными внутренними правилами и логикой, разнообразие и многообразие способов реализации шаров теперь стали реальностью. Но, как мы видим, этот путь также сталкивается с некоторыми уникальными вызовами. Таким образом, нашей текущей задачей является завершение дорожной карты, сосредоточенной на Rollup, и решение этих проблем, одновременно сохраняя уникальную надежность и децентрализованность Ethereum L1.
Всплеск: ключевая цель
В будущем Ethereum сможет достичь более 100000 TPS через L2;
Сохраняйте децентрализованность и устойчивость L1;
По крайней мере, некоторые L2 полностью унаследовали основные свойства Эфира (: доверие, открытость, устойчивость к цензуре );
Эфир должен ощущаться как единая экосистема, а не 34 различных блокчейна.
Содержание этой главы
Парадокс треугольника масштабируемости
Парадокс треугольника масштабируемости — это идея, выдвинутая в 2017 году, которая утверждает, что существует противоречие между тремя характеристиками блокчейна: децентрализация (, а именно: низкая стоимость работы узлов ), масштабируемость (, количество обрабатываемых транзакций ) и безопасность (, при которой злоумышленнику необходимо разрушить значительную часть узлов в сети, чтобы сделать одну транзакцию недействительной ).
Стоит заметить, что треугольный парадокс не является теоремой, а посты, вводящие в треугольный парадокс, также не содержат математических доказательств. Он действительно предлагает эвристический математический аргумент: если децентрализованный дружелюбный узел (, например, потребительский ноутбук ), может проверять 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 будет три блоба размером около 125 кБ на каждый слот каждые 12 секунд, или доступная ширина канала данных около 375 кБ на слот. Предполагая, что данные транзакций публикуются напрямую в цепочке, перевод ERC20 составляет около 180 байт, поэтому максимальная TPS Rollup на Ethereum составит: 375000 / 12 / 180 = 173.6 TPS
Если мы добавим теоретически максимальное значение calldata Эфира (: каждый слот 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". В Ethereum каждый blob представляет собой 4096-ую полином на 253-битом простом поле (prime field). Мы транслируем доли полинома, каждая из которых содержит 16 оценочных значений от соседних 16 координат из общего числа 8192 координат. Из этих 8192 оценочных значений любые 4096 из ( на основе текущих предложенных параметров: любые 64 из 128 возможных образцов ) могут восстановить blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить нужные ему blob из других подсетей. Более консервативная версия SubnetDAS использует только механизм подсетей, без дополнительных запросов к одноранговому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в механизме доказательства доли, использовали SubnetDAS, тогда как другие узлы (, то есть клиенты ), использовали PeerDAS.
С теоретической точки зрения, мы можем значительно увеличить масштаб "1D sampling": если мы увеличим максимальное количество blob до 256( с целью 128), то мы сможем достичь цели в 16 МБ, при этом каждый узел в выборке доступности данных будет иметь 16 образцов * 128 blob * 512 байт на каждый blob на каждый образец = 1 МБ полосы пропускания данных на каждый слот. Это едва укладывается в наши пределы терпимости: это возможно, но это означает, что клиенты с ограниченной полосой пропускания не смогут выполнять выборку. Мы можем оптимизировать это до некоторой степени, уменьшив количество blob и увеличив размер blob, но это повысит стоимость восстановления.
Поэтому мы в конечном итоге хотим пойти дальше и провести 2D выборку (2D sampling), этот метод не только выполняет случайную выборку внутри blob, но и выполняет случайную выборку между blob. Используя линейные свойства KZG-коммитментов, мы расширяем набор blob в блоке с помощью набора новых виртуальных blob, которые избыточно кодируют ту же информацию.
Таким образом, в конечном итоге мы хотим сделать шаг дальше и провести 2D-выборку, которая будет осуществляться не только внутри blob, но и между blob. Линейные свойства KZG-подписей используются для расширения набора blob в блоке, который содержит новый виртуальный список blob с избыточным кодированием одной и той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход по своей сути дружелюбен к распределенному строительству блоков. Узлы, фактически строящие блоки, просто должны иметь KZG-обязательства blob и могут полагаться на выборку доступности данных (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 теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включенных пакетов и механизмом выбора ветки вокруг него.
![Виталик новая статья: возможное будущее Эфира, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp###
Сжатие данных
( Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много места на цепочке данных: передача ERC20 требует около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость Layer протокола. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем не только решить проблему числителя, но и решить проблему знаменателя, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/social/moments-5d1a322bd6b6dfef0dbb780172226633d###
В процессе сжатия нулевых байтов каждый длинный последовательность нулевых байтов заменяется двумя байтами, которые указывают, сколько нулевых байтов содержится. Более того, мы использовали специфические свойства транзакций:
Подпись агрегирования: мы от ECD