Путь BNB Chain к большим блокам

Дорога больших блоков в цепи BNB

Подобно Solana, Heco и другим публичным цепочкам, поддерживаемым биржами, публичная цепочка BNB Chain BNB Smart Chain (BSC) уже давно стремится к высокой производительности. С момента запуска в 2020 году BSC установила лимит газовой мощности для каждого блока на уровне 30 миллионов, а стабильный интервал между блоками составляет 3 секунды. С такими параметрами BSC достигла максимального TPS (TPS с различными транзакциями, смешанными вместе) более 100. В июне 2021 года лимит блочного газа BSC был увеличен до 60 миллионов. Однако в июле того же года на BSC взорвалась цепная игра под названием CryptoBlades, в результате чего ежедневный объем транзакций превысил 8 миллионов и привел к стремительному росту комиссионных сборов. Оказалось, что в то время узкое место в эффективности BSC было еще вполне очевидным.

(Источник: BscScan)

Чтобы решить проблемы с производительностью сети, BSC еще раз повысила лимит газа для каждого блока, который долгое время оставался стабильным на уровне 80-85 миллионов. В сентябре 2022 года лимит газа на блок BSC Chain был увеличен до 120 миллионов, а к концу года он был повышен до 140 миллионов, что почти в пять раз больше, чем в 2020 году. Ранее BSC планировала увеличить лимит газовой емкости блока до 300 миллионов, но, возможно, учитывая большую нагрузку на узлы валидатора, предложение о таких сверхбольших блоках не было реализовано.

источник: YCHARTS

В дальнейшем BNB Chain, похоже, больше сосредоточились на модульном/Layer2-треке, чем на расширении Layer1. Это намерение становилось все более очевидным, начиная с запуска zkBNB во второй половине прошлого года и заканчивая GreenField в начале этого года. Исходя из сильного интереса к модульному блокчейну/Layer2, автор этой статьи использует opBNB в качестве объекта исследования, чтобы выявить узкие места в производительности Rollup, сравнивая его с Ethereum Layer2.

Повышение высокой пропускной способности BSC до уровня DA opBNB

Как мы все знаем, Celestia выделила четыре ключевых компонента в соответствии с рабочим процессом модульного блокчейна: Уровень исполнения (Execution Layer): Выполняет код контракта и завершает переходы состояний; Расчетный уровень (Settlement Layer): Обрабатывает доказательства мошенничества/доказательства действительности и решает вопросы, связанные с соединением между L2 и L1. Уровень консенсуса: Достижение консенсуса по упорядочиванию транзакций. Уровень доступности данных (DA): Публикует данные, связанные с книгой блокчейн, позволяя валидаторам загружать эти данные.

Среди них уровень DA часто сочетается с уровнем консенсуса. Например, данные DA Optimistic Rollup содержат пакет последовательностей транзакций в блоках L2. Когда полные узлы L2 получают данные DA, они знают порядок каждой транзакции в этой партии. (По этой причине сообщество Ethereum считает, что слой DA и слой консенсуса связаны при наслоении Rollup).

Однако для Ethereum Layer2 пропускная способность данных на уровне DA (Ethereum) стала самым большим узким местом, ограничивающим производительность Rollup. Это происходит потому, что текущая пропускная способность Ethereum слишком мала, что вынуждает Rollup максимально подавлять TPS, чтобы мейннет Ethereum не смог выдержать данные, генерируемые L2. В то же время, низкая пропускная способность данных приводит к тому, что большое количество инструкций транзакций в сети Ethereum находится в состоянии ожидания, что приводит к тому, что плата за газ достигает чрезвычайно высоких уровней и еще больше увеличивает стоимость публикации данных для Layer2. Наконец, многие сети Layer2 вынуждены внедрять уровни DA за пределами Ethereum, например, Celestia, а opBNB, которая находится рядом с водой, решила напрямую использовать высокую пропускную способность BSC для внедрения DA, чтобы решить проблему узкого места в публикации данных. Для простоты понимания давайте представим метод публикации данных DA для Rollup. Если взять в качестве примера Arbitrum, то цепочка Ethereum, управляемая адресом EOA секвенсора Layer2, будет периодически отправлять транзакции указанному контракту. Во входных параметрах calldata этой инструкции записываются данные упакованной транзакции, и запускаются соответствующие события на цепи, оставляя постоянную запись в журнале контрактов.

