企业级区块链（也称联盟链）主要针对大型公司、政府机构和产业联盟的区块链技术需求，提供企业级的区块链网络解决方案。联盟链的各个节点通常对应一个实体的机构组织，节点的加入和退出需要经过授权。各个机构组成利益相关的联盟，共同维护区块链网络的健康运转。

与私有链和公有链不同，企业级区块链更加着眼于区块链技术的实际落地，在区块链的性能速度和安全性、成员认证管理、数据隐私保护上有着更高的要求。除此之外，企业级区块链的研发往往直接和实际业务场景相关联，更加贴近行业痛点，为企业联盟提供一套更加完善的一体化区块链解决方案。

图展示了联盟链平台和区块链应用之间的相互促进关系。一方面，联盟链平台为实际行业应用研发、落地提供了底层技术支撑；另一方面，行业应用以及概念的验证落地也推动着联盟链平台的不断发展成熟。

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。

1. RBFT概述

   Hyperchain的共识模块采用可拔插的模块化设计，能够针对不同的业务场景需求选择配置不同的共识算法，目前支持PBFT的改进算法RBFT。Hyperchain通过优化PBFT的执行过程，增加主动恢复与动态节点增删等机制，极大地提高了传统PBFT的可靠性与性能。RBFT能够将交易的延时控制在300 ms，并且最高可以支持每秒上万笔的交易量，为区块链的商业应用提供了稳定高性能的算法保障。下面就RBFT的核心算法进行详细阐述。

2. 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虚拟机进行执行。

1. 智能合约执行引擎

   因为智能合约本质上是一段可自动执行的脚本程序，存在出错的可能性，甚至会引发严重问题或连锁反应，因此，智能合约执行引擎的安全性对企业区块链的安全性来说至关重要。

   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树进行相关信息存储。

![区块链是区块链账本中的重要数据结构，存储着核心交易信息。区块链是由包含交易信息的区块从后向前有序链接起来的数据结构。所有区块被从后向前有序地链接在这个链条里，每一个区块都指向其父区块。区块链经常被视为一个垂直的栈，第一个区块作为栈底的首区块，随后每个区块都被放置在其他区块之上。用栈形象化地表示区块依次链接这一概念后，我们便可以使用一些术语，例如，“高度”表示最新区块与首区块之间的距离，“顶部”或“顶端”表示最新添加的区块。

](https://images.mirror-media.xyz/publication-images/6pPOeBGzKULe9M_cneETb.png?height=212&width=566)

区块结构中分为两部分：区块头和交易列表。区块头中记录了一些固定大小的区块元数据信息，在交易列表中记录了所有被收录在该区块的交易信息。区块中的相应存储内容的具体定义如表

区块头进行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采用了可插拔的多级加密机制，对于业务完整生命周期所涉及的数据、用户、通信连接等都进行了不同策略的加密，方便企业用户按照具体业务的场景选择加密方式，同时保障系统的安全性和高效性。

1. 哈希算法

   通过哈希算法可以把任意长度的输入变换成固定长度的输出（哈希值），哈希值的空间通常远小于输入的空间，并且哈希函数具有不可逆性，根据哈希值无法反推输入原文的内容。

• 哈希算法在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平台提供了消息订阅、数据可视化、数据归档等功能，大大提高了交易数据的利用率。