在检查过程中，交易的手动签名是不可视的(fabric 1.4）

Question

但是我没能做到这一点，也就是说，我有一个需要多个签名的策略，所以我用这两个组织的MSP信息先后在事务文件（.tx）上签名，但是当我提交事务时，订单者或同行会拒绝它，说“签名集不满足策略...”。

奇怪的是，这个检查忽略了我所做的其他签名，它只会认为签名是由提交事务的命令自动完成的：peer channel update或peer chaincode实例化，就好像最后一个签名使我之前手动应用的签名无效一样。

关于我错过了什么的想法？

null

我修改以生成不同签名的变量：

• CORE_PEER_LOCALMSPID
• CORE_PEER_MSPConfigPath

--编辑

null

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

peer channel create --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file channel-artifacts/channel.tx

当我试图提交锚节点创建事务时，问题就开始了：

peer channel update --channelID $CHANNEL_ID --orderer orderer.example.com:7050 --tls --cafile $ORDERER_CA --file  channel-artifacts/Org1MSPanchors.tx

我收到错误消息：

错误：得到意外状态：禁止--未能达到1个子策略的隐式阈值，需要1个剩余：权限被拒绝

null

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/[e-mail]/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行）。

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

Answer 1

读取器和写入器策略必须能够由单个签名来满足，因为事务格式只允许一个签名。

Admins策略是用于管理通道配置变化（例如修改读取器或写入器策略）的默认策略。通道配置的变异确实通过对等通道signconfigtx支持多重签名工作流。

我们应该能够用多个身份对事务进行签名，这可以是策略中配置的要求。

https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchannel.html#peer-channel-signconfigtX

此命令确实允许您为配置更新收集多个签名。

https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchaincode.html#peer-chaincode-signpackage