想做区块链研发，先别急着写代码，把这三步想明白再动手

我在区块链研发这个领域已经干了整整八年了, 期间, 也就是经手过上百个项目, 而且这些项目是从制作P点到最终上线全过程都参与过的。

大多数团队在一开始的时候就急于去堆砌很多智能合约的代码内容, 但是, 这样的做法导致在共识机制、分片技术以及安全性保障这几个关键方面完全没有考虑清楚, 于是最后就是产生了大量的返工现象。

其实做区块链研发这项工作真的没有大家想象得那么神秘或者难以捉摸, 其最重要的关键点在于遵循正确的开发顺序, 而不是单纯地去追求技术投入量的大小。

区块链研发先做什么

第一步的做法, 其实永远都不是直接去写代码。在我承接项目的前两周时间里, 只做的一件事, 就是把实际的业务逻辑, 给翻译成链上的状态机模式。至于具体有哪些数据要上链, 哪些数据要留在链下, 以及读写频率到底是多少, 这些核心要素如果还没有最终敲定就急着动手操作, 那就等于手里拿着锤子到处找钉子可钉。

能够真正运行起来的最小化原型系统, 往往只需要三条合约和一个共识节点就够了。我们应当把那些看起来花里胡哨的全节点部署工作统统省去掉, 要先做的关键动作是把核心路径给彻底跑通, 然后再去谈论什么是扩展性这个问题。先把核心路径跑通,再谈扩展性。

区块链研发怎么避坑

最大的问题在于安全方面, 因为智能合约一旦部署到区块链上就无法进行更改, 所以哪怕仅仅是一个整数溢出的小错误, 都可能会导致数百万美元的资产被消耗掉。

鉴于这种情况, 我目前所规定执行的准则非常严格: 任何智能合约在正式上线之前, 必须连续通过三轮独立的安全审计程序, 并且还需要额外完成一次覆盖全链条的压力测试任务, 如果其中的任何一个环节没有达标或者缺失了, 那么都会被视为不合规而无法过关。

此外, 对于“完全去中心化”这种理念也不要盲目地迷信, 因为在项目的早期阶段, 采用授权共识机制来首先打通性能瓶颈是比较实际的做法, 等到后期再通过逐步开放的方式来实现去中心化目标, 这样一步一步来的做法, 显然比一开始就试图一步到位要更为可靠和安全一些。这比试图一步到位靠谱得多。

不要把区块链这种技术当作是那种可以解决所有问题的万能胶水来使用。你需要把心思放到搞清楚在具体的哪一个环节之中, 真的是必须要用到那种不可被篡改的特性以及各种去除了信任基础的模式之后, 再开始动手去编写代码。

这样你所节省下来的时间预算以及资源费用, 是完全足够让你额外多运行两轮关于安全性的测试工作的。这一种做法所带来的实际效果和价值, 是要比任何其他的事情都要更强, 更加有说服力的。