CITA-Cloud 文档

CITA-Cloud是云原生的区块链定制框架，使企业用户能够快速构建面向自身业务的区块链系统。

介绍

CITA-Cloud由国内区块链行业的先驱和资深人士创建，他们致力于克服区块链技术在企业应用领域的难点。

通过早期在国产高性能联盟链CITA上开发以及落地应用方面的经验积累，发现联盟链虽然在架构上和公链大体一致，但在技术选型，规模、运维、互操作性等方面有很大的不同。

CITA-Cloud是一个面向企业场景，灵活，开放，可互操作和云原生的区块链框架。

灵活

企业场景非常多变，单独一种实现无法满足所有场景。

CITA-Cloud采用微服务架构，组件可以灵活替换，针对场景定制最适合的链。

快速定制

每个微服务可以有多种不同的实现，相互之间可以替换。

用户根据需要选择适合的组件，无需底层开发，就可以快速定制一条适合具体场景链。

比如，客户原来使用Fabric，因此已经积累了一些使用chaincode编写的智能合约。

但是因为在某些项目中必须使用国密算法，而无法使用Fabric。

使用CITA-Cloud框架，只要executor_chaincode和kms_sm两个微服务实现的组合，就能同时实现复用chaincode编写的智能合约和支持国密的目标。

在企业场景中，用户需求场景非常多变，共识算法也可以有不同的选择。

使用CITA-Cloud框架，在consensus_bft和consensus_raft两个共识微服务实现之间选择即可，不用任何的额外工作。

场景定制

如果已有的组件都不能满足用户需求，可以针对场景定制某个组件。

同时可以复用其他已有的组件，达到快速定制的目标。

例如，某著名科研机构使用CITA-Cloud框架，只用了两周的时间就完成其自主研发的国密算法实现到微服务的封装，快速完成特定场景的定制。

开放

CITA-Cloud使用Apache 2.0开源协议，并提供定制所需的架构、开发工具，以及一个开放的社区。

架构

使用标准的微服务架构，本身只规定了微服务间的接口，给具体微服务实现留有非常大的发挥空间。

微服务划分采用正交分解方式，实现核心流程可定制，功能组件可替换的能力。

借鉴控制面和数据面分离的架构思想。将区块链相关的核心流程和核心数据全部集中在名为controller的微服务中，其他五个微服务则类似于数据平面，被动调用。

每一个微服务都能独立完成某项功能，接口能够自洽，保证每个微服务都是标准组件。

语言无关

微服务间通信使用gRPC和ProtoBuf的组合，各种语言的开发者都可以方便的参与。

在开发过程中可以选择最适合的语言，方便复用已有的软件栈或者库。

可互操作

随着联盟链在金融，政企领域的应用，越来越多的同构和异构的区块链应运而生。

在促进区块链生态环境日渐丰富的同时，也呈现出割裂和碎片化的趋势。

如何实现区块链之间的互操作，使不同区块链能够协同工作，这是一个非常重要的挑战。

智能合约生态

CITA-Cloud可以通过替换executor微服务的实现来兼容多种智能合约引擎。

目前兼容了以太坊和Fabric两个最大的智能合约生态，未来还可以针对具体场景兼容更多的链的生态。

比如针对隐私，支持基于零知识证明的合约引擎。

跨链协议

CITA-Cloud兼容陆羽跨链协议，实现对异构链的互操作。

陆羽跨链协议是一个面向可信源的互操作协议，旨在成为一套灵活、统一、可靠的互操作协议，实现对不同可信源的便捷接入与可靠操作。

云原生

区块链与云原生都是非常基础的分布式技术，采用云原生已有的发展思路对区块链来说是一条捷径，可以复用云原生社区成熟的资源。

联盟链的生态相比公链差很多，只有借助云原生社区的生态，才能有足够的发展空间。

区块链相比云原生更侧重去中心化的特性，两者可以互补。

复用成熟组件

区块链涉及的技术非常多，包括网络，存储，共识，智能合约引擎等。

完全自己开发，投入非常大，且达到企业级可靠性需要的时间比较漫长。

但是其中很多技术在云原生社区已经有成熟的组件。

CITA-Cloud可以方便的将已有的成熟技术封装成微服务实现。

前面提到的Raft共识算法，复用PingCAP的Raft实现。

此实现在PingCA的产品中使用多年，经过生产环境的检验。

复用此实现，节省了大量的开发测试人力，也使得该微服务实现可靠性直接达到生产可用级别。

BaaS服务

借助云原生的能力，CITA-Cloud可以提升相关资源管理能力，实现自动化运维。

支持同一条链的多个节点部署在异地集群，甚至是不同实体的多个集群中。

架构设计

CITA-Cloud总体设计上采用微服务架构，划分为Controller，Network，Consensus，Storage，Executor，Crypto六个微服务。

_images/micro_service.png

微服务架构图

微服务接口定义参见cita_cloud_proto。

微服务之间相互解耦，达到不同实现可以灵活替换，自由组合的目的。解耦设计的细节参见底层链技术白皮书。

为了能够快速构建起完整的，成熟的生态。在之前解耦的基础上，让解耦出的每一个微服务都能独立完成某项功能，每个微服务的接口能够自洽。使其不只是作为CITA-Cloud的组件存在，还可以拥有自己独立的生态。

Network

Network微服务，维护与其他节点之间的网络连接，为本节点的其他微服务提供网络服务。

主要功能有收/发网络消息和节点管理，状态查询。

接收网络消息

收的部分采用了控制反转，收到的网络消息根据消息头中的module字段分发到其他微服务，并通过回调其他微服务的gRPC接口的方式在微服务间传递网络消息。

因此只有一个注册接口，用于其他需要网络服务的微服务注册信息。

// 注册网络服务接口
rpc RegisterNetworkMsgHandler(RegisterInfo) returns (common.StatusCode);

// 注册网络服务所需的信息
message RegisterInfo {
    string module_name = 1;  // 微服务名称
    string hostname = 2;     // 网络消息分发时，回调地址的域名
    string port = 3;         // 网络消息分发时，回调地址的端口
}

// 网络消息分发时，回调的 gRPC 接口
// 注册网络服务的其他微服务必须实现该接口
service NetworkMsgHandlerService {
    rpc ProcessNetworkMsg(NetworkMsg) returns (common.StatusCode);
}

// 网络消息结构
message NetworkMsg {
    string module = 1;  // 接收的微服务名称
    string type = 2;    // 消息类型，用于在同一个微服务内区分不同的消息
    uint64 origin = 3;  // 消息的节点标识
    bytes msg = 4;      // 消息数据
}

发送网络消息

发的部分提供了单播(SendMsg)和广播(Broadcast)两个接口。

