Nar*_*sty 1 hyperledger hyperledger-fabric
当前在Hyperledger Fabric 1.0中,有一个中央成员资格服务。我想要一种分散管理的方法,以便图集的50%的成员必须同意新成员加入网络。我该如何实现?
这个想法基本上是将成员资格逻辑放在链式代码中,让成员服务在注册时从链式代码中获取数据。但是,如何实施这一点,我的意思是我们如何知道会员服务实际上是从区块链读取而不是作弊。
这实际上是Hyperledger Fabric的本机支持,并且您描述的行为实际上是通道成员资格更改的默认行为。
每个渠道都以创世块开始生活。该创世块的内容定义了渠道成员,以及来自这些组织的用户被授权在区块链上执行不同功能的策略。例如,可能允许某些用户提交交易,但不能读取整个区块链,而其他用户则可以两者都进行。
要更改渠道成员资格,请提交渠道重新配置事务。该事务指定了新的成员资格,并且必须包括足够的签名以授权此修改。默认情况下,这是大多数组织管理员的签名。
该策略框架实际上是非常强大的,并且只需一点知识,您就可以定义更强大的规则。例如,您可能要求OrgA和3/10其他组织注销才能更改成员身份。或者,您可以要求除一个组织之外的所有组织都同意进行任何成员资格更改,或无限数量的其他排列。
一些链接可能会有所帮助:
http://hyperledger-fabric.readthedocs.io/en/latest/configtxgen.html
http://hyperledger-fabric.readthedocs.io/en/latest/policies.html
http://hyperledger-fabric.readthedocs.io/en/latest/configtx.html
在撰写本文时,缺少一些有关重新配置的文档和工具。您可能会看到的最有用的位置是:
https://github.com/hyperledger/fabric/tree/release/examples/configtxupdate
您必须熟悉两种protobuf结构common.ConfigUpdate,和和common.Config。通过将签名的配置更新提交给订购服务来创建通道,订购服务会生成嵌入到创世块中的相应配置。
将管理通道的成员资格更改的策略指定为组的mod_policy字段,该Application组是该组的子Channel组。此字段默认为Admins,这是指策略定义Admins的内Application组。默认情况下,此策略设置为在该组下定义的组织组MAJORITY的Admins策略中Application。
因此,要在创建频道之前修改此策略,您可以使用该configtxlator工具将configtx解码为JSON ,进行修改,然后configtxlator再次使用该工具对其进行编码。提交此新交易将使用您指定的策略创建渠道。
如果您希望事后修改成员资格,则过程类似。检索当前通道配置,对其进行解码和修改,然后用于configtxlator计算代表您所做更改的配置更新结构。通过收集签名,peer channel signconfigtx然后提交以修改您的频道配置。
目前,此过程显然有点手工操作,但是将来,SDK可以自动执行常见任务,并且工具也应该有所改进。
注意:configtxlator是REST服务,因此可以从SDK应用程序内部方便地访问它,而与语言无关。
作为快速附录。您询问如何确保没有人在“作弊”并且没有真正获得所需的签名。这也内置在系统中。不仅通过订购网络,而且通过系统中的所有对等节点验证对通道配置的所有更改。如果到达的配置无法通过验证,则网络中的所有节点都会发出通知,并会停止使用该通道,直到采取纠正性的管理措施为止。
| 归档时间: |
|
| 查看次数: |
710 次 |
| 最近记录: |