IBM技术专家:Hyperleger Fabric 架构与部署实例解析

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 策划|Linda编辑|Linda区块链前哨导语:2018 年 3 月 28 日晚 8 点半,区块链前哨迎来了第五期社群分享“超级账本 Fabric 的架构与设计”,邀请了来自 IBM 的技术专家赵振华先生现场分享。

557172d80fa9311031ecff26c74ab79cf68440bd

策划|Linda
编辑|Linda
区块链前哨导语:2018 年 3 月 28 日晚 8 点半,区块链前哨迎来了第五期社群分享“超级账本 Fabric 的架构与设计”,邀请了来自 IBM 的技术专家赵振华先生现场分享。本文根据分享内容整理而成。本文主要介绍 Hyperledger Fabric 的特性、架构与核心组件,并具体分析交易过程的实现,企业案例等内容。从技术角度介绍下 Hyperledger Fabric 是什么,其实现过程是怎样的。

更多干货内容请关注微信公众号“区块链前哨”,(ID:blockchain-666)

新事物往往不是凭空产生的,其发展过程也并非一蹴而就。时下如火如荼的区块链技术,自 2009 年到今天已经经历了三个阶段的发展。

  • 区块链 1.0 是以比特币为代表的数字货币应用,其场景包括支付、流通等货币职能;

  • 区块链 2.0 是挣脱了数字货币枷锁的智能合约,也就是区块链的 token 化,主要应用于金融领域的股票、债券、按揭贷款、产权等方面;

  • 区块链 3.0 则超出货币和金融领域,为各种行业提供去中心化解决方案,如医疗、文化、艺术、物联网等。支持行业应用意味着区块链平台必须具备企业级属性。

3.0 时期,诞生了几个具有代表性的平台。公有链的代表是以太坊,私有链则以 R3 Corda 声名最盛,联盟链的代表作品是 Hyperledger 名下的 Fabric。

eab3e6f9d0b4106dae514ae42349aa542288e9d1

Hyperledger 是面向企业应用的全球最大的分布式账本开源项目,由 Linux 基金会支持,创建于 2015 年底。目前已有 200 多家科技、金融行业领军企业加入成员,包括 IBM、Intel、摩根、甲骨文、万达、百度、腾讯等。大量基于超级账本技术的企业界区块链项目已经成功落地。

如今说到 Hyperledger 基本都是指的当中 IBM 开发的 Fabric 平台。而 Hyperledger Fabric 项目自诞生之日起就吸引了全球众多企业的密切关注,已经先后发布了两个大的版本,0.6 实验版本(2016 年 9 月),1.0 正式版本(2017 年 7 月),1.1 正式版本(2018 年 3 月 20 日)。

Hyperledger Fabric,也叫超级账本。现在由 Linux 基金会管理,主要由 IBM 和 Digital Asset 发起。IBM 和 Digital Asset 的客户都是企业、政府部门。那么超级账本的也是是针对企业应用的开发的。

除了 Fabric 之外,Hyperledger 项目还管理一些别的工具,有兴趣的同学可以到官网了解 https://www.hyperledger.org/

ffcb51d4ccdacaa799bd9a22384ae861ceb1b367

 1. 开放

谈到 Linux 基金会的大家首先会想到 Lnux Github。Linux 毫无疑问是应用最广的 OS,Github 是最大的开源社区里面,github 上有无数的开源软件,遍布全球的程序员每天都在 Github 上提交新项目,改进代码。

Linux 基金会的会员非常多,目前企业会员就超过 1000 家,当然也包括很多中国的大企业,例如 BAT,华为,中国移动,招商银行,中国电信,中信银行等。

超级账本的是 Linux 基金会 2015 年底宣布成立的,成立之后很快就吸引了大批的企业。到 2016 年底,加入的企业数达到 120 多家,大约四分之一是中国企业。也可以看出中国的 IT 现在是非常活跃的,对区块链的投入也非常大。

目前这个项目有 18 家白金会员(见下图)

828741bfba459a664d353c2acf9ba4eb1ee8e117

现在的 Fabric 的代码,主要是由 IBM 和 Digital Asset 这两家公司提供的。IBM 把代码贡献出去之前,内部叫 Openblockchain,是 IBM 开源的 blockchain 项目,中国有很多企业在研究这个项目,包括中信,民生,华为,浪潮,腾讯,招商银行等。

 2. 开源

它的源代码是开放的,Github 上有镜像,大家可以很方便地下载。

 3. 支持多语言

