企业级区块链（也称联盟链）主要针对大型公司、政府机构和产业联盟的区块链技术需求，提供企业级的区块链网络解决方案。联盟链的各个节点通常对应一个实体的机构组织，节点的加入和退出需要经过授权。各个机构组成利益相关的联盟，共同维护区块链网络的健康运转。
与私有链和公有链不同，企业级区块链更加着眼于区块链技术的实际落地，在区块链的性能速度和安全性、成员认证管理、数据隐私保护上有着更高的要求。除此之外，企业级区块链的研发往往直接和实际业务场景相关联，更加贴近行业痛点，为企业联盟提供一套更加完善的一体化区块链解决方案。
图展示了联盟链平台和区块链应用之间的相互促进关系。一方面，联盟链平台为实际行业应用研发、落地提供了底层技术支撑；另一方面，行业应用以及概念的验证落地也推动着联盟链平台的不断发展成熟。
Hyperchain 支持企业基于现有云平台快速部署、扩展和配置管理区块链网络，对区块链网络的运行状态进行实时可视化监控，是符合 ChinaLedger 技术规范的国产区块链核心系统平台。Hyperchain 具有验证节点授权机制、多级加密机制、共识机制、图灵完备的高性能智能合约执行引擎等核心特性，是一个功能完善、性能高效的联盟链基础技术平台。在面向企业和产业联盟需求的应用场景中，Hyperchain 能够为资产数字化、数据存证、供应链金融、数字票据、支付清算等多中心应用提供优质的底层区块链支撑技术平台和便捷可靠的一体化解决方案。
hyperchain 的整体系统架构如图
对于企业级联盟链基础技术平台，我们主要考虑以下基本特性：
-
参与者的成员身份认证许可机制
-
商业交易数据的安全与隐私
-
较高的交易吞吐量和较低的交易延迟
-
安全完备的智能合约引擎
-
高用户体验的互操作性
对于参与者成员身份认证许可机制，平台有如下功能。
-
联盟自治 ACO。平台许可在联盟链网络中创建联盟链自治成员组织，通过提案的形式进行提交和组织内部表决联盟中的状态行为，如系统升级、合约升级、成员管理等，这种方式为区块链联盟治理提供了一种有效模式。
-
成员管理。平台通过 CA 体系认证的方式实现了联盟成员的准入控制，支持自建 CA 和 CFCA 两种模式，并提供链级管理员、节点管理员以及普通用户的分级权限管理机制，实现不同的权限访问控制。
对于交易数据的安全和隐私，平台有如下功能。
-
多级加密机制。采用可插拔的加密机制，对于业务完整生命周期所涉及的数据、用户、通信连接等方面都进行了不同策略的加密，通过多级加密保证平台数据的安全，而且完全支持国密算法。
-
隐私保护。平台提供了 Namespace 分区共识和隐私交易两种机制实现隐私保护。其中分区共识将敏感交易数据的存储和执行空间进行隔离，允许部分区块链节点创建属于自己的分区，分区成员之间的数据交易以及存储对其他分区中的节点不可见。而隐私交易通过在发送时指定该笔交易的相关方，该交易明细只在相关方存储，隐私交易的哈希在全网共识后存储，既保证了隐私数据的有效隔离，又可验证该隐私交易的真实性。
-
可信数据源。区块链是一个封闭的确定性的环境，链上无法主动获取链外真实世界的数据，平台引入了 Oracle 预言机机制，支持将外界信息写入区块链内，完成区块链与现实世界的数据互通，并且该预言机通过第三方可信机构签名实现信任背书，满足可证诚实的要求。
对于吞吐量以及交易延迟，平台有如下功能。
-
高效共识算法。平台采用 RBFT（Robust Byzantine Fault-Tolerant，高健壮性拜占庭容错算法）共识算法，在保证节点数据强一致性的前提下，提升系统整体交易吞吐能力以及系统稳定性，TPS（每秒处理交易数量）达到万级，延时可控制在 300 ms 以内，同时平台可使用基于 GPU 的验签加速，进一步提升整体性能，充分满足区块链商业应用的需求，并且支持动态节点管理和失效恢复机制，增强了共识模块的容错性和可用性。后续将集成其他共识算法（如 RAFT）以适配不同的业务场景需求。
-
数据分离。区块链中账本数据主要分为区块数据和状态数据两部分，考虑到区块数据会不断增长，而状态数据只会频繁更新，平台引入了 Filelog 存储引擎，实现区块数据与状态数据的分离，保证在系统数据量不断增大的情况下读写性能不受影响。
对于安全完备的智能合约引擎，平台有如下功能。
-
平台支持 EVM、JVM、HVM 等多种智能合约引擎；
-
支持 Solidity、Java 等编程语言；
-
提供完善的合约生命周期管理；
-
具有编程友好、合约安全、执行高效的特性，可以适应多变复杂的业务场景。
对于高用户体验的互操作性，平台有如下功能。
-
数据归档。为解决区块链中块链式存储数据无限增长的问题，我们通过数据归档的方式将一部分旧的线上数据归档移到线下转存，同时提供了 Archive Reader 用于归档数据浏览。
-
数据可视化。为方便用户实时查阅区块链上的合约状态数据，平台提供了一个数据可视化组件 Radar，能够在区块链正常运行的同时将区块链中的合约状态数据导入关系型数据库（如 MySQL）中，使得合约状态可视化、可监控，方便商业应用的业务统计和分析。
-
消息订阅。平台提供统一的消息订阅接口，以便外部系统捕获、监听区块链平台的状态变化，从而实现链上链下的消息互通，支持区块事件、合约事件、交易事件、系统异常监控等事件的订阅。
接下来就以 Hyperchain 为例，阐述构成企业级区块链平台的核心技术模块，主要就共识算法、智能合约、账本、安全机制以及数据管理等方面的实现原理进行深入分析。
共识算法是保证区块链平台各节点账本数据一致的关键，目前常见的分布式系统一致性算法包括 PoW、PoS、Paxos、Raft、PBFT 等。其中 PoW 依赖机器的计算能力获取账本的记账权，资源消耗较高且可监管性弱，每次交易共识的达成需要全网共同参与计算，因此不适合联盟链对监管以及性能的要求 PoS 的主要思想是节点获得记账权的难度与其持有的权益数量成反比，相比 PoW 性能较好，但是依然存在可监管性弱的问题。Paxos 和 Raft 是传统分布式系统的一致性成熟解决方案，此类型算法的性能高、消耗资源低，但是不具备对拜占庭节点的容错。PBFT 算法同 Paxos 算法的处理流程类似，是一种许可投票、少数服从多数的共识机制。该算法具备容忍拜占庭错误的能力，且能够允许强监管节点的参与，算法性能较高，适合企业级平台的开发。目前主流的企业级区块链解决方案 Fabric 和 Hyperchain 都提供了 PBFT 的实现方案。然而原生 PBFT 算法在可靠性与灵活性方面不够完善，Hyperchain 平台对可靠性与灵活性进行了增强，设计实现了 PBFT 的改进算法，即 RBFT。
-
RBFT 概述
Hyperchain 的共识模块采用可拔插的模块化设计，能够针对不同的业务场景需求选择配置不同的共识算法，目前支持 PBFT 的改进算法 RBFT。Hyperchain 通过优化 PBFT 的执行过程，增加主动恢复与动态节点增删等机制，极大地提高了传统 PBFT 的可靠性与性能。RBFT 能够将交易的延时控制在 300 ms，并且最高可以支持每秒上万笔的交易量，为区块链的商业应用提供了稳定高性能的算法保障。下面就 RBFT 的核心算法进行详细阐述。
-
RBFT 常规流程
RBFT 的常规流程保证了区块链各节点以相同的顺序处理来自客户端的交易。RBFT 同 PBFT 的容错能力相同，需要至少 3f+1 个节点才能容忍f个拜占庭错误。图 6.3 中的示例为最少集群节点数，其f的值为 1。图中的 Primary 为区块链节点中动态选举出来的主节点，负责对客户端消息的排序打包，Replica 节点为备份节点，所有 Replica 节点与 Primary 节点执行交易的逻辑相同，Replica 节点能够在 Primary 节点失效时参与新 Primary 节点的选举。
RBFT 的共识保留了 PBFT 原有的三阶段处理流程（PrePrepare、Prepare、Commit），但是穿插增加了重要的交易验证环节。
RBFT 算法的常规共识流程如下所示。
(1) Client 将交易发送到区块链中的任意节点。
(2) Replica 节点接收到交易之后转发给 Primary 节点，Primary 自身也能直接接收交易消息。
(3) Primary 会将收到的交易进行打包，生成 batch 进行验证，剔除其中的非法交易。
(4) Primary 将验证通过的 batch 构造 PrePrepare 消息广播给其他节点，这里只广播批量交易的哈希值。
(5) Replica 接收来自 Primary 的 PrePrepare 消息之后构造 Prepare 消息发送给其他 Replica 节点，表明该节点接收到来自主节点的 PrePrepare 消息并认可主节点的 batch 排序。
(6) Replica 接收到 2f个节点的 Prepare 消息之后对 batch 的消息进行合法性验证，验证通过之后向其他节点广播 Commit 消息，表示自己同意了 Primary 节点的验证结果。
(7) Replica 节点接收到 2f+1 个 Commit 之后执行 batch 中的交易并同主节点的执行结果进行验证，验证通过将会写入本地账本，并通过检查点（checkpoint）来进行结果校验的步骤，检查点规则可配置。
由以上的 RBFT 常规流程可以看出，RBFT 将交易的验证流程穿插于共识算法的整个流程中，做到了对写入区块结果的共识。首先，Primary 节点接收到交易之后首先进行验证，这保证了平台的算力不会被非法交易所消耗，使 Replica 节点能够高效地处理 Primary 节点的拜占庭失效。其次，Replica 节点在接收到 2f个 Prepare 消息之后对 Primary 节点的验证结果进行验证，如果结果验证不通过则会触发 ViewChange 消息，这再一次保证了系统的安全性。
在 PBFT 算法中，参与共识的节点可根据角色分为主节点（Primary）和从节点（Replica），从节点会将自己收到的交易转发给主节点，主节点最重要的功能就是将收到的所有交易按照一定策略打包成块，让所有节点参与共识验证。那么，一个很自然的问题就是，如果主节点发生宕机、系统错误或者被攻占（即成为拜占庭节点），其他从节点如何才能及时发现主节点的异常并选举产生新的主节点继续共识？这是保证 BFT 类算法稳定性必须要解决的问题。
PBFT 和 RBFT 中都引入了视图（View）的概念，每次更换一个主节点同时切换视图，视图更换（ViewChange）机制是保证整个共识算法健壮性的关键。
目前能够检测到的主节点的拜占庭行为有 3 种情景：
(1) 节点停止工作，不再发送任何消息；
(2) 节点发送错误的消息，错误可能是消息内容不正确、包含恶意交易的消息等，需要注意的是，这里的消息类型可能是 batch，也可能是用于视图更换的功能性消息；
(3) 伪装正常节点，发送正确的消息。
对于情景 (1)，可以由 nullRequest 机制保证，行为正确的主节点会在没有交易发生时向所有从节点发送 nullRequest 来说明这一情况的属实性，如果从节点在规定时间内没有收到主节点的 nullRequest，则会引发视图更换行为选举新的主节点。
对于情景 (2)，从节点在接收主节点的消息时，会通过验证机制检测对内容进行相应的判断，如果发现主节点的交易包含不符合相应格式的交易或者恶意交易，即验证不通过，会发起视图更换选举新的主节点。
对于情景 (3)，无须考虑，一个极端的情形是，如果一个拜占庭节点在行为上一直像正常节点那样工作，那么可以认为它不是一个拜占庭节点，由整个系统保证结果的正确性。
从节点检测到主节点有以上异常情况或者接收来自其他f+1 个节点的视图更换消息之后会向全网广播视图更换消息。当新主节点收到N-f 个视图更换消息时，会发送 NewView 消息。从节点接收到 NewView 消息之后进行消息的验证和对比，验证视图的切换信息相同之后正式更换视图并打印 FinishVC 消息，从而完成整个视图更换流程，如图 6.5 所示（其中 ViewChange 代表视图更换、Primary 代表主节点，Replica 代表从节点）
区块链网络在运行过程中由于网络抖动、突然断电、磁盘故障等原因，可能会导致部分节点的执行速度落后于大多数节点或者直接宕机。在这种场景下，节点需要自动恢复并将账本同步到当前区块链的最新账本状态，才能参与后续的交易执行。为了解决这类数据恢复工作，RBFT 算法提供了一种动态数据自动恢复机制。
RBFT 的自动恢复机制通过主动索取区块和正在共识的区块信息，使自身节点的存储尽快和系统中的最新存储状态一致。自动恢复机制大大增强了整个区块链系统的可用性。RBFT 为了恢复的方便，对执行的数据设置检查点，检查点是通过全网共识的结果。这样就保证了每个节点上检查点之前的数据都是一致的。除了检查点之外，还有部分数据存储的是当前还未共识的本地执行进度。这样在恢复过程中，首先需要本节点的检查点与区块链其他正常服务节点的检查点同步。其次需要恢复检查点之外的部分数据。图 6.6 为检查点的示意图，左边为检查点部分，右边为当前执行检查点之外的部分。图 6.7 所示是自动恢复机制的基本处理流程。
在联盟链场景下，由于联盟的扩展或者某些成员的退出，需要联盟链支持成员的动态进出服务，而传统的 PBFT 算法不支持节点的动态增删。RBFT 为了能够更加方便地控制联盟成员的准入和准出，为 PBFT 添加了保持集群非停机的情况下动态增删节点的功能。如图 6.8 所示，RBFT 为新节点加入了算法处理流程。
新的节点需要得到证书颁发机构颁发的证书，然后向联盟中的所有节点发送请求。各个节点确认同意后会向联盟中的其他节点进行全网广播，当一个节点得到 2f+1 个同意加入的回复后，会与新的节点建立连接。其次，当新的节点和N-f（N为区块链联盟节点总数）个节点建立连接后就可以执行主动恢复算法，同步区块链联盟成员的最新状态。再次，新节点再向主节点请求加入常规共识流程。最后，主节点确认过新节点的请求后会定义在哪个块号后需要改变节点总数N来共识（确保新节点的加入不会影响原有的共识，因为新节点的加入会导致全网共识N的改变，意味着f值可能改变）。
RBFT 节点的动态删除和节点的动态增加流程类似，其主要处理函数如图 6.9 所示，其主要流程如下。
(1) 退出节点需要通过调用 RPC 请求得到本节点的哈希值，然后向全网所有节点发起退出请求。
(2) 接收到删除请求的节点的管理员确认同意该节点退出，然后向全网广播 DelNode 消息，表明自己同意该节点退出整个区块链共识的请求。
(3) 当现有节点收到 2f+1 条 DelNode 消息后，该节点更新连接信息，断开与请求退出的节点间的连接；并在断开连接之后向全网广播 AgreeUpdateN 消息，表明请求整个系统暂停执行交易的处理行为，为更新整个系统参与共识的N，view 做准备。
(4) 当节点收到 2f+1 个 AgreeUpdateN 消息后，更新节点系统状态。
动态节点退出函数调用
至此，请求退出节点正式退出区块链系统。
以上便是 Hyperchain 改进版的共识算法 RBFT 的主要算法流程。RBFT 通过增加常规共识流程中的验证步骤，增加节点自动恢复机制，增加动态节点加入以及删除等功能，比传统 PBFT 算法更加稳定、灵活、高效，可以更好地满足企业级联盟链的生产环境需求。动态节点退出函数调用
至此，请求退出节点正式退出区块链系统。
以上便是 Hyperchain 改进版的共识算法 RBFT 的主要算法流程。RBFT 通过增加常规共识流程中的验证步骤，增加节点自动恢复机制，增加动态节点加入以及删除等功能，比传统 PBFT 算法更加稳定、灵活、高效，可以更好地满足企业级联盟链的生产环境需求。
P2P 网络是节点之间共识和信息传递的通道，是 Hyperchain 的网络基础。
网络通信模块主要由 Node 、Peer 和加密传输 3 个子模块构成。Node 子模块主要用于提供本节点的 gRPC 调用服务，作为服务端存在。Peer 子模块主要作为本节点向其他节点请求时的客户端。加密模块采用 ECDH 密钥协商算法，生成只有两个节点间认可的密钥，然后基于增强版的 AES 对称加密节点间传输的数据，保证数据传输的安全。
-
Hyperchain 的主要架构设计是将 Peer 和 Node 分离开来，Peer 为上层模块提供消息发送接口。而 Node 主要负责接收消息并将消息抛往上层：接收各节点的信息，然后作为一个消息分发路由，将各类消息 post 到各层。Peer 和 Node 都通过 gRPCManager 进行管理，用于控制各层的通信和分发，实现 Peer 对外暴露接口以及真正控制节点的各个状态。在 P2P 模块中也实现了各模块相互分离，由一个控制层进行控制，子模块各司其职。
-
节点类型
Hyperchain 的节点分为验证节点（VP）和非验证节点（NVP）两类：
-
验证节点是指区块链网络中参与共识验证的节点；
-
非验证节点在区块链网络中不参与共识验证，仅参与记账。
NVP 主要用来做交易转发和灾备，不会自己处理交易，也不参与共识，因而需要依靠相连的 VP 来保证与全网状态的最终一致性。但 NVP 可以接收交易，并将收到的交易转发给相连的 VP 进行处理。
VP 不会主动连接 NVP，所以当 VP 重启后，与其相连的 NVP 会全部断开且不会自动重连，需要手动连接。而 NVP 拥有完善的状态恢复机制，能够在刚刚启动或其他原因导致状态落后之后及时同步。
VP 之间通过 gRPC 远程调用服务实现通信构成 P2P 网络，其中 gRPC 服务采用 protobuf3 进行数据的序列化和反序列化，能够确保数据的完整和传输的高效和安全。
-
-
流控机制
底层平台可根据业务需要对允许进入区块链系统的流量进行人为控制，当系统流量超过系统设置的上限时，会对超过部分拒绝接收。这样可以 Hyperchain 的主要架构设计是将 Peer 和 Node 分离开来，Peer 为上层模块提供消息发送接口。而 Node 主要负责接收消息并将消息抛往上层：接收各节点的信息，然后作为一个消息分发路由，将各类消息 post 到各层。Peer 和 Node 都通过 gRPCManager 进行管理，用于控制各层的通信和分发，实现 Peer 对外暴露接口以及真正控制节点的各个状态。在 P2P 模块中也实现了各模块相互分离，由一个控制层进行控制，子模块各司其职。
-
节点类型
Hyperchain 的节点分为验证节点（VP）和非验证节点（NVP）两类：
-
验证节点是指区块链网络中参与共识验证的节点；
-
非验证节点在区块链网络中不参与共识验证，仅参与记账。
NVP 主要用来做交易转发和灾备，不会自己处理交易，也不参与共识，因而需要依靠相连的 VP 来保证与全网状态的最终一致性。但 NVP 可以接收交易，并将收到的交易转发给相连的 VP 进行处理。
VP 不会主动连接 NVP，所以当 VP 重启后，与其相连的 NVP 会全部断开且不会自动重连，需要手动连接。而 NVP 拥有完善的状态恢复机制，能够在刚刚启动或其他原因导致状态落后之后及时同步。
VP 之间通过 gRPC 远程调用服务实现通信构成 P2P 网络，其中 gRPC 服务采用 protobuf3 进行数据的序列化和反序列化，能够确保数据的完整和传输的高效和安全。
-
-
流控机制
底层平台可根据业务需要对允许进入区块链系统的流量进行人为控制，当系统流量超过系统设置的上限时，会对超过部分拒绝接收。这样可以
防止网络通信过程中因大量无用交易请求占用了节点处理时间而耽误其他交易，从而在满足业务要求的前提下保证系统的安全性。
可通过配置文件对合约交易以及普通交易进行按需流量配置。配置项及配置信息如表
智能合约是部署在区块链上的一段可以自动执行的程序，广泛意义上的智能合约包含编程语言、编译器、虚拟机、事件、状态机、容错机制等。其中，对应用程序开发影响较大的是编程语言以及智能合约的执行引擎，即虚拟机。虚拟机作为沙盒被封装起来，整个执行环境被完全隔离。虚拟机内部执行的智能合约不能接触网络、文件系统或者系统中的其他线程等系统资源。合约之间只能进行有限调用。
目前智能合约的编写及其运行环境有 3 种典型的实现范例：
(1) IBM 的 Hyperledger Fabric 项目用 Docker 作为智能合约的执行环境；
(2) R3 Corda 项目中的智能合约使用 JVM 作为合约的底层执行环境；
(3) 以太坊项目中的智能合约采用 Solidity 进行编写，并使用内嵌型的 Solidity 虚拟机进行执行。
-
智能合约执行引擎
因为智能合约本质上是一段可自动执行的脚本程序，存在出错的可能性，甚至会引发严重问题或连锁反应，因此，智能合约执行引擎的安全性对企业区块链的安全性来说至关重要。
Solidity 是一种高级编程语言，它专为智能合约的编写而设计，语法与 JavaScript 相似。其编写十分简单，是一门图灵完备的语言，更重要的是它只能用来实现合约的逻辑功能，不提供任何访问系统资源的接口（例如打开文件、访问操作系统底层资源等），这在语言层面上就保证了用 Solidity 编写的智能合约能且只能运行在一个独立于操作系统的沙盒中，无法操纵任何系统资源。而 Fabric 基于 Docker 形式的虚拟机，对语言并未进行特殊限制，因此不能完全保证安全性。
与 Docker 和 JVM 相比，Solidity 语言及其智能合约执行引擎在程序体积上更小，对资源的控制粒度更细，并且采用 Solidity 语言能够最大程度地利用开源社区在智能合约技术和经验方面的积累，提高智能合约的可重用性。因此 Hyperchain 平台在智能合约的实现上选择了 Solidity 语言，并设计研发了支持 Solidity 执行的高效智能合约执行引擎 HyperVM。
HyperVM 是 Hyperchain 的可插拔智能合约引擎通用框架，允许不同智能合约执行引擎接入，目前实现了兼容 Solidity 语言的 HyperEVM 以及支持 Java 语言的智能合约引擎 HyperJVM 和 HVM，之后将继续集成其他虚拟机如 WVM、JSVM。
- HyperEVM
-
HyperEVM 是为了最大程度利用开源社区在智能合约技术和经验方面的积累，提高智能合约的重用性而深度重构 EVM 的虚拟机，完全兼容 EVM 上开发的智能合约。HyperEVM 在保持 Solidity 开发语言的兼容性的基础上，对智能合约虚拟机进行性能优化，保持了以太坊虚拟机的沙盒安全模型，做了充分的容错机制，并进行系统级别的优化，结合环境隔离能够保证合约在有限时间内安全执行，在执行性能方面逼近二进制原生代码的效率。
-
HyperJVM
HyperJVM 通过微服务的架构设计以及多重安全检查机制为原生 Java 智能合约执行提供了一个高性能安全的执行沙盒。HyperJVM 具有以下优点：
-
支持 Java 语言进行智能合约开发，大大降低了开发门槛；
-
支持完整智能合约生命周期管理，包括合约部署、升级、冻结等；
-
支持丰富的账本操作，KV 接口、批量处理、范围查询以及列式数据操作；
-
支持复杂合约逻辑开发和授权跨合约调用；
-
支持合约自定义事件监听。
-
-
HVMHVM（Hyperchain virtual machine）是集成在 Hyperchain 中的轻量级 Java 智能合约运行时。它提供了一个沙盒环境来执行 Java 语言编写的智能合约，并能通过多种方式保证其安全性。在 HVM 上，用户可以高效地写出简单强大的智能合约。HVM 具有以下优点：
-
完善的合约生命周期支持；
-
更安全的 Java 语言智能合约执行环境；
-
更高效的状态空间操作机制；
-
更友好的编程接口方案。
-
-
HyperVM 设计原理
HyperVM 的设计如图 6.11 所示，主要组件包括用于合约编译的编译器，用于代码执行优化的优化器，用于合约字节码执行的解释器，用于合约执行引擎安全性控制的安全模块，以及用于虚拟机和账本交互的状态管理模块。
是 HyperVM 执行交易的典型流程图，HyperVM 执行一次交易之后会返回一个执行结果，系统将其保存在被称为交易回执的变量中，之后平台客户端可以根据本次的交易哈希进行交易结果的查询。
HyperVM 的具体执行流程如下。
(1) HyperVM 接收到上层传递的 transaction，并进行初步的验证。
(2) 判断 transaction 的类型，如果是部署合约则执行步骤 (3)，否则执行步骤 (4)。
(3) HyperVM 新建一个合约账户来存储合约地址以及合约编译之后的代码。
(4) HyperVM 解析 transaction 中的交易参数等信息，并调用其执行引擎执行相应的智能合约字节码。
(5) 指令执行完成之后，HyperVM 会判断其是否停机，未停机就跳转步骤 (2)，否则执行步骤 (6)。
(6) 判断 HyperVM 的停机状态是否正常，正常则结束执行，否则执行步骤 (7)。
(7) 进行 Undo 操作，状态回滚到本次交易执行之前，交易结束。
图 6.12 中的执行指令集模块是 HyperVM 执行模块的核心，指令的执行模块有两种实现，分别是基于字节码的执行以及更加复杂高效的即时编译（Just-in-time compilation，JIT）。
字节码执行的方式比较简单，HyperVM 实现的虚拟机会有指令执行单元。该指令执行单元会一直尝试执行指令集，当指定时间未执行完成时，虚拟机会中断计算逻辑，返回超时错误信息，以此防止智能合约中的恶意代码执行。
JIT 方式的执行相对复杂，即时编译也称为及时编译、实时编译，是动态编译的一种形式，是一种提高程序运行效率的方法。通常程序有两种运行方式：静态编译与动态直译。前者是指程序在执行前全部被翻译为机器码，而后者则是一边翻译一边执行。即时编译器混合了静态编译和动态直译，一句一句地编译源代码，但同时会将翻译过的代码缓存起来，这样做的好处使可以降低性能损耗。即时编译的代码相对于静态编译代码可以处理延迟绑定并增强安全性。JIT 模式执行智能合约主要包含以下步骤。
(1) 将所有同智能合约相关的信息封装在合约对象中，然后通过该代码的哈希值去查找该合约对象是否已经存储编译。合约对象有 4 种常见状态，即合约未知、合约已编译、合约准备好通过 JIT 执行、合约错误。
(2) 如果合约状态是合约准备好通过 JIT 执行，则 HyperVM 会选择 JIT 执行器来执行该合约。执行过程中虚拟机将会对编译好的智能合约进一步编译成机器码并对push、jump等指令进行深度优化。
(3) 如果合约状态处于合约未知的情况下，HyperVM 首先需要检查虚拟机是否强制 JIT 执行，如果是则顺序编译并通过 JIT 的指令进行执行。否则，开启单独线程进行编译，当前程序仍然通过普通的字节码编译。当下次虚拟机执行过程中再次遇到相同编码的合约时，虚拟机会直接选择经过优化的合约。这样合约的指令集由于经过了优化，该合约的执行和部署的效率能够获得较大的提高。
区块链本质上是一个分布式账本系统，因此区块链平台的账本体系设计至关重要。Hyperchain 的账本设计主要包含 3 个部分：首先对客户的交易信息通过区块链这种链式结构进行存储，保证了客户交易的不易篡改以及可追溯性；其次，采用账户体系模型维护区块链系统的状态，即图 6.13 中的合约状态部分；最后，为了快速判断账本信息、交易信息等关键信息是否存在，账本采用了改进版的 Merkle 树进行相关信息存储。
区块结构中分为两部分：区块头和交易列表。区块头中记录了一些固定大小的区块元数据信息，在交易列表中记录了所有被收录在该区块的交易信息。区块中的相应存储内容的具体定义如表
区块头进行 SHA256 哈希计算，可以生成一个哈希值，该值可以用作在区块链中唯一标识该区块的数字指纹。同时，在区块头信息中引用了上一个产生区块的哈希值，即在每一个区块中，都包含其父区块的哈希值。通过这种方式，所有的区块都被串联成一个垂直的链式结构，通过不断迭代访问父区块，最终可以追溯至区块链的创世区块（第一个区块）。
正是由于这种特殊的链式结构设计，父区块有任何改动时，父区块的哈希值也会发生变化，迫使子区块中的 “父区块哈希值” 字段发生变化，导致产生的子区块哈希值变化。Hyperchain 节点之间每隔一个检查点会进行一次最新区块哈希的比较，如果本地维护的最新区块哈希值与区块链网络维护的最新区块哈希值一致，则能确定本地维护的区块链信息是合法的，否则表示本地节点已经成为了一个 “拜占庭节点
Hyperchain 区块头定义
交易结构定义
Hyperchain 系统除了维护区块链数据以外，还维护了系统当前的状态信息。与比特币系统采用 UTXO 模型不同，Hyperchain 采用了账户模型来表示系统状态。
当 Hyperchain 节点收到一笔 “待执行” 的交易后，会首先交由执行模块执行。执行交易结束后，会更改相关合约账户的状态，例如某用户 A 发起一笔交易调用已部署的合约 B，使得合约 B 中的变量值b由 0 变为 1，并持久化到合约状态中存储。
每一笔交易的执行，即意味着合约账户状态的一次转移，也代表着系统账本的一次状态转移。因此，Hyperchain 也可以被认为是一个状态转移系统。
在 Hyperchain 账本中，会记录链上所有合约的状态信息。合约状态元数据共有以下几个字段，如表
除以上元数据以外，合约账户还有两个数据字段：可执行代码以及变量存储空间。可执行代码就是一段用字节数组编码的指令集，每一次合约的调用其实就是一次可执行代码的运行。合约中定义的变量则会被存储在合约所属的存储空间中，合约账户存储空间示意图如图
存储空间与标准的存储结构类似，在逻辑上是由一片地址连续的存储单元组成的（为了节省磁盘存储空间，空的存储单元不被写入磁盘）。每一个存储单元称为一个槽，大小为 32 字节。合约变量通过在合约编译阶段得到其在存储空间的索引地址，内容存储在相应的槽中。
一个简易的合约状态数据示意图如图
将区块中收录的交易依次处理之后，合约账户从原先的状态转移至一个新的状态，为了快速生成一个用于标识所有合约账户集新状态的哈希值，Hyperchain 系统中引入了 Merkle 树进行哈希计算，接下来先简明扼要地介绍一下 Merkle 树的结构和作用。
Merkle 树是一种哈希二叉树，它是一种用作快速归纳和校验大规模数据完整性的数据结构。这种二叉树包含加密哈希值，在比特币网络中，Merkle 树被用来归纳一个区块中的所有交易，同时生成整个交易集合的数字指纹，且提供了一种校验区块是否存在某交易的高效途径。但是传统的 Merkle 树性能较差，在面对高频海量数据时，计算的表现不能达到联盟链的需求。因此在 Hyperchain 中，设计了一种融合了 Merkle 树和哈希表两种数据结构各自优势的 HyperMerkle 树，大大提升了账本哈希计算的速率。
传统的 Merkle 树是自底向上构建的，如图 6.17 所示，从 L1、L2、L3、L4 这 4 个数据块开始构建 Merkle 树。首先对这 4 个数据块的数据哈希化，然后将哈希值存储至相应的叶子节点。这些叶子节点分别是 Hash0-0、Hash0-1、Hash1-0 和 Hash1-1。
完成最底层叶子节点的赋值之后，开始计算非叶子节点的值，计算方法为串联相邻叶子节点的哈希值，并以此为输入计算哈希，所得结果即为这对叶子节点父节点的哈希值。
继续类似的操作，直到只剩下顶部的一个节点，即 Merkle 根。根节点的哈希值即代表着这一批数据块的标识。
这种传统的 Merkle 树只适用于像比特币系统中对批量交易数据进行哈希的场景，而无法满足联盟链中快速计算账本哈希的需求。因此在 Hyperchain 中重新设计了结合哈希表特性的 HyperMerkle 树。
HyperMerkle 树是一棵构建在哈希表上的多叉树，哈希表的每个存储单元均是 HyperMerkle 树的一个叶子节点，所有的叶子节点称为n层节点。将相邻若干个叶子节点归纳为一个父节点，生成的父节点集合称为n-1 层节点。递归上述操作直到只剩下顶部的一个节点即为 HyperMerkle 树的根节点。每个父节点维护着子节点哈希值列表。HyperMerkle 树结构如图
HyperMerkle 树的一次计算过程如下所示。
(1) 将输入数据集中的每一个元素按照 key 值哈希到不同的位置，产生哈希冲突时采用拉链法进行处理。
(2) 对每一个涉及改动的叶子节点进行哈希重计算，输入为叶子节点的内容；计算完成后将计算结果写入相应父节点的孩子节点哈希列表中。
(3) 对每一个涉及改动的n-1 层节点进行哈希重计算，输入为节点的孩子节点哈希列表（本次计算未涉及的孩子节点的哈希值使用上次计算的值）；计算完成后将计算结果写入相应父节点的孩子节点哈希列表中。
(4) 重复步骤 (3)，直至计算至 1 层节点。1 层节点也称为根节点，账本的当前哈希值用根节点哈希值表示。
(5) 将本次重计算的所有节点的内容持久化。
一棵 HyperMerkle 树维护一批数据，且每次修改后只针对被修改的部分进行哈希重计算，通过这种机制可以大幅提升计算效率。
HyperMerkle 树在 Hyperchain 中具体进行两部分内容的哈希计算：合约账户存储空间的哈希计算；合约账户集的哈希计算。
对于每个合约账户，存储空间的内容是 HyperMerkle 树的输入，输出保存在合约账户的元数据中；对于合约账户集，每个合约的内容是 HyperMerkle 树的输入，输出保存在区块中，视作当前合约账户集状态的标识。
企业级区块链平台也即联盟链。“联盟链” 这个名词包含两层含义：首先它是区块链，其次它是有限成员联盟性质的。因此，在企业区块链安全性机制的设计上，既需要考虑传统区块链面对的各成员之间的信任问题，又要考虑联盟成员的准入准出的安全管理机制。为此，Hyperchain 平台提出了基于密码学的多级加密机制，在交易网络、交易双方以及交易实体等多个层面使用安全加密算法对用户信息进行了全方位加密，还提出了基于 CA 的权限控制机制；另外，为满足企业级区块链平台的高扩展性、高可用性等需求，平台推出了数据管理、消息订阅等功能
为了提高数据安全隐私保护以及支持灵活独立的业务场景，Hyperchain 通过设计 Namespace（命名空间）机制实现区块链网络内部交易的分区共识。使用者可以按照 Namespace 进行业务交易划分，同一个 Hyperchain 联盟链网络中的节点按照其所参与的业务组成以 Namespace 为粒度的子网络，像一个个盒子实现了不同业务之间的物理隔离，使各空间的交易互不干扰。
单个 Hyperchain 节点按照其业务需求可以选择参与一个或者多个 Namespace。如图 6.19 所示，Node1、Node2、Node4 和 Node5 组成 namespace1，而 Node2、Node3、Node5 和 Node6 组成 namespace2。其中，Node1 仅参与了 namespace1，而 Node2 则同时参与了两个 Namespace，Namespace 中通过 CA 认证的方式控制节点的动态加入和退出。
带特定 Namespace 信息的交易的验证、共识、存储以及传输仅在参与特定 Namespace 的节点之间进行，不同 Namespace 之间的交易可实现并行执行。例如，图 6.19 中的 Node1 仅能参与 namespace1 中交易的验证以及相应账本的维护，而 Node2 能够同时参与 namespace1 和 namespace2 的交易执行和账本维护，但 Node2 中的 namespace1 和 namespace2 的账本互相隔离，互不可见。
为了提供更细粒度的联盟链隐私保护方案，Hyperchain 主要实现了隐私交易的存证，隐私合约的部署、调用、升级等。
Hyperchain 可支持交易粒度的隐私保护，发送交易时指定该笔交易的相关方，该交易明细只在相关方存储，隐私交易的哈希在全网共识后存储在公共账本，既保证了隐私数据的有效隔离，又可验证该隐私交易的真实性。
图展示了隐私交易与普通共识交易各自的流程及差异性。
-
加密上链 / 哈希上链
对于某些高敏感信息，若与交易和账本无强相关性，则可将数据明文在上链之前以对称加密的方式进行加密，将隐私数据保护起来，也可以将原始数据和文件在链下保存，通过哈希的方式仅将其数字摘要保存到链上，同时解决数据容量和数据敏感的问题。
-
合约访问控制
合约编码者可以通过智能合约和访问控制策略来限制访问数据的角色和用户，即在合约中针对节点、角色、用户定制不同的合约函数访问权限。合约编码者可以在合约中为一些高权限的函数设置权限控制，使得该函数只能被固定地址的调用者调用，从而实现访问权限控制
Hyperchain 采用了可插拔的多级加密机制，对于业务完整生命周期所涉及的数据、用户、通信连接等都进行了不同策略的加密，方便企业用户按照具体业务的场景选择加密方式，同时保障系统的安全性和高效性。
-
哈希算法
通过哈希算法可以把任意长度的输入变换成固定长度的输出（哈希值），哈希值的空间通常远小于输入的空间，并且哈希函数具有不可逆性，根据哈希值无法反推输入原文的内容。
-
哈希算法在 Hyperchain 平台中有着广泛运用，例如交易的摘要、合约的地址、用户地址等都运用了哈希算法。Hyperchain 提供了可拔插的、不同安全级别的哈希算法选项。安全等级由低到高分别有 SHA2-256、SHA2-256、SHA2-384、SHA2-384 等，这些哈希算法都可以保证为消息生成体积可控、不可逆推的数字指纹，保证平台的数据安全。
-
基于 ECDSA 的交易签名
为了防止交易被篡改，Hyperchain 采用了成熟的椭圆曲线数字签名算法（elliptic curve digital signature algorithm，ECDSA）对交易进行签名，保证平台的身份安全。签名过程如图所示。
椭圆曲线密码体制的安全性是基于椭圆曲线离散对数问题的难解性，由于该问题没有亚指数时间的解决方法，椭圆曲线密码系统（elliptic curve cryptography，ECC）的单位比特强度要远高于传统的离散对数系统，因此计算参数更小，密钥更短，运算速度更快，签名也更加短小。
Hyperchain 使用 secp256k1 曲线和 r1 曲线两种方式实现了数字签名算法，用户可自行选择，对平台交易进行签名验证，保证交易的正确性和完整性。同时平台支持使用该算法对节点间消息进行签名验证，保证节点间消息通信的正确性和完整性。考虑到在数字签名及签名验证过程中涉及大量复杂的计算，Hyperchain 采取 C 语言封装的椭圆曲线加密标准，在签名和验证的性能上有更好的表现。
基于 ECDH 的密钥协商
在网络通信过程中，使用会话密钥对传输的信息进行加密，可以防止黑客窃听机密消息进行欺诈等行为。Hyperchain 通过实现椭圆曲线 Diffie-Hellman（ECDH）密钥协商协议，来完成会话密钥的建立和网络中用户之间的相互认证，保证通信双方可以在不安全的公共媒体上创建共享的机密协议，而不必事先交换任何私有信息。
在 Hyperchain 中，首先利用 ECDH 实现共享密钥的交换，交换过程如图 6.22 所示。ECDH 算法以安全身份认证为前提建立了密钥协商安全信道，任何截获交换的组织都能够复制公共参数和通信双方公钥，但是无法从公开共享值生成共享机密协议。协商出共享公钥后，再通过对称加密来极大地提高通信效率。
-
ECDH 密钥协商在身份认证和交易安全中都具有重要的作用，通过密钥协商建立起的安全通信信道能够实现安全的信息交换，保证平台的通信安全。以安全身份认证为前提建立的密钥协商安全信道，能够确认通信双方的身份合法，再通过对称加密能够大大提高通信效率，因为不需要每次通信都去认证身份了。
-
基于对称加密的密文传输
Hyperchain 在通信双方协商出一个机密共享密钥后，再基于对称加密算法保证节点间的密文传输，使得计算上破解传输内容的难度更高，从而保证平台消息传输的高安全性。
对称加密也称常规加密、私钥加密或者单钥加密，一个完整的对称加密方案由 5 个部分组成。
-
明文（plaintext）：原始的消息或者数据，作为算法输入。
-
加密算法（encryption algorithm）：加密算法对明文进行各种替换和转换。
-
秘密密钥（secret key）：算法输入、算法进行替换和转换都依赖于秘密密钥。
-
密文（ciphertext）：已被打乱的消息，作为加密算法的输出，取决于明文和秘密密钥。对于一个给定的消息，两个不同的秘密密钥会产成不同的密文。
-
解密算法（decryption algorithm）：本质上是加密算法的逆运算。使用密文和秘密密钥产生原始明文。Hyperchain 支持 AES（advanced encryption standard，高级加密标准）算法 —— 是一个基于排列和置换运算的、迭代的、对称密钥分组的密码。它可以使用 128 位、192 位和 256 位密钥，用 128 位（16 字节）分组加密和解密数据。
-
-
传输层安全
除了上述密钥协商与密文传输以外，Hyperchain 节点间还通过传输层安全 TLS（transport layer security）来保证通信安全。TLS 能够在传输层保障信息传输的安全性，是目前较为通用的网络传输实施标准，几乎所有的网络安全传输中都采用了该技术，比如 Google、淘宝、百度、微信等。
传输层安全是 Hyperchain 默认开启的功能，采用 TLSCA 签发的证书进行安全通信，即在网络传输过程中需要验证传输层安全协议证书的安全性，验证通过即可以进行正常网络通信，否则无法进行网络通信。该选项是配置可选的。
-
国密支持
相比于其他区块链平台，Hyperchain 在加密算法上有一个很大的优势：完全支持国密算法的集成。目前 Hyperchain 已集成了国密算法 SM2、SM3 和 SM4，并符合 SSL VPN 技术规范。
其中，SSL VPN 包括各类网络通信协议，用于替代 OpennSSL；SM2 是基于椭圆曲线密码的公钥密码算法标准，包含数字签名、密钥交换和公钥加密，用于替换 RSA、DiffieHellman、ECDSA、ECDH 等国际算法；SM3 为密码杂凑算法，用于替代 MD5、SHA-1、SHA-256 等国际哈希算法；SM4 为分组密码算法，用于替代 AES、DES、3DES 等国际对称加密算法。
Hyperchain 主要通过 CA 体系进行身份认证，采用证书颁发精简体系，如图
Root.ca（根证书颁发机构）代表 PKI 体系中的信任锚。根 CA 是 PKI 层次结构中最上层的 CA，用于签发证书认证机构以及角色证书准入认证机构。
ECert（enrollment certificate）为准入证书，ECA（enrollment certificate authority）为准入证书颁发机构，该机构能够向下颁发节点准入证书。持有 ECert 的节点才能够同 Hyperchain 链上服务交互，否则无法加入相应的 Namespace。
另外，Hyperchain 的 ECert 设计上有两种实现。持有 ECert1 的机构不仅拥有同 Hyperchain 链上服务交互的权限，还能够向下颁发 TCert（transaction certificate）交易证书。交易证书用于实现伪匿名交易，客户发起交易的时候需携带，客户端会使用 TCert 相匹配的私钥对 Transaction 进行加密。TCert 可以实现线上申请，由各个节点签发，每一条 Transaction 都用一个新的 TCert 进行签名，从而实现每条交易的相对匿名，但是可以由签发方审查。
RCA（role certificate authority）为角色证书认证机构，该机构有权限颁发 RCert（role certificate）。RCert 主要是用于区分区块链节点中的验证节点和非验证节点，拥有 RCert 才被认为是区块链中的验证节点，参与区块链节点之间的共识。RCert 和 TCert 一样，只能作为身份证明的证书存在，不能向下颁发证书。
Hyperchian 的证书均符合 ITU-T X.509 国际标准，它仅包含公钥信息而没有私钥信息，是可以公开发布的。
同时 Hyperchain 平台集成了 CFCA（China financial certification authority）实现数字证书管理功能，可以满足对于证书系统安全性与权威性要求较高的银行或金融公司等机构的需求。CFCA 证书体系如图 6.24 所示，它提供两种服务模式：CRL 模式和 RA 模式。CRL 是托管 RA 服务，通过 CFCA 托管 RA 服务进行证书的签发和校验，RA 模式是本地部署私有化 RA 服务进行证书的签发和校验。目前这两种模式平台都已集成。
-
CFCA 证书体系可应用于 Hyperchain 节点验证 SDK 的证书及有效性，将购买的证书配置于 SDK 中，同时 Hyperchain 节点需要配置好由 CFCA 提供的验证证书链，当 SDK 向节点发送证书时，Hyperchain 会验证证书及其有效性，同时需要通过网络请求获取 CRL，验证该证书是否被列入黑名单。
在 JavaSDK 方面，SDK 在发送 SDKCert 时根据 CFCA 特性开关选择相应的签名算法对传输内容进行签名。其中 SDK 和 Hyperchain 的 CFCA 特性开关需要保持一致，同时打开或者同时关闭。
-
证书管理
Hyperchain 提供了证书管理的配套工具 certgen，主要用来生成和管理相关的 CA 证书和数字证书，功能包括证书签发、公私钥生成、证书检查等。
-
证书签发
节点启动前需要生成一对公私钥，节点启动时各节点先根据公钥生成自签证书，并以此生成根证书。
签发子证书时可以由本节点根证书生成指定类型的子证书（ECert、RCert、TCert 和 SDKCert），或者用户提供公钥给签发方，再由签发方为其签发子证书。
-
节点准入
新节点先向各节点发出加入请求，链上所有 VP 节点根据申请节点的握手信息查询其 CA 公钥证书，并使用公钥证书进行签名验证，然后通过 ACO 表决是否允许持有该 CA 证书的节点加入。如果允许，则向其签发本节点的 ECert 证书，同时新节点也向被申请节点发放 ECert 证书。
-
证书检查
certgen 提供证书检查服务，检查内容包括证书是否由 CA 证书签发、签名是否合法、是否为能够签发子证书的 CA 证书。
-
证书撤销
证书撤销一般发生在当用户个人身份信息变更、私钥丢失、泄露或疑似泄露时。一般步骤为：首先证书用户向 CA 提出证书的撤销请求，然后 CA 将此证书放入公开发布的证书撤销列表，该列表中包含所有在有效期内但被撤销的数字证书。
此外，数字证书也可能在日期失效之前被撤销。例如一些特殊情况：证书用户擅自将证书进行了非正当用途且被 CA 发现，或者政府机关等权力部门因为某种原因要求证书撤销。
-
-
密钥管理
对于用户公私钥对，Hyperchain 提供了两种密钥管理模式：一是将私钥交由银行与第三方机构进行托管，二是由用户自行保管。两种管理模式均配备了相应的密钥找回解决方案。
(1) 用户私钥在颁发时拆为两部分分别进行加密，其中一部分由银行进行托管，另一部分交由可信的第三方机构进行托管，从而保证任意一个机构都无法独立盗取用户的私钥进行签名交易。
若用户私钥丢失，机构会在线下对用户进行身份鉴定鉴定通过后，发起私钥找回流程。用户分别从两个托管私钥的机构获得部分私钥，进行解密拼凑，最后获得完整的私钥。该私钥与用户原来的私钥完全相同，可以继续使用原私钥进行签名交易。
(2) 用户自行保管完整的公私钥对，不进行备份。
用户私钥一旦丢失则无法找回，银行会给用户新生成私钥，并通过后台调用一份超级管理员的智能合约，将用户原有的资产划拨到新的公钥地址中。该方案依赖于以下操作。
-
在现有业务合约的基础上，单独设计一个超级管理员智能合约（每个银行单独一个管理员智能合约，只能对本行客户的资产进行划拨）。
-
用户资产的相关合约中需要记录用户开户行的公钥地址。
-
在用户密钥对生成时，将对应的公钥地址存储在银行数据库中，形成一个映射关系（用户账户 / 身份信息 —> 公钥地址），这里的用户身份信息可以线下鉴定。
-
用户私钥丢失后向银行发起私钥重置申请，银行先对用户身份进行鉴定，确认身份后发起资产划拨流程，系统先生成新的公私钥对，再从数据库取得用户之前的公钥，接着调用超级管理员智能合约将用户之前公钥地址对应的现有资产全部划拨到用户新的公钥地址中，并用银行的私钥对该笔交易进行签名，该资产划拨的交易记录同样记录在区块链中，可以被公开查询。
-
用户新的公钥地址添加至数据库中（不删除用户原公钥地址）。
资产一旦划拨到用户新的公钥地址，用户就可以通过新的私钥对原来的资产进行转账等交易。当用户对历史交易进行查询时，会从数据库获得用户所有的公钥地址，私钥变更后的交易通过新的公钥地址进行查询，而私钥变更前的交易可以从曾用公钥地址进行回溯。
-
-
区块链以其去中心化、不易篡改等特性引起了广泛的关注，被认为可以用于解决新一代互联网价值交换问题以及网络传输的信用问题。但在工程实践过程中，赋予区块链可信属性的多中心及不易篡改等特性往往带来诸多使用限制，比较突出的一点就是智能合约的升级。众所周知，没有任何一个系统是没有漏洞的，也没有任何一个系统在设计之初就能确定全部需求，区块链的不易篡改性与工程上的迭代更新需求存在明显的矛盾和冲突，而解决冲突需要强有力的决策，但现有区块链系统缺乏很好的治理机制来做出合理民主的决策。
为了解决区块链多中心、不易篡改等特性与现实工程实践之间的矛盾，Hyperchain 提出了一种能促进区块链自我改进的有效的治理机制 ACO，当初始协议无法满足现实需求或区块链网络在运行过程中出现了难以调和的特殊矛盾，协议需要升级时，这些矛盾可以通过 ACO 联盟自治的方式得以妥善解决。
Hyperchain 提出的 ACO 联盟自治机制的优势体现在以下 3 个方面。
(1) 联盟成员变更。现有联盟链系统的成员变更往往与身份认证强绑定，而身份认证往往由第三方 CA 授权认证，成为多中心区块链系统中的唯一强中心。这种方式不仅存在单点故障风险，还会大大降低区块链系统的整体安全可信度。ACO 机制利用智能合约充当变更的协商平台，通过节点自派发的数据证书作为协商结果凭证（分布式 CA），使成员变更流程保有多中心化的特点，同时整个协商过程公开透明。
(2) 智能合约升级。秉持着初始信任源于线下治理、后续信任源于线上治理的设计理念，ACO 机制提供了一套有效的合约升级治理方式：由联盟成员事先指定升级策略并写入智能合约，需要升级时发起提案并由各联盟成员投票决策，智能合约收集投票后自动执行相应提案，借助权限受控的合约自升级指令，解决区块链合约的升级问题。
(3) 联盟链系统升级。系统升级共分为两种：公有链硬分叉式的非兼容性升级，以及联盟链线下手动兼容性升级。但这种联盟链升级往往需要漫长的线下商务协商，而且通常是运维人员手动完成升级，极其原始与低效。Hyperchain 提出了一种有效的线上协商系统协同升级机制，能实现系统高效自动化同步升级。
-
权限管理
为了满足更丰富复杂的商业应用场景需求，Hyperchain 提出了分级的权限管理机制，进一步保障商业隐私和安全。
(1) 链级管理员：参与区块链级别的权限管理，包括节点管理、系统升级、合约升级的权限控制，往往是各联盟机构指定的内部超级管理员。节点准入、系统升级、合约升级这种链级别的操作权限需由联盟各机构投票决定，而不仅仅是单一主体可以主导的。具体的投票规则由各联盟机构线下协商好，并写入 Genesis 区块。后续若要更改，需按照之前约定的规则进行一轮投票才能完成更改。链级权限管理需要借助上面提到的自治联盟组织（ACO）。
(2) 节点管理员：参与节点级别的权限管理，包括节点访问权限的控制，往往是各联盟机构指定的运维管理员。节点管理员给各用户颁发访问证书（SDKCert），控制用户访问 SDK 接口的权限，带有节点访问证书的请求才会被该节点受理。节点管理员可通过客户端颁发证书，配置用户权限表，分配用户访问 SDK 的权限，比如访问调用合约的权限、获取区块权限等。链级管理员默认带有节点访问证书 SDKCert。
(3) 用户：普通用户，参与链上业务场景。用户可持有不同节点颁发的证书，向不同的节点发起交易。具体用户在对应业务场景中的权限，由上层业务系统自己定义。后续平台可抽象出一系列通用的权限管理接口，供业务层更好地进行权限管理。
在业务层面，Hyperchain 设置了合约访问控制，合约编码者可以在合约中定制合约函数的访问权限，为一些高权限的函数设置权限控制，使得该函数只能被固定地址的调用者调用，从而实现访问权限控制。
Hyperchain 作为一个共享状态的区块链实现，其运转是通过不断的状态变迁实现的。每一次状态变迁都会产生相应的一系列事件，作为本次状态变迁的标志。因而，为了让外部用户更好地监视 Hyperchain 的状态变化，我们提供了一组统一的消息订阅接口，以便外部系统捕获和监听 Hyperchain 的状态变化，作为智能合约与外界通信的消息通道。
目前，外部通过消息订阅系统，可以方便地监听到 3 种类型的事件：
(1) 产生新区块；
(2) 合约产生新事件；
(3) 系统发生异常。以后还将支持更多类型的事件订阅，例如交易的状态变化消息订阅系统是在 Hyperchain 事件路由模块上进行封装的一个系统，其架构如图
-
该系统共有三层结构，从逻辑上可分为上游数据收集、数据筛选与推送、下游数据导出。其中上游数据通过事件路由器获取，数据筛选与推送由消息订阅系统本身完成，而下游数据的导出通过 RPC 模块完成。
消息订阅的使用十分简便，大致流程如下：
(1) 外部用户发起订阅请求；
(2) Hyperchain 返回订阅 ID；
(3) 外部用户根据订阅 ID，通过主动轮询或者被动推送两种方式，获取所订阅的消息。
-
具体实现
Hyperchain 分别基于 WebSocket 和 MQ（消息队列）实现了消息订阅的功能。
WebSocket 是系统提供的用于网络通信的方法，包含了通信的双方，即客户端（Client）与服务端（Server）。发布订阅需要在服务端维护已连接客户端列表，并且客户端与服务端之间需要建立可靠的长连接。服务端的 Socket 需要创建一个 Listener，用于监听客户端的连接，而客户端只有在连接到服务器之后，才可以进行消息的交换。
MQ 是一种添加了保存消息的容器的通信方法，服务端和客户端通过读写出入队列的消息来通信，无须直接互连。MQ 提供的异常情况恢复机制解决了在 WebSocket 消息订阅系统中由于连接断开导致的消息丢失问题。平台 MQ 服务需要用户独立于平台启动一个 RabbitMQ 服务器，并将其所在的服务器称为 RabbitMQ-broker。平台提供的 MQ 服务相当于一个生产者客户端，负责将平台消息推送到 RabbitMQ-broker；消息的消费者作为一个消费者客户端，会与 RabbitMQ-broker 建立连接，等待从 RabbitMQ-broker 推送的消息。
MQ 服务的具体使用方法如下。
(1) 用户向平台注册自己的消息队列 queue，指明 queue 需要的路由键（RoutingKey）集合；平台会创建队列同时启动服务，将 queue 的名称与交换机名称 Exchanger 返回给用户；
(2) 用户正常使用平台发送交易，当有路由键相应的事件产生时，消息会被 MQ 服务自动推送至 RabbitMQ-broker；
(3) 用户可通过主动查询或被动推送的方法获得订阅的信息。
区块链平台为了维护合约数据的隐私，所有部署在 Hyperchain 平台上的智能合约，其底层数据都采用了复杂的编码方式进行编码，使得区块链节点即使拥有了全量的区块链数据，也无法获得合约数据的明文信息。
然而有部分机构需要分析或审计存储于区块链上的合约数据，因此 Hyperchain 提供了一种基于源码解析的合约数据解析方案。通过这种方式，机构就可以在获取了合约源码、合约地址以及合约数据键集的前提下，利用 Hyperchain 提供的数据可视化服务进行该合约的数据解析，导出合约的明文数据以便进行审计、分析等工作；而其他没有合约源码、合约地址、合约数据键集的机构，则无法解析出明文数据。合约数据解析的过程如图
在一次数据解析的过程中，有 3 个必要的前提：
(1) 拥有合约源码；
(2) 拥有合约地址；
(3) 拥有该合约的数据键集。
智能合约中的主要数据都是利用 map 这类基本数据结构来进行组织和管理的，一个 map 的数据可以类比于传统关系型数据库中的一张表，而解析 map 中数据的前提是必须拥有存储在 map 中所有键值对的键集。因此，对于某家参与机构而言，其自身产生的数据对应的键集可以由自己维护，在不泄露的前提下，这部分数据只能由其自身进行解析。
最后可以将数据导入关系型数据库（如 MySQL）中进行分析或审计，如图
更重要的是，Hyperchain 将 Radar 视为获取可分析的高质量数据的重要工具。在获取这些数据之后，用户可以进行数据处理、数据分析等操作，挖掘数据中隐含的价值。
随着区块链运行时间的增长，区块链的存储容量将呈线性增长，这种数据增长的速度甚至会超过存储介质容量增长的速度，因此，区块链数据存储将成为限制区块链技术发展的重要因素。面对这一棘手的亟待解决问题，Hyperchain 提出了区块链数据归档的方法，使得整个区块链系统能在不停机的情况下进行动态的数据归档。
Hyperchain 所提供的区块链数据归档方式基于状态备份。简单来说，用户想要对某一个区块链节点做数据归档，必须在过去某一时刻对区块链制作一个状态快照；用户在进行数据归档时，可以将快照点之前所有的区块链数据（包括区块数据、交易数据、回执数据等）进行归档转储，以实现区块链节点存储压力的减负。
快照制作完成后，该节点又进行了 3 次状态变迁，世界状态历经了 3 次更新，本地最新的区块高度也更新为 97。
此时，用户发起数据归档请求，要求将快照点前所有的区块链数据进行转储归档。该节点将区块号为 0~93 的区块数据以及相应的交易回执等数据都进行转储，且将本地的创世状态内容更新为之前备份得到的快照状态，创世区块更新为区块号为 94 的区块，如图
区块链正常的状态变迁是状态终点不停向前更新的过程，那么数据归档就可以视为一个区块链状态起点向终点更新的过程。
上述的数据归档针对的主体是区块链数据，而部署在区块链上的智能合约，同样有较大的存储需求，来记录庞大的业务数据。针对这部分数据，Hyperchain 提供了另外一种归档机制，用户仅需发起一笔带有特殊标记的交易，调用智能合约中自己定制的归档函数，即可实现合约数据的转储。合约编码者可以在合约中实现任意逻辑的归档函数，以满足不同的业务需求。Hyperchain 还引入了 Archive Reader，便于以后归档数据的查阅。
椭圆曲线密码系统的单位比特强度要远高于传统的离散对数系统。区块链由于所有的签名验证请求都存储于固定大小的区块中，每个区块的请求数固定且较大，并且要求程序快速完成运算，响应延迟要求高，因此需要对椭圆曲线签名算法进行硬件加速，实现更快速的签名运算。
Hyperchain 以现有相关理论为基础，实现了基于 GPU 加速的验证签名算法。GPU 有远超过 CPU 的计算单元，擅长大规模并发计算，因此平台使用 NVIDIA 厂商的 GPGPU 和 CUDA 作为开发环境，用 GPU 以并行方式实现椭圆曲线标量乘法运算。图 6.32 是该算法的处理流程
企业级区块链平台 Hyperchain 为例，介绍了构成企业级区块链平台的核心组件的实现原理。企业级区块链同公有链和私有链不同，它直接面对企业级应用的需求，对区块链系统的安全性、隐私性、易用性、灵活性以及性能有着更加严格的要求。Hyperchain 企业级区块链平台分别从以下几点出发，构建了满足企业需求的区块链平台。
首先，Hyperchain 平台在成员管理方面采取了 ACO 联盟自治以及 CA 体系认证，在成员准入、身份认证、权限管理等方面提供了全方位的保护机制。其次，平台在优化传统 PBFT 的基础上设计实现了灵活、高效、稳定的共识算法 RBFT，为企业级区块链平台提供了坚实的算法基础，提高了交易数据的吞吐量。而且，在智能合约的支持上选择了支持开源领域活跃的 Solidity 语言，并自主研发了轻量级沙盒智能合约引擎 HVM，提供了完善的合约生命周期管理，以及友好编程、合约安全、执行高效的合约环境。再次，在区块链账本的设计上选择了同比特币不同的账本体系，并采用区块数据和状态数据分离存储的方式，提高了数据处理速度。此外，Hyperchain 平台通过分区共识、隐私交易等方式进行业务层、交易层的隐私保护，对交易、交易链路、应用开发包等多层面进行了加密处理，系统性地加强了企业级区块链的安全等级。最后，为提高企业级区块链的可用性和交互性，Hyperchain 平台提供了消息订阅、数据可视化、数据归档等功能，大大提高了交易数据的利用率。