区块链BaaS云服务（29） 溪塔科技 CITA-Cloud 二

Posted 2021-08-27 thefist11

1. 共识服务 Consensus

交易通过可证数据结构凝结成不可篡改的历史，在被执行器处理之后形成的数据我们称之为视图（View），记录用户账户余额的账本即是视图的一种。

• 不同的区块链设计对于视图是否需要共识有不同的态度。
• 对视图数据进行共识，有利于发现交易处理中的问题；将视图的特征值固化在区块中，- 有利于节点间视图数据的交换，是轻节点验证和跨链协议的重要基础。

1.1 反屏蔽

作为一种多参与方的共享服务，保证使用者发出的交易能够在一定的时间内被处理。

CITA 使用出块节点主动轮换策略以满足反屏蔽的要求。

• 默认的顺序轮换能够满足一般应用的需要，同时也提供随机轮换作为扩展模块。

• 在产生新区块后

1.2 CITA-BFT 共识

CITA-BFT 是一种高性能共识算法。在 PBFT，Tendermint 的基础上，针对企业级区块链的网络结构和数据结构进行了深度的改造和优化，在保证安全性的基础上（可容忍不超过节点总数 1/3 的拜占庭节点），实现了极高的吞吐量。

• 可以方便的被替换成任何更合适的共识算法，只要实现共识服务标准接口，替换算法可以用任意语言实现。
• 共识算法替换往往涉及网络、存储等多个方面，很难被完美抽象，因此共识算法的替换可能不仅仅需要共识服务的替换，还需要同步对其他微服务进行定制。

2. 交易处理服务

2.1 异步交易处理（ATE）

CITA 将共识与交易处理解耦为独立的微服务，共识服务只负责交易排序，并不关心交易内容，交易处理服务只负责对排好顺序的交易进行处理。

此时共识过程可以先于交易处理完成，交易处理服务可以异步执行。异步交易处理技术不仅使 CITA 具有更好的共识性能，还带来了更有弹性的交易处理能力，交易负荷可以被更均匀的分摊到一段时间内（见图2）。

由于交易异步处理，在共识前只能对交易进行有限的检查，例如签名验证。无效的交易有可能通过共识进入交易处理服务，产生一定程度的垃圾数据。在有必要的情况下，可以通过 CITA 的交易配额机制及垃圾清理技术解决该问题。

2.2 执行器 Executor

相对于交易列表，应用更关心的数据是视图。执行器以排好序的交易为输入，在处理过程中相应的更新对应的视图。即使处理的是相同的交易列表，不同的执行器可以产生不同的视图。CITA 默认支持如下执行器：

1. NOOP: 最简单的执行器，对传入的交易不做任何处理。
2. Native: 原生执行，将交易通过标准接口交给原生代码执行。
3. EVM: 对以太坊虚拟机的封装，可以处理以太坊轻量智能合约的部署和调用。
4. Private: 隐私交易处理，详见隐私交易。
5. Hybrid: 混合执行器，能够组合执行器形成新的执行器。
   

2.3 视图状态模型

视图状态则是执行器执行过程中读写的对象，不同的使用不同的基本数据单元。CITA 默认支持账户模型。用户可以自定义包括 UTXO 在内的其他状态模型。

• UTXO 模型
  由 UTXO 构成账本视图，每个交易在销毁旧有 UTXO 的同时创造新的 UTXO；
  包含交易前后记账单位数量不变约束，引入了业务逻辑，放弃了一定的通用性;将账户状态离散保存在多个 UTXO 中，获得了有限的并行能力提升，也带来了分割/合并 UTXO 的复杂度。

• 账户模型
  由账户构成世界状态视图，交易在处理过程中可以读写多个账户。
  实现通用任务更有效率。在企业级应用中往往存在身份验证与授权的需要，这些服务所依赖的数据可以自然的与账户关联。

2.4 配额 Quota

类似于以太坊的gas，在 CITA 中我们将资源的度量称为计算配额，相应的发行和消耗机制称为配额管理。配额消耗和发行策略都可以由具有权限的用户制定。

• 不同的执行器具有不同的配额消耗机制。例如，NOOP 执行器按照交易数据大小计算配额消耗，Native 执行器随着真实世界的时钟跳动计算消耗，而 EVM 自带细粒度的 GAS 计算机制，按照指令复杂度计算配额消耗。

