教程网

您现在的位置是: 首页 > 百科

Hyperledger Fabric是什么? Hyperledger Fabric介绍

Hyperledger Fabric是什么? Hyperledger Fabric介绍
Hyperledger Fabric是一个模块化的分布式账本解决方案支撑平台,提供高度的保密性、弹性、灵活性与可扩展性。它的目的是支持不同组件的可插入实现,并适应经济系统中存在的复杂

Hyperledger Fabric是一个模块化的分布式账本解决方案支撑平台,提供高度的保密性、弹性、灵活性与可扩展性。它的目的是支持不同组件的可插入实现,并适应经济系统中存在的复杂性。下面就来介绍下Hyperledger Fabric。

HyperledgerFabric是Linux基金会所主导的Hyperledger(超级账本)的项目之一。HyperledgerFabric旨在作为开发模块化体系结构的区块链应用程序的基础,以便诸如共识和会员服务等组件可以即插即用。它使用容器技术来托管构成系统应用逻辑的智能合约(也称为链代码)。简而言之,HyperledgerFabric是为企业构建的领先的开源、通用区块链结构。

Hyperledger超级账本此前我们科普过,它是一个开源商业联盟链项目,目的是帮助企业更容易地建立企业级区块链解决方案。目前已经有超过250家企业、组织加入,其中既包括IBM、Intel、百度、华为等IT巨头,也包括荷兰银行、埃森哲、澳新银行等金融机构。

HyperledgerFabric作为超级账本的项目之一,目前基于它开发的区块链项目非常多。不过需要注意的是,HyperledgerFabric是一个联盟链开发平台,与时下流行的以太坊、EOS等公链平台有较大的不同。HyperledgerFabric的中心化程度更高,并且链只限于联盟内的成员使用,但HyperledgerFabric相对容易达到更高的性能。

Hyperledger Fabric是什么?小编建议新手用户首先阅读接下来的内容以熟悉区块链如何工作,并熟悉Hyperledger Fabric的组成与功能。

本文选自新书《区块链核心技术与应用》,略有删节。上期介绍了Fabric基础架构的共识与交易机制,本次介绍Fabric私密交易方式:通道的结构。通道是Fabric中非常重要的概念,它实质是由排序节点划分和管理的私有原子广播通道,目的是对通道的信息进行隔离,使得通道外的实体无法访问通道内的信息,从而实现交易的隐私性。

目前通道分为系统通道(System Channel)和应用通道(Application Channel)。排序节点通过系统通道来管理应用通道,用户的交易信息通过应用通道传递。对一般用户来说,通道是指应用通道。系统通道与应用通道的关系如图10-5所示:

系统通道与应用通道

通道由排序服务节点负责管理,同时该节点还负责排序通道中的交易。在通道中一般包含有若干成员(组织),若两个网络实体的身份证书能够追溯到同一个根CA,则认为这两个实体属于同一组织。此外,通道中的每个组织都会有一个或以上的“锚节点”,它负责与其他组织交换共享账本的数据。

创建通道的时候定义了成员,只有通过成员MSP验证的实体,才能够加入到通道并访问通道数据。一个验证例子如下:

Org1 是通道 mychannel 的成员之一,与 Org1 绑定的 MSP 标识为 Org1MSP,其代表的 CA 称为 CA1;若实体的 MSP 满足以下条件则认为实体有权限访问 mychannel 的数据:

实体的MSP标识(ID)为 Org1MSP;

实体身份证书的信任链源头为 CA1.

实体只要满足通道中任意成员的 MSP 校验,则认为该实体有权限访问通道中的数据。

1.通道的配置

通道的配置信息都被打包到一个区块中,并存放在通道的共享账本中。该区块除了配置信息外不包含其他交易信息,称之为通道的配置区块(Configuration Block)。通道可以使用配置区块来更新配置,因此在账本中每新添加一个配置区块,通道就按照最新配置区块的定义来修改配置。通道账本的首个区块一定是配置区块,也称为初始区块(Genesis Block)。

2.使用configtxgen工具生成通道的配置

configtxgen是Fabric提供的工具,用于生成通道所需要的配置文件。configtxgen工具以一个yaml文件作为输入,一般称为 configtx.yaml,该文件定义了将要创建通道的配置信息,该文件通常包括以下部分:

1)Profiles: 包含了通道的配置模板,通过configtxgen工具的参数 -profile 来指定使用哪个模板。

2)Organizations: 定义了组织以及与之相应的 MSP。

3)Orderer: 定义系统通道的相关配置,如排序节点地址、共识算法。

4)Application: 定义应用通道相关配置,被 profile 引用。

