我这方面的工作已经持续了整整五年时间, 期间负责过许多不同的项目交付任务, 内容范围涵盖了从供应链的溯源环节一直到DeFi协议相关业务的开发。在这段经历之后, 我产生了一个非常强烈的感受, 那就是关于区块链技术的应用与开发, 其实际的工作内容远非仅仅编写智能合约那样简单。
在现实情况中, 我们可以看到非常多的团队因为在这两个具体环节上没有处理好, 即技术选型以及如何实现链上与链下的协同配合, 最终陷入了停滞或者失败的困境。如果在这一阶段将所用的技术栈选择错误, 那么后续的开发工作将会变得极其困难, 并且会导致大量的重复劳动和返工问题。
区块链开发难在哪
最大的困难其实并不是编写代码, 而是要去判断业务到底是不是真的需要把数据放到区块链上。在我经手的项目里面, 有百分之三十都是所谓的伪需求, 这类数据本身并不需要具备不可篡改的特性, 要是硬要把它们上链, 只会徒然地增加成本并且让系统的复杂度变得更高。
真正让人头疼的事情是, 必须要清清楚楚地把链下数据库的读取和写入操作, 与链上的状态管理彻底分开来进行处理。这个做出判断的过程, 比起直接去写Solidity这种智能合约代码来说, 难得要更多。
第二大问题是性能方面的表现。毕竟公链的每秒交易量是固定在那里的, 面对高并发的场景, 你是绝对不可能把所有的操作都放到链上去处理的。因此必须要把索引节点的设计做好, 或者是去部署像Layer2这样的解决方案。这一部分相关的公开文档是非常匮乏的, 只能靠自己去经历各种挫折和考验来慢慢积累经验。
区块链开发怎么选框架
在选择的时候, 我通常会看三个具体的方面, 就是团队对它熟不熟悉、社区生态做得怎么样, 以及之后的运维要花多少成本。虽然以太坊的生态很成熟，但是使用Gas会很贵。
如果是在联盟链的场景下使用, 用Hyperledger Fabric或者是长安链会更合适一些。不要急着去追那些新的框架, 能够把MVP跑通之后再去进行迭代。
合约安全审计是另一笔大的花费。我看见过在上线之前没有做形式化验证的这个情况, 这个结果是被黑客攻击了两个亿的一个案例。在这个预算里面必须留下对进行审计的这部分金额, 不要去节省这一部分的资金。
区块链开发是一项工程技术工作, 而不是一种依靠信仰的活动。需要明确界定业务的范围边界, 在技术选型的时候不要贪多求全, 要踏踏实实地编写代码, 认真地测试系统存在的漏洞, 并针对性能方面进行压力检测, 这样做就是符合要求的做法。
