HyperLedger Fabric 在携程区块链平台中的 应用实战 演讲人 : 何鑫铭
何鑫铭 携程技术中心创新研发部区块链技术专家 架构师, 携程区块链技术平台技术负责人, 精通 HyperLedger Fabric Ethereum Tendermint 等开源区块链技术框架
区块链普及普惠的主要障碍 开发 部署 运维成本高 公有链 私有链 联盟链架构标准多且复杂 企业缺乏工程落地经验, 各个行业缺乏标准
1. 携程 CBaas(Ctrip Blockchain as a service) 区块链服务平台的整体介绍
携程 CBaas 区块链服务平台技术栈 区块链前端 Cbaas Portal 智能合约集市区块链浏览器外部节点安装包 openapi API service IAM 公链锚定 多链兼容 / 协同 合约开发在线 IDE / 调试 区块链中间层区块链基础治理 ( 网络 联盟 通道 节点 资源 证书 链上策略 ) ChainInterface 网络中间层 节点安全体系 区块链插件层国密算法 PBFT 共识引擎 JVM/v8 区块链框架 Fabric Ethereum CtripChain CtripChainHub 区块链 PaaS 层 容器编排服务 (swarm/k8s) 中间件风控审计监控数据库文件存储秘钥管理
携程 CBaas 区块链服务平台的整体介绍 用户 发布 获取 资产存证 智能合约集市 图片鉴权 支付结算数据共享积分激励 注册调用区块链服务 (OpenAPI) 通道管理 API 合约管理 API 策略管理 API 合约调用 API 账本查询 API 组织管理 联盟管理 CBaas portal 网络管理 通道管理 策略管理 合约管理 合约在线开发 IDE PC/ 移动端轻钱包应用 私有节点客户端 区块链 浏览器 区块链治理模块 区块链网络构建 Fabric Ethereum CtripChain 组织管理 账户管理 合约管理 链内治理模块 节点管理 通道管理 网络管理 节点客户端管理 监管与审计管理 策略管理 链间治理 预言机管理 多链协同 跨链通信研究 节点监控 调用监控 智能合约监控 监控与分析 区块高度 交易量 计算量监控 日志分析 Paas 层监控... 底层区块链平台 Hyperledger Fabric 企业 Ethereum CtripChain 国密算法共识插件合约引擎
2.HyperLedger Fabric 的架构与设计理念
HyperLedger Fabric 的架构与设计理念 联盟链 : 联盟链用于既定商业用途的区块链网络, 具备成员需要实名准入的特点 网络 (network): 指一套完整区块链网络 通道 (channel):fabric 对于子链的实现方式, 每个通道间数据物理隔离, 一个联盟下可以有多个通道. 链码 (chaincode):fabric 对于智能合约的实现方式, 是由高级语言开发的链上执行程序
HyperLedger Fabric 的架构与设计理念 智能合约执行引擎 Container as a VM 智能合约开发语言 底层数据账本 账本数据 Gossip P2P 网络 Grpc protocol Kafka 共识 (CFT) 账本索引 LevelDB Txn Reads[] Writes[] Txn Reads[] Writes[] 状态数据 ( 可选 LevelDB CouchDB) intermediate CA CA 密钥证书基础设施 Root CA 历史数据 LevelDB 区块索引 LevelDB Txn Reads[] Writes[] 交易提交时更新状态数据 Client( 目前社区提供 Golang/Java/Node/Py 等版本的 SDK)
HyperLedger Fabric 的架构与设计理念 Fabric 模块化设计之 合约执行引擎的解耦 1) 以太坊 : 以太坊定义了一个全新的智能合约引擎 evm hello.sol bytecode 优点 : 简单 确定 轻量 安全的沙箱环境, 使得以太坊在公链运行环境下, 几乎没有因为引擎的 bug 导致重大的事故发生 缺点 : 1. 账本数据结构与 evm 代码绑定较深, 修改会互相影响 ; 2. 为了适应更大的内存寻址和复杂的密码学运算以实现安全的 gas 模型, 采用 256 位整数运算, 致使 32 位 /64 位 x86 处理器相对低效 3.Evm 是一个基于栈的虚拟机, 大多数操作都使用栈 evm 4. 标准库太少,solidity 开发生态 推广还需时日
HyperLedger Fabric 的架构与设计理念 Fabric 模块化设计之 合约执行引擎的解耦 2)Fabric 1 container 接口层代码, 该接口有 3 个实现 DockerVM( 执行用户合约 ) InproVM( 执行系统合约 ) MockVM(UnitTest 的 mock 环境 ) 2VM 与节点的通信方式为 Grpc 3 后续 fabric 会将 evm 集成 优点 : 1. 代码层面上实现了对 VM 和节点进行脱耦, 并且易于扩展新的 VM 方式 2. 理论可支持众多开发语言开发智能合约 缺点 : 依赖 docker 运行环境, 严重限制 fabric 节点的部署可能性 ;docker 作为沙箱环境相对复杂, 安全性 稳定性都面临较大的挑战
HyperLedger Fabric 的架构与设计理念 Fabric 模块化设计之 链上代码逻辑的解耦 1) 沿用 chaincode 的设计, 节点代码中的部分标准逻辑, 设计成系统链码的形式 2) 1.2 版本后逐渐开放系统链码的自定义修改, 如 escc/vscc 开发者可修改系统链码, 以实现不同需求 如 : 定义基于数据状态的背书策略 匿名交易场景 ( 匿名公钥 )
HyperLedger Fabric 的架构与设计理念 Fabric 模块化设计之 共识排序服务的解耦 Fabric 的共识过程 : 普通节点发 Tx input 1 根据链的背书策略, 需要起交易请求 部分组织进行背书, 背书组织预执行智能合约并签名 2 将背书组织签名的合约执行结果集给排序节点排序 排序节点根据排序算法进行交易排序, 并广播交易 Tx ouput 3 普通记账节点接受广播记录到本地账本 特点 : 跟公链的共识过程相比, 1 公链的共识者, 同时承担合约预执行 交易排序的职责 ;fabric 中排序节点只做排序, 合约预执行由背书节点做 (fabric 中背书节点与排序节点的组合 = 公链如以太坊中的共识节点 ) 2 目前 fabric 的共识过程两阶段, 背书 + 共识, 都支持扩展 Fabric 这样解耦共识部分 : 1) 排序节点代码定义了 Consenter 接口, 可以通过实现 Consenter 接口的拓展共识算法 2) fabric1.2 版本支持插件式开发 ESCC/VSCC 背书模块和交易验证模块
HyperLedger Fabric 的架构与设计理念 Fabric 模块化设计之 权限控制的解耦 1) fabric-ca, 一套 PKI 公钥基础设施, 基于证书 / 私钥来作为权限最小单元 ( 如节点 用户 ) 的唯一标识和校验依据 区块链系统中每个节点 用户都有唯一证书和私钥 2) 组织 用户 节点, 组成权限体系的角色 role 层级 如 :Org1.admin Org1.member Org1.peer 3) 将所有需要进行权限校验的单元作为 ACL, 代码 resources.go 中预制了很多 ACL 如 ( 调用合约 ACL 合约间调用 ACL): 4)1.3 版本后, 可以为 ACL 动态 ( 链运行时 ) 配置策略, 策略可以由 2) 中提到的角色组成
HyperLedger Fabric 的架构与设计理念 Fabric 对于同构链中多链以及多链通信的设计 1)Fabric 多链的设计 : 通道 channel, 原理是 P2P 网络中的数据传输通道 2)Fabric 多链通信的支持 : 通过智能合约间的调用, 如同时在 channel1/channel2 上的节点安装的合约 1/ 合约 2 可以互相调用 合约 2 合约 1 Channel: [channel1, channel2] 合约 2 Channel: [channel2] 合约 1 Channel: [channel1] 1 借助多通道与链码相互调用, 可以实现同一业务中, 账本数据的隔离与间接共享 ( 如隐私数据保护 ) 2 借助多通道, 可以缓解现在区块链账本数据逐渐增大, 无法分片存储的问题 3 借助多通道与一个组织部署多个节点, 可以实现并行计算, 提高联盟链对于高并发的支持
3. 在实践 HyperLedger Fabric 过程中的经验
在保护数据隐私的前提下, 用 fabric 在链上保存原始数据 ( 非哈希 ) 并可以按需分享的一种解决方案 多链以及跨链智能合约调用的实际应用场景设计举例
竞争, 数据敏感 OrgA OrgB OrgC 举例 : OrgA,OrgB 与 OrgC 发生交易, 但是 OrgA 与 OrgB 是同业, 互相不希望与 OrgC 发生的交易被彼此知道 channela channelb OrgD 希望可以看到与 OrgB 发生的所有交易详情 OrgD
竞争, 数据敏感 OrgA OrgB OrgC 举例 : OrgA,OrgB 与 OrgC 发生交易, 但是 OrgA 与 OrgB 是同业, 互相不希望与 OrgC 发生的交易被彼此知道 channela channelb OrgD 希望可以看到某些交易详情, 且需要经过 A/B 的授权查看才可 怎么办? OrgD
1)A 与 C 独立建立专用 channela, 同时 ACD 组成 common channel OrgA Chaincode set/get channela OrgC common channel 2)A/B 与 C 发生交易记账 1 调用 channela 的 set 合约进行明细数据记账 2 调用 common channel 的 set, 合约会读取 channela 的明细数据并 Hash 计算后记录到 common channel 两步涉及到的明细上链和 hash 计算上链都由 channela 上的所有组织进行背书 保证原始数据真实 Chaincode get Channel AD OrgD Chaincode set/get 3) 当 A 授权 channela 上某条数据查询权限给 D 后 1 双方建立私有通道 channelad 并安装 get 合约 2 执行 get acc, 该合约分别调用 channela 的 get acc 和 common channle 的 get acc 合约将数据取出并进行 hash 验证有效后返回给 OrgD 整个过程所有操作无链下环节, 保证 A 给到 D 的数据都是经过 A/C 背书的真实数据
4. 关于公有链 / 联盟链当前问题的一些思考
世界上不需要这么多的公链 -> 除非有一个公认的协议将各个公链打通 世界上很多行业都需要联盟链, 大大小小的区块链联盟 技术也已经兴起, 但如何将他们互相打通?-> 需要有一个公认的协议将各个联盟链打通 异构跨链技术 1. 通过异构跨链实现主链无法实现的内容 : 规则 / 更高的 TPS/ 联盟链锚定公链 2. 通过异构跨链实现主链价值 数据的转移
(Vitalik Buterin) 以太坊创始人给 R3 写的跨链互操作的报告 跨链技术的目的从起步阶段的传递资产 / 代币, 到现在已经变为了传递数据
公证技术 : 瑞波 Interledger 协议 1Interledger 协议使两个不同的记账系统可以通过第三方 连接器 或 验证器 互相自由地传输货币 传递状态 2 该协议采用密码算法用连接器为这两个记账系统创建资金托管 3 该协议移除了交易参与者所需的信任, 连接器不会丢失或窃取资金, 并且连接器上的交易详情是加密的
中继技术 :Polkadot( 波卡链 ) 和 cosmos
本 PPT 来自 2018 携程技术峰会更多技术干货, 请关注 携程技术中心 微信公众号