<strong style="color: rgb(0, 0, 0);">BNB Chain的大区块之路
与Solana、Heco等由交易所扶持的公链类似,BNB Chain的公链BNB Smart Chain (BSC)链对高性能的追求由来已久。<strong style="color: rgb(0, 82, 255);">从2020年上线初,BSC链就把每个区块的gas容量上限设定在3000万,出块间隔稳定在3秒。
在这样的参数设置下,BSC实现了100+的TPS上限(各种交易杂糅在一起的TPS)。2021年6月,BSC的区块gas上限提升到了6000万,但在当年7月一款名为CryptoBlades的链游在BSC上爆火,引发的日交易笔数一度超过800万,导致手续费飙升。事实证明,此时的BSC效率瓶颈还是比较明显。
<strong style="color: rgb(90, 90, 90);">

为了解决网络性能问题,BSC再次将每个区块的gas上限上调,此后长时间稳定在8000万~8500万附近。2022年9月,BSC Chain单个区块的gas上限提高到了1.2亿,年底时提高到了1.4亿,达到2020年时的近5倍。<strong style="color: rgb(0, 82, 255);">此前BSC曾计划把区块gas容量上限提升到3亿,或许是考虑到Validator节点的负担太重,上述超大区块的提议一直没有实施。
<strong style="color: rgb(90, 90, 90);">

后来的BNB Chain似乎将重心放在了模块化/Layer2赛道,而没有再执着于Layer1的扩容。从去年下半年上线的zkBNB到今年年初时的GreenField,这一意图表现的愈加明显。出于对模块化区块链/Layer2的浓厚兴趣,本文作者将以opBNB为调研对象,从opBNB与以太坊Layer2表现出的不同,来为读者简单揭示Rollup的性能瓶颈所在。
<strong style="color: rgb(0, 0, 0);">BSC的高吞吐量对opBNB的DA层加成
众所周知,Celestia按照模块化区块链的工作流程,归纳出了4个关键组件:
<strong style="color: rgb(0, 82, 255);">执行层Execution:执行合约代码、完成状态转换的执行环境;
<strong style="color: rgb(0, 82, 255);">结算层Settlement:处理欺诈证明/有效性证明,同时处理L2与L1之间的桥接问题。
<strong style="color: rgb(0, 82, 255);">共识层Consensus:对交易的排序达成一致共识。
<strong style="color: rgb(0, 82, 255);">数据可用性层Data availability (DA):发布区块链账本相关数据,使得验证者可以下载到这些数据。
<strong style="color: rgb(0, 82, 255);">

<strong style="color: rgb(0, 82, 255);">



<strong style="color: rgb(0, 82, 255);">

<strong style="color: rgb(90, 90, 90);">

<strong style="color: rgb(90, 90, 90);">




<strong style="color: rgb(90, 90, 90);">

<strong style="color: rgb(90, 90, 90);">

<strong style="color: rgb(90, 90, 90);">

<strong style="color: rgb(90, 90, 90);">

<strong style="color: rgb(0, 0, 0);">opBNB在执行层的加成:缓存优化当大多数人谈到区块链执行层的性能瓶颈时,必然会提到:EVM的单线程串行执行方式无法充分利用CPU、以太坊采用的Merkle Patricia Trie查找数据效率太低,这是两个重要的执行层瓶颈所在。说白了,对执行层的扩容思路,无非是更充分的利用CPU资源,再就是让CPU尽可能快的获取到数据。针对EVM串行执行和Merkle Patricia Tree的优化方案往往比较复杂,并不是很好实现,而投入性价比更高的工作常聚集在对缓存的优化上。其实缓存优化问题,回到了传统Web2乃至教科书中经常讨论到的点。通常情况下,CPU从内存读取数据的速度,是从磁盘读取数据速度的上百倍,比如一段数据,CPU从内存中读取只需要0.1秒,从磁盘中读取则需要10秒。所以,降低在磁盘读写上产生的开销,也即缓存优化,成为了区块链执行层优化中必需的一环。在以太坊乃至绝大多数公链中,记录链上地址状态的数据库被完整存储在磁盘当中,而所谓的世界状态World State trie只是这个数据库的索引,或者说查找数据时用到的目录。EVM每次执行合约都需要获取相关的地址状态,如果数据都要从存放在磁盘里的数据库中一条条拿过来,显然会严重降低执行交易的速度。<strong style="color: rgb(0, 82, 255);">所以在数据库/磁盘之外设置缓存,是必要的提速手段。opBNB直接采用了BNB Chain用到的缓存优化方案。按照opBNB的合作方NodeReal披露的信息,最早的BSC链在EVM与存放状态的LevelDB数据库之间设置了3道缓存,设计思路类似于传统的三级缓存,把访问频率更高的数据放到缓存中,这样CPU就可以先去缓存中寻找需要的数据。如果缓存的命中率足够高,CPU就不需要过分依赖磁盘来获取数据,整个执行过程的速度就可以实现大幅提升。

后来NodeReal在此之上增设了一个功能,调动EVM没占用的空闲CPU核心,把EVM未来要处理的数据,提前从数据库中读出来,放入缓存中,让EVM未来能从缓存直接获得需要的数据,<strong style="color: rgb(0, 82, 255);">这个功能被称为“状态预读”。
<strong style="color: rgb(0, 82, 255);">
