Fabric交易流程

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

#### 在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点验证：

1. 格式是否正确；

2. 在之前没有被提交过；

3. (客户端的)签名是否有效；

4. 提交者/客户端是否被授权执行此次提案的操作。

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

二、排序阶段：

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

三、验证阶段：

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