Hyperledger fabric认知 #

fabric由来 #

​ 2015年12月由Linux基金会主导并牵头，IBM、Intel、Cisco等制造和科技行业的巨头共同宣布了Hyperledger fabric联合项目成立。

​ hyperledger fabric利用容器技术来托管链码，其中包括系统的应用程序逻辑。

​ Hyperledger Fabric 是分布式账本解决方案的平台，采用模块化架构，提供高安全性、弹性、灵活性和可扩展性。它被设计为支持以可插拔方式实现不同组件，并适应复杂的经济生态系统。

hyperledger fabric与其他公有区块链系统最大的不同主要体现在以下两个方面：
（1）私有
fabric提供建立通道的功能，允许参与交易新建一个单独的账本。
（2）许可
与开放无须许可的网络系统允许未知身份的参与者加入网络不同（需要通过工作量证明协议来保证交易有效并维护网络的安全），Hyperledger fabric通过MSP来登记所有成员。

cURL是什么？有什么作用？

cURL是一个可以在终端命令行下使用URL语法执行的开源文件传输工具。它支持基于HTTP/Socket的代理；cURL还支持使用SSL证书，支持HTTP POST、HTTP PUT，支持FTP上传，以及基于HTTP表单的上传；支持cookie，可以使用用户名+密码的方式实现认证等。

Hyperledger fabric架构 #

交易流程 #

背书 #

一个示例背书策略可能这样定义：参与区块链网络的四个组织中有三个必须在交易被认为有效之前签署该交易。所有的交易，无论是有效的还是无效的，都会被添加到分布式账本中，但只有有效交易会更新世界状态。

如果一项背书策略指定了必须有不止一个组织来签署交易，那么只有当足够数量的组织都执行了智能合约，才能够生成有效交易。

背书策略是 Hyperledger Fabric 与以太坊（Ethereum）或比特币（Bitcoin）等其他区块链的区别所在。在这些区块链系统中，网络上的任何节点都可以生成有效的交易。而 Hyperledger Fabric 更真实地模拟了现实世界；交易必须由 Fabric 网络中受信任的组织验证。例如，一个政府组织必须签署一个有效的 issueIdentity 交易，或者一辆车的 买家 和 卖家 都必须签署一个 车辆 转移交易。

有效交易 #

当智能合约执行时，它会在区块链网络中组织所拥有的节点上运行。智能合约提取一组名为交易提案的输入参数，并将其与程序逻辑结合起来使用以读写账本。对世界状态的更改被捕获为交易提案响应（或简称交易响应），该响应包含一个读写集，其中既含有已读取的状态，也含有还未书写的新状态（如果交易有效的话）。注意，在执行智能合约时世界状态没有更新！

所有的交易都有一个识别符、一个提案和一个被一群组织签名的响应。所有交易，无论是否有效，都会被记录在区块链上，但仅有效交易会更新世界状态。

一项交易被分发给网络中的所有节点，各节点通过两个阶段对其进行验证。首先，根据背书策略检查交易，确保该交易已被足够的组织签署。其次，继续检查交易，以确保当该交易在受到背书节点签名时它的交易读集与世界状态的当前值匹配，并且中间过程中没有被更新。如果一个交易通过了这两个测试，它就被标记为有效。所有交易，不管是有效的还是无效的，都会被添加到区块链历史中，但是仅有效的交易才会更新世界状态。

共享账本 #

Hyperledger Fabric 有一个账本子系统，包括两个组件： 世界状态 和 交易日志 。每个参与者都拥有他们所属的每个 Hyperledger Fabric 网络的账本副本。

世界状态组件描述了在给定时间点的账本的状态。它是账本的数据库。交易日志组件记录产生世界状态中当前值的所有交易；这是世界状态的更新历史。然后，账本包括世界状态数据库和交易日志历史记录。

**账本中世界状态的数据存储是可替换的。**默认情况下，这是 LevelDB 键值存储数据库。

