Hyperledger Fabric的Transaction处理
Hyperledger Fabric的Transaction处理流程
在介绍Transaction处理流程之前，我们先来了解区块链网络的最重要的组成部分->peer节点。通过分析peer节点与其他组件之间的关系来逐步了解Fabric中transaction的处理流程。
我们通过一下几个方面来进行了解：
- fabric的网络结构
- Peer节点和账本和链码的关系
- applications和peers的关系
- peers和channels的关系
- peers和organizations的关系
- peers和identity的关系
- peers和orderers的关系
Fabric的网络结构
区块链网络由账本（ledger）、智能合约（smart contracts）、背书节点（orderers）、通道（channels）、应用（applications）、组织（organizations）、成员关系服务提供商（MSP）等部分组成。
trans.png
- 信息描述：client端的application通过sdk向被选成背书节的peer发送交易提案。peer节点调用链码模拟执行交易。生成读写集，返回给client端。client端接收返回结果，生成交易发送给排序节点进行排序。排序节点对交易进行排序，在达到配置阈值要求时生成区块。并广播到所有peer节点（实际过程是先发送给所有主节点，主节点在发送到各自对应的所有peer节点）。peer节点对交易进行验证，验证通过更新世界状态，将区块追加到区块链中。
Peer节点和账本和链码的关系
peer节点是区块链网络的基础组成部分，peer存储了区块链账本数据，智能合约也是在peer节点上运行的。下图展示了peer节点、账本和链码这三者之间的关系。
peers.png
- 信息描述：区块链网络包含三个peer节点，分别是P1,P2,P3。三个peer节点都维护了一份相同的账本数据L1，都运行了同一个链码S1.
当peer节点刚创建时，是不包含账本和链码的。当它加入到区块链网络中，安装完链码之后，才会同步账本数据。
多账本（Multiple Ledgers）
一个peer节点可以维护多套账本，如下图：
muledgers.png
- 信息描述：peer节点P1同时维护了两套账本L1和L2，其中L1账本由链码S1维护，L2账本由链码S1和链码S2同时维护。
多链码（Multiple Chaincodes）
一个peer节点同时也可以维护多套链码，如下图：
muchaincodes.png
- 信息描述：Peer节点P1同时维护两套账本L1和L2。其中L1账本由链码S1和S2维护，账本L2由链码S1和链码S3维护。其中链码S1可以同时维护账本L1和账本L2。
结论：一个链码可以适用于多个账本，而一个账本也可以同时由多个链码来维护。
applications和peers的关系
在上面网络结构中，描述了交易执行的流程，客户端发起交易提案，经过背书后，生成交易发送给排序节点排序，并生成区块，最后提交给提交节点进行校验并提交。
appp.png
注意事项：
其中链码的执行是由application通过sdk调用，通过peer节点执行的。
交易通过排序节点提交到peer节点后，如果通过校验会直接将读写集的写集作为结果更新世界状态，并不会再重新执行一次链码处理流程。</br>
校验失败的交易会被标记成无效，区块依旧会追加到区块链中，但是不会更新世界状态。
查询交易不会执行上述图片中的4、5步。在提案结果返回后结束。
peers和channels的关系
上面已经描述了application、peer、账本、链码之间的关系。但是它们之间的交互并不是没有限制的。链与链之间通过通道来隔离。只有加入到同一个通道的组件之间才能进行交互。如下图：
channel.png
- 信息描述：区块链网络N包含通道C，包含两个peer节点P1和P2，P1和P2都安装了同一套链码S1，维护同一套账本L1.网络外的应用程序A，通过加入到通道中，与网络进行通信，发起交易。
channel并不是一个实体，它只是一个逻辑概念。
peers和organizations的关系
peer节点是区块链网络的最基础的组成部分。但是区块链网络并不是按peer为单位进行管理的，而是按组织。如下图：
org.png
- 信息描述：区块链网络N包含了8个peer节点，和一个通道C。其中P1、P2节点属于组织1，P3、P4、P5属于组织2，P6、P7属于组织3，P8属于组织4.组织1中的peer节点P1、组织2中的peer节点P3 P4、组织3中的peer节点P7、组织4中的peer节点P8都加入到了同一个通道C中。同时应用程序A1、A2、A3、A4，分别加入了对应的组织。
注意事项：一个组织中的peer节点可以加入到不同的通道中。一个peer节点属于一个组织。应用程序可以链接到所加入的组织中的其中一个节点。
peers和identity的关系
关于加入到链中的peer的身份管理，如下图：
identity.png
当一个peer加入到一个通道，它所属的组织会通过MSP给这个peer分配一个数字证书。在上面这个图例中，P1、P2通过CA1分配证书，P3、P4通过CA2分配证书。通道C通过配置的通道配置策略CP来确认peer节点和组织的关系。
一个peer只能属于一个组织，所以一个peer也只是对应一个MSP，一个MSP可以给多个peer分配证书。
peers和orderers的关系
排序节点负责对交易进行排序，并负责生成区块。一个交易执行的主要过程大致分成三部分，第一部分：发起提案，由背书节点对提案进行背书签名。第二部分：发起交易，由排序节点进行排序，并声称区块。第三部分：分发到所有peer节点进行校验，然后更新账本。排序节点处于交易的核心位置。
接下来我们分别看这三部分的处理流程：
提案处理
proposal.png
- 信息描述：区块链网络N，包含通道C、排序节点O1、peer节点P1、P2，都安装了链码S1，维护同一套账本L1，由applicationA1，发起交易请求。A1发起交易提案，由P1、P2背书后，将结果返回至A1。其中P1、P2属于不同的组织。
问题：一笔交易应该由哪些背书节点进行背书？
答：这个是由背书策略决定的，背书策略定义了需要经过一组组织确认，交易才会被认可。背书策略可以手工指定。
问题：背书的过程是怎么样的？
答：背书节点模拟执行链码生成结果之后，背书节点通过自身的私钥对返回结果进行加密。这也是背书策略验证是否收集到足够背书的一个证明。
打包生成区块
背书节点接收很多application的交易，并对这写交易进行排序，根据配置文件配置的区块生成配置来生成区块。
packing.png
- 信息描述：区块链网络N，包含通道C、排序节点O1、peer节点P1、P2。这个网络中有多个application发起了交易，order接收这些交易。对收集到的交易进行排序，并生成区块B2。排序结果与排序节点接收到交易的先后次序没有关系。
在配置文件fabric/examples/e2e_cli/configtx.yaml中有两个配置，定义了区块的生成策略。
BatchTimeout：从区块的第一笔交易开始，创建一个计时器，当超过这个超时时间，还没有足够的交易，那么会将所有未打包的交易进行打包生成区块。
BatchSize：这个配置又主要包含三个部分。如下：MaxMessageCount：区块包含的最大交易数量。
AbsoluteMaxBytes：区块最大的大小。（不包括交易头部）
PreferredMaxBytes：每个区块建议的大小。Kafka对于相对小的消息提供更高的吞吐量；区块大小最好不要超过1MB。
打包生成的区块是一定会被加入到区块链中的，如果是无效交易，会被标示成无效，但是交易依旧是存在于区块中。区块中的交易是不能修改的。
校验区块并更新账本
validation.png
- 信息描述：区块链网络N包含通道C、排序节点O1、peer节点P1、P2，排序节点O1将排序后生成的区块B2，分发给P1、P2。P1、P2在对区块中的交易进行过校验之后，将区块追加到链码L1中。这个过程中是不需要执行链码的。
