教程网

您现在的位置是: 首页 > 知识

Fabric基础架构原理(1):主要组件

Fabric基础架构原理(1):主要组件
本文选自新书《区块链核心技术与应用》,略有删节,Linux基金会于2015年12月启动了名为“超级账本”(Hyperledger)的开源项目,旨在推动各方协作,共同打造基于区块链的企

本文选自新书《区块链核心技术与应用》,略有删节,Linux基金会于2015年12月启动了名为“超级账本”(Hyperledger)的开源项目,旨在推动各方协作,共同打造基于区块链的企业级分布式账本底层技术,用于构建支撑业务的行业应用和平台。

超级账本里包括10个项目(project),其中区块链框架类项目5个:Fabric,Sawtooth,Iroha,Burrow和Indy;区块链工具类项目5个:Cello,Composer,Explorer, Caliper 和 Quilt 。

Fabric 于 2017 年 7月发布了1.0 GA版本,并得到社区较广泛的使用。本文主要介绍Fabric的总体架构。

Fabric基础架构

Fabric 项目的目标是实现一个通用的权限区块链(Permissioned Chain)的底层基础框架,为了适用于不同的场合,采用模块化架构提供可切换和可扩展的组件,包括共识算法、加密安全、数字资产、智能合约和身份鉴权等服务。

Fabric 克服了比特币等公有链项目的缺陷,如吞吐量低、交易公开无隐私性、无最终确定性以及共识算法低效等问题,使得用户能够方便地开发商业应用。

另一方面,Fabric 也存在不足之处,如 v1.2 的共识算法尚不支持 BFT 类型,交易过程还有并发控制的局限性,整体性能还有待提高等。

主要组件

Fabric 的组件包括客户端(Client),网络节点(Peer),CA(Certificate Authority)节点和排序节点(Orderer)。各个组件的相互关系如图所示。

Fabric组件关系

客户端的主要作用是和 Fabric 系统交互,实现对区块链系统的操作。这些操作分为管理类和链码类的两种。管理类包括启停节点和配置网络等;链码类操作主要是链码的生命周期管理,如安装、实例化以及调用链码。最常用的客户端是命令行客户端(CLI),此外是用 Fabric SDK 开发的应用客户端。用户通过不同的客户端使用 Fabric 系统的功能。

网络节点(Peer)是区块链去中心化网络中的对等节点,按照功能主要分为背书节点(Endorser)和确认节点(Committer)。背书节点主要对交易预案进行校验、模拟执行和背书。确认节点主要负责检验交易的合法性,并更新和维护区块链数据和账本状态。在实际部署中,背书节点和确认节点既可以部署在同一物理节点上,也可以分开部署。

排序节点(Orderer)主要职责是对各个节点发来的交易进行排序。在并发的情况下,各个节点交易的先后时序需要通过排序节点来确定并达成共识。排序节点按照一定规则确定交易顺序之后,发给各个节点把交易持久化到区块链的账本中。排序节点支持互相隔离的多个通道,使得交易只发送给相关的节点(Peer)。

CA 节点主要给Fabric网络中的成员提供基于数字证书的身份信息,可以生成或取消成员的身份证书(certificate)。在成员身份明确的基础上,Fabric可以实现权限控制的管理。

Fabric 网络的组件往往归属于不同的组织,在组织之间形成对等的去中心化网络。每个组织通常拥有自己的客户端、网络节点和 CA 节点,并且可以根据需要创建一个或多个不同的类型节点。排序节点不属于某个组织的实体,属于组织共同维护的组件。

通道

商业应用的一个重要的需求是私密性交易,为此 Fabric 设计了通道(Channel)来提供成员之间的隐私保护。通道是部分网络成员之间拥有独立的通信渠道,在通道中发送的交易只有属于通道的成员才可见,因此通道可以看作是Fabric的网络中部分成员的私有通信“子网”。

通道由排序服务管理。在创建通道的时候,需要定义它的成员和组织、锚节点(anchor peer)和排序服务的节点,一条和通道对应的区块链结构也同时生成,用于记录账本的交易,通道的初始配置信息记录在区块链的创世块(第一个区块)中。通道的配置信息可以用增加一个新的配置区块来更改。

每个组织可有多个节点加入同一个通道,这些节点中可以指定一个锚节点(或多个锚节点做备份)。锚节点代表本组织与其他组织的节点交互,从而发现通道中的所有节点。另外,同一组织的节点会选举或指定主导节点( leading peer ),主导节点负责接收从排序服务发来的区块,然后转发给本组织的其他节点。主导节点可以通过特定的算法选出,因此保证了在节点数量不断变动的情况下仍能维持整个网络的稳定性。

在 Fabric 的网络中,可能同时存在多个彼此隔离的通道,每个通道包含一条私有的区块链和一个私有账本,通道中可以实例化一个或多个链码,以操作区块链上的数据。由此可见,Fabric 是以通道为基础的多链多账本系统。

分布式账本

Fabric 里的数据以分布式账本的形式存储。账本由一系列有顺序和防篡改的记录组成,记录包含着数据的全部状态改变。账本中的数据项以键值对的形式存放,账本中所有的键值对构成了账本的状态,也称为“世界状态”( World State )。

每个通道中有唯一的账本,由通道中所有成员共同维护着这个账本,每个确认节点上都保存了它所属通道的账本的一个副本,因而是分布式账本。对账本的访问需要通过链码实现对账本键值对的增加、删除、更新和查询等的操作。

账本由区块链和状态数据库两部分组成。

区块链是一组不可更改的有序的区块(数据块),记录着全部交易的日志。每个区块中包含若干个交易的数据,不同区块所包含的交易数量可以不同。区块之间用哈希链( Hashed-link )关联:每个区块头包含该区块所有交易的哈希值,以及上一个区块头的哈希值。这样的链式架构可以确保每个区块的数据不可更改,以及每个区块之间的顺序关系不可更改。这个特点决定了区块链的区块只可以添加在链的尾部。

状态数据库记录了账本中所有键值对的当前值,相当于对当前账本的交易日志做了索引。链码执行交易的时候需要读取账本的当前状态,从状态数据库可以迅速获取键值的最新状态。

如果没有状态数据库,要获得某个键值时,需要遍历整个区块链中和该键值相关的交易,效率非常低,因此,读取状态数据库可以认为是快速定位和访问某个键值的方法。另外,当状态数据库出现故障的时候,可以通过遍历账本重新生成。

当一个区块附加到区块链尾部的时候,如果区块中的有效交易修改了键值对,则会在状态数据库中作相应的更新,这样区块链和状态数据库始终保持一致。

区块链的数据块以文件形式保存在各个节点中。状态数据库原理上可以是各种键值数据库,Fabric 缺省使用的是 LevelDB ,也支持 CouchDB 的选项。CouchDB 除了支持键值数据之外,也支持 JSON 格式的文档模型,能够做复杂的查询。

(未完待续)

本文选自新书《区块链核心技术与应用》,略有删节。上期介绍了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 )阶段就是由排序服务对交易进行排序,确定交易之间的时序关系。排序服务把一段时间内收到的交易进行排序,然后把排序后的交易打包成数据块(区块),再把区块广播给通道中的成员。采用这种方式,各个成员收到的是一组发生顺序相同的交易,从而保证了所有节点的数据一致性。

 1/3    1 2 3 下一页 尾页