其他分享
首页 > 其他分享> > Fabric v1.x Orderer的原子广播(全排序)

Fabric v1.x Orderer的原子广播(全排序)

作者:互联网

文章目录

一、执行-排序-验证(Execute-Order-Validate)

Fabric采用的是先执行、后排序、最后验证的共识模型(Execute-Order-Validate),如下图所示:
在这里插入图片描述
首先由client提出交易,发给peer仿真执行,产生读写集并签名后返回给client,client会把签名的读写集(proposal response)打包发送给orderer,orderer会将所有从client接收的proposal response进行排序,并打包成区块,然后将区块发送给peer,最后由peer打开每个区块,并验证读写集的版本号和签名,满足条件便可将数据写入本地账本。peer还会给client发送event说明交易已经被提交到账本中了。以上就是Fabric交易的生命周期。

二、Orderer的全排序

Orderer的作用就是将Fabric网络中的交易进行全排序。Orderer是一个集群,将集群中每个节点接收到的所有交易进行全排序,然后通过一定的规则将交易打包成区块,如下图所示:
在这里插入图片描述
在Fabric中并不是所有人都可以参与排序的,由联盟里的核心企业运行orderer节点,因此只允许某几个组织参与排序工作。

Orderer全排序需要实现 以下需求:

2.1 产生相同的块(Produce identical blocks)

Orderer各个节点需要通过一致性算法产生完全相同的区块,这样各个peer节点接收的区块也将是完全相同,如下图所示,各个orderer产生的区块哈希都是一致的:
在这里插入图片描述

2.2 崩溃容错(Crash Fault Tolerance)

Orderer集群中某个节点停止服务后,剩下的节点依然能够完成排序功能,比如raft算法中只要超过半数的节点正常工作,就能完成正常的排序。
在这里插入图片描述
Orderer节点宕机后,被隔离的orderer节点可能还会继续运行,这时会产生网络分区(Network Partition),被隔离的orderer节点要能嗅探到自己被隔离了,拒绝产生新区块。
在这里插入图片描述

2.3 强一致性(Strong Consistency)

公链中的“Po”系列共识算法只能达成概率上的一致性,而Fabric则需要强一致性,已被提交的交易被回滚是不能被接受的,因此也不存在临时性分叉,每个区块都是确定性的(Finality)。
在这里插入图片描述

2.4 拜占庭容错(Byzantine Fault Tolerance)

拜占庭容错指的是一个节点不仅仅是停止服务,还可以作恶,提交一些恶意交易或拒绝响应别人的请求。Fabric1.4版本的Orderer本身是不支持拜占庭容错(BFT)的,仅支持崩溃容错(CFT),但是Fabric存在背书和验证的机制,整个Fabric是拜占庭容错(BFT)的,即使有一些攻击无法防范,使得无法出块,peer节点提交的交易不会写到账本里,但在Fabric里可以查看别的orderer的log,可以诊断出某个orderer在作恶,最然对网络造成了影响,但不会造成peer的数据丢失或篡改,因为没有peer的背书,交易永远不会被提交到账本中。
在这里插入图片描述

三、区块切割(Block Cutting)

Orderer将交易排序后,每个Orderer节点还需要进行区块切割,只要满足BatchSize和BatchTimeout其中一个条件就将产生区块。

3.1 BatchSize

Orderer中一直在积累交易,当大小总额达到PreferredMaxBytes就可以出块,或者交易个数达到了MaxMessageCount同样可以出块。
但是最后一个交易bytes可能较大,不能保证总大小一定小于PreferredMaxBytes ,这时仍然是可以将交易包含进去出块的。单个交易的大小通过AbsoluteMaxBytes限制,超过该限制的交易会被拒绝掉。

3.2 BatchTimeout

区块可能一直达不到设置的大小,到了设置的“Timeout”时间后,只要有一个交易就会出块。

ice_fire_x 发布了32 篇原创文章 · 获赞 3 · 访问量 6026 私信 关注

标签:区块,Fabric,v1,Orderer,peer,排序,节点
来源: https://blog.csdn.net/ice_fire_x/article/details/104428471