Hyperledger Fabric原理详解与实战6

1,808 阅读7分钟

本文主要内容如下,爱看不看~

每条区块链的第一个块(0号块)称为创世块,这个名字可能大概也许应该是来自比特币吧。

系统通道与应用通道

前面说过,Fabric是多链系统,每个Channel对应一条区块链。不难理解,Channel是为了业务隔离而设置的,或者说是为了资源隔离而设置的。

可有一个Channel比较特殊,它是其他Channel的基础,维护着基础网络运行的基本配置信息。

它被称为“系统通道(Orderer system channel)”,而其他的Channel则统称为”应用通道(Application channel)”。

它对应的区块链存在于orderer集群中,而其他的存在于peer集群中。

这次我们要生成一个系统通道对应的区块链的创世块文件。以启动我们的基础网络。

基础配置文件

要生成创世块文件,需要有初始化配置。这个配置比生成证书的可复杂多了,完整的文件请参考《操作指南》。

老规矩,拆开来看看它有哪些配置:

configtx.yaml
configtx.yaml

文件名为configtx.yaml,里面包含一个配置块---Profiles,下面包含2个子块,在这一节中要用到的是ForGenesisBlock这一个块中的配置。

又要进入长篇大论模式啦!下面关于配置的论述有碰到不理解的,直接跳过。把完整的内容读完后,再回过头来看很可能就理解了。

Capabilities配置

Capabilities
Capabilities

先说个简单的,Capabilities这个配置表示本节点或这本Channel运行的是哪个版本的程序。当前配置为2.0版本。

由于Fabric的节点分布在各个组织中,不能保证所有组织同时运行版本相同的程序,这个配置声明了当前节点运行的版本号。用于与其他节点协作时声明版本和能力,保证兼容性。

当然,这个配置在使用上还有其他一些限制,这里就不展开讲了。以后再补充吧!

Policies配置

这个配置的含义,说来,就话长了。

那就长话短说,它叫“策略”!

什么是策略和ACL

Policies这个配置在配置文件中的很多层级都会出现,里面定义了一系列的策略。

policies
policies

那啥叫策略呢?

如果你熟悉公有云,它就类似于安全组。

如果你熟悉网络的交换路由,它就类似于ACL(Fabric中也有ACL,下面会讲到)。

如果你都不熟悉,那就给你打个比方吧。

策略与ACL
策略与ACL

如上图,这是你家的房子。每个房间的门都是智能门锁,可以由你制定开锁规则。

于是,你制订了图上策略中描述的规则。

那哪扇门谁可以开,谁不能开呢?

图中的ACL就规定了每一扇门可以被打开的方法。

注意到,想进金库的门,必须有你本人和你老婆同时按指纹进入。你想偷点宝贝到外边换酒钱,没门!

明白了吗?策略是规则本身,只有指定规则用在哪个资源上它才有意义。

使用策略会得到两种结果:满足规则和不满足规则。至于得到结果后怎么处理是由业务逻辑决定的。

回到Fabric的策略上来。拿这一条策略来说:

#Profiles.ForGenesisBlock.Policies
Readers:             # 策略名称
  Type: ImplicitMeta # 类型
  Rule: ANY Readers  # 规则
  • 策略名称可以自定义,但Readers、Writers和Admins这几个默认的要保留。

  • 类型分为两种:ImplicitMeta,Signature。

    来看一个Signature类型的:

#Profiles.ForGenesisBlock.Consortiums.BondNetConsortium.Organizations.Policies
Readers:
    Type: Signature
    Rule: OR('McorpMSP.admin', 'McorpMSP.peer', 'McorpMSP.client')

类型和规则共同决定了这条策略如何才能被满足。

如何满足策略

让我们先了解一下Channel的层次结构。

Channel的层次结构

在配置文件中,Profiles下的两个子块其实是描述的两个Channel的配置。ForGenesisBlock是系统通道的配置,而ForCreateChannel是业务通道的配置。

