Hyperledger Fabric的交易旅程

基于Fabric的交易其实和现实中的交易一样。

举个例子，小明借给小红50块钱，在现实中就是小明个人账户里少了50块钱，小红多了五十块钱。但是俗话说，亲兄弟还明算帐，这种现实中的交易或是缺少交易记录，或是交易记录丢失，甚至是对保存交易记录的人可能篡改记录。这个帐就存在着“算不明”的情况。

还有一种情况是小明夸下海口，要借给小红50块钱。小红很开心地和小明签了交易协议，但是实际上，小明根本没有50块钱。这时候这个协议应该是无效的。

区块链的出现，就可以有效地解决以上问题。如下图所示，小明和小红在交易的时候，只要在客户端表明，我们要进行一笔怎样怎样的交易。这笔交易就会作为一个提案发送出去，在验证这是个有效的交易，再改变两个人名下的资产状况（写入状态数据库）。

Fabric的交易形式有solo模式和kafka模式（多节点的）两种。接下来，我们就来分析一下，一个完整的solo模式的交易过程。

从上面这张时序图可以看出来：交易的前期其实是在客户端、排序节点、背书节点之间来回传递信息的。背书节点本身是peer节点，在背书策略时被指定为背书节点的。

客户端首先在本地做一些准备：它接收小明和小红的请求，利用支持SDK（node,java,python）的应用程序创建对应的交易提案，对交易双方的身份作验证等。把交易提案打包为适合的格式，向背书节点提交交易提案。背书节点在收到消息之后，会模拟执行提案（将提案内容作为智能合约中invoked函数的参数传入，产生响应值、读集和写集的交易结果），根据模拟的结果进行背书，把它传回给客户端。

客户端和背书节点的互动可以对照成现实中的工程建设，如果想要申请建造某栋大楼，需要自己准备好一些材料，然后提交给有关部门审核。背书节点的背书过程就像有关部门的审核一样，它根据上交的材料，对提案进行模拟判断，确定资格，对提案进行背书。这个过程在整个交易中非常重要，如果审核没有通过（背书回应为NO），则不能完成申请（交易无法完成）。

根据在本地机器上的实测，从背书节点（在本地中为peer01节点）的日志中我们发现，背书节点的过程在交易过程中时间占比大约为38%左右。也就是说，背书过程的优化会明显提高交易的效率。

申请人在收到回复时候，会先检查一下有关部门的回复，在得到足够的有关部门的认证之后，申请人就可以拿着认证的材料去找建筑公司施工了。同样的，客户端在收集到足够的背书签名之后，就会发送给排序节点。

从排序节点的日志中，我们可以得知。在接收到客户端发送的背书模拟结果后，排序节点会进行验证，验证成功后会广播入队成功的消息。这时，客户端的提案才开始被执行。执行完成之后，排序节点会关闭广播。从客户端来看，一次交易到此结束了。

回到我们之前用的建筑工程的例子。也就是建筑公司在检查过申请人提供的签名等证明之后，开始和他确认具体方案。确定完成之后，从申请人的角度来看，接下来已经没有申请人参与的部分了。

但是从建筑公司的角度来看。他自己的工程才刚刚开始。和申请人交流的这个建筑公司只是负责交接，它并不会读取详细内容。他把好多申请人的任务都聚集在一起，按照时间先后顺序排一下序。然后把他们一起分发给自己手下的施工队伍去完成。开始真正的施工（更新状态数据库）。

如下图所示，排序节点（order）并不会在一个交易结束之后马上创建块。而是等到能写满一个块的几个交易或者达到默认的时间，才会开始创块，把未打包的交易排序之后，连同签名等信息一起生成区块，发送给peer节点。值得一提的是，此时背书节点已经恢复成普通的peer节点了，承担记账任务。

就像工程分发给施工队伍是告诉包工头而不是告诉每个工人一样。排序节点分发给peer节点时，也是分发给主节点（通过选举产生），由主节点来负责把接收到批量区块广播给其他节点。上图可以看出。在本次实验中，peer01和peer12承担着主节点的角色。他们比peer02和peer12更早收到排序节点发来的区块。

每个peer节点在承担记账任务时过程都很相似。首先要验证排序节点广播的块（VSCC检查背书策略，MVCC检查验证是否通过）。如果验证成功，那么将在本地账本中写入一个新的块，并把块中的有效交易的内容更新到状态数据库中，产生区块生成事件。

以上，就是一个从交易发起到写入区块的完整的内容。