d9630dd3b80ead72f82401d71dded6e30485eebb

SDK 目前支持 go, java, js, python 四种语言,基本是目前最流行的编程语言,绝大部分写代码的同学至少会其中的一种。这也就大大降低了使用 Fabric 的门槛,开发者不用再学习新的语言就可以开始写程序做区块链的应用了。

另外,超级账本还有一个叫做 Hyperledger Composer 的工具。借助这个工具,可以很快的搭建区块链环境。

 4. 可插拔,可扩展

Fabric 中的 CA,数据库,共识算法等,都是可以插拔的。而且,Farbric 的 Chaincode 通过 docker 实现。

Chaincode 是什么呢?这又要回到共识机制。共识机制就是所有参与者对每个合约的确认过程。举个简单的例子,A 转账给 B100 元:“A 付款,B 收款确认”,这些信息被记录在账本上,这就是共识机制。

代码怎么实现这个动作呢?A 转账的动作,B 确认的动作,都是在 chaincode 实现。类似于我们定义一个转账的接口,A 实现付款的代码,B 实现确认的代码。这些代码就是 chaincode。

 5. 兼顾数据共享和隐私保护

隐私一直是大家都比较关心的话题。Facebook 也因为 Cambridge Analytica 被搞得焦头烂额,很多公司也都修改了隐私保护规则。欧盟也出了新的数据保护条例——GDPR(General Data Protection Regulation),于 5 月 25 日生效,对数据保护提出了更高的要求。据说目前欧盟超过一半的企业达不到要求。

区块链的账本是共享的,像比特币,以太坊等,交易数据大家都可以查看。虽然不知道是谁的数据,但是让人们很担心。在 Fabric 中,账本不是共享给所有人的。而是通过 channel 隔离数据,虽然大家都在同一个区块链网络里,但是不在同一个 channel,也没办法共享账本。所以,通过建立不同的 channel 可以达到按需共享的目的。

ef056e744a3e107fc87c8e12fa380d189e51ccaa

Fabric 核心组件Fabric 有三大核心组件:Peer——节点,大部分代码都在 peer 里面实现;Ordering-Service——完成共识机制的地方;CA——成员管理。(如下图所示)

8aba05d3fb5e0319bdb464094a208560aa41dc20

 1. 节点 (Peer)

Peer 是在网络中具有一定功能的服务或者软件。它在 Fabric 网络中,主要负责接收交易请求。维护账本,一般都是运行在容器。节点之间通过 gRPC 进行通信。

在 Fabric 中,Peer 主要有三种类型:Endorser, Committer, Submitter。

  1. Endorser(背书节点): 负责对交易提案进行检查背书,根据定义好的规则读写数据,读写集,这个读写的数据叫 state db,或者叫 world state db。背书就是签署,它做的具体事情就是根据约定,往事务里读写数据,可以理解为执行合同里的每个条款。注意这个数据没有写到账本数据,因为账本是共享的。

  2. Committer(确认节点):负责检查交易请求,验证 endorsements 和 transaction 结果,并且执行交易,并维护区块链和账本结构。Commiter 会写到共享账本数据。

  3. Submitter:目前版本中还未公布其具体功能,可能会参与写账本,请大家期待。

83012d180a0b6a37ff5c1d3d4846beb40e0fd43b

如下图所示,左边的是账本,每个 peer 都保存一份。右边的是 state db 或者叫 world state db,它记录背书的数据,签名等等。

ee91eebc3a731ad3f258b1a41209a270d3bb994e

账本数据本身是文件系统。World State DB 可以是 CouchDB 或者 LevelDB。

 2. 排序者 (Orderer)

Orderer 负责对收到的交易在网络中进行全局排序。Order 是接收 transaction,产生 block。并且负责共识机制的 policy 管理,RWSet。有点类似比特币里面的矿工。

92aeaf3d66effadf9200fd26152a996b573f765a
 3.CA 节点

负责对网络中的成员身份进行管理。目前采用的事数字证书机制,CA 节点实现了 PKI 服务。

PKI 体系 PKI (Public Key Infrastructure),它不是某一种技术,而是综合多种密码学手段来实现安 全可靠传递消息和身份确认的一个框架和规范。 一般情况下,包括如下组件: CA(Certification Authority) :负责证书的颁发和作废,接收来自 RA 的请求; RA(Registration Authority):对用户身份进行验证,校验数据合法性,负责登记,审 核过了就发给 CA; 证书数据库:存放证书,一般采用 LDAP 目录服务,标准格式采用 X.500 系列。