// 发送消息给一个特定的节点
// 通过消息中的 origin 字段指定接收节点的标识
rpc SendMsg(NetworkMsg) returns (common.StatusCode);

// 广播消息
// 消息中的 origin 字段被忽略
rpc Broadcast(NetworkMsg) returns (common.StatusCode);

关于消息中的origin字段，在收到网络消息之后，需要对其进行一个处理。

发送时填的是接收节点的标识，接收到之后会将该字段修改为发送节点的标识。

状态查询

message NetworkStatusResponse {
    uint64 peer_count = 1;
}

rpc GetNetworkStatus(common.Empty) returns (NetworkStatusResponse);

查询网络连接状态的接口，返回当前连接的节点数量。

注意，这个数量里不包括节点自身。因此，4个子节点的链，正常查询结果是3。

message NodeNetInfo {
    string multi_address = 1;
    uint64 origin = 2;
}

message TotalNodeNetInfo {
    repeated NodeNetInfo nodes = 1;
}

rpc GetPeersNetInfo(common.Empty) returns (common.TotalNodeNetInfo);

查询节点网络信息的接口，返回连接的邻居节点的网络地址和标识信息。

注意：网络微服务的实现可以是任意的网络协议，为了兼容不同的协议，这里展示用的是multi_address。

节点管理

message NodeNetInfo {
    string multi_address = 1;
    uint64 origin = 2;
}

rpc AddNode(common.NodeNetInfo) returns (common.StatusCode);

增加节点信息的接口(AddNode)，用于临时增加一个节点到网络中。

发展方向

独立出该微服务的初衷是网络部分比较复杂，希望该服务能隔离这部分复杂性，其他微服务就可以不用关心网络的具体情况。因此，其实现会朝着如下方向发展：

处理复杂的网络场景。比如，p2p，防火墙穿透，虚拟私有网络等场景。
对接多种协议。比如，TCP，UDP等。
提供更高的可靠性。比如，提供重发，限流，QoS，保证消息到达且仅到达一次等。

Storage

Storage微服务，主要提供KV存储相关的功能，涵盖了常用的增删改查功能。

用于保存交易，区块和一些链相关的全局信息。

存储分区

针对区块链业务，预先定义了不同的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;
    COMPACT_BLOCK = 10;
    FULL_BLOCK = 11;
    BUTTON = 12;
}

GLOBAL 保存链相关的全局信息，比如当前链的最新高度，当前链的最新区块Hash等，对应的key为自定义的固定值。

TRANSACTIONS 保存交易哈希 -> 交易原始数据的对应关系。

HEADERS 保存区块高度 -> 区块头数据的对应关系。

BODIES 保存区块高度 -> 区块体数据的对应关系。

BLOCK_HASH 保存区块高度 -> 区块哈希的对应关系。

PROOF 保存区块高度 -> 区块证明的对应关系。

RESULT 保存区块高度 -> 区块执行结果的对应关系。

TRANSACTION_HASH2BLOCK_HEIGHT 保存交易哈希 -> 交易所在区块高度的对应关系。

BLOCK_HASH2BLOCK_HEIGHT 保存区块哈希 -> 区块高度的对应关系。即 BLOCK_HASH 的反查。

TRANSACTION_INDEX 保存交易哈希 -> 交易在所在区块中的序号的对应关系。

COMPACT_BLOCK 保存区块高度 -> 紧凑区块的对应关系。

FULL_BLOCK 保存区块高度 -> 完整区块的对应关系。

定制开发者可以根据自己的需要调整region列表。

store

message Content {
    uint32 region = 1;
    bytes key = 2;
    bytes value = 3;
}

// store key/value
rpc Store(Content) returns (common.StatusCode);

其中region即前述存储分区的枚举值。

注意:

key和value类型为bytes，需要调用方提前进行类型转换。
其语义是updata，同时包含增和改的功能。

load

message ExtKey {
    uint32 region = 1;
    bytes key = 2;
}

message Value {
    common.StatusCode status = 1;
    bytes value = 2;
}

// given a ext key return value
rpc Load(ExtKey) returns (Value);

delete

message ExtKey {
    uint32 region = 1;
    bytes key = 2;
}

// given a ext key delete it
rpc Delete(ExtKey) returns (common.StatusCode);
}

发展方向

联盟链的存储压力相较公链会大很多，可靠性要求也更高。因此，其实现会朝着如下方向发展：

大数据量。比如，分布式数据库。
更多功能。比如，冷热数据分离，备份等。

Crypto

Crypto微服务，主要提供其他微服务需要的密码学服务。

目前提供区块链最基础的签名和哈希服务。

GetCryptoInfo

message GetCryptoInfoResponse {
    common.StatusCode status = 1;
    string name = 2;
    uint32 hash_len = 3;
    uint32 signature_len = 4;
    uint32 address_len = 5;
}

// Get crypto info
rpc GetCryptoInfo(common.Empty) returns (GetCryptoInfoResponse);

查询结果：

name 算法组合的名称。
hash_len 哈希算法得出的哈希值的字节长度。
signature_len 签名算法得出的签名的字节长度。
address_len 账户地址的字节长度。

签名

message SignMessageRequest {
    bytes msg = 2;
}

message SignMessageResponse {
    common.StatusCode status = 1;
    bytes signature = 2;
}

// Sign a message
rpc SignMessage(SignMessageRequest) returns (SignMessageResponse);

本接口入参为签名所使用的账户的序号和要签名的消息，返回数字签名。

message RecoverSignatureRequest {
    bytes msg = 1;
    bytes signature = 2;
}

message RecoverSignatureResponse {
    common.StatusCode status = 1;
    bytes address = 2;
}

// Recover signature
rpc RecoverSignature(RecoverSignatureRequest) returns (RecoverSignatureResponse);

本接口入参为消息和其对应的数字签名，返回执行签名的账户地址。

注意：从接口定义看，似乎只能支持能恢复出公钥的签名算法。但是实际上可以把公钥附在签名后面，模拟出能恢复出公钥的签名算法。

哈希

message HashDataRequest {
    bytes data = 1;
}

message Hash {
    bytes hash = 1;
}

message HashResponse {
    StatusCode status = 1;
    Hash hash = 2;
}

// Hash data
rpc HashData(HashDataRequest) returns (common.HashResponse);

本接口入参为要哈希的数据，返回哈希值。

message VerifyDataHashRequest {
    bytes data = 1;
    bytes hash = 2;
}

// Verify hash of data
rpc VerifyDataHash(VerifyDataHashRequest) returns (common.StatusCode);

本接口入参为要哈希的数据和相应的哈希值，返回校验结果。

CheckTransactions

// check transactions
rpc CheckTransactions(blockchain.RawTransactions) returns (common.StatusCode);

本接口用于批量校验交易。