交易日志不需要是可插拔的。它只记录区块链网络使用账本数据库前后的值。

智能合约 #

Hyperledger Fabric 智能合约用 链码 编写，当该应用程序需要与账本交互时，由区块链外部的应用程序调用。在大多数情况下，链码只与账本的数据库、世界状态（例如，查询）交互，而不与交易日志交互。

共识 #

共识被定义为组成区块的一组交易的正确性的闭环验证。

当区块中交易的顺序和结果满足明确的策略标准检查时，最终会达成共识。这些制衡措施是在交易的生命周期内进行的，包括使用背书策略来规定哪些特定成员必须背书某个交易类别，以及使用系统链码来确保这些策略得到执行和维护。在提交之前，节点将使用这些系统链码来确保存在足够的背书，并且它们来自适当的实体。此外，在将包含交易的任何区块附加到账本之前，将进行版本检查，以确保在此期间，账本的当前状态是能与交易中的信息达成共识的。该最终检查可防止双重花费操作和可能危及数据完整性的其他威胁，并允许针对非静态变量执行功能。

除了众多的背书、验证和版本检查外，交易流的各个方向上还会发生持续的身份验证。访问控制列表是在网络的分层上实现的(排序服务到通道)，并且当一个交易提议通过不同的架构组件时，有效负载会被反复签名、验证和认证。总而言之，共识并不仅仅局限于一批交易的商定顺序；相反，它的首要特征是交易从提案到提交的过程中不断进行核查而附带实现的。

交易必须按照发生的顺序写入账本，即使它们可能位于网络中不同的参与者集合之中。

为此，必须建立交易的顺序，且必须采用一种方法来拒绝错误（或恶意）插入到账本中的非法交易。

例如，PBFT（实用拜占庭容错算法）可以为文件副本提供一种机制，使其能够保持各个副本的一致性，即使在发生损坏的情况下也是如此。或者，在比特币中，通过称为挖矿的过程进行排序，其中竞争计算机竞相解决加密难题，该难题定义所有过程随后构建的顺序。

Hyperledger Fabric 被设计为允许网络启动者选择最能代表参与者间存在的关系的共识机制。

四大核心组件 #

成员服务 #

成员服务管理保证了fabric平访问的安全性，提供了成员组册、管理及审核功能。

区块链服务 #

区块链的核心部分，为区块链对主题功能提供了底层支撑，包括共识管理、分布式账本实现、账本的存储及网络中各节点之间的通信实现。

• 区块链：区块之间以hash连接为结构的交易日志。Peer节点从orderer service 节点接收交易区块，并根据背书策略和并发冲突标记区块上的交易是否有效，然后将区块追加到peer文件系统中的Hash Chain上。

• 交易

  • 部署交易

    部署是请求peer上启动链码容器；创建新的链码并设置一个程序作为参数。

  • 调用交易

  ​ 调用是从账本中请求读写集，是在之前已部署链码的情况下执行一个操作。调用交易将使用链码提供的一个函数。

链码服务 #

提供链码部署及运行时的所需环境

事件 #

为各组件之间的异步通信提供技术实现。

Orderer（排序服务节点） #

对客户端提交的交易请求进行排序，之后生成区块广播给通道内的Peer。

Peer #

Peer：表示组织中的节点；Peer节点以区块的形式从排序服务节点接收有序状态更新，维护状态和账本。

• 背书节点：根据指定的策略调用智能合约，对结果进行背书，返回提案响应到客户端。
• 提交节点：验证数据并保存至账本中。
• 锚节点：通道中的每个组织都有一个锚节点，锚节点可以允许同一通道中不同组织的peer节点发现通道内的所有peer节点。
• Leader节点：作为组织内所有节点的代表，能够连接到排序服务节点，将从排序服务节点接收到的批量区块广播给组织内的其他节点。

Hyperledger Fabric交易流程 #

