架构设计
整体设计原则
CITA-Cloud
总体设计上依然采用微服务架构,划分为Controller
,Network
,Consensus
,Storage
,Executor
,KMS
六个微服务。微服务之间相互解耦,达到不同实现可以灵活替换,自由组合的目的。
解耦设计的细节参见底层链技术白皮书。
在此基础上,为了能够快速构建起完整的,成熟的生态。在之前解耦的基础上,让解耦出的每一个微服务都能独立完成某项功能,每个微服务的接口能够自洽,方便直接复用已有的库或者软件。
协议详解
Network
Network
微服务,主要提供网络部分的功能,分为收/发两大部分功能。收的部分采用了控制反转,收到的网络报文根据报文头中的字段分发到不同的Grpc
地址,因此只提供了一个注册接口(RegisterNetworkMsgHandler
);发的部分提供了单播(SendMsg
)和广播(Broadcast
)两个接口。此外就是一个查询网络连接状态的接口(GetNetworkStatus)。
实现上就是已有网络库的简单封装。
其中一个实现network_direct直接使用系统网络库,内部实现为节点的全互联。另外一个实现network_p2p,使用了已有的一个p2p
库。
Storage
Storage
微服务,主要提供KV
存储相关的功能,涵盖了常用的增删改查功能。接口上有:Store
(其语义是updata
,同时包含增和改的功能),Load
,Delete
。
针对区块链业务,预先定义了不同的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
列表。
具体实现上,就是已有存储系统的简单封装。
当前实现有基于sqlite
的storage_sqlite,基于rocksdb
的storage_rocksdb,以及基于tikv
的storage_tikv。
region
的实现,基于sqlite
时是用不同的table
来实现;基于tikv
时是直接把region
序列化之后拼接在key
的前面;基于rocksdb
时是用不同的ColumnFamily
来实现。
KMS
KMS
微服务,主要提供私钥加密存储,以及相关的密码学服务。接口有:GenerateKeyPair
,HashData
,VerifyDataHash
,SignMessage
,RecoverSignature
,形成——生成密钥对/哈希以及相关的验证/签名以及相关的验证——这么一个自洽的功能集合。此外还有一个查询接口GetCryptoInfo
。可以认为是一个软件加密机加上一个密码学工具箱。
Executor
Executor
微服务,主要提供根据交易改变链上状态以及查询链上状态的功能。接口有:Exec
和Call
,分别对应执行和查询。
至于执行的细节,比如采用何种VM
;状态有哪些内容;状态如何组织和保存,都由具体实现来决定。
后续会给出一些兼容已有链的特定实现,比如executor_chaincode就是兼容Fabric
的实现。executor_evm则是兼容以太坊
的实现。
也可以针对一些特定应用场景,提供特定的VM
和智能合约编程语言。比如可信计算,隐私计算,数据格式转换等。
甚至可以不提供智能合约,直接针对具体应用实现,类似于原生合约。
Consensus
Consensus
微服务,主要提供让提案在多个共识参与方之间达成一致的功能。接口包括:
实现在
controller
中的:GetProposal
本节点提交的提案;CheckProposal
检查别的节点提交的提案;CommitBlock
确认一个提案。实现在
Consensus
中的:CheckBlock
检查同步自别的节点的已经确认的提案;Reconfigure
处理系统配置变更。
单独这个微服务的功能,可以认为是一个分歧解决机。
实现上,目前尝试了PoX
类型的consensus_proof_of_sleep,基于raft
的consensus_raft,以及基于bft
的consensus_bft。
Controller
Controller
微服务在整个区块链中处于核心的位置,主导所有主要的流程,并给上层用户提供RPC
接口。
接口除了前述的针对Consensus
微服务的接口,就是针对上层用户的RPC
接口。其中最重要的是SendRawTransaction
发送交易接口,剩下的都是一些信息查询接口。
单独就这个微服务来说,可以认为是一个提案管理系统。用户通过发送交易接口,提交原始交易数据,Controller
管理这些原始交易数据。通过计算原始交易数据的哈希,组装CompactBlock
,以及再次哈希,形成Consensus
需要的提案,管理这些提案。这里所说的管理,包括持久化,同步,以及验证其合法性。
Blockchain.proto
文件中定义了一套交易和块的数据结构,但是前面所述的从原始交易数据如何产生最终Consensus
需要的提案,并且这个过程还是要可验证的,这些都由具体实现决定。未来我们会提供一个框架,方便用户自定义整个流程,甚至是自定义交易和块等核心数据结构。
实现上,目前只有一个controller_poc。主要模块还是以自己实现为主,只有同步模块使用了Syncthing
。实现上的技术细节参见项目Wiki。整个实现的代码量还是比较大,后续会考虑进一步细化设计,让尽量多的模块能够复用已有的软件或者库。