• 可以为区块(中的视图）或是用户设置配额消耗上限，以此将控制单个区块的资源消耗。

• 许可链中往往无需配额消耗。CITA 中的配额发行策略非常灵活，不仅默认支持包括周期性恢复在内的简单策略，也可以根据需要自定义复杂策略。

3. 视图 View

实现了多执行策略支持与基本的并行处理。

• 用户在配置 CITA 区块链网络时可以设定多个视图，视图相互独立。每个视图都可以设定对应的交易执行器和状态存储模型，并将交易执行器注册到交易路由。交易在经过共识服务排序后，由交易路由分配到不同的执行器处理（见图3）。不同视图处理的交易子集可以有交集，也可以没有交集。

• 全面的支持各种应用场景。例如配置 NOOP 执行器的视图能够很好的支持数据存证的场景，避免不必要的执行开销；Native 执行器与账户模型的组合适合业务逻辑比较固定的场景，同时能够获得很好的性能；EVM执行器与账户模型组合适用于业务逻辑灵活多变的场景。

由于使用独立的状态存储，CITA 支持对不同的视图使用独立的交易处理服务并行处理。在配置了多个视图的 CITA 区块链网络中，系统处理能力几乎与可以与视图数量成正比。

3.1 隐私交易

当前问题：

• 基于假名（psedonymous）的隐私保护，只能在一定程度上隐藏交易的发起方和接收方, 通过数据分析手段还是能获得交易方信息。在使用临时私钥对交易加密的方案中，共识节点依然需要对交易进行解密才能执行交易，交易对共识节点没有隐私。

• 零知识证明以及同态加并不成熟

交易局部执行技术，实现了一种实用的隐私方案。
step1. 隐私交易提交后，先在本地进行加密，加密后的交易通过点对点隐私交易传输协议被传送给拥有解密私钥的节点，同时交易哈希被打包进入区块链。
step2. 隐私交易数据只在拥有解密私钥的相关节点上保存，相关节点先解密再执行交易，交易数据不会发送给无关节点，完全杜绝了任何信息泄漏的可能。

4 身份验证与授权服务

区块链中的参与方可分为节点和用户两类。

• 节点：区块链服务的提供者
  节点身份验证提供了标准接口，同时对节点接入进行更严格的控制。对于身份验证失败的节点，即使该节点能够在网络层与其他 CITA 节点联通，CITA 节点也会拒绝与其建立通讯会话，避免信息泄漏。

• 用户：区块链服务的消费者

CITA 为用户身份验证提供了标准接口，能够方便的与企业内已有的身份验证服务集成。例如 LDAP 或是 PKI 证书体系。

• 身份验证服务支持更复杂的身份管理策略，在用户私钥丢失或是定期更新时，具有私钥更新权限的操作者可以根据用户申请使用新的私钥替换旧的私钥。

• 实现了基于角色的权限控制（Role-based access control）。

• 为可供用户操作的资源进行了细粒度的划分和权限定义，并允许用户自定义角色，用户可以通过角色方便的组织用户、管理资源权限，使权限分配准确匹配企业的组织架构。同时权限与角色数据和变更历史都会被保存在区块链上，满足日后审计需要。

5 系统治理

CITA 以交易历史不可修改为设计原则，支持各种治理机构以及视图订正。

• 用户可以设定超级管理员角色，超级管理员角色可以有任意的身份验证逻辑。在单中心的治理结构下该角色可以由单一核心用户控制，在多中心的治理结构下，核心用户可以形成类似委员会的治理机构联合控制（例如通过多重签名）超级管理员角色。
• 中心化治理角色能够通过链外通道协商形成一致行动决议，增强系统在紧急情况下的应对能力。
• 在操作错误、软件错误或是硬件错误等问题发生时，系统可能进入紧急状态。

5.1紧急状态

• 交易可恢复（Transaction Recoverable）
  由于错误的交易或者是有 bug 的智能合约生成了错误的视图数据，但是节点依然能够处理交易，此时系统处于交易可恢复紧急状态。超级管理员可以构造修订交易快速应对。节点在处理修订交易时同样会先将该交易打包入块，再执行交易，因此所有修订交易都将被记录在历史中，为操作审计提供支持。

• 消息可修复（Message Recoverable）
  节点无法再正常处理交易并打包，共识服务停滞，但是点对点网络依然能够正常工作。此时超级管理员可以通过 CITA 提供的管理员工具构造特殊消息并广播，节点收到消息并验证发送者身份后将直接处理，无需共识。