• 客户端利用受支持的SDK提供的API构建交易提案请求，将交易事务提案打包成为一个正确的格式。交易提案包含如下要素。
  • channel ID：通道信息
  • chaincodeID：要调用的链码信息
  • timestamp：时间戳
  • sign：客户端的签名
  • txPayload：提交的事务本身包含的内容，包含两项。
    • operation：要调用的链码的函数及相应的参数
    • metadata：调用的相关属性

• 在交易提案中使用用户的加密凭据为此事物提案生成唯一的签名，之后将事物提交给背书节点。
• 背书节点对接收到的交易提案请求进行验证
  • 交易提案格式是否正确
  • 交易在之前未提交过
  • 提交交易提案的客户端签名是否有效（使用MSP）
  • 提交交易提案的请求者是否在该通道中有相应的执行权

​ 验证通过后调用链码进行模拟执行，产生包括响应值、读集和写集的事务结果。对结果进行背书并响应给客户端。

• 应用程序收集到足够的消息和背书签名之后，构建合法的交易请求并将交易请求广播给Ordering服务节点。

  如果应用程序的请求仅仅是查询分类账本，则应用程序将检查查询响应信息，并不会将事物提交给Ordering排序服务

• 交易请求被提交到Orderer节点，该事物将包含读/写集、背书签名和通道ID。Orderer节点接收到事务请求之后，并不需要检查交易中的具体数据，只是从网络中的所有通道接收交易，按时间顺序对它们进行排序，并创建交易区块，之后广播给同一通道内所有组织的Leader节点。

• Leader节点：Leader节点对接收到的区块进行验证（交易消息结构是否正确、是否重复、是否有足够的背书、读写集版本），通过验证后将结果写人本地的分类账本中。

• 同步广播：Leader节点同步广播给组织内的其他节点（保证在同一通道内的）。在Hyperledger fabric中，广播给其他节点默认为临近的3个节点。此广播数量可以通过配置文件改变，注意：跨组织广播则由组织内的锚节点负责。

• 分类账本更新：每个peer节点将区块附加到区块链中，写集被提交到当前的状态数据库中，并且对每个有效的事务，发出一个事件，通知客户端应用程序事务（调用）已被不可变的附加到链中，以及通知该事务是否已经过验证或为无效事务。

交易过程：

1.交易产生

客户端应用程序将交易提案发送给一组节点，这些节点将调用智能合约来生成一个账本更新提案，然后背书该结果。

2.背书

背书节点此时不将提案中的更新应用于其账本副本。相反，背书节点将向客户端应用程序返回一个提案响应。

3.交易排序

应用程序客户端把包含已背书交易提案响应的交易提交到排序服务节点。

一个区块中交易的顺序不一定与排序服务接收的顺序相同，因为可能有多个排序服务节点几乎同时接收交易。重要的是，排序服务将交易放入严格的顺序中，并且 Peer 节点在验证和提交交易时将使用这个顺序。

区块内交易的严格排序使得 Hyperledger Fabric 与其他区块链稍有不同，在其他区块链中，相同的交易可以被打包成多个不同的区块，从而形成一个链。在 Hyperledger Fabric 中，由排序服务生成的区块是最终的。一旦一笔交易被写进一个区块，它在账本中的地位就得到了保证。正如我们前面所说，Hyperledger Fabric 的最终性意味着没有账本分叉，也就是说，经过验证的交易永远不会被重写或删除。

4.产生区块

排序服务创建交易区块，这些交易区块最终将分发给通道上的所有 Peer 节点，以便在第三阶段进行最终验证和提交。

排序服务节点同时接收来自许多不同应用程序客户端的交易。这些排序服务节点一起工作，共同组成排序服务。它的工作是将提交的交易按定义好的顺序安排成批次，并将它们打包成区块。

5.广播区块

然后将这些区块保存到排序节点的账本中，并分发给已经加入通道的所有节点。如果此时恰好有一个 Peer 节点关闭，或者稍后加入通道，它将在重新连接到排序服务节点或与另一个 Peer 节点通信之后接收到这些区块。

