Hyperledger 蓑衣网小编2022 Fabric架构使用有保证的发布-订阅消息传递通道(如Kafka中的主题分区)将共识服务与事务日志(帐簿)分离。共识服务由称为订购者的网络节点提供，而分类帐由对等节点管理。

每个对等节点连接到共识服务的一个或多个通道，就像发布-订阅通信系统中的客户端一样。在信道上广播的事务以一致的顺序排列(例如，PBFT、卡夫卡)，并且订阅该信道的对等节点接收加密的块。每个对等节点验证该块并将其提交给帐簿，然后使用帐簿向应用程序提供其他服务。

一、定义和术语

订购者：提供共识服务的网络节点，例如，使用Kafka或PBFT。

Peers:维护账簿的网络节点。通常，在Hyperledger Fabric架构中有各种角色，如签署者和提交者。

通道：订单服务为订阅的主题(如发布-订阅消息队列)提供对等节点，每个主题都是一个通道。对等方可以订阅中的多个通道，并且只能访问订阅通道上的事务。

账簿：账簿存储订单提交、节点确认的交易记录。

成员：访问和使用账簿的网络节点。

连锁：基本上一个连锁由1个渠道，1个账本，N个会员组成。非链成员不能访问链上的事务。链的成员可以由应用程序动态指定。

二。数据隔离和机密性

共识服务支持多通道消息传递，因此对等节点可以基于访问控制策略的应用订阅任意数量的通道；也就是说，应用程序指定对等节点的子集来建立通道。这些对等体形成了一组向该通道提交事务的利益相关者，只有这些对等体可以接收包含相关事务的块，这些块与其他事务完全隔离。

此外，对等子集将这些私有块提交给不同的帐簿，允许它们保护这些私有事务，并将它们与其他对等子集的帐簿隔离。应用程序根据业务逻辑决定将事务发送到一个或多个通道。这不是一个固有的限制。区块链网络不知道并假设不同渠道的交易之间没有关系。

比如上图所示，对等体1、2、N订阅红色通道，共同维护红色账本；对等体1和n订阅蓝色通道并维护蓝色总账；类似地，对等体2和对等体N在黑色通道上，并且维护黑色总账。

在这个例子中，peer N订阅了所有的通道，我们看到每个通道都有一个相关的账簿。一般来说，我们把不涉及所有同行的书称为子书，另一种是系统书，也就是全书。

渠道和账本的组合是一个虚拟的链条，所以一个区块链网络可以有多个1共识服务的链条。系统渠道和整个账簿形成一个系统链。每个区块链网络只有一个系统链。如果交易是公开的，区块链网络可能永远不需要多个链；的所有事务对所有对等成员可见。然而，在成员之间的私人交易(如双边合同)中，单独的链是隔离数据和提供保密性的一种方式。

注意：共识服务接收所有链的所有事务，因此机密性只与对等方有关，而与订购方无关。当共识服务由许可网络中的受信任方和监管者组成时，这是合理的，即这些事务仅作为业务需求对他们可见。另一方面，如果应用程序不希望订购者知道交易的内容，它必须使用其他技术来隐藏敏感数据，如哈希或加密。共识作为可信任的一方而存在。如果用拜占庭容错(BFT)共识协议(如PBFT)实现，可以防止不可信订购者破坏账本一致性，阻碍系统可用性。然而，没有协议可以在不可信订购者存在的情况下提供多通道设计和数据保密性。

三。实现

在Fabric consensus服务的当前实现中，通道是隐式的；当对等体连接到区块链网络时，没有指定通道。 所以为了支持多渠道，订购者和对等者都需要改变。订购方必须提供多渠道订阅，对等方需要知道它可以订阅哪些渠道。以下部分描述了技术细节。

1)指南

共识服务由1个或多个订购者组成。每个订单都配置有一个匹配的创建块，该块由boot CLI命令生成。它提供了一些必要的数据，包括一系列可信根节点的列表、订单证书和IP地址的列表、一组特定的共识算法配置和访问控制策略(谁可以创建通道)。

要启动并连接到共识服务，peer至少需要以下配置：

1。入网登记证书。证书可以来自任何CA，只要该CA是对等方将连接到

2的共识服务的受信任根的一部分。共识服务管理CLI

3生成的订购者证书和IP地址列表。可信根节点列表

4。对等方可以订阅的可选频道列表。除非明确配置，否则对等机在启动时不会订阅任何通道

。注意# 2和# 3来自引导的创建块，我们可以从boot CLI命令中获得。

对等方可以通过CLI或使用SDK API的应用程序订阅现有通道。Order通过在信道创建或重新配置期间接收的消息来决定谁可以加入信道。

2)创建通道

您可以通过向合意服务发送通道配置事务和参与成员证书列表来创建通道。

应用程序决定哪些成员创建通道。该证书在对等方之间是公开的，并且可以被查询。渠道成员达成共识，为了避免订单处理过程中不必要的麻烦，不需要使用链码式交易背书，直接使用渠道配置交易即可。

我们将引入一个新的系统链码，称为配置系统链码(CSCC)，主要负责处理所有与配置相关的事务。CSCC提供了查询大量配置数据的方法，包括通道配置。