Таким образом, данные о транзакциях Layer2 хранятся в блоках Ethereum в течение длительного времени. Люди, способные управлять узлами L2, могут загружать соответствующие записи и анализировать соответствующие данные, но сами узлы Ethereum не выполняют эти транзакции L2. Легко заметить, что L2 хранит данные о транзакциях только в блоках Ethereum, неся расходы на хранение, в то время как вычислительные расходы на выполнение транзакций несут сами узлы L2. Вышеупомянутый способ является методом реализации DA от Arbitrum, в то время как Optimism использует адрес EOA, контролируемый секвенсором, для передачи на другой указанный адрес EOA, неся в дополнительных данных новую партию данных транзакции уровня 2. Что касается opBNB, который использует стек OP, то его метод публикации данных DA в основном такой же, как и у Optimism.

Очевидно, что пропускная способность уровня DA будет ограничивать размер данных, которые Rollup может опубликовать в единицу времени, тем самым ограничивая TPS. Учитывая, что после EIP1559 производительность каждого блока ETH стабилизировалась на уровне 30 миллионов, а время блока после слияния составляет около 12 секунд, Ethereum может обрабатывать максимум только 2,5 миллиона газа в секунду. В большинстве случаев на каждый байт в calldata расходуется 16 единиц газа, потребляемого при размещении данных транзакций L2, поэтому Ethereum может обрабатывать максимальный размер calldata всего 150 КБ в секунду. В отличие от этого, максимальный средний размер обрабатываемых в секунду calldata у BSC составляет около 2910 КБ, что в 18,6 раз больше, чем у Ethereum. Разница между этими двумя слоями DA очевидна.

Подводя итог, можно сказать, что Ethereum может передавать около 150 КБ данных транзакций L2 в секунду. Даже после запуска EIP 4844 это число не сильно изменится, только уменьшится плата за DA. Так сколько же данных о транзакциях можно уместить в 150 КБ в секунду? Здесь нам нужно объяснить степень сжатия данных в Rollup. Виталик был слишком оптимистичен в 2021 году, оценивая, что Optimistic Rollup может сжать размер данных транзакции до 11% от исходного размера. Например, базовый перевод ETH, первоначально занимавший размер calldata в 112 байт, может быть сжат до 12 байт с помощью оптимистического сворачивания, перевод ERC-20 может быть сжат до 16 байт, а транзакции Swap на Uniswap - до 14 байт. По его оценке, Ethereum может регистрировать около 10 000 транзакций L2 в секунду (с различными типами, смешанными вместе). Однако, согласно данным, обнародованным командой Optimism в 2022 году, реальная степень сжатия данных может достигать максимум лишь около 37%, что в 3,5 раза ниже оценки Виталика.

(Оценка Виталиком эффекта масштабируемости Rollup значительно отклоняется от реальных условий)

(Фактическая степень сжатия, достигнутая различными алгоритмами сжатия, раскрытыми Optimism)

Поэтому давайте приведем разумную цифру: даже если Ethereum достигнет своего предела пропускной способности, максимальный TPS всех оптимистичных роллапов вместе взятых составит лишь немногим более 2000. Другими словами, если бы блоки Ethereum полностью использовались для переноса данных, публикуемых оптимистическими роллапами, такими как те, что распределены между Arbitrum, Optimism, Base и Boba, совокупный TPS этих оптимистических роллапов не достиг бы и 3000, даже при использовании самых эффективных алгоритмов сжатия. Кроме того, следует учесть, что после EIP1559 газовая мощность каждого блока составляет в среднем лишь 50% от максимального значения, поэтому указанное выше число должно быть уменьшено вдвое. После запуска EIP4844, хотя плата за публикацию данных будет значительно снижена, максимальный размер блока Ethereum сильно не изменится (поскольку слишком сильное изменение повлияет на безопасность главной цепи ETH), поэтому расчетная стоимость, приведенная выше, не сильно изменится.