6.验证区块

每个节点将独立地以确定的方式验证区块，以确保账本保持一致。具体来说，通道中每个节点都将验证区块中的每个交易，以确保得到了所需组织的节点背书，也就是节点的背书和背书策略相匹配，并且不会因最初认可该事务时可能正在运行的其他最近提交的事务而失效。无效的交易仍然保留在排序节点创建的区块中，但是节点将它们标记为无效，并且不更新账本的状态。

排序节点的第二个角色是将区块分发给 Peer 节点。在本例中，排序节点 O1 将区块 B2 分配给节点 P1 和 P2。节点 P1 处理区块 B2，在 P1 上的账本 L1 中添加一个新区块。同时，节点 P2 处理区块 B2，从而将一个新区块添加到 P2 上的账本 L1中。一旦这个过程完成，节点 P1 和 P2 上的账本 L1 就会保持一致的更新，并且每个节点都可以通知与之连接的应用程序交易已经被处理。

搭建Hyperledger fabric网络 #

生成组织结构与身份证书 #

crypto-config.yaml #

crypto-config.yaml文件主要指定整个网络中相关组织的详细信息

crypto-config.yaml文件详解

configtx.yaml #

指定Orderer服务的相关配置，以及当前联盟信息、联盟中包含的组织信息。

configtx.yaml文件详解

docker-compose.yaml文件 #

docker-compose.yaml文件详解

启动网络 #

solo节点测试

为什么要创建节点并将其加入应用通道中？

创建应用通道交易配置文件，可以指定创建的应用通道中可以有哪些组织加入及指定响应的权限；网络上的每个交易都需要在一个指定的通道中执行；在通道中，交易必须通过通道的认证和授权。要加入一个通道的每个节点都必须有自己的通过MSP获得的身份标识，用于鉴定每个节点在通道中的是什么节点和服务。

智能合约 #

智能合约

MSP 成员管理及Hyperledger fabric CA #

fabric-ca详解

共识算法 #

​ 交易如何在分布式场景下实现所有节点对同一个提案或值的一致性？

​ 共识算法是保证分布式系统一致性实现的解决方式，共识算法是计算机科学中用于在分布式过程或系统之间实现对单个数据值的一致性的过程。在分布式场景中，可能出现网络丢包、时钟漂移、节点宕机、节点作恶等等故障情况，共识算法需要能够容忍这些错误，保证多个节点取得相同的数据状态。

• 共识算法的属性

  • 安全性

    表示每个节点保证相同的输入序列，并在每个节点上产生相同的输出结果。该算法必须与单个节点系统的执行结果相同。

  • 活跃性

    在通信正常情况下，每个非故障节点最终都能接收每个提交的交易。

数据分发机制Gossip #

Gossip协议 #

​ Gossip是一种去中心化的分布式协议，用于实现节点或者进程之间的信息交换，通常用在大型的无中心化网络环境中，并且假设网络环境不太稳定，时分布式系统中广泛使用的一种最终一致性协议。

​ Gossip协议时在网络中的某个节点将指定的数据发送到网络内的一组其他节点。数据通过节点像病毒一样逐个传播，最终传播到系统中的每个节点，从而在大型分布式系统中可靠地进行数据传输。

Gossip协议的特征

• Gossip协议本质上是概率性的，节点选择其网络内随机通信的目标节点。
• 扩展性高：发送方节点向固定数量的接收方节点发送消息，与网络中的总节点数量无关。
• 低延迟：发送节点不必确认接受点是否收到消息。
• 不需要故障检测或特定的恢复操作，因为节点没有特定的角色，接收信心失败的节点不会阻止其他节点继续发送消息。
• 实现容错：节点可从其他不同的节点接收消息的副本。

Gossip协议的类型