以下面的配置文件configtx.yml为例,解释如何通过 configtxgen 创建通道的初始区块。 configtx.yml 清单如下:

上面的 profile 定义了系统通道和应用通道两种不同类型的通道。

系统通道必须定义 Orderer 和 Consortiums 两部分,应用通道必须定义 Application 和 Consortium 两部分。 (更详细的说明请参看 哈希1024社区文章[需粘贴地址到浏览器]:https://hash1024.org/topics/50 )

定义好 yaml 文件后,需要把 configtxgen 工具以及 msp 目录都拷贝到yaml文件的所在的目录下,configtxgen 默认会读取当前目录的 configtx.yaml 作为输入:

1)创建排序节点的初始区块:

configtxgen -profile Genesis -outputBlock genesis.block

该命令通过 profile 参数来指定生成 yaml 文件中 Profile.Genesis 的配置,通过 -outputBlock 参数来将区块写入 genesis.block 文件。

2)创建应用通道 mychannel 的初始区块的交易文件 channel.tx:

configtxgen -profile Channel -outputCreateChannelTx channel.tx -channelID mychannel

该命令通过-outputCreateChannelTx参数将生成的交易写入channel.tx文件,通过-channelID来指定创建通道的名称为mychannel。

3)创建配置区块的交易文件Org1MSPanchors.tx以更新mychannel中PeerOrg1的锚节点:

configtxgen -profile Channel -outputAnchorPeersUpdate Org1MSPanchors.tx -channelID mychannel -asOrg PeerOrg1MSP

该命令通过-asOrg来指定使用PeerOrg1MSP身份创建配置区块,并且通过-outputAnchorPeersUpdate参数将配置区块写入到文件Org1MSPanchors.tx中。

类似地,创建配置区块的交易文件 Org2MSPanchors.tx 以更新 mychannel 中 PeerOrg2 的锚节点:

configtxgen -profile Channel -outputAnchorPeersUpdate Org2MSPanchors.tx -channelID mychannel -asOrg PeerOrg2MSP

3.通道相关命令

对通道的管理可通过命令行的方式,与通道相关的命令如下:

peer channel create: 用于创建通道,主要参数有-c, -f, -o分别用于指定通道ID, configtx的路径和orderer的地址。

peer channel fetch:抓取通道中的特定区块,通过-c和-f参数来指定通道ID和orderer地址。

peer channel join:加入通道,通过-b参数指定初始区块。

peer channel list:列出peer加入的通道。

peer channel update :签名并且发送configtx以升级通道配置,需要通过-c, -f, -o参数分别指定通道ID, configtx的路径以及排序节点的地址。

4.动态修改通道配置

在通道创建后,通道相关的配置以区块的形式存在于通道的账本中。如果需要修改通道的配置,可通过生成新的配置区块去更新。修改通道配置的步骤如下:

1)通过sdk或CLI获得最新的配置区块。

2)编辑配置区块。

3)计算配置更新量。

4)为配置区块添加配置更新量。

5)sdk或CLI签名并发送配置区块。

若新的配置区块通过验证,则通道配置以最新配置区块为准。具体操作流程请参考后文修改通道配置。

(未完待续)

(来源:亨利笔记)

本文选自新书《区块链核心技术与应用》,略有删节。上期介绍了超级账本的主要组件,本次介绍共识机制和交易流程。Fabric 的网络节点本质上是互相复制的状态机,节点之间需要保持相同的账本状态。为了实现这个目的,各个节点需要通过共识( consensus )过程,对账本状态的变化达成一致性的认同。

Fabric 的共识过程包括 3 个阶段:背书、排序和校验。

1. 背书

在背书( endorsement )阶段中,背书节点对客户端发来的交易预案进行合法性检验,然后模拟执行链码得到交易结果,最后根据设定的背书逻辑判断是否支持该交易预案。如果背书逻辑决定支持交易预案,它将把预案签名后发回给客户端。

客户端通常需要根据链码的背书策略,向一个或者多个成员的背书节点发出背书请求。背书策略会定义需要哪些节点背书交易才有效,例如需要5个成员的背书节点中至少3个同意;或者某个特殊身份的成员支持等。客户端只有在收集满足背书策略的支持之后,广播出去的交易才能被视为有效。

2. 排序

排序( ordering )阶段就是由排序服务对交易进行排序,确定交易之间的时序关系。排序服务把一段时间内收到的交易进行排序,然后把排序后的交易打包成数据块(区块),再把区块广播给通道中的成员。采用这种方式,各个成员收到的是一组发生顺序相同的交易,从而保证了所有节点的数据一致性。

