Fabric Peer节点的类型

Peer节点是网络的基本元素，因为他们存储了账本和智能合约

在 Hyperledger Fabric 中，所有的 Peer 节点都是一样的，基于这个网络的配置，Peer 节点能够担当多个角色。这些角色有：

• 提交节点(Committing peer)

通道中的每个 Peer 节点都可以是一个提交节点。提交节点会接收排序节点(排序节点不是Peer节点)生成的区块，在这些区块被验证之后会以附加的方式提交到 Peer节点的账本副本中。

• 背书节点(Endorsing peer)

每个安装了智能合约的 Peer 节点都可以作为一个背书节点。然而，想要成为一个真正的背书节点，节点上的智能合约必须要被客户端应用使用，来生成一个被签名的交易响应。背书节点的术语就是这样来的。

智能合约的背书策略明确了在交易被接受并且记录到提交节点的账本之前，需要哪些组织的 Peer 节点为交易签名。

Peer 节点的两个主要类型，一个 Peer 节点还可以担任的两种其他的角色：

• 主节点

当组织在通道中具有多个 Peer 节点的时候，会有一个主节点，它负责将交易从排序节点分发到该组织中其他的提节点。一个节点可以选择参与静态或者动态的领导选举。

从管理者的角度来考虑的话会有两套节点，一套是静态选择的主节点，另一套是动态选举的主节点。对于静态选择，0个或者多个节点可以被配置为主节点。对于动态选举，一个节点会被选举成为主节点。另外，在动态选举主节点中，如果一个主节点出错了，那么剩下的节点将会重新选举一个主节点。

这意味着一个组织的节点可以有一个或者多个主节点连接到排序服务。这有助于改进需要处理大量交易的大型网络的弹性以及可扩展性。

• 锚节点

如果一个 Peer 节点需要同另一个组织的 Peer 节点通信的话，它可以使用对方组织通道配置中定义的锚节点。一个组织可以拥有0个或者多个锚节点，并且一个锚节点能够帮助很多不同的跨组织间的通信。

需要注意的是，一个 Peer 节点可以同时是一个提交节点、背书节点、主节点和锚节点。在实际情况中只有锚节点是可选的，一般都会有一个主节点，至少一个背书节点和一个提交节点。

Fabric交易流程

这里我把交易分为了两种，查询交易和更新交易

查询交易：

• 不产生新区块
• 整个交易流程不经过Orderer节点
• 目前创建的网路，读的权限为"ANY Readers"

更新交易

• 产生新区块
• 交易经过Orderer节点
• 需要多个节点背书，背书策略为"MAJORITY Endorsement"

查询交易

查询交易不产生新的区块，所以不会经过Orderer节点(排序节点)，Peer结点内存有账本和智能合约的副本。Peer 节点可以马上将查询的结果返回给应用程序，因为满足这个查询的所有信息都保存在 Peer 节点本地的账本副本中。

客户端连接到Peer节点

首先客户端(SDK/CLI)需要能连接到Peer节点，即能连接到区块链网络。

SDK可以通过gateway测试

CLI可以通过下面的命令进行测试

peer channel list

客户端发起查询交易

客户端根据背书策略向背书节点发起请求，可以发给任一背书节点，即可完成查询。要构建一个交易提案。应用程序使用所支持的 SDK（Node，Java，Python）中的 API 生成一个交易提案。提案是带有确定输入参数的调用链码方法的请求，该请求的作用是读取账本。

SDK 的作用是将交易提案打包成合适的格式（gRPC 使用的 protocol buffer）以及根据用户的密钥对交易提案生成签名。

背书节点验证签名并执行交易

背书节点验证

• 交易提案的格式完整
• 验证该交易提案之前没有被提交过（重放攻击保护）
• 验证签名是有效的（使用 MSP）
• 验证发起者（在这个例子中是客户端 A）有权在该通道上执行该操作（也就是说，每个背书节点确保发起者满足通道 Readers策略(目前网络为所有组织成员都可读)）。

