【问题标题】:Hyperledger fabric Endorsement policy in fabric nodesdkFabric nodedk 中的 Hyperledger Fabric 背书策略
【发布时间】:2020-07-31 13:10:26
【问题描述】:

我已经实现了 fabric sdk 来安装和实例化链码。一切正常,但无法弄清楚在结构节点dk 中实施背书的正确方法

这是我在使用命令时使用的背书政策:

peer chaincode ${CHAINCODE_ACTION} -o orderer.google.com:7050 \
    --tls --cafile ${ORDERER_CA} -C $CHANNEL_NAME \
    -n ${CHAINCODE_NAME} -l ${LANG} -v "$CHAINCODE_VERSION" \
    -c '{"Args":[]}' \
    -P "AND (OR('Org1MSP.peer', 'Org1MSP.client','Org1MSP.member','Org1MSP.admin'),
    OR ('Org2MSP.peer', 'Org2MSP.client', 'Org2MSP.member', 'Org2MSP.admin'))"

如果我想在nodedk中实现相同的功能,下面是我从余额转移示例中得到的参考:

const request = {
      targets: [peer],
      chaincodeId: 'cc1',
      chaincodeType: 'java',
      chaincodeVersion: '7.0',
      txId: tx_id,

      // Use this to demonstrate the following policy:
      // The policy can be fulfilled when members from both orgs signed.
      'endorsement-policy': {
        identities: [
          {role: {name: 'member', mspId: 'Org1MSP'}},
          {role: {name: 'member', mspId: 'Org2MSP'}}
        ],
        policy: {'2-of': [{'signed-by': 0}, {'signed-by': 1}]}
      }
    };

我理解 2-of 只是组织之间的 AND 条件。由 0 和 1 签名的是身份的索引。但是我们如何在 Org member、client、admin、peer 中添加 OR 条件呢?

我没有找到任何文档来深入研究这一点。任何帮助将不胜感激。

【问题讨论】:

    标签: node.js hyperledger-fabric blockchain hyperledger-chaincode hyperledger-fabric-sdk-js


    【解决方案1】:

    你对node-sdk中endorsement-policy的理解是绝对正确的。 “signaturePolicy”具有以下对象结构。

    type -- SIGNATURE
    rule
        Type -- n_out_of
        n_out_of
            N -- {int}
            rules -- {array}
                Type -- signed_by
                signed_by -- {int}
        identities -- {array}
            principal_classification -- {int}
            msp_identifier -- {string}
            Role -- MEMBER | ADMIN
    

    您可以阅读更多关于它的信息here。您也可以参考ChaincodeInstantiateUpgradeRequest部分中的示例。

    现在,谈到您提出的问题,我们如何在 Org member、client、admin、peer 中添加OR 条件。查看以下示例,该示例最初来自节点 SDK 文档。

    背书政策:“由 ordererOrg 的管理员和对等组织之一的任何成员签名”

    {
      identities: [
        { role: { name: "member", mspId: "peerOrg1" }},
        { role: { name: "member", mspId: "peerOrg2" }},
        { role: { name: "admin", mspId: "ordererOrg" }}
      ],
      policy: {
        "2-of": [
          { "signed-by": 2},
          { "1-of": [{ "signed-by": 0 }, { "signed-by": 1 }]}
        ]
      }
    }
    

    如您所见,您可以在背书政策中指定的唯一身份是 adminmember。此处的成员可以是管理员以外的任何成员。它可以是对等点、客户端、用户。如果您希望它由管理员签名,则必须在 role 对象中为属性 name 明确指定值为 admin

    对于您的情况,我认为以下结构将是恰当的。

    {
      identities: [
        { role: { name: "member", mspId: "peerOrg1" }},
        { role: { name: "admin", mspId: "peerOrg1" }},
        { role: { name: "member", mspId: "peerOrg2" }},
        { role: { name: "admin", mspId: "peerOrg2" }}
      ],
      policy: {
        "2-of": [
          { "1-of": [{ "signed-by": 0 }, { "signed-by": 1 }]}
          { "1-of": [{ "signed-by": 2 }, { "signed-by": 3 }]}
        ]
      }
    }
    

    遗憾的是,我在 node-sdk 中找不到更多背书策略示例,但我认为上面的示例可以解释其工作原理。

    另外,我认为this 将帮助您更好地了解认可政策中的成员和管理员。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2019-06-30
      • 1970-01-01
      • 1970-01-01
      • 2019-09-17
      • 2020-07-01
      • 1970-01-01
      • 2019-11-27
      • 1970-01-01
      相关资源
      最近更新 更多