• -------------------------------------------------------------
  • ====================================

02-HyperLedger-Fabric1.0原理-图说-节点与Channel之间的关系

区块链 dewbay 5年前 (2020-01-06) 2104次浏览 已收录 0个评论 扫描二维码

前段时间,基于HyperLedger-Fabric1.0 进行了简单的区块链的开发,对里面设计的一个新概念Channel一直不理解。看了几篇文章,渐渐有了理解,这里分享出来,有不对的,欢迎指正!

全文的架构如下:

02-HyperLedger-Fabric1.0原理-图说-节点与Channel之间的关系

1.Fabric 中的节点

在理解Fabric1.0 区块链时,(以下简称Fabric)脑子里一定要有以下这些基本概念:

关于节点的术语:

  1. Orderers:提供共识服务的网络节点,例如,使用 Kafka 或 PBFT。
  2. Peers:维护账本的网络节点,通常在 Hyperledger Fabric中担任背书或者记账角色。
  3. Comitter:检查交易的合法性,最终将交易提交到去区块链中。

三者之间的关系可以用下图来表示:

02-HyperLedger-Fabric1.0原理-图说-节点与Channel之间的关系

在整个交易过程中,各个组件的主要功能如下:

  • 客户端(App):客户端应用使用 SDK 来跟Fabric网络打交道。首先,客户端从 CA 获取合法的身份证书来加入网络内的应用通道。然后,将交易的提案发送给配置文件里指定的背书节点(Endorser 节点)。
  • Endorser 节点:完成对交易提案的背书(目前主要是签名)处理。检查是否合法,通过则模拟运行交易,对交易导致的状态变化进行背书并返回结果给客户端。
  • Orderer 节点:仅负责排序。为网络中所有合法交易进行全局排序,并将一批排序后的交易组合生成区块结构。Orderer 一般不需要跟账本和交易内容直接打交道。
  • Committer 节点:负责维护区块链和账本结构。该节点会定期地从 Orderer 获取排序后的批量交易区块结构,对这些交易进行落盘前的最终检查。检查通过后执行合法的交易,将结果写入账本,同时构造新的区块。

注意!同一个物理节点可以仅作为 Committer 角色运行,也可以同时担任 Endorser 和 Committer 这两种角色。在下文关于通道的图例中,没有将 Committer 节点单独画出来。

  • CA:负责网络中所有证书的管理(分发、撤销等),实现标准的 PKI(公共密钥基础)架构。

2.Fabric 中的通道

上面只是在一个交易中,从节点的角度,来看交易的处理过程。然而,究竟有多少节点参与背书?多少节点来进行共识排序呢?在Fabric中,引入了通道的概念。

一般情况下,一条区块链网路的子链是按照“1 个通道+ 1 个账本+ N 个成员 ”的基本组成。

通道是两个或多个特定网络成员之间的通信的私有“子网”,用于进行需要数据保密的交易。在Fabric中,建立一个通道相当于建立了一个个子链。

接下来,我们来介绍一下关于通道的术语。

创建通道是为了限制信息传播的范围,是和某一个账本关联的。每个交易都是和唯一的通道关联的。这会明确地定义哪些实体(组织及其成员)会关注这个交易。

关于通道的术语:

  1. 通道:Order 服务提供 Peer 节点供订阅的主题,每个主题是一个通道。 peer 可以在订阅多个通道,并且只能访问订阅通道上的交易。关于“订阅-发布主题”,在后面会详细介绍。
  2. 账本:账本保存 Orders 提交经节点确认的交易记录。
  3. 成员:访问和使用账本的网络节点。
  4. 链:基本上,一个链由1 个通道+ 1 个账本+ N 个成员组成。非链的成员无法访问该链上的交易。链的成员可以由应用程序动态指定。

从关键词“1 个通道+ 1 个账本+ N 个成员”可以知道,要在 Fabric 区块链网络中,搭建一个子链,需要创建通道,利用通道将成员加入进来,由 N 个成员维护一个账本,从而实现一个区块链。