По данным Arbiscan и Etherscan, партия транзакций на Arbitrum содержит 1115 транзакций, потребляя 1,81 млн. газа на Ethereum. По экстраполяции, если слой DA заполняется в каждом блоке, теоретический предел TPS Arbitrum составляет приблизительно 1500. Конечно, учитывая проблему реорганизации блока L1, Arbitrum не может публиковать партии транзакций по каждому блоку Ethereum, поэтому приведенные выше цифры на данный момент являются лишь теоретическими. Кроме того, с широким распространением смарт-кошельков, связанных с EIP 4337, проблема DA станет еще более острой. Поскольку с поддержкой EIP 4337 способ подтверждения личности пользователя может быть изменен, например, загрузка двоичных данных отпечатков пальцев или радужной оболочки глаза, что еще больше увеличит объем данных, занимаемых обычными транзакциями. Поэтому низкая пропускная способность данных Ethereum является самым большим узким местом, ограничивающим эффективность Rollup, и эта проблема может быть не решена должным образом в течение длительного времени. С другой стороны, в BNB Chain публичной цепочки BSC максимальный средний размер calldata, обрабатываемых в секунду, составляет приблизительно 2910 КБ, что в 18,6 раз больше, чем у Ethereum. Другими словами, до тех пор, пока исполнительный уровень может идти в ногу со временем, теоретический верхний предел TPS Уровня2 в экосистеме BNB Chain может достигать примерно 18 раз по сравнению с ARB или OP. Это число рассчитано на основе текущей максимальной мощности блокчейна BNB Chain, равной 140 миллионам, при времени блокировки 3 секунды.

Другими словами, текущий совокупный лимит TPS всех роллапов в экосистеме BNB Chain в 18,6 раз больше, чем у Ethereum (даже с учетом ZKRollup). С этой точки зрения легко понять, почему так много проектов Layer2 используют для публикации данных уровень DA в цепочке Ethereum, поскольку разница вполне очевидна. Однако вопрос не так прост. Помимо проблемы пропускной способности данных, стабильность самого Layer1 также может влиять на Layer2. Например, большинство ролловеров часто ждут несколько минут, прежде чем опубликовать пакет транзакций в Ethereum, учитывая возможность реорганизации блока Layer1. Если блок уровня 1 будет реорганизован, это повлияет на блокчейн уровня 2. Поэтому секвенсор будет ждать публикации нескольких новых блоков Layer1 после каждого выпуска партии транзакций L2, что значительно снижает вероятность отката блока, прежде чем опубликовать следующую партию транзакций L2. Это фактически задерживает время окончательного подтверждения блоков L2, снижая скорость подтверждения крупных транзакций (крупные транзакции требуют необратимых результатов для обеспечения безопасности). В общем, транзакции, происходящие в L2, становятся необратимыми только после публикации в блоках уровня DA и после того, как уровень DA сгенерирует определенное количество новых блоков. Это важная причина, ограничивающая производительность Rollup. Однако скорость генерации блоков у Ethereum невысока: на создание блока уходит 12 секунд. Если предположить, что Rollup публикует партию транзакций L2 каждые 15 блоков, то между разными партиями будет 3-минутный интервал, а после публикации каждой партии ему еще нужно подождать, пока сгенерируется несколько блоков уровня L1, прежде чем они станут необратимыми (при условии, что они не будут оспорены). Очевидно, что время от инициации до необратимости транзакций на Уровне2 Ethereum довольно велико, что приводит к низкой скорости расчетов; в то время как BNB Chain требуется всего 3 секунды для создания блока, а блоки становятся необратимыми всего за 45 секунд (время, необходимое для создания 15 новых блоков). Исходя из текущих параметров, предполагая одинаковое количество транзакций L2 и учитывая необратимость блоков L1, количество раз, которое opBNB может опубликовать данные о транзакциях в единицу времени, может достигать 8,53 раза по сравнению с Arbitrum (раз в 45 секунд для первого и раз в 6,4 минуты для второго). Очевидно, что скорость расчетов по крупным транзакциям на opBNB намного выше, чем на Layer2 Ethereum. Кроме того, максимальный размер данных, публикуемых opBNB каждый раз, может достигать 4,66 раза больше, чем у Ethereum's Layer2 (ограничение по объему газа блока L1 у первого составляет 140 миллионов, а у второго - 30 миллионов). 8.53 * 4.66 = 39.74. Это представляет собой разрыв между opBNB и Arbitrum с точки зрения предельного TPS в практической реализации (в настоящее время, в целях безопасности, ARB, похоже, активно снижает TPS, но теоретически, если TPS будет увеличен, он все равно будет во много раз ниже по сравнению с opBNB).