CA 是最核心的组件,主要完成对公钥的管理。密钥有两种 类型:用于签名和用于加解密,对应称为 签名密钥对 和 加密密钥对 。 用户基于 PKI 体系要申请一个证书,一般可以由 CA 来生成证书和私钥,也可以自己生成公钥和私钥,然后由 CA 来对公钥进行签发。

34ca5a24c66a26ce83763f9500930766e9184193

事务就是合约、合同,完成这个合同不同的参与者需要完成不同的任务

f689a3fb3c4c870c4a4be53a77fe731178da53c2

如图所示,右上角的紫色的框内是签署规则,根据这个规则,E0,E1,E2 三方需要完成签名。

第一步就是客户端根据规则向这个网络中广播一条消息

613b8faffa0128003ca9b70123e5afd974ec8301

E0,E1,E2 收到消息就执行背书

1bf96f95b67946f8d9706a9eccd06805bbada295

E0,E1,E2 完成背书之后,通知客户端

146b8fbde88940ef518e22b572fb68c876e61f0f

客户端收到大家的确认之后就,就向 Orderer service 发送请求。Order service 对这个 transaction 进行排序,之后写到 block 中,并发送给 committing peers。这个 block 就是区块链的 block.

fa14bb88b95b1284e4c6dc781b38a947bb361479

第六步 Committer peer 验证 transcation

Committing peer 调用 validate chaincode 对这个 transaction 进行验证。验证通过,就写入到账本里面。

4ec241f85f4ba7e4ec61767375c18c0130c64eed

最后再通知客户端,交易完成

47db74badd5f57a53fdb3a503c40e64cfc22c70d


IBM 目前已经完成了 400 多个区块链的项目,包括以下几个:

a2daf744e61d12264e3b43c26b62f7081e4d9a37

We Trade 这个项目主要做金融方面的审计。审计就是各个公司各个部门之间去对账,以前这些数据是分散在不同的公司的,对起帐来非常费时费力。有了区块链之后,因为数据都是共享的,所以这个查起来就非常方便,据说他们效率提高了五倍。

9f66cb91f4814130d0e9472c0daf4dbe631baa86

这是 IBM 为荷兰银行做的第三个项目,前两个都是和金融相关的,而这个是跟中国的渤海实业合作的。渤海实业是我国农业的龙头企业,这个项目主要是跟踪大豆的进口。我国是大豆的进口大国,每年大约有 1 亿吨的大豆,进口价值 400 多亿美元。采用区块链技术可以比较完整的跟踪整个大豆的生产和贸易。

37619419ac977ac77e52709ce86da15a856c5c62



以上内容基于 IBM 技术专家赵振华的分享整理而成。现场,前哨的伙伴们也提出了各种问题,振华老师也做了相应的回答。

问题 1:如果区块上有部分交易数据需要保护隐私(不想让其他能够访问 block 的 member 看到),如何设置?

赵振华可以通过创建不同 channel 来隔离用户和数据,只有在同一个 channel 上的用户才可以访问这个 channel 对应的账本上的数据。

问题 2:ordering service 可以有多个实例吗? 如果是多个组织构成的联盟链,谁负责这个 order?

赵振华:每一个 channel 都有一个 ordering service, ordering service 可以有一个或者几个节点共同组成。

问题 3:针对【E0,1,2 完成背书之后,通知客户端】这部分,是都通知吗,还是最后完成的那个通知有效?

赵振华:E0,1,2 执行不同的背书业务,它们背书的顺序是不确定的,每一个完成之后都需要通知。但是可以制定不同的 policy,比如 5 个节点,3 个完成背书就可以认为是有效的。客户端收到 3 个就认为已经完成了。

问题 4:peer 可以即是 endosor,又是 commiter 吗?

赵振华:每个 peer 只有一个角色。

问题 5:State DB 存储的是啥,交易结果吗? 和账本的区别是什么?

赵振华:State DB 存储的交易的最新状态。验证完 Block 中的所有 Transactions 后,提交节点会把 Block 写入账本,并且根据这个 Transaction 更新 State Database。举一个存款的例子,客户 A 银行账户中 1000 元,现在通过 ATM 再存 500 元。ATM 收到钱后,从 state db 中读取 A 的余额 1000,然后把 A 的账户余额改为 1500,这个交易被验证之后写入账本。State DB 中记录的 A 的余额就是 1500,而不是以前的 1000 元了。

问题 6:orderer 节点是通过排序 rwset 使逻辑执行顺序一致,从而达到共识的目的么?

