搞区块链不踩坑？开发前这3条保命铁律你必须刻进骨子里

导读： 别急着写代码先想清楚业务到底要干啥不少人一开始就赶忙搭节点，撰写智能合约，还觉着自己懂些技术便能搞定区块链系统开发。那结果如何呢？业务逻辑都尚未理顺...

别急着写代码先想清楚业务到底要干啥

不少人一开始就赶忙搭节点，撰写智能合约，还觉着自己懂些技术便能搞定区块链系统开发。那结果如何呢？业务逻辑都尚未理顺，开发到半途才发觉需求根本不契合上链要求。区块链并非包治百病的神药，它所解决的是信任难题，并非你全部业务流程的数据库。倘若你仅是想让几个内部节点共享数据，那么用个中心化数据库加API就已然足够，何苦弄个分布式账本来给自己增添麻烦呢。

业务场景得实实在在地完整经历一回。诸如你打算做供应链溯源，那么从原材料环节开始，经过生产过程，再到物流阶段以及销售环节，每一步骤当中的数据由谁来录入、要怎样录入，还有上链之后谁拥有查看权限，要是这些细微之处没想明白，即便代码编写得极为美观也不过是徒有其表的空架子。我在一个项目当中目睹团队耗费三个月时间打造了一套溯源系统，然而客户却表示说“我们仅仅需要记录最后一级经销商的信息”，前面的流程全部是通过线下手动填写的Excel表格来完成的。那么你所构建的那套去中心化存证又究竟有何价值呢？在展开系统开发之前，需率先将业务模型绘制于纸面之上，要跟甲方清晰表明区块链解决了他们哪些痛点，而非仅是为了追逐风口便强行上马。

智能合约写不好比没写还可怕

许许多多的人认为智能合约不过是一连串的if - else逻辑，随意编写一番便能够运行。然而你是否清楚，合约一旦被部署至链上，就如同泼洒出去的水那般无法收回。仅仅一个简易的整数溢出漏洞，便能够使数百万的资金付诸东流。在历史上那些遭受黑客窃取利益的项目之中，绝大多数都是合约编写得不够严密。你觉得自己添加了SafeMath库就万无一失了？倘若前端调用合约时传递的参数出现错误会怎样呢？倘若你使用了他人的开源合约却未能察觉其中的漏洞又会如何呢？

开发智能合约，得将测试当作核心部分，去进行考量。编写一个合约时，起码要编写三倍数量的测试用例才行。要针对正常流程运行一遍，针对边界情况运行一遍，针对恶意攻击模拟运行一遍，这还不够，还得请第三方审计公司来核查一遍。审计可不是走走过场就算了，那是要用实实在在的资金去换取安全感。我曾经见过一个项目，其审计报告当中写有三条高风险漏洞，然而团队却认为“不影响核心功能”便选择了忽视，结果上线第三天就遭受了攻击，导致损失极为惨重。记住，你所编写的合约不但要能够顺利运行，而且还得经得起人性恶意的试探。

性能瓶颈别等上线才喊救命

区块链系统的性能，与传统服务器不同，没办法随意增添机器来实现扩容。共识机制、节点数量、区块尺寸、出块时间，一旦这些参数设定好了，往后若想进行调整，那就得改动底层架构。在开发阶段，或许仅仅部署了五个节点，运行速度极快，然而等上线之后，当联盟链里增添了二十个节点，交易量上升时，链就会直接陷入卡死状态。到那个时候，再去修改共识算法，基本上就等同于重新编写一套系统。

性能规划需在起始阶段着手进行，首先要预估业务峰值，依据最坏情形予以设计。举例而言，倘若预定每秒要处理一千笔交易，那么出块时间、单块容量以及节点硬件配置均需预先核算明晰。切莫寄望借助云服务器自动扩容来化解区块链性能问题，因为那仅对无状态服务生效，区块链的每个节点都必须存储全量账本。此外，存在一个易被忽视的要点，即链上数据的存储膨胀问题。若每笔交易均存储于链上，待一年后硬盘满了该如何应对？是否应设计归档策略？是否要用 IPFS 存储大文件而链上仅存储哈希？这些事项，务必要在系统进行开发的阶段，就做到充分地思考清楚，不然的话，等到上线过去了几个月之后，你就会满脸泪水地给众多用户发送公告，然后说道“系统马上就要进行暂停并且升级”了。