其他的优化点像大区块分片 EC 编码和分层传输、流水线化充分利用硬件资源、并行合约执行等，都是在高 TPS 下必须要做的工程实现，当然想到不代表做到，Solana 在公链架构优化工程实践层面走的是比较靠前的。

Flow 和 Solana 都是在公链架构优化层面不错的案例，这也让持有相同理念的 HECO 在行进的道路上不觉孤单，当然 HECO 相比于 Flow 和 Solana 还有一个更大的特点就是完全兼容以太坊和 EVM。下面就一起来了解一下 HECO 在扩展性方面的实践和成果。

HECO 公链扩展性理念和实践

首先来看一下 HECO 的战略定位，HECO 作为整个 DeFi 平台的技术底座和生态基础设施，承载着上层资产、应用和流量入口的所有核心业务，而 HECO 自身的技术矩阵又可以按资产安全、容量性能、网络规模、应用生态 4 大维度细分为 12 个核心模块，接下来给大家分享的主要是我们在容量性能相关的交易执行、状态存储等方面的优化工作。

容量性能优化首先要明确其理论模型，HECO 当前还是基于最长链的 POA+POS 共识，在出块时间方面一定要保证可以 cover 住区块打包+区块传播+交易二次执行和验证的时间。那反过来想就是如果可以进一步降低交易执行和区块传播时间，就可以在一个区块内纳入更多的交易，从而有效提升网络整体的吞吐。

左图是我们整理的扩展性瓶颈以及优化的层次，右图是当前整体优化后的效果，可以看蓝色的线，HECO 已经可以安全地将 Block GasLimit 设置到 100M Gwei 以上，TPS 可以到 1500+。下面来展开几个代表性优化。

首先来看并行执行优化，大家都知道以太坊节点的一大瓶颈就是其 MPT 状态树，HECO 针对状态树更新做了很多并行优化，比如多账户之间可以无关联地并行 RLP 编码，更新 StorageTrie，并行计算 StorageRoot 等，还有并行计算区块 bloom 和 receiptRoot 等。并行执行整体优化效果是可以将区块内交易执行时间降低 30% 以上。

再来看存储流水线优化，当区块执行完成之后，需要进行写块、更新 snapshot 和状态提交 3 步存储更新，分析发现状态提交是耗时最长的，而且可以和下一个区块执行进行流水线优化，即上一个区块完成更新 snapshot 就可以开始下一个区块的执行，但同时也要保证上一个区块状态提交完成之后才开始下一个区块的状态提交，从而保证状态提交的顺序性和一致性。通过存储流水线优化，HECO 基本上将存储更新在整个成块时间中串行的占比降低了 90% 以上，效果还是非常明显的。 (责任编辑：admin)