我们应该能够签署具有多个身份的交易，这可能是在策略中配置的要求。
但是我无法使其正常工作，也就是说，我有一个需要多重签名的策略，因此我先使用两个组织的MSP信息对交易文件（.tx）进行了连续签名，但是当我提交交易时然后， 订购者或同行将拒绝它，并说“ 签名集不符合策略... ”。
奇怪的是，此检查忽略了我所做的其他签名，它只会考虑提交事务的命令自动完成签名：对等通道更新或对等链码实例化，就像 最后一个签名使我之前手动应用的签名无效。
对我所缺少的东西有什么想法？
我使用的命令：
我修改以形成不同签名的变量：
-已编辑
我正在使用Fabric版本1.4.0的第一网络示例：
这是configtx.yaml文件中的应用程序部分，我在其中将作家策略从 ANY Writers 更新为 MAJORITY Admins < / strong>：
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ApplicationCapabilities
在cli容器中，我可以毫无问题地创建频道：
peer channel create --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file channel-artifacts/channel.tx
在我加入对等方peer0.org1.example.com和peer0.org2.example.com之后，没有任何问题。
当我尝试提交锚点对等创建事务时，问题就开始了：
peer channel update --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file channel-artifacts/Org1MSPanchors.tx
我收到错误消息：
错误：状态发生意外：已禁止-无法隐式到达 1个子策略的阈值，需要剩余1个：权限被拒绝
订购者提供了更多详尽的日志：http://snippi.com/s/hlxkvl3
日志显示订购者尝试了以下操作来验证交易签名：
当我看到此错误时，我说好，我将首先使用Org1的管理员对事务进行签名，然后使用Org2的管理员签名进行提交：
peer channel signconfigtx -f channel-artifacts/Org1MSPanchors.tx
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.key
CORE_PEER_LOCALMSPID=Org2MSP
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/server.crt
CORE_PEER_TLS_ENABLED=true
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
CORE_PEER_ID=peer0.org2.example.com
CORE_PEER_ADDRESS=peer0.org2.example.com:7051
peer channel update --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file channel-artifacts/Org1MSPanchors.tx
我收到错误消息：
错误：状态发生意外：已禁止-无法隐式到达 1个子策略的阈值，需要剩余1个：权限被拒绝
订购者的日志：http://snippi.com/s/qjb7dlv
这一次的日志显示，订购者首先无法找到Org1的admin的签名（例如，第28行），然后找不到Org2的admin的签名（第45行）。并且 / Channel / Application / Writers 和 / Channel / Orderer / OrdererOrg / Writers 这两个策略都没有得到满足（第64行）。
我可以看到交易文件在签名后会增加，这是文件被正确修改的证明。但是为什么为什么订购者在控制过程中期望的这种签名似乎对它不可见？
继续前进，作为临时解决方法，我使用了订购者的管理员MSP来提交锚点对等方的交易：
CORE_PEER_LOCALMSPID=OrdererMSP
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin\@example.com/msp/
peer channel update --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file channel-artifacts/Org1MSPanchors.tx
这次命令起作用了。但奇怪的是，它之所以起作用，是因为我之前曾与Org1的管理员MSP签署了该交易，也就是说，如果我尝试在未与Org1的管理员MSP进行签名的情况下向订购者的管理员MSP提交交易，则交易失败。再次奇怪，如果我先用订购者的管理员签署交易，然后再用Org1的管理员提交交易，该命令将再次失败。
当我尝试实例化链码时，我遇到了同样的问题，正如我们在订购者的日志中看到的：http://snippi.com/s/324asxa
最好对Fabric的签名机制如何工作有深入的指导。
答案 0 :(得分：0)
单个事务签名必须满足读者和作家策略，因为事务处理格式只允许一个签名。
“管理员”策略是用于控制通道配置突变（例如修改“读取器”或“写入器”策略）的默认策略。通道配置的更改确实通过peer channel signconfigtx支持多签名工作流。
我们应该能够签署具有多个身份的交易，这可能是在策略中配置的要求。
某些事务（如配置更新事务）可能具有多个标识。其他事务，例如链码调用（包括对peer chaincode instantiate之类的lscc的调用）通常只能具有一个签名者。
但是我无法使其正常工作，也就是说，我有一个需要多重签名的策略，因此我先使用两个组织的MSP信息对交易文件（.tx）进行了连续签名，但是当我提交交易时然后，订购者或对等方将拒绝它，并说“签名集不符合策略...”。
如果这是配置更新，则粘贴更多日志将很有帮助。通常，如果正确设置了CORE_PEER_LOCALMSPID和CORE_PEER_MSPCONFIGPATH变量，则策略不满足，因为身份不满足所需的规则（通常为“ admin”）。
如果这是正常的链码调用（例如生命周期操作），则网络配置错误，因为必须能够通过单个提交者签名来满足这些调用。
此命令的确旨在允许您收集多个签名以进行配置更新。
该命令不是特别有用，可能会引起误解。它添加了签名，以便管理员可以手动验证协议，但是在评估任何结构策略时不会使用这些签名。