(Секвенсор Arbitrum публикует пакет транзакций каждые 6-7 минут)

(Секвенсор opBNB публикует пакет транзакций каждые 1-2 минуты, причем самая быстрая занимает всего 45 секунд). Конечно, необходимо учитывать еще один важный момент, а именно плату за газ в слое DA. Каждый раз, когда L2 публикует пакет транзакций, существует фиксированная стоимость 21 000 газа, не связанная с размером calldata, что является расходом. Если плата за газ для уровня DA/L1 высока, в результате чего постоянные затраты на публикацию пакета транзакций на L2 остаются высокими, секвенсор снизит частоту публикации пакетов транзакций. Кроме того, при рассмотрении компонентов комиссии L2 затраты на уровне исполнения очень малы, и их часто можно игнорировать, сосредоточившись только на влиянии затрат DA на комиссию за транзакцию. В итоге, хотя публикация calldata одинакового размера потребляет одинаковое количество газа на Ethereum и BNB Chain, цена газа, взимаемая с Ethereum, примерно в 10 - десятки раз выше, чем у BNB Chain. В пересчете на комиссию за транзакции L2, текущие комиссии за пользовательские транзакции на Ethereum Layer2 также примерно в 10 - десятки раз выше, чем на opBNB. В целом, различия между opBNB и Optimistic Rollup на Ethereum довольно очевидны.

(Транзакция, потребляющая 150 000 газа на Оптимизме, стоит $0,21)

(Транзакция, потребляющая 130 000 газа на opBNB, стоит $0,004) Однако увеличение пропускной способности уровня DA, хотя и может повысить общую пропускную способность системы Layer2, все же имеет ограниченное влияние на повышение производительности отдельных Rollups. Это происходит потому, что уровень выполнения часто не обрабатывает транзакции достаточно быстро. Даже если ограничения уровня DA можно игнорировать, уровень выполнения становится следующим узким местом, влияющим на производительность Rollup. Если скорость исполнения на уровне исполнения Layer2 низкая, переполнение спроса на транзакции распространится на другие Layer2, что в конечном итоге приведет к фрагментации ликвидности. Поэтому повышение производительности уровня исполнения также имеет решающее значение, поскольку он служит еще одним порогом над уровнем DA.

opBNB's Boost на уровне исполнения: Оптимизация кэша

Когда большинство людей обсуждают узкие места в производительности уровней исполнения блокчейна, они неизбежно упоминают два важных узких места: однопоточное последовательное исполнение EVM, которое не позволяет полностью использовать центральный процессор, и неэффективный поиск данных в трие Меркла Патриция, принятый в Ethereum. По сути, стратегии масштабирования для уровня выполнения сводятся к более эффективному использованию ресурсов ЦП и обеспечению максимально быстрого доступа ЦП к данным.

Оптимизационные решения для последовательного выполнения EVM и Merkle Patricia Trie часто сложны и трудны в реализации, в то время как более экономичные усилия обычно направлены на оптимизацию кэша. На самом деле, оптимизация кэша возвращает нас к вопросам, часто обсуждаемым в традиционных контекстах Web2 и даже в учебниках.

Как правило, скорость, с которой процессор извлекает данные из памяти, в сотни раз выше, чем скорость извлечения данных с диска. Например, выборка данных из памяти может занять всего 0,1 секунды, а выборка с диска - 10 секунд. Поэтому снижение накладных расходов, связанных с чтением и записью на диск, т.е. оптимизация кэша, становится важным аспектом оптимизации уровня исполнения блокчейна.