Fabric 1.0 中的排序服务支持可插拔的架构,除了提供的 SOLO 和 Kafka 模式外,用户可以添加第三方的排序服务。SOLO 是单机确认模式,仅适合开发测试中使用。Kafka 模式是基于 Kafka 开源的分布式数据流平台,具有高扩展性和容错能力,适合用在生产系统。需要注意的是,Kafka 只提供了 CFT 类型的容错能力,即仅可对节点的一般故障失效容错,缺乏对节点故意作恶的行为进行容错的能力。

排序服务是共识机制中重要的一环,所有交易都要通过排序服务的排序才可以达成全网共识,因此排序服务要避免成为网络上的性能瓶颈。

3. 校验

校验( validation )阶段是确认节点对排序后的交易进行一系列的检验,包括交易数据的完整性检查、是否重复交易、背书签名是否符合背书策略的要求、交易的读写集是否符合多版本并发控制 MVCC ( Multiversion Concurrency Control )的校验等等。当交易通过了所有校验之后,将被标注为合法并写入账本中。因为所有的确认节点都按照相同的顺序检验交易,并且把合法的交易依次写入账本中,因此它们的状态能够始终保持一致。

基于上面的共识机制,Fabric 的交易流程如下图所示:

1)应用端首先构建交易的预案,预案的作用是调用通道中的链码来读取或者写入账本的数据。应用端使用 Fabric 的 SDK 打包交易预案,并使用用户的私钥对预案进行签名。

应用打包完交易预案后,接着把预案提交给通道中的背书节点。通道的背书策略定义了哪些节点背书后交易才能有效,应用端根据背书策略选择相应的背书节点,并向它们提交交易预案。

2)背书节点收到交易预案后,首先校验交易的签名是否合法,然后根据签名者的身份,确认其是否具有权限进行相关交易。此外,背书节点还需要检查交易预案的格式是否正确以及是否之前提交过(防止重放攻击)。

在所有合法性校验通过后,背书节点按照交易预案,调用链码。链码执行时,读取的数据(键值对)是节点中本地的状态数据库。需要指出的是,链码在背书节点中是模拟执行,即对数据库的写操作并不会对账本作改变,所有的写操作将归总到一个写入的集合( Write Set )中记录下来。

在链码执行完成之后,将返回链码读取过的数据集( Read Set )和链码写入的数据集( Write Set )。读集和写集将在确认节点中用于确定交易是否最终写入账本。

3)背书节点把链码模拟执行后得到的读写集( Read-Write Set )等信息签名后发回给预案提交方(应用端)。

4)应用端在收到背书响应之后,检查背书节点的签名和比较不同节点背书的结果是否一致。如果预案是查询账本的请求,则应用端无需提交交易给排序节点。如果是更新账本的请求,应用端在收集到满足背书策略的背书响应数量之后,把背书预案中得到的读写集、所有背书节点的签名和通道号发给排序节点。

5)排序节点在收到各个节点发来的交易后,并不检查交易的全部内容,而是按照交易中的通道号对交易分类排序,然后把相同通道的交易打包成数据块( blob )。

6)排序节点把打包好的数据块广播给通道中所有的成员。数据块的广播有两种触发条件,一种是当通道的交易数量达到某个预设的阈值,另一种是在交易数量没有超过阈值但距离上次广播的时间超过某个特定阈值,也可触发广播数据块。两种方式相结合,使得排序过的交易可以及时广播出去。

7)确认节点收到排序节点发来的交易数据块后,逐笔检查区块中的交易。先检查交易的合法性以及该交易是否曾经出现过。然后调用 VSCC( Validation System Chaincode )的系统链码检验交易的背书签名是否合法,以及背书的数量是否满足背书策略的要求。

接下来进行多版本并发控制 MVCC 的检查,即校验交易的读集(Read Set)是否和当前账本中的版本一致(即没有变化)。如果没有改变,说明交易写集(Write Set)中对数据的修改有效,把该交易标注为有效,交易的写集更新到状态数据库中。

如果当前账本的数据和读集版本不一致,则该交易被标注为无效,不更新状态数据库。数据块中的交易数据在标注成“有效”或“无效”后封装成区块(block)写入账本的区块链中。

上述的交易流程中,采用了 MVCC 的乐观锁( optimistic locking )模型,提高了系统的并发能力。需要注意的是,MVCC 也带来了一些局限性。例如,在同一个区块中若有两个交易先后对某个数据项做更新,顺序在后的交易将失败,因为它的读集版本和当前数据项版本已经不一致(因为之前的交易更新了数据)。(未完待续)

FT/Fabric Token基本信息

币种名称:FT/Fabric Token

币种概念:平台

团队规模:11

上线时间:2018-10-15

所在国家:海外

官方网址:https://fabrictoken.io/

 1/2    1 2 下一页 尾页