(内容可能有些乱,请见谅,日后会对格式进行整理!)

#### 在1.0及以后的版本中,客户端应用会先向Fabric CA申请用户所需要的Fabric中的准入证书,用于签名提案以及交易,然后由客户端(Application)端生成一个提案(Proposal)(一般应用程序会借助于目前Fabric提供的一系列SDK生成Proposal)发送至背书节点进行模拟执行并进行背书,背书节点Endorser会进行相应的校验,然后将提案交由对应的链码Chaincode进行模拟执行,之后背书节点Endorser会对执行结果进行背书,将背书的Response返回至客户端程序Application,随之,客户端程收集到符合背书策略的提案响应(Proposal Response)之后,将其封装成一个交易Transaction,调用排序节点Orderer的Broadcast接口,进行发送交易至Orderer,在v1.0-v1.4版本中,生产环境只有基于分布式消息队列Kafka的排序打包方式,Orderer作为生产者将交易统一发送至每个通道Channel对应的Topic的Partition当中进行全局统一地排序,同时每个排序节点基于同样的切块规则从Kafka中将区块切下推送Deliver至与之连接的Leader Peer(在网络环境良好的情况下,每个组织只有一个leader),Leader Peer收到区块后,会将区块通过Gossip协议广播至组织内其余节点。每个Committer在收到区块之后会对区块进行校验,包括签名、背书策略以及读写集的校验,在校验无误的情况下进行commit,提交到账本,同时更新世界状态,同时订阅了相应事件的应用程序会收到来自Event Hub的消息通知。

Orderer对来自不同通道的交易做区分,同时在Peer节点中会采用MSP对不同通道的消息做校验,用于判断消息是否属于某个通道,通过Orderer以及Peer相结合,形成一个逻辑上的通道技术。


执行—排序—验证

一、执行阶段:

客户端发送的交易提案是调用链码功能的请求。背书节点对交易提案进行4点验证:

如果以上验证都通过,背书节点就将提案输入作为所调用链码函数的参数,对当前状态数据库执行chaincode并返回经过背书节点签名的执行结果(读写集)给客户端!然后客户端收集背书,直到满足背书策略。

二、排序阶段:

当收集到足够数量的背书后,客户端将提案、执行结果和背书组装成交易,发送给排序服务。排序服务按通道、按时间顺序对接收的交易进行排序,并为每个通道创建区块(注意:排序服务接收到交易的顺序并不一定是交易被打包进入区块的顺序。。。)。然后将区块发送到每个通道上的主节点(leader),由背书节点向其所在通道内的peers分发交易。

三、验证阶段:

当每个peer接收到新区块后,会对其中包含的交易进行验证,以确保满足背书策略,以及确保账本当前状态的"读集"变量没有变化(因为"读集"是由当前区块中的交易执行生成的)。然后每个peer将区块追加到本地的区块链副本上,并将"写集"提交到当前状态数据库!

05-15 14:07