Channel的配置是有其层次结构的,如下图:

Channel配置的层次结构1
Channel配置的层次结构1

这是从系统通道的创世块中转换出来的内容。

channel_group作为根节点,它的子节点在groups下,共3个子节点:ApplicationConsortiumsOrderer

再展开Application,又会看到它下面的子节点,同样是在groups下。

Channel配置的层次结构2
Channel配置的层次结构2

Application下有1个子节点:MidMSP,展开它,groups为空,说明MidMSP已经是叶子节点了(这里的MidMSP是mid.org组织MSP的名称)。

画成树状图就是这样:

Channel配置树状图
Channel配置树状图

注意:

图中的灰色节点是我加上去的一个不存在的节点,待会用来说明问题。另外,省略掉了Consortiums这个节点。

注意到,每个节点下都会有policies的配置。以Admins这个策略为例,加入到树图中就是这样的:

说了这么多,这跟满足策略有什么关系呢?别急,再把这些策略的内容加上去。

好了,现在正式开始说策略怎么满足啦!

策略校验规则

首先,看根节点(Channel/Admins),TypeImplicitMeta,说明本节点策略是否满足,取决于本节点的子节点。

怎么个取决法呢?看Rule: MAJORITY Admins,它的意思是说,需要大部分子节点的Admins策略被满足。

那大部分是多少呢?>50%,也就是说,如果有3个子节点,那至少需要2个子节点被满足,如果有2个子节点,那2个节点都要被满足。

接着看第二层的节点,含义和根节点一样。

再来看中间灰色的叶子节点,Type: Signature说明要满足本节点策略,需要有人签名。

谁签名呢?看Rule: OR('otherMSP.admin', 'otherMSP.peer', 'otherMSP.client'),它的意思是说,只需要otherMSP中的admin或者peer或者client中的任意一个角色的任意一个签名就可以了。

明白了吗?策略是否被满足,责任最终落到了组织中的具体的成员(包括用户和节点)身上。如果同意就加上自己的签名,只要签名角色和数量满足条件就能通过。

当然,为了制订更加灵活的策略,还有其他几个可选项:

  • ImplicitMetaPolicy类型Rule的格式为:
    <ANY|ALL|MAJORITY> <SubPolicyName>
    如:Rule: ANY Readers表示任意子节点中的Reader策略。

  • Signature类型Rule的格式为:EXPR(E[, E...]),解释如下:
    EXPR有三个选项:AND, OROutOfE表示责任人(英文:principal),比如:

    • 'Org0.admin': Org0组织中的任何管理员
    • 'Org1.member': Org1组织中的任何用户
    • 'Org1.client': Org1组织中的任何客户端
    • 'Org1.peer': Org1组织中的任何peer

举几个完整的例子:

  • AND('Org1.member', 'Org2.member', 'Org3.member'):需要Org1,Org2和Org3每个组织中的任意一个用户同时提供签名。

  • OR('Org1.member', 'Org2.member'):Org1或Org2中的任意一个用户提供签名即可。

  • OR('Org1.member', AND('Org2.member', 'Org3.member')):Org1和Org3每个组织中任意用户同时提供签名,或者,Org1组织中任意一个用户提供签名。

  • OutOf(1, 'Org1.member', 'Org2.member'):n out of m是n/m的意思。这条等价于 OR('Org1.member', 'Org2.member')

  • OutOf(2, 'Org1.member', 'Org2.member'):等价于AND('Org1.member', 'Org2.member')

  • OutOf(2, 'Org1.member', 'Org2.member', 'Org3.member'):这条等价于OR(AND('Org1.member', 'Org2.member'), AND('Org1.member', 'Org3.member'), AND('Org2.member', 'Org3.member'))

好了,今天内容够你们消化一阵子了。如果迷糊了,没关系,看完后面的内容再回头来理解。

我是2流程序员,我们下次再贱!

本文使用 mdnice 排版