因为交易验证过程中设计大量的密码学校验，如果每次都发起rpc调用性能会比较差。

可以认为是一个特殊的批量调用接口。

发展方向

密码学在区块链中至关重要，独立出该微服务的初衷是将系统与所使用的密码学算法解耦，方便将来替换密码学算法。

因此，其实现会朝着如下方向发展：

新密码学算法的支持。比如，更加安全，更加高效的密码学算法。
更多密码学相关功能集成。比如，对称加密，零知识证明等。

Executor

Executor微服务，提供智能合约能力。

根据交易内容执行对应的智能合约，改变链上状态或者查询链上状态的。

Exec

// exec a block return executed_block_hash
rpc Exec(blockchain.Block) returns (common.HashResponse);

本接口入参为一个完整的区块数据，返回执行完区块中所有交易后的状态结果。

此结果数据类型为哈希值，类似以太坊的state_root。

Call

message CallRequest {
    bytes to = 1;
    bytes from = 2;
    bytes method = 3;
    repeated bytes args = 4;
}

message CallResponse {
    bytes value = 1;
}

rpc Call(CallRequest) returns (CallResponse);

合约查询功能，调用合约中的指定方法，返回调用该方法的返回值。

发展方向

智能合约是区块链在可编程性方面很重要的功能。

该微服务只做了非常粗粒度的抽象，至于实现的细节，比如采用何种VM；状态有哪些内容；状态如何组织和保存，都由具体实现来决定。

其实现会朝着如下方向发展：

移植有广泛智能合约生态的引擎。比如，以太坊的EVM。
提供通用语言的Runtime，使得用户可以用通用编程语言编写智能合约，降低合约开发门槛。
针对一些特定应用场景，提供特定的VM和智能合约编程语言。比如可信计算，隐私计算，数据格式转换等。

Consensus

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

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

_images/consensus.png

共识微服务时序图

获取本节点提案

message Proposal {
    uint64 height = 1;
    bytes data = 2;
}

message ProposalResponse {
    StatusCode status = 1;
    Proposal proposal = 2;
}

rpc GetProposal(common.Empty) returns (common.ProposalResponse);

该接口实现在Controller微服务中,Consensus微服务去调用。

返回的提案数据类型为bytes，因为Consensus微服务不需要了解提案的具体内容。

检查其他节点的提案

rpc CheckProposal(common.Proposal) returns (common.StatusCode);

该接口实现在Controller微服务中,Consensus微服务去调用。

当本节点的Consensus微服务收到其他节点发送的提案，调用该接口检查提案是否合法。

提交共识结果

message ProposalWithProof {
    Proposal proposal = 1;
    bytes proof = 2;
}

message ConsensusConfiguration {
    uint64 height = 1;
    uint32 block_interval = 2;
    repeated bytes validators = 3;
}

message ConsensusConfigurationResponse {
    StatusCode status = 1;
    ConsensusConfiguration config = 2;
}

rpc CommitBlock(common.ProposalWithProof) returns (common.ConsensusConfigurationResponse);

该接口实现在Controller微服务中,Consensus微服务去调用。

共识达成之后，提交经过共识的提案以及相关证明，例如投票信息等。

Controller微服务会给Consensus微服务返回新的配置信息。

目前配置信息包括:

出块间隔。
共识参与方账户地址列表。

检查同步的提案

rpc CheckBlock(common.ProposalWithProof) returns (common.StatusCode);

该接口实现在Consensus微服务中,Controller微服务调用。

本节点进度落后的时候，Controller微服务会从其他节点同步已经共识过的提案及相关的证明。

Controller微服务本身无法验证证明是否合法，只能交由Consensus微服务来验证。

配置变更

rpc Reconfigure(common.ConsensusConfiguration) returns (common.StatusCode);

该接口实现在Consensus微服务中,Controller微服务调用。

发展方向

共识是区块链非常核心的功能，但是共识算法实现非常多样化。

该微服务尽量做到抽象，以适应不同的共识算法。

其实现会朝着如下方向发展：

更新更高效的共识算法。
针对一些特定应用场景。比如非拜占庭容错的共识算法等。

Controller

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

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

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

Blockchain.proto文件中定义了一套交易和区块的数据结构，但是前面所述的从原始交易数据如何产生最终Consensus需要的提案，并且这个过程还是要可验证的，这些都由具体实现决定。

发展方向

Controller微服务是整个区块链系统的控制中枢，其内部逻辑和流程非常复杂，可定制部分也比较多。

未来我们会进一步梳理该微服务，并尝试提供一个框架，方便用户自定义流程，甚至是自定义交易和块等核心数据结构。

组件

组件是各个微服务的实现。

每个组件单独一个代码仓库，仓库名称以微服务名称开头，下划线后接用于标识不同实现的名称。

构建物使用微服务名称，以便于相互替换。

比如storage_rocksdb，是基于rocksdb实现的Storage微服务，其构建物为可执行文件storage。

组件分为两类：

原厂组件，即CITA-Cloud自带的组件。
第三方组件。

组件还有以下一些指标：

组件的成熟度：1-5，1表示仅实现必要的功能的最小实现，5表示非常成熟的实现。
组件的状态：开发中，维护中，废弃。
组件的授权状态：商业，或者开源。

原厂组件

network_p2p

介绍：基于网络库tentacle实现。

特点：

支持secio，通信加密保证安全。
支持多路复用(yamux)，可以自定义协议。
支持节点发现，节点之间会自动交换连接的节点信息。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

network_tls

介绍：基于tokio-rustls实现。

特点：

支持TLS1.3，通信加密保证安全。
使用标准的x509证书，方便复用已有的基础设施。
支持白名单，便于权限管理。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

network_quic

介绍：基于QUIC网络协议的实现。

特点：

高效，基于UDP协议，开销更小。
安全，默认支持TLS，通信加密。
可靠，弱网络下效果更高。

代码仓库

镜像仓库

成熟度： 2

状态：开发中

授权：开源，Apache-2.0 License

storage_rocksdb

介绍：基于rocksdb的实现。

特点：

高效，KV数据库，读写效率高。
可靠，多数区块链项目都使用rocksdb作为存储引擎，稳定性好。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

storage_sled

介绍：基于sled的实现。

特点：

高效，读写效率高。
目前尚未稳定。

代码仓库

镜像仓库

成熟度： 2

状态：开发中

授权：开源，Apache-2.0 License

crypto_sm

介绍：国密算法的实现，使用sm2签名算法和sm3哈希算法。

特点：

符合中国国家密码标准。
高效，纯Rust实现，采用多种优化技术。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

crypto_eth

介绍：兼容以太坊算法的实现，使用secp256k1签名算法和keccak哈希算法。

特点：

兼容以太坊。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

executor_evm

