This article aims to briefly summarize the working principle and commercial significance of opBNB, to sort out the important step taken by the BSC public chain in the era of modular blockchain.
Author: Faust, Geek web3
Introduction: If we were to summarize Web3 in 2023 with a keyword, most people might instinctively think of "The Summer of Layer2." While application layer innovations are emerging one after another, long-term hotspots like L2 are rare to come by. With the successful promotion of the modular blockchain concept by Celestia, Layer2 and modularity have almost become synonymous with infrastructure, and the past glory of single-chain seems difficult to reproduce. With Coinbase, Bybit, and Metamask successively launching their dedicated Layer2 networks, the Layer2 battle is in full swing, resembling the scene of the fierce battle between new public chains in the past.
In this Layer2 network battle led by exchanges, BNB Chain is bound to not be willing to lag behind. As early as last year, they had launched the zkBNB test network, but because zkEVM's performance was still unable to meet the needs of large-scale applications, opBNB, which adopts the Optimistic Rollup solution, became a better solution for achieving a universal Layer2. This article aims to briefly summarize the working principle and commercial significance of opBNB, to sort out the important step taken by the BSC public chain in the era of modular blockchain.
The Road of Large Blocks for BNB Chain
Similar to public chains supported by exchanges such as Solana and Heco, BNB Chain's public chain BNB Smart Chain (BSC) has long pursued high performance. Since its launch in 2020, BSC has set the gas capacity limit for each block at 30 million, with a stable block interval of 3 seconds. With such parameter settings, BSC achieved a TPS limit of over 100 (TPS with various transactions mixed together). In June 2021, the block gas limit of BSC was raised to 60 million, but in July of the same year, a chain game called CryptoBlades became popular on BSC, causing the daily transaction volume to exceed 8 million at one point, leading to a surge in transaction fees. It turned out that the efficiency bottleneck of BSC was still quite obvious at that time.
(Data source: BscScan)
To address the network performance issues, BSC once again raised the gas limit for each block, which remained stable at around 80-85 million for a long time. In September 2022, the gas limit for a single block of BSC Chain was raised to 120 million, and by the end of the year, it was raised to 140 million, nearly 5 times that of 2020. Previously, BSC had planned to increase the block gas capacity limit to 300 million, but perhaps considering the heavy burden on Validator nodes, the proposal for such super-large blocks has not been implemented.
(Data source: YCHARTS)
Later, BNB Chain seemed to shift its focus to the modular/Layer2 track, rather than persisting in Layer1 expansion. From zkBNB launched in the second half of last year to GreenField at the beginning of this year, this intention became increasingly apparent. Out of a strong interest in modular blockchain/Layer2, the author of this article will take opBNB as the research object, to reveal the performance bottlenecks of Rollup by comparing opBNB with Ethereum Layer2 for readers.
BSC's High Throughput Adds to opBNB's DA Layer
As we all know, Celestia has summarized 4 key components according to the workflow of modular blockchain:
- Execution layer Execution: The execution environment that executes contract code and completes state transitions.
- Settlement layer Settlement: Handles fraud proofs/validity proofs, and addresses the bridging issues between L2 and L1.
- Consensus layer Consensus: Reaches consensus on the ordering of transactions.
- Data availability layer Data availability (DA): Publishes blockchain ledger-related data, allowing validators to download this data.
The DA layer and the consensus layer are often coupled together. For example, the DA data of Optimistic Rollup contains a batch of transaction sequences in L2 blocks. When L2 full nodes obtain the DA data, they actually know the sequence of each Tx in this batch of transactions. (For this reason, when the Ethereum community discusses the layering of Rollup, they believe that the DA layer and the consensus layer are related)
However, for Ethereum Layer2, the data throughput of the DA layer (Ethereum) has become the biggest bottleneck restricting the performance of Rollup, because the current data throughput of Ethereum is too low, forcing Rollup to suppress its TPS as much as possible to prevent the Ethereum mainnet from being unable to handle the data generated by L2.
At the same time, the low data throughput has left a large number of transaction instructions within the Ethereum network in a pending state, causing gas fees to rise to extremely high levels, further increasing the cost of data publication for Layer2. As a result, many Layer2 networks have had to adopt DA layers outside of Ethereum, and opBNB, which has a high throughput, directly uses BSC to implement DA to solve the bottleneck problem in data publication.
For ease of understanding, it is necessary to introduce the method of DA data publication for Rollup here. Taking Arbitrum as an example, the EOA address controlled by the Layer2 sequencer on the Ethereum chain will periodically send Transactions to a specified contract. In the input parameters calldata of this instruction, the packaged transaction data is written, and the corresponding on-chain event is triggered, leaving a permanent record in the contract logs.
In this way, the transaction data of Layer2 is stored in the Ethereum block for a long time, and those capable of running L2 nodes can download the corresponding records and parse the corresponding data, but Ethereum's own nodes do not execute these L2 transactions. It is easy to see that L2 only stores transaction data in the Ethereum block, incurring storage costs, while the computational costs of executing transactions are borne by the L2's own nodes.
The above describes the implementation method of DA for Arbitrum, while Optimism is controlled by the sequencer's EOA address, transferring to another specified EOA address, carrying a new batch of Layer2 transaction data in the additional data. As for opBNB, which uses the OP Stack, its DA data publishing method is basically the same as Optimism's.
It is obvious that the throughput of the DA layer will limit the size of data that Rollup can publish in a unit of time, thereby limiting the TPS. Considering that after EIP1559, the gas capacity of each ETH block remains at 30 million, and the block time after the merge is about 12 seconds, Ethereum can process a maximum of only 2.5 million gas per second.
Most of the time, the gas consumed by each byte of calldata containing L2 transaction data on Ethereum is 16. Therefore, the maximum calldata size that Ethereum can process per second is only about 150 KB. In contrast, BSC can process a maximum average calldata size of about 2910 KB per second, which is 18.6 times that of Ethereum. The difference between the two as the DA layer is evident.
To summarize, Ethereum can accommodate approximately 150 KB of L2 transaction data per second. Even after the launch of EIP 4844, this number will not change significantly, only reducing the DA fees. So, with approximately 150 KB per second, how many transactions' data can be included?
Here we need to explain the data compression rate of Rollup. In 2021, Vitalik made an overly optimistic estimate that Optimistic Rollup could compress the size of transaction data to 11% of the original. For example, a basic ETH transfer that originally occupied 112 bytes of calldata could be compressed to 12 bytes by Optimistic Rollup, an ERC-20 transfer could be compressed to 16 bytes, and a Swap transaction on Uniswap could be compressed to 14 bytes. According to his estimation, Ethereum could record a maximum of about 10,000 L2 transaction data per second (with various types mixed together). However, according to the data disclosed by the Optimism team in 2022, the actual data compression rate in practice can only reach about 37%, which is 3.5 times lower than Vitalik's estimate.
(Vitalik's estimate of the scaling effect of Rollup is largely off from the actual situation)
(Actual compression rates achieved by various compression algorithms disclosed by the Optimism team)
So, let's give a reasonable number, even if Ethereum reaches its maximum throughput limit, the total TPS of all Optimistic Rollups combined would only be a little over 2000. In other words, if all the space in Ethereum blocks is used to carry the data published by Optimistic Rollup, divided among platforms like Arbitrum, Optimism, Base, and Boba, the combined TPS of these Optimistic Rollups would not even reach 3000, even with the highest efficiency of the compression algorithm. Additionally, we also need to consider that after EIP1559, the average gas capacity carried by each block is only 50% of the maximum value, so the above numbers should be halved. After the launch of EIP4844, although the transaction fees for publishing data will be significantly reduced, the maximum block size of Ethereum will not change much (too much change would affect the security of the ETH main chain), so the estimated values above will not improve much.
According to the data from Arbiscan and Etherscan, a batch of transactions on Arbitrum contained 1115 transactions, consuming 1.81 million gas on Ethereum. Therefore, if the DA layer is filled with transactions in each block, the theoretical TPS limit of Arbitrum would be approximately 1500. Of course, considering the possibility of L1 block reorganization, Arbitrum cannot publish transaction batches on every Ethereum block, so the above numbers are currently only theoretical.
At the same time, with the widespread adoption of smart wallets related to EIP 4337, the DA issue will become even more serious. Because with support for EIP 4337, users can customize the way they verify their identity, such as uploading binary data of fingerprints or irises, which will further increase the data size occupied by regular transactions. Therefore, the low data throughput of Ethereum is the biggest bottleneck limiting the efficiency of Rollup, and this problem may not be properly resolved for a long time in the future.
On the other hand, on the BNB Chain's public chain BSC, the maximum average calldata size that can be processed per second is about 2910 KB, which is 18.6 times that of Ethereum. In other words, as long as the execution layer can keep up, the theoretical TPS limit of Layer2 within the BNB Chain system can reach approximately 18 times that of ARB or OP. This number is calculated based on the current maximum gas capacity of 1.4 billion per block and a block time of 3 seconds for BNB Chain.
In other words, the total TPS limit of all Rollups within the BNB Chain system is 18.6 times that of Ethereum (even when considering ZKRollup). From this perspective, it is understandable why so many Layer2 projects use the DA layer under the Ethereum chain to publish data, as the difference is evident.
However, the problem is not that simple. In addition to the data throughput issue, the stability of Layer1 itself will also affect Layer2. For example, most Rollups often wait for several minutes before publishing a batch of transactions on Ethereum, considering the possibility of L1 block reorganization. If an L1 block is reorganized, it will affect the blockchain ledger of L2. Therefore, after the sequencer publishes a batch of L2 transactions, they will wait for several new L1 blocks to be published, and the probability of block rollback will significantly decrease before publishing the next batch of L2 transactions. This actually delays the time for L2 blocks to be finally confirmed, reducing the confirmation speed of large transactions (large transactions need to be irreversible to ensure security).
In summary, the transactions occurring in L2 are only irreversible after being published to the DA layer block, and a certain amount of new blocks have been generated in the DA layer. This is an important reason limiting the performance of Rollup. However, Ethereum has a slow block generation speed, with a block produced every 12 seconds. Assuming that Rollup publishes an L2 batch every 15 blocks, there will be a 3-minute interval between different batches. Additionally, after each batch is published, it still needs to wait for multiple L1 blocks to be generated before becoming irreversible (assuming no challenges). Clearly, the time from initiating transactions on Ethereum L2 to their irreversibility is long, resulting in slow settlement speed. On the other hand, BNB Chain only takes 3 seconds to produce a block, and the block becomes irreversible in just 45 seconds (the time it takes to produce 15 new blocks).
Based on the current parameters, assuming the same number of L2 transactions and considering the irreversibility of L1 blocks, the frequency of opBNB publishing transaction data can reach up to 8.53 times that of Arbitrum (45 seconds for the former, 6.4 minutes for the latter). Clearly, the settlement speed of large transactions on opBNB is much faster than on Ethereum L2. Additionally, the maximum data volume published by opBNB can reach 4.66 times that of Ethereum L2 (the former's L1 block gas limit is 140 million, while the latter's is 30 million).
8.53 * 4.66 = 39.74, which is the current practical difference in TPS limits between opBNB and Arbitrum (currently, it seems that ARB has voluntarily lowered its TPS for security reasons, but theoretically, if it were to increase TPS, it would still be many times lower than opBNB).
(Arbitrum's sequencer publishes a batch of transactions every 6-7 minutes)
(opBNB's sequencer publishes a batch of transactions every 1-2 minutes, with the fastest taking only 45 seconds)
Of course, there is another important issue to consider, which is the gas fees in the DA layer. Each time L2 publishes a transaction batch, there is a fixed cost of 21,000 gas unrelated to the calldata size, which is an expense. If the DA layer/L1 fees are high, causing the fixed cost of publishing each transaction batch on L2 to remain high, the sequencer will reduce the frequency of publishing transaction batches. Additionally, when considering L2 fee components, the cost of the execution layer is very low most of the time and can be ignored, only considering the impact of DA costs on fees.
In summary, when publishing calldata data of the same size on Ethereum and BNB Chain, although the gas consumed is the same, the gas price charged by Ethereum is about 10 to several tens of times that of BNB Chain. When this is passed on to L2 fees, the current user fees for Ethereum Layer2 are probably also 10 to several tens of times that of opBNB. Overall, the difference between opBNB and Optimistic Rollup on Ethereum is quite significant.
(A transaction consuming 150,000 gas on Optimism costs $0.21)
(A transaction consuming 130,000 gas on opBNB costs $0.004)
However, increasing the data throughput of the DA layer can only improve the overall throughput of the Layer2 system to a limited extent, as the performance improvement of individual Rollups is limited. This is because the execution layer often does not process transactions fast enough. Even if the limitations of the DA layer can be ignored, the execution layer will become the next bottleneck affecting Rollup performance. If the execution layer of Layer2 is slow, the overflow of transaction demand will spread to other Layer2, ultimately causing a fragmentation of liquidity. Therefore, improving the performance of the execution layer is also important, serving as another threshold above the DA layer.
opBNB's Boost in the Execution Layer: Cache Optimization
When most people talk about the performance bottleneck of the blockchain execution layer, they inevitably mention that the EVM's single-threaded serial execution method cannot fully utilize the CPU, and Ethereum's use of the Merkle Patricia Trie for data lookup is inefficient. These are two important execution layer bottlenecks. In essence, the scaling solutions for the execution layer boil down to making more efficient use of CPU resources and allowing the CPU to access data as quickly as possible. Optimization solutions for EVM's serial execution and Merkle Patricia Tree are often complex and not easily implemented, and the more cost-effective work often focuses on cache optimization.
In fact, cache optimization brings us back to points that are frequently discussed in traditional Web2 and even in textbooks.
In most cases, the speed at which the CPU reads data from memory is hundreds of times faster than reading from disk. For example, reading data from memory takes only 0.1 seconds, while reading from disk takes 10 seconds. Therefore, reducing the overhead of disk reads and writes, i.e., cache optimization, is a necessary part of optimizing the blockchain execution layer.
In Ethereum and most public chains, the database that records on-chain address states is fully stored on disk, and the so-called World State trie is just an index of this database, or a directory used when looking up data. Every time the EVM executes a contract, it needs to access the relevant address state. If the data needs to be fetched one by one from the database stored on disk, it will significantly slow down the transaction execution speed. Therefore, setting up a cache outside the database/disk is a necessary means of speeding up the process.
opBNB directly adopts the cache optimization solution used by BNB Chain. According to information disclosed by opBNB's partner NodeReal, the original BSC chain set up 3 levels of cache between the EVM and the LevelDB database storing the state. The design concept is similar to the traditional three-level cache, placing data with higher access frequency into the cache so that the CPU can first look for the required data in the cache. If the cache hit rate is high enough, the CPU does not need to overly rely on the disk to access data, and the speed of the entire execution process can be significantly improved.
Later, NodeReal added a feature to this, which utilizes the idle CPU cores of the EVM to read the data that the EVM will need to process in the future from the database in advance and store it in the cache. This allows the EVM to directly obtain the required data from the cache in the future, and this feature is called "state pre-reading."
The principle of state pre-reading is actually very simple: Blockchain nodes' CPUs have multiple cores, while the EVM operates in a single-threaded serial execution mode, utilizing only 1 CPU core, leaving the other CPU cores underutilized. To address this, the unused CPU cores can be utilized to do some work. They can determine the data that the EVM will need in the future from the sequence of transactions that the EVM has not yet processed. Then, these CPU cores outside the EVM will read the data that the EVM will need from the database, helping the EVM reduce the overhead of data retrieval and improve execution speed.
After thorough optimization of the cache, combined with a sufficiently powerful hardware configuration, opBNB has actually pushed the performance of the node's execution layer close to the limit of the EVM: it can process up to 100 million gas per second. 100 million gas is basically the performance ceiling of the unmodified EVM (based on experimental test data from a well-known public chain).
In specific terms, opBNB can process a maximum of 4761 simple transfers per second, process 1500-3000 ERC20 token transfers, and handle approximately 500-1000 SWAP operations per second (based on transaction data from the block explorer). Comparing the current parameters, opBNB's TPS limit is 40 times that of Ethereum, over 2 times that of BNB Chain, and over 6 times that of Optimism.
Of course, due to the severe limitations of the DA layer itself, the execution layer of Ethereum Layer2 cannot fully perform. If we consider the factors such as the block generation time and stability of the DA layer mentioned earlier, the actual performance of Ethereum Layer2 will be significantly reduced based on the performance of the execution layer. For high-throughput DA layers like BNB Chain, achieving over 2 times the capacity of opBNB is very valuable, especially since such expansion projects can be deployed on BNB Chain for multiple purposes.
It can be foreseen that BNB Chain has already included Layer2 solutions led by opBNB in its strategic plan and will continue to incorporate more modular blockchain projects in the future, including introducing ZK proof in opBNB and integrating supporting infrastructure such as GreenField to provide a highly available DA layer, attempting to compete or collaborate with the Ethereum Layer2 system. In the era where layered scaling has become the trend, it remains to be seen whether other public chains will also rush to emulate BNB Chain in supporting their own Layer2 projects. However, there is no doubt that the paradigm shift towards modular blockchain and infrastructure revolution is already happening.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
