chain33开发随记

chain33 开发过程中的一些心得体会，分享给大家。

开发一个软件，最重要的问题，不是一开始就做一个很牛的架构，很好的任务分配，而是要“审时度势”。我理解的敏捷就是“审时度势”，根据人员情况，以及项目的情况，及时调整架构和工作流，开发软件是一个进化的过程。

如果做一件事情，他有固定的模式，这个东西就不能叫做艺术，而且一定不需要非常牛逼的人来做这个事情。软件开发之所以比较有趣，就是因为，没有固定的模式。要根据项目特点和人员情况来构造系统。

我比较喜欢的一种开发模式，就是不断的迭代和重构，从混沌走向秩序。一开始就设计好的架构，往往会和实际的编码情况脱离，所以，过度设计往往是一个好系统的最大的敌人。架构师必须参与开发的整个过程，并且实际的去写一些模块，才能对整个系统的问题以及缺陷有更深的体会，才能把握下一步重构进化的重点。

当然，要做到系统可以不断的迭代和重构，系统必须有非常好的测试系统。迭代和重构的过程中往往会引入很多的bug，这个时候，如果没有一套好的测试程序，那是非常危险和低效的事情。

chain33的整个开发过程都在 github的历史中可以找到，一开始，我们设计了一个模块分离的结构，把整个系统分成9个模块，并且通过一个queue模块 把模块松散耦合的连接起来。这个只是一个大的结构的分离，但是一个智能合约的执行，他会涉及很多的模块之间的配合，这个时候，你写一个合约，可能会涉及改很多个模块。比如我要完成一笔转账，那就会涉及 mempool，executor，store，blockchain，rpc 等模块的配合。如果有些业务逻辑比较特殊，我们可能要专门定制这些模块来配合这个业务逻辑。这样我们的系统就不够通用，如果开发人员必须修改内核才能完成业务的需要，就像一个操作系统需要修改内核满足需求一样不合理。

所以，关键的问题并不是合理的模块划分，而是每个模块必须做到可以定制，可替换。

共识模块，根据业务的需要，你必须要支持各种各样的共识算法，并做到可以插拔和扩展。目前，官方已经写了 raft , pbft, tendermint, safe pos, solo 等共识插件，提供给不同的需求使用。

存储模块，也是一样，在以太坊中，需要mpt树，是因为要支持轻钱包，而类似fabric的联盟链场景，或者 eos 这样的高效公链的场景，这个轻钱包的功能显的不太重要了，而性能变的更加重要，目前官方支持了 mavl, kvdb, mvcckvdb, mpt 等多类存储模式，其中mvcckvdb的性能是 mpt的20倍左右。当然，每个存储都有他的优点和缺点，适用不同的应用场景。

还有加密签名的方式，也可能需要定制，目前，我们提供了 sm2，ed25519，sep256k1 等。

当然，最重要的可扩展性，还在于区块链业务功能的可扩展，以太坊采用 evm的方式扩展，而eos 采用wasm的方式扩展。但是，实际上这个不够基本，evm 和 wasm 本身就是区块链的一个功能，他们自身就应该是一个扩展。所以，我们引入了一个执行器的概念，他是区块链的功能单元，也就是说，区块链要支持evm，那就添加一个 evm的执行器，要支持wasm，那就添加一个 wasm的执行器，也可以两个同时支持。

目前，我们官方提供了很多执行器，包括evm, coins, manage, token, 各种区块链游戏，还有提供了类似门罗币的隐私保护执行器。值得注意的时候，我们在共识的级别上专门做了一个随机数，这个随机数可以避免目前eos上的博彩游戏很容易就被攻击的情况。

这还不够，系统可扩展，可定制 这只是一个基础，还有一个重要的问题是分享。我开发的一个组件，可以通过配置文件的方式被别人的系统引用，并用工具自动下载源代码和编译。这个也是为什么docker 能够成功的原因，就是引入了镜像的分享功能，全世界的人都可以把自己的开发成果分享出来，并且互相使用。

如果你深入了解chain33，一定会考虑放弃自己开发一个区块链底层，而选择和chain33合作一起完善生态。

所有的这些想法不是一开始就被设计的，而是在不断的实践过程中，不断的重构的过程中形成的。当然，如果真的对未来的一切都毫无预测，那么必然会引起大量的返工，影响开发效率。所以，这个地方有一个平衡，而这个就是开发软件的魅力所在，用中医的理论来说，就是要做到阴阳平衡。

不过，在我看来，最重要的还不是上面说的这些。而是，对软件的一种态度，那就是 “不甘平凡，追求卓越”。