介绍：基于以太坊的EVM实现。

特点：

兼容以太坊的智能合约生态。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

consensus_bft

介绍：基于CITA-BFT实现。

特点：

拜占庭容错。
线性消息复杂度。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

consensus_raft

介绍：基于Raft实现。

特点：

非拜占庭容错。
成熟实现，稳定可靠。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

consensus_overlord

介绍：基于overlord实现。

特点：

拜占庭容错。
成熟实现。
线性消息复杂度。

代码仓库

镜像仓库

成熟度： 2

状态：开发中

授权：开源，Apache-2.0 License

controller

介绍：目前唯一的Controller实现。

特点：

先共识后执行。
高性能，流水线式并行。
utxo模型的系统配置管理。
丰富的治理功能。

代码仓库

镜像仓库

成熟度： 4

状态：维护中

授权：开源，Apache-2.0 License

废弃组件

network_direct

介绍：基于tokio网络库的实现。

特点：

网络直连，简单可靠
无通信加密

代码仓库

镜像仓库

成熟度： 3

状态：废弃

授权：开源，Apache-2.0 License

废弃原因：被network_tls替代。因为区块链的去中心化属性，网络通信加密是比较基础的需求。

storage_sqlite

介绍：基于sqlite的实现。

特点：

轻量，嵌入式数据库，开销小。
功能丰富，完整支持SQL。

代码仓库

镜像仓库

成熟度： 3

状态：废弃

授权：开源，Apache-2.0 License

废弃原因：被storage_rocksdb替代。目前区块链的实现中主要还是以KV存储为主，SQL数据库的优势发挥不出来，反而性能上不如KV数据库。也许将来对链上数据分析有更多需求的时候可以切换至SQL数据库。

storage_tikv

介绍：基于tikv的实现。

特点：

扩展能力强，分布式KV数据库。
稳定可靠，支持分布式事务操作，得到广泛应用。

代码仓库

镜像仓库

成熟度： 2

状态：废弃

授权：开源，Apache-2.0 License

废弃原因：这个组件主要就是验证使用分布式KV数据库的可行性。但是目前数据量还没有到这个程度，所以暂时搁置。

executor_chaincode

介绍：实验性兼容Fabric Chaincode实现。

特点：

兼容Fabric的智能合约生态。

代码仓库

镜像仓库

成熟度： 1

状态：废弃

授权：开源，Apache-2.0 License

废弃原因：本身就是实验性质的组件，为了验证框架有足够的灵活性。后期有相关需求之后完善之后成为executor_chaincode_ext。

第三方组件

废弃组件

executor_chaincode_ext

介绍：增强型兼容Fabric Chaincode实现。

特点：

兼容chaincode合约。
支持了CouchDB。
增加了chaincode事件相关功能。

代码仓库：无镜像仓库：无

成熟度： 3

状态：废弃

授权：商业

废弃原因：专门为某个商业项目定制，后续没有类似的需求。

kms_sdibc

介绍：基于高性能国密算法实现。

特点：

性能好。

代码仓库：无镜像仓库：无

成熟度： 4

状态：废弃

授权：商业

废弃原因：专门为某个商业项目定制，后续没有类似的需求。

部署指南

因为采用微服务架构，相比单体软件来说，运维部署比较复杂。

例如：微服务之间如何相互调用；启动顺序如何保证；配置项如何管理等等。

所幸微服务架构已经非常流行，相应的基础设施也已经非常成熟。其中最重要的一点就是云原生技术的发展，它大大简化了微服务架构的应用在运维部署，配置管理方面的工作。

运行环境

CITA-Cloud推荐的运行环境为k8s集群。

对于开发，可以是minikube等单机版本的k8s集群。
对于测试，可以是几台机器搭建的简单的k8s集群。
对于生产环境，推荐有专人维护的高可用k8s集群，或者云厂商提供的容器云方案。

其优点是：

不同环境的操作方式是统一的。
功能灵活，强大。可以实现各种复杂的配置，自动化运维等。
生态繁荣。基于云原生社区，有非常多成熟的配套工具和解决方案。

部署一条CITA-Cloud产生的链，除了准备好运行环境，还需要事先进行持久化存储和网络的设置。

持久化存储

链的节点是有状态的服务，需要挂载持久化存储保存数据。

为了方便对接不同类型的存储服务，我们使用了k8s中的PV/PVC概念对存储进行了抽象。

建议由运维人员配置StorageClass，对PV/PVC实行动态绑定。

对于开发环境，可以使用简单的hostPath，在宿主机本地存储。
对于测试环境，可以使用NFS，由单独一台磁盘比较大的机器提供存储。
对于生产环境，推荐使用各种成熟的云存储，分布式存储，NAS等专业存储系统。

网络

网络方面，需要微服务之间，以及节点之间可以通过网络相互访问。

目前推荐的部署方式是，一个节点一个Pod，里面包含6个微服务的容器。

微服务之间可以直接通过本地环回网络通信。

节点间的网络通信，如果所有节点都在一个k8s集群内部，可以通过k8s的Service来暴露节点的网络端口。如果是跨集群的情况，则需要使用NodePort或者LoaderBalancer等服务对外暴露节点的网络端口。

工具

配置工具

当前的配置工具为cloud-config，用于生成一条链多个节点，以及每个节点内多个微服务的配置文件。

该配置工具支持常用的大部分组件；适用于各种场景，开发或是生产，单集群或者多集群；支持多种配置模式，集中式，去中心化方式。

具体使用方法，请参考代码仓库中的README。

Chart工程

为了简化部署工作，按照云原生的指导原则，提供了Charts工程。

使用Helm工具，可以实现一条命令完成一条链的部署。

注意：

该Charts工程已经包含了配置功能，无需再单独使用配置工具。
该Charts工程支持多种场景和环境，单集群/多集群，开发环境/公有云环境。

具体使用方法，请参考代码仓库中的README。

Operator

区块链类似于数据库，但与数据库又有一些不同的地方。相同的是都是有状态的服务，不同的是区块链在备份，迁移，升级，扩容等运维操作时都有特殊的要求。

对于备份来说，区块链每个节点都是一个副本，相当于自带热备方案。冷备也跟数据库不一样，不是按时间（比如每天备份），而是要考虑区块高度。
对于迁移和升级来说，区块链的节点是有身份的，因此不能先部署新的节点，再停老的节点，而是要反过来。
对于扩容来说，增加节点并不能提升区块链的性能，反而会造成反效果，只能扩容cpu，内存。存储也必须所有节点一起扩充。

因此，比较简单的配置部署工作，Charts工程就足以支撑。一旦涉及到比较复杂的运维操作，则需要一些定制开发。而Operator在k8s领域就是用来扩展自定义功能的。

