密钥级背书策略在 hyperledger fabric 中功能不全
key-level endorsement policy is not fully-functional in hyperledger fabric
我正在 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
这里的问题是，在背书期间，客户端不知道您的交易调用将 read/write 哪些分类帐密钥，或者可能应用哪些基于密钥的背书策略。它所知道的（使用发现服务）是被调用的链代码的背书策略，因此它将选择背书节点来满足该策略。
如果您的交易调用将访问私有数据集合或进行链码到链码调用，您可以向客户端表明这一点，以便它可以（再次使用发现服务）select 一个适当的集合考虑到这些集合 and/or 链代码调用，认可同行以满足有效的认可政策。本教程页面描述了这是如何完成的：
https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-discovery-fabric-network.html
这仍然没有涵盖基于密钥的背书策略的场景，因为访问的账本密钥是由您的交易功能的业务逻辑和客户端应用程序传入的参数决定的。因此，您需要提供必须明确认可使用 Transaction.setEndorsingOrganizations() 的组织的知识。这将覆盖 select 认可同行的正常机制并使用您指定的组织。
在撰写本文时，更新的 Fabric Gateway 客户端 API（Node、Go 和 Java）正在开发中，它移动了客户端中存在的大部分逻辑今天的端 SDK 变成了网关对等体。它的目标是与 Fabric v2.4 一起发布。此 Fabric Gateway 实现将检查背书期间模拟事务调用生成的 read/write 集，并使用它来动态检测给定事务调用的背书要求。因此，在进行客户端调用时，您不再需要指定所需的组织、集合或链代码到链代码的调用，并且它应该可以开箱即用地使用基于密钥的背书策略。此一般规则的例外情况是在传递私人数据时，您应该指定允许接收数据的组织，以防止意外泄露私人信息。
我正在 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
这里的问题是，在背书期间，客户端不知道您的交易调用将 read/write 哪些分类帐密钥，或者可能应用哪些基于密钥的背书策略。它所知道的（使用发现服务）是被调用的链代码的背书策略，因此它将选择背书节点来满足该策略。
如果您的交易调用将访问私有数据集合或进行链码到链码调用，您可以向客户端表明这一点，以便它可以（再次使用发现服务）select 一个适当的集合考虑到这些集合 and/or 链代码调用，认可同行以满足有效的认可政策。本教程页面描述了这是如何完成的：
https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-discovery-fabric-network.html
这仍然没有涵盖基于密钥的背书策略的场景，因为访问的账本密钥是由您的交易功能的业务逻辑和客户端应用程序传入的参数决定的。因此，您需要提供必须明确认可使用 Transaction.setEndorsingOrganizations() 的组织的知识。这将覆盖 select 认可同行的正常机制并使用您指定的组织。
在撰写本文时，更新的 Fabric Gateway 客户端 API（Node、Go 和 Java）正在开发中，它移动了客户端中存在的大部分逻辑今天的端 SDK 变成了网关对等体。它的目标是与 Fabric v2.4 一起发布。此 Fabric Gateway 实现将检查背书期间模拟事务调用生成的 read/write 集，并使用它来动态检测给定事务调用的背书要求。因此，在进行客户端调用时，您不再需要指定所需的组织、集合或链代码到链代码的调用，并且它应该可以开箱即用地使用基于密钥的背书策略。此一般规则的例外情况是在传递私人数据时，您应该指定允许接收数据的组织，以防止意外泄露私人信息。