Fabric基本原理 Consensus Network

一、Fabric架构

二、Fabric网络

三、Fabric模块

四、Fabric交易流

根据Hyperledger Fabric 1.0架构,Fabric交易的整个生命周期可以分为7个阶段。如下图反应了交易的整个生命周期以及交易于账本的交互。

(1)在交易的第一阶段,客户端应用发起智能合约A的一个交易请求给背书节点E0。智能合约A配置的背书策略要求只需要E0,E1和E2签名。其他节点不包含在策略的要求中,因此可以不签名。注意图中的红色和蓝色小矩形块分别代表不同的子链或者叫通道,这个通道是1.0架构引入的新概念,用来实现各条业务链的数据隔离,保护交易的隐私性,避免像比特币那样的交易对所有人都公开。

如图所示,这里说明一下,图中的C代表共识网络(Consensus Network),黄色的圆角矩形表示在peer上部署的智能合约。如E0,E1,E2上部署了A,B两个智能合约,E3上部署了A,D两个智能合约,而E4,E5上部署了Y,Z两个智能合约
(2)背书节点E0使用 MSP(MSP=Member Service Provider)验证签名,判断是否客户端应用被正确授权可以执行发起交易请求。背书节点获取交易请求中的参数(链代码)作为输入参数,然后E0会与交易对应ChainCode所属的docker实例通信,并为其提供模拟执行的State Database的读写集,也就是说ChainCode会执行完智能合约中的业务逻辑,但是并不会在stub.PutState的时候写数据库,ChainCode所属的docker实例执行完ChainCode后产生交易执行结果,然后将执行结构返回给E0。这个执行结果包括下列数据:响应值,读集合和写集合。不过,这个时候,并不会更新账本。这些值的集合,连同背书节点的签名和一个YES/NO 的陈述一起放到 proposal response 中返回给客户端应用(图中的Client App)。

(3)客户端应用验证背书节点签名,然后继续发送背书请求给E1和E2,过程跟与E0的交互时一样。

(4)背书节点E1和E2发送背书处理结果给客户端应用。客户端应用收集完所有背书节点的签名后,检查是否指定的背书策略已经满足。根据 Fabric 的架构设计,即使应用选择不检查交易的背书反馈,或者继续发送一个没有经过背书处理的交易,在commit交易的验证阶段,这个背书策略仍然会被peer 强制执行。
(5)客户端应用将交易和响应信息封装到一个事务消息(transaction message)中,然后广播到共识网络(这里的共识网络又称为排序服务Ordering Service,后续统一称为共识网络)。交易中包含读写集,背书节点签名和通道 ID。共识网络节点不会关注交易细节和交易消息的具体内容,只是简单地从网络中接收来自所有通道的交易,然后按通道按时间顺序排序,处理的结果是一个Batch的交易,也就是一个区块,这个区块的产生有两种情况,一种情况是区块中的交易很多,区块的大小达到了配置文件中配置的大小,而另一种情况是区块中的交易很少,没有达到配置的大小,那么共识网络节点就会等,等到大小足够大或者超时时间。这些设置是在configtx.yaml(/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml)中配置的。# Batch
Timeout: The amount of time to wait before creating a batch.
BatchTimeout: 2s
# Batch Size:
Controls the number of messages batched into a block.
BatchSize:
# Max Message
Count: The maximum number of messages to permit in a
# batch.
MaxMessageCount:
10
# Absolute Max Bytes: The absolute
maximum number of bytes allowed for
# the serialized messages in a batch.
If the "kafka" OrdererType is
# selected, set 'message.max.bytes' and
'replica.fetch.max.bytes'># Kafka brokers to a value that is
larger than this>AbsoluteMaxBytes: 10 MB
# Preferred Max Bytes: The preferred
maximum number of bytes allowed for
# the serialized messages in a batch. A
message larger than the
# preferred max bytes will result in a
batch larger than preferred max
# bytes.
PreferredMaxBytes: 512 KB
# Max
Channels is the maximum number of channels to allow># network.
When set to 0, this implies no maximum number of channels.
MaxChannels:
0
这里主要的配置项是BatchTimeout和MaxMessageCount。BatchTimeout是配置多久产生一个区块,默认是2秒,通常在项目实践中,苹果国际发现交易量并不大,如果配置的时间过小就会产生很多空的区块,配置时间太长,则发现等待产生区块的时间太长。具体时间由交易频率和业务量决定。苹果国际实际项目中,通常配置在30秒。MaxMessageCount是配置在一个区块中允许的交易数的最大值。默认值是10。交易数设置过小,导致区块过多,增加orderer的负担,因为要orderer要不断的打包区块,然后deliver给通道内的所有peer,这样还容易增加网络负载,引起网络拥堵。苹果国际实际项目中通常配置500,不过具体还应该看业务情况,因为如果每个交易包含的数据的size如果太大,那么500个交易可能导致一个区块太大,因此需要根据实际业务需求权衡。
7)Peers收到共识网络发来的区块后,会先进行以下校验:再次验证区块中的交易以确保背书策略满足。
检查区块的数据是否正确。
对每个交易进行验证,确保自从读集合数据在交易执行生成后,读集合变量对应的账本的状态没有变化,也就是验证交易中的读写数据集是否与State Database的数据版本一致。
验证通过后,区块中的交易打上合法和非法交易的标签,然后添加区块到通道对应的链上,同时把所有验证通过的交易的读写集中的写的部分写入状态数据库State Database。对于每个合法交易,写集合被提交到当前的状态数据库。同时,一个区块事件产生并发出,通知客户应用,交易已经不可更改的添加到了链上,也是告诉应用客户端,交易是合法还是非法。另外对于区块链,本身是文件系统,不是数据库,所有也会有把区块中的数据在LevelDB中建立索引。

85%的人还喜欢以下相关话题

相关文章 (标签)

相关文章(同苹果国际

最新文章

020年或开启加密货币征税大潮

近日,韩国、俄罗斯、委内瑞拉等国对于加密货币可能征税的消息频频发布,在数字经济的大趋势下,各国日渐重视起加密货 […]
Doug Harvey Womens Jersey