Новая статья Виталика: возможное будущее Ethereum, The Surge
Сначала в дорожной карте 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 полностью унаследовали основные свойства Эфира (: доверие, открытость, антицензурирование );
Ethereum должен восприниматься как единая экосистема, а не как 34 разных блокчейна.
Содержание этой главы
Парадокс треугольника масштабируемости
Дальнейшие достижения в области выборки доступности данных
Сжатие данных
Обобщенный Плазма
Зрелая L2 система доказательств
Улучшение межоперабельности между L2
Расширение выполнения на L1
Парадокс треугольника масштабируемости
Парадокс треугольника масштабируемости — это идея, предложенная в 2017 году, которая утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, более конкретно: низкая стоимость работы узлов ), масштабируемость (, большое количество обрабатываемых транзакций ) и безопасность (, при этом злоумышленникам необходимо разрушить большую часть узлов в сети, чтобы сделать одну транзакцию недействительной ).
Стоит отметить, что треугольный парадокс не является теоремой, и в постах, представляющих треугольный парадокс, не прилагаются математические доказательства. Он действительно приводит эвристический математический аргумент: если децентрализованный дружественный узел (, например, потребительский ноутбук ) может проверять 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 Эфира (: на каждый слот 30 миллионов газа / на байт 16 газа = на каждый слот 1,875,000 байт ), то это станет 607 TPS. С использованием PeerDAS количество блобов может увеличиться до 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 возможных образцов (.
Работа 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, но и между ними. Линейные свойства KZG-призывов используются для расширения набора blob внутри блока, который включает новый виртуальный список blob с избыточным кодированием той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому эта схема в корне благоприятна для распределенного построения блоков. Узлы, которые фактически строят блоки, должны лишь обладать KZG-обязательством blob, и они могут полагаться на выборку доступности данных )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 занимать на цепочке меньше байтов, что тогда произойдет?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение - это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
В процессе сжатия нулевых байтов каждый длинный последовательность нулевых байтов заменяется на два байта, которые указывают, сколько нулевых байтов было. Более того, мы использовали определенные свойства транзакций:
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
22 Лайков
Награда
22
8
Репост
Поделиться
комментарий
0/400
BearHugger
· 08-19 09:26
Суть в том, чтобы зарабатывать деньги.
Посмотреть ОригиналОтветить0
MEVSupportGroup
· 08-17 12:40
Централизованный L2, я умираю от смеха, разве это не просто собственная база данных?
Посмотреть ОригиналОтветить0
GasWaster
· 08-17 00:14
всё ещё плачу 500 гвеи за мост... когда Луна, брат?
Посмотреть ОригиналОтветить0
ForkPrince
· 08-16 19:07
Апгрейд пути, в конечном счете, все равно для того, чтобы Будут играть для лохов в мире криптовалют.
Посмотреть ОригиналОтветить0
OnchainDetective
· 08-16 19:06
Кто-нибудь заметил, что торговая модель адреса Кошелька в статье Вита очень подозрительна? Жду анализа от коллег.
Виталик анализирует Ethereum The Surge: цель в 100 000 TPS и путь расширения L2
Новая статья Виталика: возможное будущее Ethereum, The Surge
Сначала в дорожной карте 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 полностью унаследовали основные свойства Эфира (: доверие, открытость, антицензурирование );
Ethereum должен восприниматься как единая экосистема, а не как 34 разных блокчейна.
Содержание этой главы
Парадокс треугольника масштабируемости
Парадокс треугольника масштабируемости — это идея, предложенная в 2017 году, которая утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация (, более конкретно: низкая стоимость работы узлов ), масштабируемость (, большое количество обрабатываемых транзакций ) и безопасность (, при этом злоумышленникам необходимо разрушить большую часть узлов в сети, чтобы сделать одну транзакцию недействительной ).
Стоит отметить, что треугольный парадокс не является теоремой, и в постах, представляющих треугольный парадокс, не прилагаются математические доказательства. Он действительно приводит эвристический математический аргумент: если децентрализованный дружественный узел (, например, потребительский ноутбук ) может проверять 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 Эфира (: на каждый слот 30 миллионов газа / на байт 16 газа = на каждый слот 1,875,000 байт ), то это станет 607 TPS. С использованием PeerDAS количество блобов может увеличиться до 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 возможных образцов (.
Работа 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, но и между ними. Линейные свойства KZG-призывов используются для расширения набора blob внутри блока, который включает новый виртуальный список blob с избыточным кодированием той же информации.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому эта схема в корне благоприятна для распределенного построения блоков. Узлы, которые фактически строят блоки, должны лишь обладать KZG-обязательством blob, и они могут полагаться на выборку доступности данных )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 занимать на цепочке меньше байтов, что тогда произойдет?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение - это эта картинка двухлетней давности:
! [Виталик Новая статья: Возможное будущее Ethereum, всплеск])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
В процессе сжатия нулевых байтов каждый длинный последовательность нулевых байтов заменяется на два байта, которые указывают, сколько нулевых байтов было. Более того, мы использовали определенные свойства транзакций:
Подписываем агрегат: мы