• 传播协议/谣言协议：通过网络中的泛洪代理来工作，节点收到广播的数据后直接转发给所有的邻居节点。此方式可以提高网络的健壮性，但容易造成广播风暴。
• 反熵协议：用于修复复制数据，通过比较复制和协调差异进行操作。fabric中的数据同步就是使用此方式实现的。
• 计算聚合协议：对网络中的节点的信息进行采样，并将这些值组合起来得到系统范围内的值，从而计算出网络范围内的集合；之后将建立一种全面的信息流模式。

Gossip数据传输 #

如何保证网络中的每一个节点都能够接收到对应的数据且在不稳定的网络环境中保持数据的实时同步？

Gossip数据分发协议实现了两种数据传输方式

• 推送方式
  • 网络中的某个节点随机选择N个节点作为数据接收对象
  • 该节点向其选中的N个节点传输相应的信息
  • 接收到信息的节点处理所接收的数据
  • 接收到数据的节点再从第一步开始重复执行
• 拉取方式
  • 某个节点周期性地随机选择N个节点询问有没有最新的信息
  • 收到请求的节点回复请求节点其最近未收到的信息

fabric数据同步的实现 #

​ Gossip消息是连续的，通道中的每个Peer节点都不断地接收来自多个节点已完成一致性的区块数据。每条传输的Gossip消息都有相应的签名，从而有拜占庭参与者发送的伪造消息很容易被识别出来，并且可以防止将消息分发给不在同一通道中的其他节点。受到延迟、网络分区或其他导致区块丢失的原因影响的节点，最终将通过联系已经拥有这些缺失区块的节点而与当前账本状态进行同步。

fabric网络中基于Gossip的数据传播协议主要实现3个功能：

• 通过不断的识别可用的成员节点并最终检测节点离线状态的方式，对通道中的成员进行管理。
• 将分类账本数据传播到通道中的所有节点。任何节点中如有缺失区块都可以通过从通道中其他节点复制正确的数据来标识缺失的区块并同步自身。
• 在通道中的所有节点上同步分类账本状态。通过允许点对点状态传输更新账本数据，保证新连接的节点以最快的速度实现数据同步。

对于新区块的传播，通道中的Leader节点从Orderer服务中提取数据，并向随机选择的邻居节点发起Gossip广播。

随机选择的邻居节点数量可以通过配置文件进行声明。节点也可以使用拉取机制，而不是等待消息的传递。

数据同步流程 #

​ 客户端应用程序将交易提案请求提交给背书节点，背书节点处理并背书签名后返回响应，然后提交给Orderer服务进行排序，排序服务达成后生成区块，通过deliver()广播给各个组织中通过选举方式选出的Leader节点，Leader节点随机选择N个节点将接收到的区块进行分发。另外，为了保持数据同步，每个节点会在后台周期性地与其他随机的N个节点的数据进行比较，以保持区块数据状态的同步。

• 新的交易被提交给Ordering服务进行排序
• 创建新区块
• 将新区块交给所有的peer
  • Peer（Leader）节点接收到新消息
  • 该节点将消息发送到预先指定数量多其他peer节点
  • 接收到消息的每个peer节点再将消息发送给预定数量的其他peer节点
  • 依次类推，直到所有peer节点都收到新消息

​ Gossip协议的关键部分是每个节点将消息随机选择并转发给网络中的其他节点。这意味着每个节点都知道网络中的所有节点，因此可以在相应的Peer节点中进行选择。

​ 某一个节点如何都知道网络中的所有节点？

在fabric中每个节点会随机向预先定义数量的其他节点定期广播一条消息，指示它仍处于活动状态并连接到网络。每个节点都维护着自己网络中的所有节点的列表（活跃的节点和无响应的节点）。

在fabric中，peer节点之间定期相互交换成员资格数据（peer节点列表，活动和死亡）和分类账本数据（事物块）。在这种机制下，peer节点即使因为故障或其他原因错过了接收新区块的广播或因为其他原因产生了缺失区块，但在加入网络之后仍然可以与其他的peer节点交换信息以保持数据同步。

