企业级区块链平台核心原理剖 析 趣链科技-Hyperchain 浙江大学软件学院副研究员 浙江 大学区块链 研究中心 主任助理 杭州趣链科技有限公司 联合创始人、副总经 理 梁秀波 2019年10月 前言 企业级 区块链（也称联联盟链链）主要针对大型公司、政府机构和产业联 盟的 区 块链 技术需求，提供企业级的区块链网络解决方案。 联盟链的各个节点通常对应 一个实体的机构组织 ，节点的加入和退出需要 经 过授权权。各个机构组成利益相关的联盟，共同维护区块链网络的健康运转。 企业2 企业1 企业4 企业3 联盟 链 通信 通信 通信 通信 通信 通信 企业5 授权 加入 企业6 授权 退出 前言 区块链 私有链联盟链 公有链 完全去中心化 性能低 全网络参与的节 点 共同维护 着眼于区块链技术的实际落 地 区块链 的性能速度和安全性、 隐私性保护上有着更高的要求 直接和实际业 务场景相关联， 更加贴近行业痛点，为企业联 盟提供一套更加完善的一体化 区块链 解决方案 中心化 与目前的中心化金 融系统 （例如：银行）类 似 前言 下图展示了联盟链平台和区块链应用之间的相互促进关系 。 联盟 链 云 平台 区块链块链 行业应业应 用 技术支撑 特质优 势 落地验证 需求推动 作为国产的企业级区块链服务平台，Hyperchain面向企业、政府机构和产业联盟的区 块 链技术需求，提供企业级的区块链网络解决方案。本章将以Hyperchain为例，阐述企业 级区 块链 平台设计的核心原理。 目 录 Hyperchain 整体架构 共识算法 智能合约 账本数据存储 安全与隐私机制 可视化平台 总结 Hyperchain 整体架构 Hyperchain具有验证 节点授权机制、多级加密机制、共识机制、图灵完 备的高性能智能合约执 行引擎等核心特性，是一个功能完善、性能高效 的 联盟链基础技术平台。 在面向企业和产业联 盟需求的应用场景中，Hyperchain能够为 资产数字化 、 数据存证、供应链 金融、数字票据、支付清算等多中心应用提供优质的底 层区 块链 支撑技术平台和便捷可靠的一体化解决方案。 Hyperchain支持企业基于现有云平台快速部署、扩展和配置管理区块链网络 ， 平台定位对区块链 网络的运行状态进行实时可视化监控，是符合ChinaLedger技术规 范 的国产区块链 核心系统平台。 技术支 撑 应用场 景 Hyperchain 整体架构 API and SDK API接口和SDK Node Monitor 节点监控 Contract Manage 合约管理 Block Monitor 区块监控 Node Config 节点配置 HTTP Server 接口服务器 Docker Kubernetes Docker 集群管理工具 OpenStack Aliyun Aws 云平台 Message Channel 消息通道 RBFT 高性能共 识算法 DMPC 动态成员 管理与权 限控制 MLEM 多级加密 机制 HPVM 智能合约 引擎 Peer Manager 节点管理 器 Level DB 数据存储 Block Pool 区 块池 Ledger 账本存储 Hyperchain 通过多种API与SDK对 上层应用提供服务，为应用开发 者 屏蔽了区块链底层实现细节 。 目前 提供了Restful、JSON-RPC 等API 以及Java、JavaScript、Go 等语言 的SDK。 上述外部编程接口通过内部的HTTP 服 务器同 Hyperchain 平台进行交 互。 Hyperchain的整体系统架构图 Hyperchain 平台的核心组件， 包括： 1、基于PBFT改进的可靠高性能 共识算法RBFT。 2、支持动态 成员加入与退出、 权限控制。 3、多级加密的企业级 安全模块 。 4、高性能图灵完备的智能合约 执行引擎。 除外，Hyperchain还包含用于交 易、区块存储的相关存储管理组 件。 Hyperchain 整体架构 本章接下来就以Hyperchain为例，阐述构成企业级区块链平台的核心技术模块，主 要就共识识算法、智能合约约、账账本、安全机制以及可视视化监监控平台的实现原理进行深入分析 。 为了企业级区块链平 台的管理以及智能合 约的开发方便， Hyperchain提供了一 套可视化监管平台 Hypervision Hyperchain既支持直接裸机 的安装部署，也可以使用 Docker、Kubernetes等集 群管理工具进行资源管理方 式的部署 平台可以部署在物理机以及 OpenStack、Aliyun、 AWS等主流的云平台上，适 配各种服务器配置，适用各 种主流操作系统。 目 录 Hyperchain 整体架构 共识算法 智能合约 账本数据存储 安全与隐私机制 可视化平台 总结 共 识 算 法 共识算法是保 证 区块链 平台 各节 点账本数 据一致 的关键 PoW（Proof of Work）依赖机器的计算能力获取账本的记账权 ，资源消耗较 高 且可监管性弱，每次交易共识的达成需要全网共同参与计算，因此不适合 联盟 链对监 管以及性能的要求。 PoS（Proof of Stock）的主要思想是节点获得记账权 的难度与其持有的权益数 量成反比，相比PoW性能较好，但是依然存在可监管性弱的问题。 Paxos和Raft是传统分布式系统的一致性成熟解决方案，此类型算法的性能高 、 消耗资源低，但是不具备对拜占庭节点的容错。 PBFT （Practical Byzantine Fault Tolerant）算法同Paxos算法的处理流程类 似，是一种许可投票、少数服从多数的共识机制。该算法具备容忍拜占庭错 误 的能力，且能够允许强监管节点的参与，算法性能较高，适合企业级平台 的开 发。 目前主流的企业级 区块链 解决方案Fabric和Hyperchain都提供了PBFT的实现 方案。然而原生PBFT 算 法在可靠性与灵活性方面不够完善，Hyperchain平台对可靠性与灵活性进行了增强，设计实现 了 PBFT的改进算法，即RBFT（Robust Byzantine Fault Tolerant）。 RBFT 概述 Hyperchain的共识模块采用可拔插的模块块化设设计计，能够针对不同的业务场景需求 选 择配置不同的共识算法，支持PBFT的改进算法RBFT。Hyperchain通过优化PBFT的 执行 过程，增加主动恢复与动态节点增删等机制，极大地提高了传统PBFT的可靠性与 性能。 RBFT能够将交易的延时控制在300ms，并且最高可以支持每秒上万笔的交易量 ，为区块 链的商业应用提供了稳定高性能的算法保障。下面就RBFT的核心算法进行详 细阐述，包 括一些几个部分： RBFT 常规流程 RBFT 视图更换 RBFT 自动恢复 RBFT 节点删减 RBFT 常规流 程 RBFT的常规流程保证了区块链各节点以相同的顺序处理来自客户端的交易。RBFT同PBFT 的 容错能力相同，需要至少3f+1个节点才能容忍f个拜占庭错误。下图中的示例为最少集群节点 数， 其f的值为1。 RBFT的共识保留了PBFT原有的三阶段处理流程（PrePrepare、Prepare、Commit） ， 但是穿插增加了重要的交易验验证证环节。 Client Primary 1 Replica 2 Replica 3 Replica 4 TransactionBatchPrePreparePrepareCommitWrite Block Primary进行 validate Replica收到2f个prepare后进行validate Replica将消息发送给Primary Primary为区块链节 点中 动 态选举 出来的主节节点， 负责 对客户端消息的排序 打包。 Replica节点为备备份节节点，所 有 Replica节点与Primary节 点执 行交易的逻辑相同， Replica节 点能够在Primary节 点失效时参 与新Primary节点 的选举。 RBFT 常规流 程 RBFT算法的常规共识流程如下所示： 1、Client将交易发送到 区块链中的任意节点 2、Replica节点接收到交易之后转发给 Primary 节点，Primary自身也能直接接收交易消息。 3、Primary会将收到的交易进行打包，生 成batch进行验证，剔除其中的非法交易 。 4、Primary将验证通过的batch构造 PrePrepare消息广播给其他Replica节点。 5、Replica接收来自Primary的PrePrepare消息之后构造 Prepare消息发送给其他Replica节点，表明该节点接收到 来自主节点的PrePrepare消息并认可主节点的batch排序 。 6、Replica接收到2f个节点的Prepare消息之后对 batch的消息进行合法性验证，验证通过之后向其 他 Replica节点广播Commit消息，表示自己同意 了 Primary节点的验证结 果。 7、Replica节点接收到2f+1个Commit之后执行batch中的交易并同主 节点的执行结果进行验证，验证通过将会写入本地账本。 由以上的RBFT常规流程可以看出，RBFT将交易的验 证流程穿插于共识算法的整个流程中，做到了对写入 区块结 果的共识。 RBFT 常规流 程 右图是RBFT的共识 流程与传统 的PBFT算法 验证 的具体流程对比图 。 recvReqBatch sendPrePrepare recvPrePrepare recvPrepare maybeCommit recvCommit recvTxBatch sendPrePrepare recvPrePrepare recvPrepare maybeCommit recvCommit validateBatch recvValidatedRes Hyperchain RBFTFabric PBFT Balance验证 Hash RootHash TxHash ReceptHash 普通Replica确认 Primary的验证 结 果；不通过发 送 Viewchange Primar y Replic a 2f Prepare 首先，Primary节点接收到交易之后首 先进行验证，这这保证证了平台的算力不会 被非法交易所消耗，使Replica节节点能够够 高效地处处理Primary节节点的拜占庭失效 。 其次，Replica节点在接收到2f个 Prepare消息之后对Primary节点的 验 证结果进行验证，如果结果验证 不通 过则会触发ViewChange消息， 这这再 一次保证证了系统统的安全性。 RBFT 视图 更 换 在PBFT算法中，参与共识的节点可根据角色分为主节点（Primary）和从节点（Replica）， 从节点会将自己收到的交易转发给 主节点，主节点最重要的功能就是将收到的所有交易按照一定 策略打包成块，让所有节点参与共识验 证。那么，一个很自然的问题 就是，如果主节点发生宕机 、 系统错误 或者被攻占（即成为拜占庭节点），其他从节点如何才能及时发现 主节点的异常并 选举 产生新的Primary继续 共识？这是保证BFT类算法稳定性必须要解决的问题。 在PBFT以及RBFT中都引入了视图 （View）的概念，每次更换一个Primary节点同时切换视 图，ViewChange（视图 更换）机制是保证整个共识算法健壮性的关键。 RBFT 视图 更 换 可检测 到的主 节点的拜占庭 行为有3种情 景 (1)节点停止 工 作，不再 发送 任何消 息 (2)节点发送错误 的消息， 错 误可能是消息内容不正 确、 包含恶意交易的消息 等 （3）伪装正 常节点，发 送 正确的消 息