架构设计

整体设计原则

CITA-Cloud总体设计上依然采用微服务架构,划分为ControllerNetworkConsensusStorageExecutorKMS六个微服务。微服务之间相互解耦,达到不同实现可以灵活替换,自由组合的目的。

解耦设计的细节参见底层链技术白皮书

在此基础上,为了能够快速构建起完整的,成熟的生态。在之前解耦的基础上,让解耦出的每一个微服务都能独立完成某项功能,每个微服务的接口能够自洽,方便直接复用已有的库或者软件。

协议详解

Network

Network微服务,主要提供网络部分的功能,分为收/发两大部分功能。收的部分采用了控制反转,收到的网络报文根据报文头中的字段分发到不同的Grpc地址,因此只提供了一个注册接口(RegisterNetworkMsgHandler);发的部分提供了单播(SendMsg)和广播(Broadcast)两个接口。此外就是一个查询网络连接状态的接口(GetNetworkStatus)。

实现上就是已有网络库的简单封装。

其中一个实现network_direct直接使用系统网络库,内部实现为节点的全互联。另外一个实现network_p2p,使用了已有的一个p2p库。

Storage

Storage微服务,主要提供KV存储相关的功能,涵盖了常用的增删改查功能。接口上有:Store(其语义是updata,同时包含增和改的功能),LoadDelete

针对区块链业务,预先定义了不同的region

enum Regions {
    GLOBAL = 0;
    TRANSACTIONS = 1;
    HEADERS = 2;
    BODIES = 3;
    BLOCK_HASH = 4;
    PROOF = 5;
    RESULT = 6;
    TRANSACTION_HASH2BLOCK_HEIGHT = 7;
    BLOCK_HASH2BLOCK_HEIGHT = 8;  // In SQL db, reuse 4
    TRANSACTION_INDEX = 9;
    BUTTON = 10;
}

用户可以根据自己的需要调整region列表。

具体实现上,就是已有存储系统的简单封装。

当前实现有基于sqlitestorage_sqlite,基于rocksdbstorage_rocksdb,以及基于tikvstorage_tikv

region的实现,基于sqlite时是用不同的table来实现;基于tikv时是直接把region序列化之后拼接在key的前面;基于rocksdb时是用不同的ColumnFamily来实现。

KMS

KMS微服务,主要提供私钥加密存储,以及相关的密码学服务。接口有:GenerateKeyPairHashDataVerifyDataHashSignMessageRecoverSignature,形成——生成密钥对/哈希以及相关的验证/签名以及相关的验证——这么一个自洽的功能集合。此外还有一个查询接口GetCryptoInfo。可以认为是一个软件加密机加上一个密码学工具箱。

目前的实现kms_ethkms_sm,分别实现了secp256k1+keccaksm2+sm3两种密码学算法组合。

Executor

Executor微服务,主要提供根据交易改变链上状态以及查询链上状态的功能。接口有:ExecCall,分别对应执行和查询。

至于执行的细节,比如采用何种VM;状态有哪些内容;状态如何组织和保存,都由具体实现来决定。

后续会给出一些兼容已有链的特定实现,比如executor_chaincode就是兼容Fabric的实现。executor_evm则是兼容以太坊的实现。

也可以针对一些特定应用场景,提供特定的VM和智能合约编程语言。比如可信计算,隐私计算,数据格式转换等。

甚至可以不提供智能合约,直接针对具体应用实现,类似于原生合约。

Consensus

Consensus微服务,主要提供让提案在多个共识参与方之间达成一致的功能。接口包括:

  1. 实现在controller中的:GetProposal本节点提交的提案;CheckProposal检查别的节点提交的提案;CommitBlock确认一个提案。

  2. 实现在Consensus中的:CheckBlock检查同步自别的节点的已经确认的提案;Reconfigure处理系统配置变更。

单独这个微服务的功能,可以认为是一个分歧解决机。

实现上,目前尝试了PoX类型的consensus_proof_of_sleep,基于raftconsensus_raft,以及基于bftconsensus_bft

Controller

Controller微服务在整个区块链中处于核心的位置,主导所有主要的流程,并给上层用户提供RPC接口。

接口除了前述的针对Consensus微服务的接口,就是针对上层用户的RPC接口。其中最重要的是SendRawTransaction发送交易接口,剩下的都是一些信息查询接口。

单独就这个微服务来说,可以认为是一个提案管理系统。用户通过发送交易接口,提交原始交易数据,Controller管理这些原始交易数据。通过计算原始交易数据的哈希,组装CompactBlock,以及再次哈希,形成Consensus需要的提案,管理这些提案。这里所说的管理,包括持久化,同步,以及验证其合法性。

Blockchain.proto文件中定义了一套交易和块的数据结构,但是前面所述的从原始交易数据如何产生最终Consensus需要的提案,并且这个过程还是要可验证的,这些都由具体实现决定。未来我们会提供一个框架,方便用户自定义整个流程,甚至是自定义交易和块等核心数据结构。

实现上,目前只有一个controller_poc。主要模块还是以自己实现为主,只有同步模块使用了Syncthing。实现上的技术细节参见项目Wiki。整个实现的代码量还是比较大,后续会考虑进一步细化设计,让尽量多的模块能够复用已有的软件或者库。