fabric使用peer之间的Gossip作为容错和可扩展机制，以保持区块链分类账本的所有副本同步，它减少了Orderer节点的负载。由于不需要固定连接来维护基于Gossip的数据传播，因此该流程可以可靠地为共享账本保证数据的一致性和完整性，包括对节点奔溃的容错。

某些节点可以加入多个不同的通道，但是通过将基于节点通道订阅的机制作为消息分发策略，由于通道之间实现了相互隔离，一个通道中的节点不能在其他通道上发送或共享信息，所以节点无法将区块传播给不在通道中的节点。

点对点消息的安全性由节点的TLS层处理，不需要签名。节点通过其由CA分配的证书进行身份验证。节点在Gossip层的身份认证会通过TLS证书体现。账本中的区块由排序服务进行签名，然后传递给通道中的Leader节点。

身份验证过程由节点的成员管理服务的提供者（MSP）进行管理。当节点第一次连接到通道时，TLS会话将与成员身份绑定。这本质上是通过网络和通道中的成员身份对连接的每个节点进行身份验证的。

Leader节点的选举 #

• 静态选举

  系统管理员手动配置实现

• 动态选举

​ 动态选举可以在各自的组织内动态选举出一个Leader节点，它将代表各自的组织连接到Ordering服务节点并拉取新的区块。

​ 当选的Leader节点必须向组织内的其他节点定期发送心跳信息，作为处于活跃状态的证据。如果一个或多个节点在指定的一段时间内得不到最新消息，则网络将启动新一轮领导人选举程序，最终选出新的Leader节点。

锚节点 #

​ 锚节点主要用于启动来自不同组织的节点之间的Gossip通信。锚节点作为同一通道上的另一组织的节点的入口点，可以与目标锚节点所在组织中的每个节点通信。跨组织的Gossip通信必须包含在通道的范围内。

​ 由于跨组织的通信依赖于Gossip，某一个组织的节点需要知道来自其他组织的节点的至少一个地址（由这个节点，可以找到该组织中的所有节点的信息）。所以，添加到通道的每个组织应该将其节点中的至少一个节点标识为锚节点（也可以有多个锚节点，以防止单点故障）。

数据存储 #

区块链账本数据 #

Fabric的账本由两个不同但相关部分组成。

世界状态 #

是以键值对的方式保存一组分类账本数据状态的最新值。保存世界状态的实际上是一个NoSQL数据库,以方便对状态的存储及检索；可以使应用程序无须遍历整个事物日志而快速获取当前账本的最新值。

每个世界状态都具有一个版本号，起始版本号的值为0。每次对状态进行更改时，状态的版本号都会递增。对状态进行更新时也会检查，以确保它与创建事务时对版本匹配。

应用程序提交那些会更改世界状态的交易，这些交易最终被提交到账本区块链上。应用程序无法看到 Hyperledger Fabric SDK（软件开发工具包）设定的共识机制的细节内容，它们能做的只是调用智能合约以及在交易被收进区块链时收到通知（所有被提交的交易，无论有效与否，都会被收进区块链）。Hyperledger Fabric 的关键设计在于，只有那些受到相关背书组织签名的交易才会更新世界状态。如果一个交易没有得到足够背书节点的签名，那么它不会更新世界状态。

区块链 #

区块链的结构是一群相互链接的区块的序列化日志，其中每个区块都包含一系列交易，各项交易代表了一个对世界状态进行的查询或更新操作。

区块头包含了本区块所记录交易的哈希值，以及前一个区块头的哈希值。区块链总是以文件实现，而与之相反的是，世界状态以数据库实现。

区块头 #

这个部分包含三个字段，这些字段是在创建一个区块时候被写入的。

• 区块编号：编号从0（初始区块）开始，每在区块链上增加一个新区块，编号的数字都会加1。
• 当前区块的哈希值：当前区块中包含的所有交易的哈希值。
• 前一个区块头的哈希值：区块链中前一个区块头的哈希值。

