Question

使用Fabric和Java SDK。

我要求两个组织在将其添加到分类帐之前对其进行认可。

没有设施可以将多个客户端（org.peers）与Channel相关联 - 它来自client.newChannel并且具有对{1}}中的单个HFClient实例的瞬态引用构造函数。

单个组织代言要求我构建一个TransactionProposalRequest并将其放入我已创建的频道。

然后解析返回的ProposalResponse集合（每个对等体中的一个），如果可以发送给订购者。

我对如何将更多组织加入频道感到茫然。

我是否需要实例化更多HFClient并拥有Channel的多个副本，每个组织一个副本，然后逐个调用不同的频道/客户端组合并聚合响应。

这（imo）意味着您需要知道所有您的链代码的代言人，并一次调用一个代码。对于由多个组织管理的财团来说，这肯定是不正确的？

我错过了什么，有一种更清洁的方法吗？

文档中的Tx流似乎意味着您连接到单个客户端，并且事务将传播到所有对等方以获得该客户端的认可。

Answer 1

我自己完成这个并不完全清楚。

在实例化链码时设置认可政策（在1个频道上）。 CLI示例：-P“OR（'Org1MSP.member'，'Org2MSP.member'）”
（两个组织的同伴必须加入频道并安装cc）。
因此，cc知道需要哪些同行支持交易。我认为这应该主要由客户处理。（我正在使用Node SDK，但它们大致相同）
但您仍然需要来自其他组织的端点和ca证书。我在某些IBM文档中找到了这个地方。

'例如，如果您想要定位网络中的其他对等方，则需要来自不属于您的组织的对等方的认可，那么您需要获取这些对等方的正确API端点信息。您还需要为其他组织存储CA证书，以验证返回到您的应用程序的响应。此信息未在您的服务凭据中公开，因此您必须联系Bluemix Org的相应管理员，并在带外操作中获取此信息。订购服务URL在整个网络中是通用的;您不需要任何特定于会员的信息来订购服务。'

在Node中，我们使用网络配置JSON，其条目类似于（不完美）......

"channels": {
"peers": {
            "org1peer": {
                "endorsingPeer": true,
                "chaincodeQuery": true,
                "ledgerQuery": true,
                "eventSource": true
},

            "org2peer": {
                "endorsingPeer": true,
                "chaincodeQuery": true,
                "ledgerQuery": true,
                "eventSource": true
            }
        }

和

"peers": {
    "org1peer": {
        "url": "grpc://org1peer.org1.com:7051",
        "eventUrl": "grpc://org1peer.org1.com:7053"
    },

    "org2peer": {
        "url": "grpc://org2peer.org2.com:7051",
        "eventUrl": "grpc://org2peer.org2.com:7053"
    }

和

"organizations": {
    "Org1MSP": {
        "mspid": "Org1MSP",
        "peers": [
            "org1peer"
        ],
        "certificateAuthorities": [
            "fabric-ca1"
        ],
        "adminPrivateKey": {
            "path": "./crypto/org1/bpn/admin/msp/keystore/a4941a637013e_sk"
        },
        "signedCert": {
            "path": "./crypto/org1/bpn/org1peer/msp/signcerts/cert.pem"
        }
    },

    "Org2MSP": {
        "mspid": "Org2MSP",
        "peers": [
            "org2peer"
        ],
        "certificateAuthorities": [
            "fabric-ca2"
        ],
        "adminPrivateKey": {
            "path": "./crypto/org2/bpn/admin/msp/keystore/04c5a4992d5_sk"
        },
        "signedCert": {
            "path": "./crypto/org2/bpn/org2peer/msp/signcerts/cert.pem"
        }
    }
},

希望这对你有所帮助，我期待更好的答案。

Answer 2

嗯，它比起初看起来更糟糕。

如果您为组织创建另一个客户端并使用该组织的对等方实例化另一个通道副本，那么可能 - 但似乎是一个非常复杂的过程 - 获得来自另一个对等方（集合）的认可。你需要证书，但在我的情况下，我拥有所有的组织，所以这不是问题。

因此，您有来自多个客户（orgs）的一组响应。它们都没关系，您认为将它们提交给订货人就足够了，不是吗？

那不行。

Orderer. Cause: UNSUCCESSFUL. FORBIDDEN-403, Additional information: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied

看起来您无法向orderer提交由与您的客户设计代表的组织签署的不同组织的交易。

这让我坦白地说。提交给订购者（或者我喜欢它的提交 - 提交）并不是可以分散到多个客户端的东西。它似乎是一个原子操作。

我开始怀疑是否有人真的这样做过......

来自hyperledger-fabric java sdk客户端

2 个答案: