本文主要内容如下,爱看不看~
每条区块链的第一个块(0号块)称为创世块,这个名字可能大概也许应该是来自比特币吧。
系统通道与应用通道
前面说过,Fabric是多链系统,每个Channel对应一条区块链。不难理解,Channel是为了业务隔离而设置的,或者说是为了资源隔离而设置的。
可有一个Channel比较特殊,它是其他Channel的基础,维护着基础网络运行的基本配置信息。
它被称为“系统通道(Orderer system channel)”,而其他的Channel则统称为”应用通道(Application channel)”。
它对应的区块链存在于orderer集群中,而其他的存在于peer集群中。
这次我们要生成一个系统通道对应的区块链的创世块文件。以启动我们的基础网络。
基础配置文件
要生成创世块文件,需要有初始化配置。这个配置比生成证书的可复杂多了,完整的文件请参考《操作指南》。
老规矩,拆开来看看它有哪些配置:
文件名为configtx.yaml,里面包含一个配置块---Profiles,下面包含2个子块,在这一节中要用到的是ForGenesisBlock这一个块中的配置。
又要进入长篇大论模式啦!下面关于配置的论述有碰到不理解的,直接跳过。把完整的内容读完后,再回过头来看很可能就理解了。
Capabilities配置
先说个简单的,Capabilities这个配置表示本节点或这本Channel运行的是哪个版本的程序。当前配置为2.0版本。
由于Fabric的节点分布在各个组织中,不能保证所有组织同时运行版本相同的程序,这个配置声明了当前节点运行的版本号。用于与其他节点协作时声明版本和能力,保证兼容性。
当然,这个配置在使用上还有其他一些限制,这里就不展开讲了。以后再补充吧!
Policies配置
这个配置的含义,说来,就话长了。
那就长话短说,它叫“策略”!
什么是策略和ACL
Policies这个配置在配置文件中的很多层级都会出现,里面定义了一系列的策略。
那啥叫策略呢?
如果你熟悉公有云,它就类似于安全组。
如果你熟悉网络的交换路由,它就类似于ACL(Fabric中也有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_group
作为根节点,它的子节点在groups
下,共3个子节点:Application
、Consortiums
和Orderer
。
再展开Application,又会看到它下面的子节点,同样是在groups下。
Application下有1个子节点:MidMSP
,展开它,groups为空,说明MidMSP已经是叶子节点了(这里的MidMSP
是mid.org组织MSP的名称)。
画成树状图就是这样:
❝「注意:」
图中的灰色节点是我加上去的一个不存在的节点,待会用来说明问题。另外,省略掉了Consortiums这个节点。
❞
注意到,每个节点下都会有policies的配置。以Admins这个策略为例,加入到树图中就是这样的:
说了这么多,这跟满足策略有什么关系呢?别急,再把这些策略的内容加上去。
好了,现在正式开始说策略怎么满足啦!
策略校验规则
首先,看根节点(Channel/Admins
),Type
是ImplicitMeta
,说明本节点策略是否满足,取决于本节点的子节点。
怎么个取决法呢?看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
,OR
和OutOf
。E
表示责任人(英文: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 排版