Fabric背书策略相关概念与背书验证过程

目录

背书策略

CLI中背书策略语法

为chaincode指定背书策略

背书策略的验证过程

---

背书策略

节点通过背书策略来确定一个交易是否被正确背书。当一个peer接收一个交易后，就会调用与该交易Chaincode相关的VSCC（validator system chaincode实例化时指定的）作为交易验证流程的一部分来确定交易的有效性。为此，一个交易包含一个或多个来自背书节点的背书。

VSCC的任务是验证：

1.  所有的背书是有效的（即有效证书进行的有效签名）

2.  恰当的（满足要求的）背书数量

3.  背书来自预期的背书节点

背书策略即是用于定义2和3的验证规则。

CLI中背书策略语法

在CLI中，用一种简单的布尔表达式来表示背书策略。

Fabric使用MSP来描述主体，MSP用于验证签名者的身份和签名者在MSP中的角色、权限。目前支持：member, admin, client和peer。主体的描述形式是MSP.ROLE，其中MSP是MSP ID，ROLE是member，admin，client或peer。

比如一个有效的主体可表示为 'Org0.admin'（MSP Org0的管理员）或 'Org1.member'（MSP Org1的成员）或 'Org0.client（MSP Org0的客户端）或 'Org1.peer（MSP Org1的节点）。

CLI语法是：EXPR(E[, E...])

其中EXPR是AND或OR，表示布尔表达式；E是上面语法所描述的主体或者是另一个嵌套进去的EXPR。

例如：

  AND('Org1.member', 'Org2.member', 'Org3.member')表示需要三个主体共同签名背书

  OR('Org1.member', 'Org2.member')表示需要两个主体之一的签名背书

  OR('Org1.member',AND('Org2.member', 'Org3.member'))表示需要Org1的签名背书或者Org2和Org3共同的签名背书

为chaincode指定背书策略

如果在实例化chaincode时未指定背书策略，则背书策略默为“由通道中的组织的任何一个成员进行背书”。例如，一个带有“Org1”和“Org2”的通道将有一个默认的背书策略：OR（“Org1.成员”，“Org.成员”）。

命令：peerchaincode instantiate -C <channelid> -n mycc -P "AND('Org1.peer','Org2.peer')"

实例化chaincode后添加到通道中的新组织，可以查询chaincode，但将无法提交由其背书的事务。必须修改背书策略，来让由新加入的组织背书的交易得到认可。

背书策略的验证过程

1.  客户端（SDK）把交易提议（TX Proposal）发给指定的一个或多个背书节点(endorsing peer)。接收提议的背书节点在SDK的交易提议请求中指定，最终进行背书的节点由交易所属的ChainCode和该Chaincode所定义的背书策略（Endorsement Policy）共同决定。

例如node.js sdk的交易提议请求接口：

Channel. sendTransactionProposal(request, timeout)

request是一个ChaincodeInvokeRequest对象，可以在该对象中指定目标节点，如果未指定，则会将交易提议请求发送给加入该通道的所有节点。

2.  背书节点收到交易提议后，首先用客户端（SDK）的公钥验证它的签名、客户端是否可以在该channel进行操作、交易是否已被提交、交易提议组织是否正确。验证通过后模拟执行chaincode（不会将结果写入到账本里），将执行的结果反馈给客户端。

3.  客户端（SDK）收到足够多的背书节点的结果后（背书策略），表示这个交易已经正确背书，然后将交易提议、模拟结果和背书信息打包发给orderer节点；如果客户端没有搜集到足够多的背书节点反馈的背书信息，这个交易就会被舍弃。

4.  Orderer节点对来自客户端（SDK）的信息进行排序，并创建区块，然后在channel上进行广播。

channel上的peer节点接收到交易区块后，验证背书策略是否满足，然后更新账本，至此，背书策略的验证过程完成。

原文链接：Docs » Operations Guides » Endorsement policies