注意:
共识服务接收所有链的所有交易,因此保密性仅与 peer 而不是 Orderers 相关。
当共识服务由被许可网络中的可信方和监管机构组成时,这样是合理的,也就是说,这些交易作为业务需求仅对他们可见。

另一方面,如果应用程序不希望 Orderers 知道交易的内容,它必须利用其他技术来隐藏敏感数据,例如哈希散列或加密。
共识服务作为一个信任方存在,如果是由拜占庭容错(BFT)共识协议实现(例如 PBFT),可以防止不可信的 Orderers 破坏账本的一致性和阻碍系统可用性。

然而,现在还没有一种协议可以在有不可信的 Orderers 存在的情况下,提供多通道设计的同时提供数据保密性。[关于这一句话,还不是特别理解。。。暂时先贴上,以后理解了再回来填坑]


3.Fabric 的拓扑结构

下图展示了一个典型的 Fabric 网络中几个子链的拓扑关系:

02-HyperLedger-Fabric1.0原理-图说-节点与Channel之间的关系

下面,来简单介绍以上图的含义:

  1. 三条线,蓝色实线,红色实线,和橙色虚线,分别代表三个通道。
  2. 所有的通道,都连接了 Ordering Service 说明,共识服务接收所有链的所有交易。这一点,也说明了HyperLedger Fabric 不是完全的去中心化,而是多中心化。
  3. peer1.1 等节点,接入了多个通道,说明一个 peer 节点也可以参与到多个 channel 中。每个Channel之间是相互隔离,且是并行运行的。这一特性大大提高了系统的吞吐量。

从上图可以知道,一个链由1 个通道+ 1 个账本+ N 个成员组成。共识是由Ordering Service 提供的。应用程序指定 Peer 节点的子集中架设通道。 这些 peer 组成提交到该通道交易的相关者集合,而且只有这些 peer 可以接收包含相关交易的区块与其他交易完全隔离。


4.Fabric 子链的示意图

下图展示了多通道消息订阅与共识服务,账本之间的关系:

02-HyperLedger-Fabric1.0原理-图说-节点与Channel之间的关系

如上图所示,peer 1,2 和 N 订阅红色通道,并共同维护红色账本; peer 1 和 N 订阅蓝色通道并维护蓝色账本; 类似地,peer 2 和 peer N 在黑色通道上并维护黑色账本。

在这个例子中,peer N 在订阅了所有通道,我们看到每个通道都有一个相关的账本。 一般来说,我们称不涉及所有 peer 的账本为子账本,而涉及所有 peer 的账本另一种是系统账本,即全账本。


总结

在这里,我们理解了 Fabric 中的一个重要的概念,通道。

以及一种重要的关系,通道和 Peer 节点的关系。

Hyperledger Fabric 架构使用具有保证的发布-订阅模式消息传递通道(如 Kafka 中的主题分区),这种发布-订阅模式将共识服务与交易日志(账本)进行了有效的分离。

共识服务由称为 Orderers 的网络节点提供,并且账本由 Peer 节点管理。

从节点的角度来看,每个 Peer 节点连接到共识服务的一个或多个通道,就像发布-订阅通信系统中的客户端一样。 在通道上广播的交易按共识的顺序排列(例如 PBFT、kafka),订阅通道的 Peer 节点接收到加密的区块。 每个 peer 节点验证区块并将其提交到账本,然后向应用程序提供其他使用账本的服务。

从通道的节点来看,通道在众多的节点中,选择 N 个节点,加入到通道中,共同维护账本。以实现“1 个通道+ 1 个账本+ N 个成员”为基本要素的子链!

转自知乎 苏小乐 :https://www.zhihu.com/people/shan-de-ding-zhu/activities


露水湾 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:02-HyperLedger-Fabric1.0原理-图说-节点与Channel之间的关系
喜欢 (0)
[]
分享 (0)
关于作者:
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址