超级账本结构中的关键级背书策略功能不全答案

【问题标题】：key-level endorsement policy is not fully-functional in hyperledger fabric超级账本结构中的关键级背书策略功能不全
【发布时间】：2021-10-15 00:08:56
【问题描述】：

我正在 Hyperledger Fabric v2.3.3 上设置基于密钥的背书策略。我的链码背书政策是"OR('org1.peer','org2.peer','org3.peer','org4.peer')"，对于一个非常具体的密钥，背书政策是"AND('org1.peer','org2.peer')"。第一次提交事务时，它可以正常工作，因为那时链码背书策略有效，但是当我尝试更新相同的密钥时，它不起作用。节点fabric-sdk仅将背书请求发送到1个组织，即org1（调用者），对等方拒绝该块并抛出“背书策略失败”。

当我验证区块时，我看到该交易仅由org1 认可，而不是由org1 和org2 认可。似乎 fabric-sdk 没有将交易发送到其他组织。

但是，如果我将我的链码背书策略更改为 "AND('org1.peer','org2.peer','org3.peer','org4.peer')"，一切都会正常工作，因为 fabric-sdk 会将交易发送给每个组织的对等方进行背书。

官方文档说

 In practice, this means that the key-level endorsement policy can be either less restrictive or more restrictive than the chaincode-level or collection-level endorsement policies.

但从上述情况来看，它似乎只能减少限制。对等日志：


2021-10-14 11:05:24.443 UTC [gossip.privdata] StoreBlock -> INFO 36d Received block [207] from buffer channel=assetschannel

2021-10-14 11:05:24.450 UTC [vscc] Validate -> ERRO 36e VSCC error: stateBasedValidator.Validate failed, err validation of key PUB-TEST-6 (coll'':ns'assets') in tx 207:0 failed: signature set did not satisfy policy

2021-10-14 11:05:24.454 UTC [committer.txvalidator] validateTx -> ERRO 36f Dispatch for transaction txId = b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e returned error: validation of key PUB-TEST-6 (coll'':ns'assets') in tx 207:0 failed: signature set did not satisfy policy

2021-10-14 11:05:24.454 UTC [committer.txvalidator] Validate -> INFO 370 [assetschannel] Validated block [207] in 5ms

2021-10-14 11:05:24.459 UTC [validation] preprocessProtoBlock -> WARN 371 Channel [assetschannel]: Block [207] Transaction index [0] TxId [b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

2021-10-14 11:05:24.495 UTC [kvledger] commit -> INFO 372 [assetschannel] Committed block [207] with 1 transaction(s) in 36ms (state_validation=0ms block_and_pvtdata_commit=6ms state_commit=29ms) commitHash=[35570558fc04d3dfa400f053f2a0f9bed92ea227c894ae4536990627a5a19036]

fabric-sdk 日志：

2021-10-14T11:05:24.491Z - warn: [TransactionEventHandler]: strategyFail: commit failure for transaction "b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e": TransactionError: Commit of transaction b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e failed on peer peer1.org1.com:7051 with status ENDORSEMENT_POLICY_FAILURE

2021-10-14T11:05:24.491Z - warn: [TransactionEventHandler]: strategyFail: commit failure for transaction "b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e": TransactionError: Commit of transaction b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e failed on peer peer1.org1.com:7051 with status ENDORSEMENT_POLICY_FAILURE

【问题讨论】：

标签： hyperledger-fabric hyperledger hyperledger-chaincode hyperledger-fabric-peer

【解决方案1】：

这里的问题是，在背书期间，客户端不知道您的交易调用将读取/写入哪些分类帐密钥或可能应用哪些基于密钥的背书策略。它只知道（使用发现服务）被调用的链码的背书策略，因此它会选择背书节点来满足该策略。

如果您的事务调用将访问私有数据集合或进行链码到链码调用，您可以向客户端表明这一点，以便它可以（再次使用发现服务）选择一组合适的背书节点来满足考虑到这些集合和/或链码调用的有效背书策略。本教程页面描述了这是如何完成的：

https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-discovery-fabric-network.html

这仍然不包括基于密钥的背书策略的场景，因为访问的分类账密钥是由您的交易功能的业务逻辑和客户端应用程序传入的参数决定的。因此，您需要提供必须使用Transaction.setEndorsingOrganizations() 明确认可的组织的知识。这将覆盖选择背书节点的正常机制并使用您指定的组织。

在撰写本文时，更新的 Fabric Gateway 客户端 API（Node、Go 和 Java）正在开发中，它将当今客户端 SDK 中存在的大部分逻辑转移到网关对等点中。它的目标是与 Fabric v2.4 一起发布。此 Fabric Gateway 实现将在背书期间检查通过模拟事务调用生成的读/写集，并使用它来动态检测给定事务调用的背书要求。因此，在进行客户端调用时，您应该不再需要指定所需的组织、集合或链码到链码调用，并且它应该与基于密钥的背书策略一起开箱即用。此一般规则的例外情况是在传递私人数据时，您应指定允许接收数据的组织，以防止私人信息意外泄露。

【讨论】：