我们的Operator以CRD的形式自定义了Account/Chain/Node等高层的资源类型，并提供了对这些自定义资源的操作方法。进一步简化了配置部署工作，同时也为将来提供复杂的运维功能打下了坚实的基础。

基于Operator的工具有以下几个部分：

Operator本身cita-cloud-operator。
代理服务端operator-proxy。
代理客户端cco-cli。

注意：

Operator已经包含了配置功能，无需再单独使用配置工具。
cita-cloud-operator作为一个标准的Operator可以单独使用。
代理服务端和客户端cco-cli进一步降低了操作难度，无需用户编写yaml文件。

具体使用方法，请参考代码仓库中的README。

快速入门

本章介绍的是使用minikube作为运行环境，使用默认推荐的组件，快速搭建一条链的操作方法。

关于更加深入的定制操作，请参阅定制章节。

环境准备

硬件配置建议

CPU：4核或以上
内存：8GB或以上
硬盘：30G或以上

软件依赖

操作系统

常见的Linux发行版本均可，例如：CentOS，Debian，Ubuntu等等。

docker

安装方法参见官方文档。

Helm

Helm是Kubernetes的包管理器，是寻找、共享和使用为Kubernetes构建的软件的最佳方式。

安装方法参见文档。

minikube

安装方法参见官方文档。

安装完成后用下面的命令启动minikube，国内需要在启动minikube时设置一些镜像参数。

注意不能使用root权限启动minikube。

minikube start --registry-mirror=https://hub-mirror.c.163.com --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers --vm-driver=docker --alsologtostderr -v=8 --base-image registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.17

耐心等待，看到以下信息代表启动成功。

* Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

kubectl

kubectl是Kubernetes集群的命令行工具，通过kubectl能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。

安装方法参见官方文档。

cloud-cli

该工具为CITA-Cloud链的命令行客户端，可以方便的对链进行常用的操作。

使用方法参见文档。

$ wget https://github.com/cita-cloud/cloud-cli/releases/download/v0.4.0/cldi-x86_64-unknown-linux-musl.tar.gz
$ tar zxvf cldi-x86_64-unknown-linux-musl.tar.gz
$ sudo mv ./cldi /usr/local/bin/
$ cldi -h
$ cldi -h
cldi 0.4.0
Rivtower Technologies <contact@rivtower.com>
The command line interface to interact with CITA-Cloud

USAGE:
    cldi [OPTIONS] [SUBCOMMAND]

OPTIONS:
    -c, --context <context>       context setting
    -r <controller-addr>          controller address
    -e <executor-addr>            executor address
    -u <account-name>             account name
        --crypto <crypto-type>    The crypto type of the target chain [possible values: SM, ETH]
    -h, --help                    Print help information
    -V, --version                 Print version information

SUBCOMMANDS:
    get            Get data from chain
    send           Send transaction
    call           Call executor
    create         create an EVM contract
    context        Context commands
    account        Account commands
    admin          The admin commands for managing chain
    rpc            Other RPC commands
    ethabi         Ethereum ABI coder.
    bench          Simple benchmarks
    watch          Watch blocks
    completions    Generate completions for current shell. Add the output script to `.profile`
                       or `.bashrc` etc. to make it effective.
    help           Print this message or the help of the given subcommand(s)

运行链

添加Charts仓库

$ helm repo add cita-cloud https://cita-cloud.github.io/charts
$ helm repo update
$ helm search repo cita-cloud/
NAME                                            CHART VERSION   APP VERSION     DESCRIPTION
cita-cloud/cita-cloud-aliyun-lb                 6.4.0           6.4.0           Setup CITA-Cloud node SLB in aliyun
cita-cloud/cita-cloud-config                    6.4.0           6.4.0           Create a job to change config of CITA-Cloud blo...
cita-cloud/cita-cloud-huaweiyun-lb              6.4.0           6.4.0           A Helm chart for Kubernetes
cita-cloud/cita-cloud-local-cluster             6.4.0           6.4.0           Setup CITA-Cloud blockchain in one k8s cluster
cita-cloud/cita-cloud-multi-cluster-node        6.4.0           6.4.0           Setup CITA-Cloud node in multi k8s cluster
cita-cloud/cita-cloud-nodeport                  6.4.0           6.4.0           A Helm chart for Kubernetes
cita-cloud/cita-cloud-porter-lb                 6.4.0           6.4.0           Setup porter Loadbalancer for CITA-Cloud node
cita-cloud/cita-cloud-pvc                       6.4.0           6.4.0           Create PVC for CITA-Cloud

创建PVC

PVC(PersistentVolumeClaim)是对PV的申请(Claim)。PVC通常由普通用户创建和维护。需要为Pod分配存储资源时，用户可以创建一个PVC，指明使用的StorageClass，Kubemetes会动态创建并绑定相关的PV。

这里使用的是minikube自带的名为standard的StorageClass。

$ helm install local-pvc cita-cloud/cita-cloud-pvc --set scName=standard
$ kubectl get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
local-pvc   Bound    pvc-fd3eaebd-3413-4205-b88a-dbc6cee9a057   10Gi       RWO            standard        18m

对应的路径在minikube虚拟机内的/tmp/hostpath-provisioner/default/local-pvc。

注意：如果minikube版本为 v1.20.0，这里会有一个bug。详细情况和解决方法参见链接。

生成超级管理员账户

使用 cldi 创建账户

$ cldi account generate -h
cldi-account-generate
generate a new account

USAGE:
    cldi account generate [OPTIONS]

OPTIONS:
        --name <name>             The name for the new generated account, default to account address
    -p, --password <password>     The password to encrypt the account
        --crypto <crypto-type>    The crypto type for the generated account. [default: <current-
                                  context-crypto-type>] [possible values: SM, ETH]
    -h, --help                    Print help information

为了演示方便，这里不设置密码，加密算法也使用默认值。

$ cldi account generate --name admin
{
  "crypto_type": "SM",
  "address": "0xc8ca9cc77a7f822fdd0baef7a7740f9dba493455",
  "public_key": "0x0d9edfd3889ec752e92fb1aa53fdfc26512c6a0ea39deb12510e7ac4d0915c4d4f0a18a3c1cf2a5950319d429af38b13483e2ccc9bafd698f5ce2c7ef558ddf6",
  "secret_key": "0x50dc0c1655419938d83d924a3c3b4cbbd57de5df901ce4772272445605a52d43"
}

启动链

$ helm install test-chain cita-cloud/cita-cloud-local-cluster --set config.superAdmin=0xc8ca9cc77a7f822fdd0baef7a7740f9dba493455
NAME: test-chain
LAST DEPLOYED: Thu Mar 24 02:48:52 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1

该命令会创建一条有4个节点，名为test-chain的链。

