在区块链系统的优化工作方面, 这从来就不是一种只需要拧紧一个参数就能轻易解决的简单事情。因为在整个系统架构里面, 它实际上是横跨了共识协议模块、状态机执行模块或者是存储引擎模块这三个主要部分的, 所以任何一点微小的变动都必然会牵动其他所有部分, 也就是常人们所说的牵一发动全身的情况出现。
在实际进行项目开发的实践过程里面, 我个人发现了这样一个比较普遍的现象, 那就是绝大多数技术团队把绝大部分精力全部都使劲砸在了共识层的优化上, 可是与此同时, 那些技术人员们却是完全对 I/O 瓶颈可能带来的影响以及状态同步过程中所产生的那种严重拖累现象选择视而不见, 或者说是选择不去正视这些问题的存在方式。
区块链系统优化怎么做
我此前带着团队完成了大量的区块链性能调优工作, 在交流之中最经常被提问的问题就是换用其他的共识机制是否可行。采用以权威证明为代表的POA来替代工作量证明, 同时将去中心化最终性组件里的节点数量从二十一个大幅度缩减到七个, 确实能够让每秒处理交易量的这一指标显著地提升到一个新的台阶。
不过经过深入的拆解和分析可以明确地看出来, 真正形成瓶颈、从而导致吞吐量无法突破现有上限的根本原因, 绝大多数情况下都指向了状态机在执行计算任务时以及验证新区块的过程中, 并行处理能力不足的这一核心问题。
基于同样的共识逻辑进行推演, 由Go语言所承载的并发模型与Rust语言所运行的并发模型最终呈现出来的数值对比结果是可以相差整整一个数量级的。从根本原因上来分析, 这一现象并不是算法层面出现的问题, 而仅仅是执行引擎层面的问题所产生的直接后果。
一旦落实到具体的工程实现方面, 交易排序、并行执行以及跨节点状态哈希校验这三部分内容, 究竟能不能被构建成一条流水线作业的形式, 这在很大程度上直接决定了性能上限能够达到什么高度。
我去仔细查阅过很多开源区块链项目当中所采用的默认设置参数, 发现其中关于MPT的数据结构的并行遍历机制, 在绝大多数情况下根本就没有被开启启用, 这就导致了一代中央处理器所拥有的多核计算能力, 被毫无意义地白白浪费了。
区块链系统优化难在哪
最让人头疼的是耦合的问题。共识层修改投票超时时间, 存储层的checkpoint策略就必须随之改变。如果不这样做, 出块节奏和磁盘刷盘频率就无法对得上, 这会导致GC日志刷屏长达半小时。
我在一个联盟链项目里就因为这个问题摔倒过。具体发生的情况是, 共识间隔从4秒降低到1.5秒,状态同步延迟反而翻了一倍, 最后我们花了三周的时间才把两层协调一致。
验证成本变得特别高,这算是第二个需要面对的大问题。数据一旦上链那就不能更改了。所以就没办法像对待传统数据库那样去随意增加索引、做分表或者是处理分区这些操作了。
哪怕只是改动了一个版本的优化方案。也要把全面回归测试都重新跑一遍。这么折腾起来往往就得花费好几天时间。想要回退也是巨大的代价。所以能够进行试错的空间其实非常非常有限。
根本不存在那种可以一下子解决所有问题的银弹。你需要先把这三层结构给拆开, 然后分别去进行调整和调试, 直到各自能够通畅运行, 紧接着再把它们串联在一起, 最后去做压力测试, 这算是唯一比较靠谱的一条路子了。大家千万不要抱有什么幻想, 指望说靠打一个补丁就能把所有问题都给解决了。
转载请注明出处：imtoken，如有疑问，请联系（）。
本文地址：https://www.zmdyd.cn/zbimqbxz/10770.html