写Go语言搞区块链这事儿,一干就是三四个年头。从怎么跟gRPC握手成功, 到最后把整个共识算法真正跑通一遍。这一路来, 踩过的坑那真的是太多了不少。
Go这个协程模型还有它的并发那些工具, 确实让做区块链开发这件事儿, 变得比用C++要顺手许多好多。但是啊, 用起来顺手不等于说这事儿本身就变得简单了不多。下面就来聊点儿真正实在的大家都能看到的情况。
go区块链怎么入门
千万别一上手就去看那些厚厚的专业文献, 你应当先把channel和goroutine这两个概念练习到形成肌肉记忆的程度。回想我过去的经历, 曾经在本地环境中搭建过成百上千的模拟节点来运行P2P网络, 期间光是为了手写出TCP这一层的协议代码, 就已经花费了整整两周的时间去打磨。
当你真的开始去动手操作的时候, 你就会发现, 接口的设计工作实际上要比算法本身更加让人感到痛苦和被折磨。如果一开始没有把那个RPC的序列化方案定清楚, 那么在后续的阶段里每增加一种节点类型的时候, 就必须把所有已经完成的工作全部推翻并且重新进行书写, 这绝对是一个让人痛彻心扉的经验教训。
go区块链性能如何
单节点TPS跑到十万级不算难, 我亲自压过测, 瓶颈基本都在磁盘IO和GC上。把GOGC参数从默认的一百调到三百, 吞吐立马多给你提个百分之二十。
一旦把集群给拉起来, 网络延迟这个东西就肯定是一个无法回避的硬伤。千万不要去相信那些关于什么零延迟的瞎吹嘘。在真实的实际操作环境里面, 如果要在不同的机房之间去同步一个区块数据, 那么所耗费的时间至少是需要两百毫秒的。
至于那个共识超时的参数具体应该怎么去配置, 这整个事情是完全需要依靠实实在在的生产环境下所采集到的数据来进行实际的测试和验证的。
这两年以来工具链的成熟程度已经有所提升, 与此同时社区的生态环境也在不断地进行补充和完善, 所以现在的状况同五年之前那种纯粹地进行重复造轮子的状态相比, 已经发生了实质性的变化, 但是我们还是要清楚地认识到工程复杂度方面仍然存在切实存在的诸多困难, 因此不要指望能够仅仅花费一周的时间就拿出可用的工作成果, 务必需要为自己预留出充足的时间用于后续的迭代与优化过程。