注意：superAdmin参数必须设置为自己生成的账户地址，此处仅为演示，切勿在正式环境中使用演示值。

查看运行情况

$ kubectl get pod
NAME                                               READY   STATUS    RESTARTS   AGE
test-chain-0                                       7/7     Running   0          8m3s
test-chain-1                                       7/7     Running   0          8m3s
test-chain-2                                       7/7     Running   0          8m3s
test-chain-3                                       7/7     Running   0          8m3s

查看日志：

$ minikube ssh
docker@minikube:~$ tail -10f /tmp/hostpath-provisioner/default/local-pvc/test-chain-0/logs/controller-service.log
2022-03-24T02:57:41.562867997+00:00 INFO controller::node_manager - update node: 0x6028b1113a9ac5f79d2fdfb37ca135812d675691
2022-03-24T02:57:43.863863944+00:00 INFO controller::controller - chain_check_proposal: add remote proposal(0x90543745dee079d9a37d2b5bd1e026ad092089c1f3fd88ebbc16b10b3d1926f3)
2022-03-24T02:57:43.864261069+00:00 INFO controller::controller - chain_check_proposal: finished
2022-03-24T02:57:44.441848936+00:00 INFO controller::chain - height: 103 hash 0x90543745dee079d9a37d2b5bd1e026ad092089c1f3fd88ebbc16b10b3d1926f3
2022-03-24T02:57:44.672342679+00:00 INFO controller::node_manager - update node: 0x6028b1113a9ac5f79d2fdfb37ca135812d675691
2022-03-24T02:57:44.672366020+00:00 INFO controller::controller - update global status node(0x6028b1113a9ac5f79d2fdfb37ca135812d675691) height(103)
2022-03-24T02:57:44.673242652+00:00 INFO controller::chain - exec_block(103): status: Success, executed_block_hash: 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421
2022-03-24T02:57:44.783682991+00:00 INFO controller::chain - finalize_block: 103, block_hash: 0x90543745dee079d9a37d2b5bd1e026ad092089c1f3fd88ebbc16b10b3d1926f3

基本操作

指定链的RPC端口

链有两个rpc地址，分别是controller和executor微服务。

我们可以通过-r和-e来告诉cldi如何访问链：

默认链会开启nodeport，端口分别为30004和30005。

参数为:

-r `minikube ip`:30004 -e `minikube ip`:30005

注意：这里minikube可能出现Service端口映射问题。可以换一种操作方式。

$ kubectl port-forward pod/test-chain-0 50002:50002 50004:50004

参数为：

-r localhost:50004 -e localhost:50002

查看块高

$ cldi -r localhost:50004 -e localhost:50002 get block-number
246

查看系统配置

$ cldi -r localhost:50004 -e localhost:50002 get system-config
{
  "admin": "0xc8ca9cc77a7f822fdd0baef7a7740f9dba493455",
  "admin_pre_hash": "0x000000000000000000000000000000000000000000000000000000000000000000",
  "block_interval": 3,
  "block_interval_pre_hash": "0x000000000000000000000000000000000000000000000000000000000000000000",
  "chain_id": "0x63586a3c0255f337c77a777ff54f0040b8c388da04f23ecee6bfd4953a6512b4",
  "chain_id_pre_hash": "0x000000000000000000000000000000000000000000000000000000000000000000",
  "emergency_brake": false,
  "emergency_brake_pre_hash": "0x000000000000000000000000000000000000000000000000000000000000000000",
  "validators": [
    "0x40283e85bfbe778a0ef0ee80688861ccc2c557a2",
    "0x7b9e332f91fe894da0260fe2207f021d2d24008c",
    "0x014146185e3b32e64f0d06021aa6fff8639d134a",
    "0x6028b1113a9ac5f79d2fdfb37ca135812d675691"
  ],
  "validators_pre_hash": "0x000000000000000000000000000000000000000000000000000000000000000000",
  "version": 0,
  "version_pre_hash": "0x000000000000000000000000000000000000000000000000000000000000000000"
}

停止链

$ helm uninstall test-chain
release "test-chain" uninstalled

删除链

$ helm install clean cita-cloud/cita-cloud-config --set config.action.type=clean
NAME: clean
LAST DEPLOYED: Thu Mar 24 02:47:45 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

注意：该命令将永久性的删除链的所有数据，请谨慎操作。

账户操作

创建账户

$ cldi account generate --name user
{
  "crypto_type": "SM",
  "address": "0xf4b80a27b7d526028183e705604b865c1458c838",
  "public_key": "0x71ebc3701780b4ac6a6ae0817e2fa402fb26082e6eade00f117015a1063a5c3af6e1f74c26c01f87af5ddea20fb28ff6d1a20f5438416afe95e9247ab2e517ce",
  "secret_key": "0x2757242a6138e9617b30ec63f6a240b880d25851d86d9d15849f2d45061d3288"
}

选择操作使用的账户

$ cldi -u user -r localhost:50004 -e localhost:50002
cldi> 

-u选择使用该账户，后续将以该账户的身份发送交易。

进入cldi的交互式模式。

发送交易

编译合约

这里以Counter合约为例:

$ cat Counter.sol 
pragma solidity ^0.4.24;

contract Counter {
    uint public count;
    
    function add() public {
        count += 1;
    }
    
    function reset() public {
        count = 0;
    }
}

$ curl -o solc -L https://github.com/ethereum/solidity/releases/download/v0.4.24/solc-static-linux
$ chmod +x solc
$ sudo mv ./solc /usr/local/bin/
$ solc --hashes --bin Counter.sol 

======= Counter.sol:Counter =======
Binary: 
608060405234801561001057600080fd5b5060f58061001f6000396000f3006080604052600436106053576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306661abd1460585780634f2be91f146080578063d826f88f146094575b600080fd5b348015606357600080fd5b50606a60a8565b6040518082815260200191505060405180910390f35b348015608b57600080fd5b50609260ae565b005b348015609f57600080fd5b5060a660c0565b005b60005481565b60016000808282540192505081905550565b600080819055505600a165627a7a72305820a841f5848c8c68bc957103089b41e192a79aed7ac2aebaf35ae1e36469bd44d90029
Function signatures: 
4f2be91f: add()
06661abd: count()
d826f88f: reset()

创建合约

cldi> create 0x608060405234801561001057600080fd5b5060f58061001f6000396000f3006080604052600436106053576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306661abd1460585780634f2be91f146080578063d826f88f146094575b600080fd5b348015606357600080fd5b50606a60a8565b6040518082815260200191505060405180910390f35b348015608b57600080fd5b50609260ae565b005b348015609f57600080fd5b5060a660c0565b005b60005481565b60016000808282540192505081905550565b600080819055505600a165627a7a72305820faa1d1f51d7b5ca2b200e0f6cdef4f2d7e44ee686209e300beb1146f40d32dee0029
0xf18153579e86b4d81617bf9d3b34e1ca2d0433296927f4b04d5c5219d2d82d46