赵振华:不仅是读取数据,还需要检查业务逻辑。

问题 7:达成共识需要多久时间?比特币的账本更新 peer 会越来越庞大,更新都很慢。

赵振华:比特币是按 PoW 计算的,所以比较耗时。在 Fabric 中,完成背书,排序和验证就达到共识了。

问题 8:目前的联盟链里多少个点,每个点做了多大的存储冗余

赵振华:每个节点存储一份账本,账本数据一般都不大。空间不是问题。

问题 9:区块链怎么存储大文件,例如视频文件

赵振华:如果业务需要存储大文件,建议把大文件的摘要信息存储在账本里,比如 MD5 码,大文件存在文件系统上。

问题 10:区块链技术目前成熟度低于数据库,成本 / 难度高于数据库,企业内自身似乎很难找到非用不可的场景与理由?

赵振华:区块链确实是比较新的技术,也有不足,但是很多应用场景用区块链比传统方案更好。

问题 11:Fabric 中账本实际包括 Key-value 数据库和区块链,其中的 key-value 数据库中的记录实际上是可以修改的。不能修改的只是区块链账本。这样防篡改功能实际上是打问号的。请问老师如何看待这个问题?

赵振华:数据以账本上的数据为主,peer 启动的时候会根据账本 recover state db,也可以根据需要随时 recover state db。

问题 12:除了 jira 还有没有开发交流社区,感觉文档不是很全。Fabric-CA 有点鸡肋,实际项目中有用到吗?因为只是证书颁发而与 MSP 没直接关联,用 openssl 库去做证书管理到自己的平台可能更快点? 另外,目前项目好像只有 ECC 的签名实现,有计划做加解密吗?目前要加密 aes key 是否意味着需要同时生成一套 rsa 证书?

赵振华:Fabric 是 permissoned 区块链,企业的合作对象都是已知的,每一个参与者都是经过大家同意。其实即使公有链,没有参与者也有 key,只是没有集中管理。



原文发布时间为:2018-04-02
本文作者:赵振华
本文来源: 微信公众号-区块链前哨,如需转载请联系原作者。
目录
相关文章
|
20天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
18天前
|
存储 分布式计算 关系型数据库
架构/技术框架调研
本文介绍了微服务间事务处理、调用、大数据处理、分库分表、大文本存储及数据缓存的最优解决方案。重点讨论了Seata、Dubbo、Hadoop生态系统、MyCat、ShardingSphere、对象存储服务和Redis等技术,提供了详细的原理、应用场景和优缺点分析。
|
18天前
|
传感器 算法 物联网
智能停车解决方案之停车场室内导航系统(二):核心技术与系统架构构建
随着城市化进程的加速,停车难问题日益凸显。本文深入剖析智能停车系统的关键技术,包括停车场电子地图编辑绘制、物联网与传感器技术、大数据与云计算的应用、定位技术及车辆导航路径规划,为读者提供全面的技术解决方案。系统架构分为应用层、业务层、数据层和运行环境,涵盖停车场室内导航、车位占用检测、动态更新、精准导航和路径规划等方面。
75 4
|
19天前
|
Kubernetes Cloud Native 持续交付
云原生技术在现代应用架构中的实践与思考
【10月更文挑战第38天】随着云计算的不断成熟和演进,云原生(Cloud-Native)已成为推动企业数字化转型的重要力量。本文从云原生的基本概念出发,深入探讨了其在现代应用架构中的实际应用,并结合代码示例,展示了云原生技术如何优化资源管理、提升系统弹性和加速开发流程。通过分析云原生的优势与面临的挑战,本文旨在为读者提供一份云原生转型的指南和启示。
32 3
|
19天前
|
运维 Kubernetes Cloud Native
云原生技术在现代应用架构中的实践与挑战####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在实际项目中的应用案例,分析了企业在向云原生转型过程中面临的主要挑战及应对策略。不同于传统摘要的概述性质,本摘要强调通过具体实例揭示云原生技术如何促进应用的灵活性、可扩展性和高效运维,同时指出实践中需注意的技术债务、安全合规等问题,为读者提供一幅云原生技术实践的全景视图。 ####
|
18天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
49 2
|
2月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
70 0
|
2月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
57 0
|
2月前
|
存储 Java C++
Collection-PriorityQueue源码解析
Collection-PriorityQueue源码解析
64 0
|
2月前
|
安全 Java 程序员
Collection-Stack&Queue源码解析
Collection-Stack&Queue源码解析
85 0