【问题标题】:Hyperledger fabric endorsement policy超级账本结构背书政策
【发布时间】:2020-04-24 09:31:34
【问题描述】:

我想知道在以下场景 w.r.t HLFabric 中实施的可能性。

(A) 在 Org1 下有 peer0 和 peer1,在 Org2 下有 peer 0,在 Org3 下有 Peer0。

(B) 背书策略为 1-of(Org1 的 peer1,Org2 的 peer0,Org3 的 peer0)。

当我们尝试上述场景时,它在所有背书节点都启动并运行的情况下工作正常。但是,当我故意让 Org1 的 peer1 或 Org2 的 peer0 或 Org3 的 peer0 之一关闭时,只是为了模拟即使背书节点之一出现故障,区块链网络也能正常工作。但我观察到的是,如果所有对等点都未处于运行状态,则 putState 事务将失败。

请注意,我希望在来自不同地理区域或由不同网络管理的不同 Hyperledger Fabric 组织中运行单个对等点。在这种情况下,我想知道是否有任何背书节点出现故障,如何使区块链网络正常运行。

上面的场景可以实现吗?

【问题讨论】:

  • 您如何制定该政策?政策是针对组织和角色的,而不是针对特定的同行......
  • 如果我没有记错,请验证这是否是您的背书政策:"OR('Org1MSP.peer', 'Org2MSP.peer', 'Org3MSP.peer')"。另外,请注意,正如 @kekomal 所建议的,您不能将政策推荐给组织内的特定同行。
  • 我们在使用 sendInstantiateProposal 方法实例化链码时使用以下代码。 var req = {targets:'peer0.example.org', chaincodeId : 'clog' chaincodeVersion : 'v1' chaincodeType.. : 'node', args: , txId:tx_id, 'endorsement-policy':{identities:[{角色:{name:'member',mspId:'Org1MSP'}},{role:{name:'member',mspId:'Org2MSP'}},{role:{name:'member',mspId:'Org3MSP' }}],策略:{'1-of':[{'signed-by':0},{'signed-by':1,{'signed-by':2}}]}}}

标签: hyperledger-fabric


【解决方案1】:

这样理解。有些组织互不信任,但想做生意。

Org1、Org2 和 Org3。该协议是,只有在三个组织都同意的情况下,才能进行业务交易。这意味着他们所有人都必须参与背书政策,而他们这样做的方式是通过对等方。现在,这意味着每个组织都应该有一个同行 UP,以便每个组织成为认可的一部分。

在每个组织有多个对等点的情况下,另一个对等点仅用于“备份”,这是我的理解(对此我不确定)。在您的情况下,Org1 有两个对等点,其余两个各有一个对等点。如果你将 Org2 和 Org3 中的任何一个 Peer 拉下来,那么它们就无法参与背书过程,并且原来的“三个 org 互不信任,仍然想做生意”的问题陈述就丢失了。这就是 HLF 未能“putState”的原因。

每个组织至少有一个对等点,并且一切正常。

如果您的背书策略像其他人指出的那样具有“OR('Org1MSP.peer', 'Org2MSP.peer', 'Org3MSP.peer')”,这意味着只要任何一个组织拥有对等。这意味着原来的“三个组织互不信任,但仍然想做生意”的问题陈述正在变为“三个组织互相信任,只要有一个认可就可以做生意”。您需要了解这是否适合您的业务案例。

我自己没有对此进行测试,但我只是表达了我的理解。

希望这会有所帮助。

【讨论】:

  • 我们使用的是 HLF 1.4 版本。我的目的是测试何时将签名策略定义为 '1-of':[ { 'signed-by':0 }, { 'signed-by':1 }, { 'signed-by':2 } ]
【解决方案2】:

根据您的要求,将链码实例化为小修正的请求对象。正确的对象应如下所示:

{
    targets:'peer0.example.org', 
    chaincodeId : 'clog',
    chaincodeVersion : 'v1',
    chaincodeType.. : 'node', 
    args: , 
    txId:tx_id, 
    'endorsement-policy':
        {
        identities:
            [{
                role:
                {
                    name:'member',
                    mspId:'Org1MSP'
                }
             },
             {
                role:
                {
                    name:'member',
                    mspId:'Org2MSP'
                }
             },
             {
                role:
                {
                    name:'member',
                    mspId:'Org3MSP'
                }
             }
            ], 
            policy:{
                '1-of':[
                    {
                        'signed-by':0
                    },
                    {
                        'signed-by':1
                    },
                    {
                        'signed-by':2
                    }
                ]
            }
        }
}

如果您仔细观察,错误出现在策略部分,因为您将 'signed-by':2 放置在 'signed-by':1 的另一个块中。

另外,请注意,我们无法将政策限制为指向组织的特定同行。在这里,如果您想要更严格的策略,您可以将“角色”类型更改为peer,而不是使用member

除此之外,如果您的发现服务未运行,请确保您将交易提案发送给网络中的每个对等方,以接收有效数量的背书。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-02-16
    • 2021-09-27
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多