创建合约的参数是编译合约输出的二进制字节码，注意前面要增加0x前缀。

返回值为这笔创建合约交易的交易哈希。

查看交易回执

cldi> get receipt 0xf18153579e86b4d81617bf9d3b34e1ca2d0433296927f4b04d5c5219d2d82d46
{
  "block_number": 454,
  "contract_addr": "0xa4582f4966bdef3a2839e2f256a714426508ddb7",
  "cumulative_quota_used": "0x0000000000000000000000000000000000000000000000000000000000018ed3",
  "error_msg": "",
  "legacy_cita_block_hash": "0x09b2e445d5b3a5e118bb0aad8d812d237ff24f2aa9e37da75e5c68d43ddcdbba",
  "logs": [],
  "logs_bloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "quota_used": "0x0000000000000000000000000000000000000000000000000000000000018ed3",
  "state_root": "0x28913fc520eaf50c72fad929d0f57c94ad487bfd63278a57cb40ef370a7697a0",
  "tx_hash": "0xf18153579e86b4d81617bf9d3b34e1ca2d0433296927f4b04d5c5219d2d82d46",
  "tx_index": 0
}

参数为前一步操作返回的交易哈希。

返回值为该笔交易的执行结果信息，其中contract_addr字段为刚才部署的合约的地址。

得到合约地址后，就可以调用其中的方法。

查询合约状态

查询合约中的count值：

cldi> call 0xa4582f4966bdef3a2839e2f256a714426508ddb7 0x06661abd
0x0000000000000000000000000000000000000000000000000000000000000000

第一个参数为合约地址。

第二个参数为要调用的count()方法的函数签名。

返回值为count的当前值。

发送交易

向合约发送交易，调用add方法改变count的值：

cldi> send 0xa4582f4966bdef3a2839e2f256a714426508ddb7 0x4f2be91f
0x24f0bc60340c49e875a8701e80849725a0a10e1bf47990e8c9cb399e31acea05

第一个参数为合约地址。

第二个参数为要调用的add()方法的函数签名。

等待交易上链之后，再次查询就可以发现合约状态有了变化：

cldi> call 0xa4582f4966bdef3a2839e2f256a714426508ddb7 0x06661abd
0x0000000000000000000000000000000000000000000000000000000000000001

定制

CITA-Cloud本身不是一条链，而是一个区块链定制框架，定位类似于Substrate和Cosmos SDK。

但是Substrate和Cosmos SDK更类似于传统的应用开发框架，比如Java的Spring。框架提供一些现成的功能组件和代码自动生成的功能，目的是简化定制开发工作，但是仍然需要进行代码开发。

而CITA-Cloud沿袭了一直以来的微服务架构，并进一步结合了云原生的思想，更类似于PaaS化的开发框架。用户可以不需要代码开发，通过选择并配置组件来构建一条链；也可以根据自己的特殊需求来定制开发相应的组件，结合已有的其他组件构建一条链。

定制链

CITA-Cloud划分为Controller，Network，Consensus，Storage，Executor，Crypto六个微服务，详情参见架构设计章节。

用户可以从现有的组件（参见组件章节）中，根据自己的场景选择6个组件，每个组件必须对应一个前述的微服务，即可组合成一条链。类似于：

_images/kfc.jpg

具体配置方法，参考部署指南章节配置工具部分。

定制组件

定制有两种方式：

fork现有组件（参见组件章节），对其进行定制化开发。
已有对应某个微服务的功能完善的库，新实现一个组件。

对于后一种情况，参考架构设计章节对应的微服务部分，封装已有的库，实现对应的gRPC接口，然后提供对应的Docker镜像。

路线图

2020.4 项目启动
2020.8 白皮书发布
2020.10 首个版本发布
2021.7 v6.0.0发布，协议稳定，将作为长期支持大版本
2022.3 引入Rollup方案，协议再次大升级，筹备v7.0.0

版本发布

历史版本

v6.4.0

更新概览：本次版本在稳定性和运维方面做了逐多优化，如果你想要多方共同参与创建联盟链，同时又不想暴露自己的私钥，那么你可以关心gitops这一新功能；如果你担心自己的机器哪天会爆炸，那么你可以关注cloud-op新的快照功能；如果你想要想要节省硬盘运维开销，那么你可以关注execuotr-evm的full mode模式，这比过去的archive mode在硬盘占用上有不少的提升。主要更新内容如下：

集成测试的搭建
cita-cloud集成gitops
运维工具cloud-op提供快照功能
提供输出完整区块的RPC接口，同时cloud-cli完成支持
execuotr-evm支持full mode和archive mode切换
charts增加微服务资源限制
controller正确处理节点重连和关机情况
network-tls的TLS证书支持多级证书体系
cita-cloud增加了健康检查(livness check)
executor_evm的evm升级到London

Controller

[Feature]

[feat] add inner block growth check @Pencil-Yao[feat] add rpc get_block_detail_by_number @JLerxky[feat] add health check @Pencil-Yao[feat] add health check @rink1969

[Fix]

[fix] repeat node set @Pencil-Yao

[Optimization]

[optim] handle repeat & idle node @Pencil-Yao[optim] hanle the same origin node @Pencil-Yao[optim] record package limit in utxo db @NaughtyDogOfSchrodinger

consensus_raft

[Feature]

[feat] add health check @rink1969

consensus_bft

[Feature]

[feat] add health check @rink1969

[Optimization]

[optim] optimize handle commit entries @NaughtyDogOfSchrodinger

cloud-config

[Feature]

[feat] add livness probe @rink1969[feat] Support gitops @rink1969[feat] add container resource requirements @rink1969

[Fix]

[fix] panic when create-dev @rink1969[fix] update node, protect rewrite file in used @rink1969

executor_evm

[Feature]

[feat] add health check @rink1969[feat] add base_fee opcode @JLerxky[feat] support switch between full mode and archive mode @Pencil-Yao

storage_rocksdb

[Feature]

[feat] add health check @rink1969

kms_sm

[Feature]

[feat] add health check @rink1969

network_tls

[Feature]

[feat] add health check @rink1969

[Optimization]

[optim] update dependence tokio-rustls and unit-test @Pencil-Yao

network_p2p

[Feature]

[feat] add health check @rink1969 kms_eth

[Feature]

[feat] add health check @rink1969

cloud-cli

[Feature]

[feat] add get_block_detail @JLerxky[feat] add set-package-limit and set-block-limit sub-command @NaughtyDogOfSchrodinger

[Optimization]

[optim] use cloud proto @JLerxky

兼容性问题