背书节点将交易提案输入作为调用的链码函数的参数。然后根据当前状态数据库执行链码，生成交易结果，包括响应值、读集和写集（即表示要创建或更新的资产的键值对）。目前没有对账本进行更新。这些值以及背书节点的签名会一起作为“提案响应”返回到 SDK，SDK 会为应用程序解析该响应。

客户端接收背书节点响应

应用程序将检查查询响应，并且通常不会将交易提交给排序服务。到这整个查询交易就结束了。

更新交易

更新交易和查询交易起点相同，但是有两个额外的步骤。尽管更新账本的应用程序也会连接到 Peer 节点来调用链码，但是不像查询账本的应用程序，一个独立的 Peer 节点目前是不能进行账本更新的，因为其他的 Peer 节点必须首先要同意这个变动（即达成共识）。因此，Peer 节点会返回给应用程序一个被提案过的更新，这个 Peer 节点会依据其他节点之前的协议来应用这个更新。第一个额外的步骤，要求应用程序将响应的提案过的更新发送到网络中，网络中的 Peer 节点会将交易提交到它们相应的账本中。应用程序会收到排序节点打包了交易的区块，然后将他们分发到网络中所有的 Peer 节点，在区块被更新到每个 Peer 节点本地账本的副本中之前，这些区块都需要被验证。排序流程需要一定时间来完成 (数秒钟)，因此应用程序会被异步通知。

客户端连接到Peer节点

首先客户端(SDK/CLI)需要能连接到Peer节点，即能连接到区块链网络。

SDK可以通过gateway测试

CLI可以通过下面的命令进行测试

peer channel list

客户端发起更新交易

客户端根据背书策略向背书节点发起请求。要构建一个交易提案。应用程序使用所支持的 SDK（Node，Java，Python）中的 API 生成一个交易提案。提案是带有确定输入参数的调用链码方法的请求，该请求的作用是更新账本。

SDK 的作用是将交易提案打包成合适的格式（gRPC 使用的 protocol buffer）以及根据用户的密钥对交易提案生成签名。

背书节点的设置：

• SDK：在connection.json文件进行配置。配置错误则交易被拒绝
• CLI：在调用invoke方法时，须指定背书节点的IP、port、证书文件位置(–tlsRootCertFiles)

背书节点验证签名并执行交易

背书节点验证

• 交易提案的格式完整
• 验证该交易提案之前没有被提交过（重放攻击保护）
• 验证签名是有效的（使用 MSP）
• 验证发起者（在这个例子中是客户端 A）有权在该通道上执行该操作（也就是说，每个背书节点确保发起者满足通道 Writers策略）。

背书节点将交易提案输入作为调用的链码函数的参数。然后根据当前状态数据库执行链码，生成交易结果，包括响应值、读集和写集（即表示要创建或更新的资产的键值对）。目前没有对账本进行更新。这些值以及背书节点的签名会一起作为“提案响应”返回到 SDK，SDK 会为应用程序解析该响应。

客户端检查提案响应

应用程序验证背书节点的签名，并比较这些提案响应，以确定其是否相同。客户端应用程序向排序服务提交交易以更新账本，应用程序在提交之前需确定是否已满足指定的背书策略（即 peerA 和 peerB 都要背书）。该结构是这样的，即使应用程序选择不检查响应或以其他方式转发未背书的交易，节点仍会执行背书策略，并在提交验证阶段遵守该策略。

客户端将背书结果封装进交易

应用程序将交易提案和“交易消息”中的交易响应“广播”给排序服务。交易会包含读写集，背书节点的签名和通道 ID。排序服务不需要为了执行其操作而检查交易的整个内容，它只是从网络中的所有通道接收交易，将它们按时间按通道排序，并将每个通道的交易打包成区块。

验证和提交交易

交易区块被“发送”给通道上的所有 Peer 节点。对区块内的交易进行验证，以确保满足背书策略，并确保自交易执行生成读集以来，读集中变量的账本状态没有变化。块中的交易会被标记为有效或无效。

账本更新

每个 Peer 节点都将区块追加到通道的链上，对于每个有效的交易，写集都提交到当前状态数据库。系统会发出一个事件，通知客户端应用程序本次交易（调用）已被不可更改地附加到链上，同时还会通知交易验证结果是有效还是无效。