我们应该能够签署具有多个身份的事务，这可能是策略中配置的要求。
但是我没有使这个工作，也就是说，我有一个需要多个签名的策略，所以我用两个组织的MSP信息连续签署了事务文件（.tx），但是当我提交事务时， orderer或同行会拒绝它，说“签名集不符合政策......”。
奇怪的是，这个检查忽略了我做的其他签名，它只会考虑提交事务的命令自动完成签名：对等通道更新或对等链代码实例化，好像这最后一个签名使我之前应用的签名无效手动。
关于我缺少什么的一些想法？
我使用的命令：
我修改的变量用于创建不同的签名：
- 编辑
我正在使用Fabric版本1.4.0的第一个网络示例：
这是configtx.yaml文件中的Application部分，我将作者策略从任何作者更新为MAJORITY Admins：
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
我有错误消息：
错误：出现意外状态：FORBIDDEN - 无法达到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/[email protected]/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
我收到了错误消息：
错误：出现意外状态：FORBIDDEN - 无法达到1个子策略的隐含阈值，需要1个剩余：权限被拒绝
来自订货人的日志：http://snippi.com/s/qjb7dlv
日志显示，此时订货人首先找不到Org1管理员的签名（例如第28行），然后找到Org2管理员的签名（第45行）。并且两个策略/ Channel / Application / Writers和/ Channel / Orderer / OrdererOrg / Writers都没有得到满足（第64行）。
我可以看到，当我签名时，事务文件的大小会增加，因为文件的改进很好。但是为什么在控制期间由命令者预期的这种签名似乎对它不可见？
为了向前推进，作为临时解决方法，我使用orderer的管理员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签署了交易，也就是说，如果我尝试使用orrrer的管理员MSP提交交易而没有在Org1的管理员MSP上签名，那么它就失败了。再次奇怪，如果我开始使用orderer的管理员签署交易，然后通过Org1的管理员提交，该命令将再次失败。
当我尝试实例化链码时我遇到了同样的问题，正如我们在订货人的日志中看到的那样：http://snippi.com/s/324asxa
如何深入了解Fabric的签名机制是如何工作的。
必须能够通过单个签名来满足读者和写作者策略，因为事务格式只允许一个签名。
Admins策略是用于管理通道配置变异的默认策略（例如修改Readers或Writers策略）。通道配置的变异确实通过peer channel signconfigtx支持多签名工作流程。
我们应该能够签署具有多个身份的事务，这可能是策略中配置的要求。
某些事务（如配置更新事务）可能使用多个身份进行签名。其他事务，如链代码调用（包括像peer chaincode instantiate这样的lscc调用）通常只能有一个签名者。
但是我没有使这个工作，也就是说，我有一个需要多个签名的策略，所以我用两个组织的MSP信息连续签署了事务文件（.tx），但是当我提交事务时， orderer或同行会拒绝它，说“签名集不符合政策......”。
如果这是配置更新，那么粘贴更多日志会很有帮助。大多数情况下，如果正确设置了CORE_PEER_LOCALMSPID和CORE_PEER_MSPCONFIGPATH变量，则不满足策略，因为身份不满足所需规则（通常为“admin”）。
如果这是正常的链代码调用（如生命周期操作），则网络配置错误，因为必须能够通过单个提交者签名来满足这些调用。
此命令确实允许您为配置更新收集多个签名。
这个命令不是特别有用，可能有点误导。它添加了签名，以便管理员可以手动验证协议，但在评估任何Fabric策略时不使用这些签名。