添加新组织的频道配置更新 - [政策]/频道/管理员不满意

Question

我正在构建一个网络，我需要节点在应用程序的整个生命周期中加入，作为第一个实现，我想更改通道配置，以便更改有关谁需要签署配置更改的策略。 因此，我正确地遵循了获取最新配置块的过程，我正在对其进行解码，并且能够以 JSON 格式对其进行编辑。

{
  "channel_group": {
    "groups": {
      "Application": {
      },
      "Orderer": {
      }
    },
    "mod_policy": "Admins",
    "policies": {
      "Admins": {
        "mod_policy": "Admins",
        "policy": {
          "type": 3,
          "value": {
            "rule": "ANY",
            "sub_policy": "Admins"
          }
        },
        "version": "0"
      },
      "Readers": {
        "mod_policy": "Admins",
        "policy": {
          "type": 3,
          "value": {
            "rule": "ANY",
            "sub_policy": "Readers"
          }
        },
        "version": "0"
      },
      "Writers": {
        "mod_policy": "Admins",
        "policy": {
          "type": 3,
          "value": {
            "rule": "ANY",
            "sub_policy": "Writers"
          }
        },
        "version": "0"
      }
    },
    "values": {
    },
    "version": "0"
  },
  "sequence": "8"
}

所以我有上述输出，并将管理员策略的规则更改为任何（因为它已更改）。

之后我将其编码回信封并开始签名。

我目前有 4 个组织，由于默认规则是签署大多数管理员，所以我与所有组织一一签署。

如果我仅与一两个组织管理员签约并提交更新，我会收到以下错误：

Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'channel': error authorizing update: error validating DeltaSet: policy for [Policy] /Channel/Admins not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Admins' sub-policies to be satisfied

这非常合理。

在 4 个签名中的 3 个签名后，由于存在多数规则，我在更新和提交中得到以下更改：

Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'channel': error authorizing update: error validating DeltaSet: policy for [Policy] /Channel/Admins not satisfied: implicit policy evaluation failed - 1 sub-policies were satisfied, but this policy requires 2 of the 'Admins' sub-policies to be satisfied

我们可以看到其中 1 个子策略已得到满足，但此时它需要 2 个。 这就是我不明白的地方。第二个子政策是什么？由于我已与每个组织的所有管理员签署，还有谁需要签署此配置通道更新？

谢谢你

Answer 1

经过持续研究，我发现对于这种更新，默认情况下，策略规定大多数对等管理员需要签名，但也需要大多数订购者管理员签名。因此，有 2 个“管理员”子策略！

由于我有一个订购者组织，因此我导出了以下环境变量，并使用与之前相同的命令进行签名。您不应该因使用“peer”命令作为排序者而感到困惑。 Peer 是发送到 orderer 节点的节点，orderer 是创建块并分发它的人。这就像使用另一个用户的peer命令一样。

export ORDERER_GENERAL_TLS_ENABLED=true
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/network/organizations/ordererOrganizations/authorizer/orderers/orderer.authorizer/msp/tlscacerts/tlsca.authorizer-cert.pem
export CORE_PEER_MSPCONFIGPATH=${PWD}/network/organizations/ordererOrganizations/authorizer/users/Admin@authorizer/msp

这是我作为订购者用户导出并使用的签名。 将签名传递到信封后，政策就已履行！