这些字段是通过在内部对区块数据进行加密哈希而生成的。它们确保了每一个区块和与之相邻的其他区块紧密相连，从而组成一个不可更改的账本。

• 区块头详情：区块 B2 的区块头 H2 包含了区块编号 2，当前区块数据 D2 的哈希值 CH2，以及前一个区块头 H1 的哈希值。

• 区块数据

  这部分包含了一个有序的交易列表。区块数据是在排序服务创建区块时被写入的。这些交易的结构很复杂但也很直接，我们会在后边进行讲解。

• 区块元数据

  这个部分包含了区块被写入的时间，还有区块写入者的证书、公钥以及签名。随后，区块的提交者也会为每一笔交易添加一个有效或无效的标记，但由于这一信息与区块同时产生，所以它不会被包含在哈希中。

区块数据（交易） #

正如我们所看到的，交易记录了世界状态发生的更新。让我们来详细了解一下这种把交易包含在区块中的区块数据结构。

交易详情：交易 T4 位于区块 B1 的区块数据 D1 中，T4包括的内容如下：交易头 H4，一个交易签名 S4，一个交易提案 P4，一个交易响应 R4 和一系列背书 E4。

在上面的例子中，我们可以看到以下字段：

• 头

  这部分用 H4 表示，它记录了关于交易的一些重要元数据，比如，相关链码的名字以及版本。

• 签名

  这部分用 S4 表示，它包含了一个由客户端应用程序创建的加密签名。该字段是用来检查交易细节是否未经篡改，因为交易签名的生成需要用到应用程序的私钥。

• 提案

  这部分用 P4 表示，它负责对应用程序供给智能合约的输入参数进行编码，随后该智能合约生成提案账本更新。在智能合约运行时，这个提案提供了一套输入参数，这些参数同当前的世界状态一起决定了新的账本世界状态。

• 响应

  这部分用 R4 表示，它是以读写集 （RW-set）的形式记录下世界状态之前和之后的值。交易响应是智能合约的输出，如果交易验证成功，那么该交易会被应用到账本上，从而更新世界状态。

• 背书

  就像 E4 显示的那样，它指的是一组签名交易响应，这些签名都来自背书策略规定的相关组织，并且这些组织的数量必须满足背书策略的要求。你会注意到，虽然交易中包含了多个背书，但它却只有一个交易响应。这是因为每个背书都对组织特定的交易响应进行了有效编码，那些不完全满足背书的交易响应肯定会遭到拒绝、被视为无效，而且它们也不会更新世界状态，所以没必要放进交易中。

  在交易中只包含一个交易响应，但是会有多个背书。这是因为每个背书包含了它的组织特定的交易响应，这意味着不需要包含任何没有有效的背书的交易响应，因为它会被作为无效的交易被拒绝，并且不会更新世界状态。

数据存储 #

区块链是以文件的形式进行存储，各区块文件默认以blockfile_为文件前缀，后面以6位数字命名，起始数字默认位000000，如有新文件则每次递增1.

区块链文件默认存储目录位/var/hyperledger/production/ledgersData/chains,包括两个子目录：

• 保存区块链文件的chains目录
• 使用LevelDB实现保存索引信息的index目录。

orderer节点本身只会保存一份账本，但不包括状态数据库及历史索引数据，这些均由Peer节点进行维护。

在peer节点中，除了存储一份账本外，还需要维护状态数据库、历史数据库、区块索引这些内容。

• 状态数据库

  存储交易日志中所有Key的最新值，默认使用LevelDB。链码调用基于当前的状态数据库执行交易。

• 历史数据库

  以LevelDB数据库作为数据存储载体，存储区块中有效交易相关的Key，而不存储Value。

• idStore

  存储当前peer节点加入的所有ledgerId，并且保证账本编号全局唯一性。

fabric-sdk-go #

fabric-sdk-go详解