在过去做区块链底层架构的这五年时光里, 我越来越产生这样一种感受, 那就是内核开发这一部分, 在整个技术发展链条之中, 确实是被认为最为耗费心力, 同时也是占据着最为核心的地位的关键环节, 它和智能合约领域拥有Solidity这样一套可以拿来就用的成熟生态环境的情况有着本质的不同, 在该领域里面, 针对每一个独立的技术模块, 开发者都必须从零开始着手去进行序列化处理协议的梳理与搭建工作, 并且还需要自己花费大量的时间和精力去反复地确认其正确性与稳定性, 因此接下来我想要详细地分享和探讨一些我在实际工作过程中所遭遇到的、并且已经积累了一定的教训的具体问题与困难。
区块链内核开发难在哪
最让人觉得直观的难点在于共识层。BFT类的协议在状态机同步这个环节, 一旦网络出现分区的这种状况, 就非常容易产生分叉。你要是去写一个测试用例来运行, 即便跑了三天时间, 都不见得能够复现那个边界的条件。
我记得曾经有过一次经历, 是因为一条超时消息的时序竞态问题, 导致整个验证节点集群不断地出现出块失败的错误, 为了排查这个问题, 前前后后整整花费了两天的时间。
在P2P网络层那边也一样, 让人很头疼。关于gossip协议本身的传播效率有多高、在弱的网络环境下面对节点发现机制的时候其具备的鲁棒性水平到底如何这些事儿, 并没有现成的最优解可以用。大家只能在各种各样的不同网络拓扑结构的环境之中去反复地做压力测试工作并进行参数调优调整处理。
区块链内核开发怎么写
我的工作习惯是首先从状态机模型的视角来进行绘制, 将各种类型的交易对账户以及存储环节所产生的具体影响逐条详细罗列出来, 紧接着再反过来推导消息的具体格式与序列化相关的技术方案。若是省略掉这一关键步骤而直接着手编写代码,那么在后期进行系统重构时所付出的代价将会非常沉重与高昂。
在语言选型的方面, 核心路径这一部分采用 Rust 来进行编写, 而那些对性能有着敏感要求的加密模块, 则需要单独使用 C 语言来实现。
千万不要去追求用一门语言就去通吃所有的情况, 这一点至关重要, 因为模块之间的边界要划分得清晰明确, 这一点的含义和重要性, 比起所谓语言的纯度来说, 是重要得多的存在。
内核这块内容不存在可以一次性解决所有问题的万能解决方案。所以你必须采取多读开源源码、多做混沌测试这种做法。这种方式比任何学习教程都要来得更加实在可靠。
转载请注明出处：imtoken，如有疑问，请联系（）。
本文地址：https://m.zmdyd.cn/imgfb/11108.html