В Ethereum и большинстве других публичных цепочек база данных, в которой записываются состояния адресов в цепочке, хранится полностью на диске, а так называемый World State trie - это просто индекс этой базы данных или каталог, используемый для поиска данных. Каждый раз, когда EVM выполняет контракт, ему необходимо получить доступ к соответствующим состояниям адресов. Получение данных из дисковой базы данных по одному значительно замедлило бы выполнение транзакции. Поэтому создание кэша вне базы данных/диска является необходимым средством повышения скорости.

opBNB напрямую использует решение по оптимизации кэша, применяемое в BNB Chain. Согласно информации, предоставленной партнером opBNB, компанией NodeReal, самая ранняя цепочка BSC устанавливала три уровня кэша между EVM и базой данных LevelDB, хранящей состояние. Концепция дизайна похожа на традиционные трехуровневые кэши, где данные с более высокой частотой доступа хранятся в кэше. Это позволяет процессору сначала найти нужные данные в кэше. Если процент попадания в кэш достаточно высок, процессору не нужно слишком полагаться на диск для получения данных, что приводит к значительному повышению общей скорости выполнения.

Позже компания NodeReal добавила к этому функцию, которая использует неиспользуемые ядра процессора для упреждающего считывания данных, которые EVM нужно будет обработать в будущем, из базы данных и хранения их в кэше. Эта функция называется "предварительная загрузка состояния".

Принцип предварительной загрузки состояния прост: центральные процессоры узлов блокчейна являются многоядерными, в то время как EVM работает в однопоточном режиме последовательного выполнения, используя только одно ядро процессора, оставляя другие ядра процессора недоиспользованными. Чтобы решить эту проблему, ядра CPU, которые не используются EVM, могут помогать в выполнении задач, предсказывая данные, которые понадобятся EVM из еще не обработанной последовательности транзакций. Эти ядра CPU, находящиеся вне EVM, будут извлекать из базы данных те данные, которые понадобятся EVM, помогая EVM сократить накладные расходы на поиск данных и тем самым ускоряя выполнение.

Благодаря оптимизации кэш-памяти и достаточным аппаратным конфигурациям, компания opBNB добилась того, что производительность уровня исполнения ее узла приблизилась к пределу EVM, обрабатывая до 100 миллионов газов в секунду. Эти 100 миллионов газа - по сути, предел производительности немодифицированного EVM, что подтверждается данными экспериментальных испытаний, проведенных известной публичной сетью.

Если говорить кратко, то opBNB может обрабатывать до 4761 простых переводов в секунду, 15003000 переводов токенов ERC20 в секунду и примерно 5001000 операций SWAP в секунду, основываясь на данных о транзакциях, наблюдаемых на блокчейн-исследователях. Если сравнивать текущие параметры, то предел TPS opBNB в 40 раз больше, чем у Ethereum, более чем в 2 раза больше, чем у BNB Chain, и более чем в 6 раз больше, чем у Optimism.

Конечно, для решений Ethereum Layer2 из-за серьезных ограничений самого уровня DA производительность значительно снижается по сравнению с производительностью уровня исполнения, если учитывать такие факторы, как время генерации блоков уровня DA и стабильность.

Для BNB Chain с высокопроизводительным уровнем DA, таким как opBNB, удвоение эффекта масштабирования очень ценно, особенно если учесть, что BNB Chain может принимать несколько подобных проектов масштабирования. Можно предположить, что BNB Chain уже включила решения Layer2 под руководством opBNB в свои стратегические планы и продолжит работу над новыми модульными блокчейн-проектами, включая внедрение ZK-доказательств в opBNB и обеспечение высокой доступности DA-слоев с дополнительной инфраструктурой, такой как GreenField, в попытке конкурировать или сотрудничать с экосистемой Ethereum Layer2.

В эпоху, когда многоуровневое масштабирование стало трендом, поспешат ли другие публичные сети также поддержать свои собственные проекты Layer2, пока неясно, но, несомненно, смена парадигмы в сторону модульной блокчейн-инфраструктуры уже происходит.

Отказ от ответственности：

1. Эта статья перепечатана с сайта[极客 Web3], все авторские права принадлежат автору оригинала[Faust, 极客web3]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.