例如，假设对等体A和B属于两个不同成员Alice和Bob。请注意，Alice和Bob在网络上可能有多个对等体，并且他们的任何对等体都可以加入通道。下面是一个典型的序列：

1。应用程序/SDK获得A和B的认可以创建通道“foo”的配置事务。

2。应用程序/SDK调用Broadcast RPC将认可的配置事务传递给订单服务。

3。然后，应用程序/SDK调用foo通道上的deliver RPC。此RPC将返回一个错误，直到订单服务成功创建通道。

4。最终创建通道时，Deliver 蓑衣网小编2022 RPC会将通道的信息返回给application/SDK。此时，信道foo应该仅具有包含相关订户的创建块，并且与该配置事务一起被引导(或最新的重新配置事务)。

5。应用程序/SDK调用A和B上的JoinChannel API，将通道foo的创建块传递给A和B，并将CSCC添加到通道中。

CSCC在6楼。a和B检查创建块，包括检查块中的配置事务的背书。如果一切都正确，他们在通道上调用Deliver RPC来开始接收块。

如果频道已经存在，参与者列表将被替换。ERS会自动替换订阅者，并将该事务与通道上的其他事务一起发送给新成员，新成员将同步整个块。

3)关闭通道

应用程序可以通过发送与通道创建类似的配置事务来关闭它创建的通道。根据应用程序设置的策略，它需要获得渠道参与者的认可。Peer不会自动销毁相关书籍，但切割过程会适时处理。

应用程序可以继续从关闭的账簿中读取数据，只要账簿没有被删除，但是由于通道已经被破坏，交易无法执行。

4)查询渠道

渠道只能由本渠道成员查询。也就是说，交易发起者的签名可以通过存储在帐簿配置块中的CA证书来验证。这是通过向CSCC发起查询事务并附加链的ID来完成的。返回的结果是一个配置块，其中包含成员证书和一些其他配置

5)链上的交易

交易必须包含目标的链ID(链ID=渠道ID=账簿ID)。共识服务将把事务放在由链ID标识的指定通道上，并在该通道中对它们进行排序，而不考虑其他通道上的事务。最后，在通道上生成包含事务的块，并发送给订阅通道的对等方。

注意每个链都是独立并行的，所以一个对等体可以同时接收和处理不同链上的块。

chaincode事务只能操作指定链中的状态变量(类似于操作对象实例变量的函数)。链上的

6) ChainCode

部署到链上，只能在此链上调用。在某些应用场景下，我们需要调用另一个链的数据，修改自己链或者其他链的状态值。当我们需要一个只能部署一次但可以在任何链上调用的链代码时，跨链调用变得特别有用。

例如，假设系统账簿有一个记录输入事件的天气链码，ABC是一个新创建的账簿。我们可能想从ABC调用Weather，从系统链查询返回值，所以发送transaction [ABC，Weather.worldMap()]将返回系统链上的当前天气图。但是我们可能也希望Weather chaincode操作局部变量，所以发送[ABC，Weather.temperature()]将返回ABC链上的当前温度，而不是系统链上的当前温度。这个例子的需求是特殊的，但是它表明我们需要从一个事务或从另一个链代码调用不同链之间的链代码的能力。这对系统链上的链码特别有用。我们只需要部署它们一次，并且可以从任何私有链调用它们。

我们需要一个可编程的模型来表达被调用链码的操作。另一个解决方案是包含一个上下文，该上下文封装了chaincode将运行的分类帐(数据对象)。但是，chaincode可能在每个部署的分类帐中都有一些初始化参数(init函数)，所以我们需要能够在每个新分类帐上初始化chaincode。我们希望chaincode可以在本地执行。

在这一点上，我们要设置一些约定，让编程模型清晰起来：

1。从事务调用链码总是在发送事务的链上操作

2。只有系统链上的链代码可以被私有链上的其他链代码调用，并且是只读的

IV。API [允许App/SDK通知对等方它已成功加入的通道。通道API的输入是共识服务在新创建的通道上返回的创建块。对等方使用该块来设置与通道相关联的账簿。

一种新的交易类型叫做配置交易，这种交易类型可以由订购方和对等方处理。创建或重新配置信道的事务都是配置事务，其中背书请求是让对等体批准或不批准它们创建或重新配置信道。对等方可以通过建议请求返回接受或拒绝。为了保持灵活性，我们将提供一个系统链码来处理渠道创建的背书申请，它将自动响应签名申请。Chaincode还提供了查询该频道参与成员列表的功能。

配置事务具有ConfigurationEnvelope类型的有效负载，其中嵌入了序列号、链id和签名配置条目的列表。一个事务包含整个链的配置，单个配置总是独立存在的。这种简单的编码将允许容易的剪裁，并简化将来配置事务的开销。新的配置事务必须包含所有以前的配置条目，并且所有新的/修改的配置条目必须标记有它们的序列号和包含配置信封的链ID。每个配置条目都有一个枚举类型、一个唯一的(按类型分类)ID和一个由其名称引用的修改策略。订单服务将根据现有配置策略验证配置交易，如果不满足所有修改策略，则拒绝交易。

SDK可以为API提供进一步的抽象。例如，它可以提供1个API来创建一个通道(成员证书列表)，并且它将执行在创建通道一节中讨论的所有6个步骤。 最后，SDK将调用应用程序上的回调来返回创建通道的状态。