多元化的工程开发模式，保障区块链公链的安全

自从2009年比特币诞生后，区块链公链已经发生了很多起重大的安全事故。由于公链都会涉及到发币，这些币都是投资人真金白银换来的，一旦发生事故，损失惨重，而且，除了分叉，基本上是不可以挽回的。这样以来，公链的安全就尤为重要。

现在普遍的做法，还是采用传统软件开发方式和安全预防措施。看看比特币，以太坊，柚子，等等，还是沿用的传统软件系统开发模式，选择一种语言，一个编译器，一些基础库，一个操作系统，一个开发机，一套开发流程，等等。然后，设计好系统架构，定义好子系统和子系统接口，定义好存储结构，将系统分成不同的模块，或是不同的微服务。接下来，将团队分成不同的项目组，每组负责一个或是几个模块，开始用前面商定的语言，工具和流程开发。最后，经过各种测试，安全检查测试，部署上线。对于安全预防措施，也是传统的代码审查，安全漏洞检查，安全漏洞测试，无论是从以往经验，还是基于代码的白盒，还是基于源代码或是执行代码的分析，还是基于各种安全工具的检测，发现问题，修补，然后更多安全检查测试，发现更多问题，修补更多。尽管如此，安全问题依然层出不穷。因为，传统的系统，是基于一个中心，一台机器，一个操作系统，一个人，运行的，解决各自的问题，相互孤立，它们可以是独立的系统。一个系统的问题，不会演化为全局的灾难。

但是到了区块链时代，一条公链是一个有机的整体的系统，虽然有不同的节点，但它们完成的功能都是一致的，跑的也是同样代码，在某个时段充当挖矿出块的角色，在另外一个时段充当见证验证的角色，这样，一个节点的问题，一个节点的安全漏洞，会是所有节点的安全问题，这样会引起整个链条的错误，从而给用户，给用户的资产，造成不可挽回的损失。

既然是这样，既然区块链公链是个全局性全球性的系统，那么，是不是应该学习在航空航天领域久经考验的用于飞行安全控制系统的工程开发模式：

多元性

即同一功能模块或是子系统的多元性实现。

飞行安全控制系统的开发，要求软件多元化，硬件多元化，频道多元化，控制多元化，主辅多元化。这样的好处是一个地方的问题，不容易是别的地方的问题，从而不会造成全局的问题。

对照到区块链公链，将公链分解为不同的功能单元和子系统，对一个子系统，采用多元化的实现。比方说，像比特币的脚本语言，以太坊的EVM，柚子的WASM，同时有两个或以上的团队，分别以不同的编程语言，不同的开发测试流程，使用不同的底层库，在不同的操作系统，不同的CPU上，实现不同的版本。然后，节点远行的时候，可以随机或是指定不同的实现版本。这样，就能有效的保障，一种实现的bugs，安全漏洞，不大可能在另一种实现上重现。一个出块节点上的安全漏洞，不大容易在其它实现的版本上的验证节点上获得通过。这样，才能像飞行安全控制系统一样，达到很多个九的安全可靠性。具体实施的时候，设计好公链的架构，定义好模块的接口，然后，就可以让不同的团队用不同的编程语言去同时实现同一个模块，这并不是一个浪费，反而是事半功倍。比如，同样的虚拟机模块，根据同样的spec，我用C++，你用Go，他用Java。最后用哪种实现，是运行节点的选择。

区块链是一个全球的分布式系统，每个节点运行同样版本的系统，很容易引起全局性的安全问题。提出的多元性的工程开发模式和实践，能将这种代码实现引起的安全问题降到最低，从而保障整个公链的安全。