数据兼容 v6.4.0 与 v6.3.3 以及 v6.3.4 数据完全兼容。旧有的 v6.3.3 以及 v6.3.4 链跑出来的数据，只需要停链然后使用新的 v6.4.0 镜像启动，就可以正常出块。
版本兼容 v6.4.0 与 v6.3.3 以及 v6.3.4 版本的节点可以混合组成网络，并正常出块
配置变更 v6.4.0 与 v6.3.3 以及 v6.3.4 的配置未发生修改或减少

遗留问题

WAL损坏问题。
增加删除节点会报错。

v6.3.3

本次版本在稳定性和运维方面做了优化，主要更新内容如下：

修复上个版本 WAL 功能引入的问题。
支持消块工具。可以修复因为意外导致区块链节点数据不一致的问题。
梳理微服务的命令行参数。参数统一从配置文件传递，配置更清晰，更统一。也为将来支持gitops打下基础。
network支持配置文件热更新。增加删除节点之后，已有节点可以自动感知到网络的变化。
CLI重构。新增交互式模式，优化用户体验。参见文档。
更新文档。新的文档更加面向链的定制开发者。参见文档。
k8s Operator实验性支持。参见项目。

修改详情：

Controller

[Feature]

[feat] update readme @rink1969 @JLerxky

[feat] Support cloud-op @Pencil-Yao @JLerxky

[Fix]

[fix] Add the judgment of not redoing wal @JLerxky

[fix] save current_block_hash before saving current_block_height @Pencil-Yao

[Optimization]

[optim] handle add existed peer @Jayanring

[optim] use cloud_util::wal @JLerxky

[optim] run -c & -l @JLerxky

consensus_raft

[Feature]

[feat] update readme @rink1969 @NaughtyDogOfSchrodinger

[feat] support recover @Pencil-Yao

consensus_bft

[Feature]

[feat] update readme @NaughtyDogOfSchrodinger

[feat] Support cloud-op @Pencil-Yao @JLerxky

[Optimization]

[optim] use cloud_util::wal @JLerxky

[optim] run -c & -l @JLerxky

cloud-config

[Feature]

[feat] Update k8s subcmd @NaughtyDogOfSchrodinger

[feat] output stdout and log file at same time @rink1969

[Fix]

[fix] fix typo @rink1969

[fix] add license and copyright info @rink1969

[fix] update images @rink1969

[fix] fix update node, protect rewrite file in used @rink1969

[Optimization]

[optim] github ci & fix: fmt @Pencil-Yao @Jayanring

[chore] update clap @JLerxky

executor_evm

[Feature]

[feat] update readme @rink1969

[feat] Support cloud-op @Pencil-Yao @JLerxky

[Optimization]

[optim] run -c & -l @JLerxky

storage_rocksdb

[Feature]

[feat] update readme @rink1969

[feat] Support cloud-op @Pencil-Yao @JLerxky

[Optimization]

[optim] run -c & -l @JLerxky

kms_sm

[Feature]

[feat] remove create subcmd; update example and readme @rink1969

[Optimization]

[optim] run -c & -l @JLerxky

network_tls

[Feature]

[feat] update readme @rink1969

[feat] support hot update + peer-count + origin @Pencil-Yao @Jayanring

[Optimization]

[optim] run -c @JLerxky

network_p2p

[Feature]

[feat] update readme @rink1969

[Optimization]

[optim] run -c & -l @JLerxky

kms_eth

[Feature]

[feat] remove create subcmd; update example and readme @rink1969

[Fix]

[fix] check invalid msg @rink1969

[Optimization]

[optim] run -c & -l @JLerxky

兼容性问题

数据兼容

v6.3.3 与 v6.3.2 数据完全兼容。旧有的 v6.3.2 链跑出来的数据，只需要停链然后使用新的 v6.3.3 镜像启动，就可以正常出块。
版本兼容

v6.3.3 与 v6.3.2 版本的节点可以混合组成网络，并正常出块
配置变更

微服务的参数有变化，但是采用默认值的情况下，行为与v6.3.2一致。

如果有自行设置参数的情况，可能需要进行修改。

遗留问题

WAL损坏问题。

v6.3.2

本次版本更新对稳定性和运维作了优化，稳定性方面链能够在高负载的情况下更稳定的运行，主要更新内容如下：

优化了 consensus_bft 由于网络时延问题导致的无法正常出块的问题；
controller 具备 WAL 的能力，可以处理进程突然被杀掉而引发的存储问题。
升级的微服务添加了 apache license

修改详情：

Controller 

[Feature]

[feat] add wal [@JLerxky @Pencil-Yao @Jayanring]

[feat] support retransmit chain_status_init regularly [@Pencil-Yao ]

[feat] store genesis system config [@JLerxky @Jayanring]

[Fix]

[fix] executor init [@Pencil-Yao]

[fix] in csi mode, can’t send block request [@Pencil-Yao]

[fix] dup tx in busy environment [@Pencil-Yao]

[Optimization]

[optim] confirm executor when init chain [@Jayanring]

[optim] process earlystatus logic [@Pencil-Yao ]

[optim] chain lock [@Pencil-Yao ]

Consensus_bft 

[Fix]

[fix] handle leader_commit error with dup-tx [@Pencil-Yao ]

Executor_evm 

[Feature]

[feat] hanle same or invalid block re-enter [@Pencil-Yao ]

[Optimization]

[optim] use reenter-invalid block code [@Pencil-Yao ]

Cloud-config 

[Feature]

[feat] rewrite! from cita_cloud_config [@NaughtyDogOfSchrodinger, @Pencil-Yao ]

[feat] support config [@NaughtyDogOfSchrodinger ]

[BugFix]

[fix] fix series 6.3.0 adaption problem [@Pencil-Yao, @NaughtyDogOfSchrodinger ]

兼容性问题

数据兼容

v6.3.2 与 v6.3.1 数据完全兼容。旧有的 v6.3.1 链跑出来的数据，只需要停链然后使用新的 v6.3.2 镜像启动，就可以正常出块。
版本兼容

v6.3.2 与 v6.3.1 版本的节点可以混合组成网络，并正常出块

常见问题

ALL #0 - 所有集成环境，如果后续增加集成环境也包含在内
BST 链 #1 - BST 单链集成环境
REP 链 #2 - REP 单链集成环境

Syntax	Description
问题现象	节点重启时，很快出现报错并退出: ProposalTooLow, src/chain.rs:715
出现频率	必现
链	ALL #0
影响版本	v6.3.2
问题原因	怀疑机器磁盘io占用较高，导致删除WAL文件的时候的出现了堵塞
解决方法	备份 ./data/wal_chain 目录后，将./data/wal_chain 目录内除 index 文件之外的其它文件删除重启当前节点