简述Hyperledger Fabric的工作流程

说起来也是很巧合的一件事情，去年暑假自己一个人在宿舍学习Hyperledger Fabric的相关东西，后来因为各种原因就放弃这个方向开始跟着老师做一些CV方面的工作，现在竟然又开始看区块链的相关东西。
去年开始学习区块链的时候很多东西还没有掌握，比如PKI、密码学，计算机网络当时也学得迷迷糊糊的，因此当时废了很大力气，记得关于PKI证书那块自己就折腾了好久才算明白。当时还写了十来篇博客记录所学的东西，现在也很久没有回头看了，不知道其中存在多少错误。
大三这一年又学习了PKI和密码学这些课程，感慨当时或许不应该进入这个领域，自己走了很多弯路。转念一想其实也不是坏事，摸索中自己也学到了许多东西，算是有得有失吧。
前几天导师给了几篇论文让看，其中一篇是《Blurring the Lines between Blockchains and Database Systems: the Case of Hyperledger Fabric》，昨天看完之后豁然开朗，尤其是论文中Hyperledger Fabric的工作流程这部分。当然中间的部分也很精彩易读，算法部分都给了详细的例子讲解，并没有感到什么困难很快就读完了。由此想起来前几天在看的SBFT，那篇真是读不动=_=||

架构

Fabric是一个permissioned blockchain system，也就是整个区块链网络的每一个peer都可以及时知道其他peer的存在。多个peer可以组成organization，在organization内，peers之间互相信任，每一个peer都维护一份ledger的副本，ledger包含有效和无效的transaction，除此之外peer还以状态数据库的形式维护一个当前状态。除了peer外，还有一个重要的角色是ordering service，用来给transaction排序。

工作流程

Fabric基本的流程包括四个阶段，分别是模拟（simulate）、排序（order）、验证（validata）、提交（commit），如下图所示：

模拟

如其名字所说的一样，这一阶段只是模拟进行交易，并不真正更新ledger。

client发起交易请求，请求被发送至endorsers（endorsement peer，这些peer是根据endorsement policy选出来的），endorsers根据当前本地的ledger状态并行模拟进行这些交易，虽然不改变ledger状态，但是会产生一个read set和一个write set记录这个交易的影响，模拟完成后，endorser对read set和write set进行签名并将其一起返回给client。

如果client收到的read set和write set是一致的（可能存在恶意endorser或者智能合约存在不确定的算法导致出现不一致），那么client就会生成一个真正的交易请求，包含read set、write set和对应的签名，并将这个请求发送给ordering service。

排序

ordering service对来自client的交易进行排序，需要注意的是这里并不检查交易的内容，默认按照交易到达的顺序进行排序（这种简单的排序可能导致大量的交易冲突，降低性能，如果按某一特定的顺序排序可以极大的较少交易冲突，提高吞吐量，这也是这篇论文提出的最重要的工作，这里就不细说）。

ordering service将交易排序后打包成block，发送给网络中的peers，这里不保证所有的peer同时收到这个block，但保证收到的block的顺序是一致的（使用gossip协议）。

验证

当peer收到block后，就开始验证阶段。

验证阶段主要包括两个检查：

• Endorsement Policy检查
  检查交易是否满足endorsement policy以及是否包含有效的签名，否则说明交易可能被client或者恶意peer篡改过，直接丢弃。
• 交易冲突检查
  检查交易之间是否存在冲突，也就是是否读脏数据的问题（某个交易在读取ledger之前，ledger被前一个交易改变了），如果存在就丢弃该交易。

两次检查都通过的话就可以进入commit阶段了。

提交

peer将block添加到链上，注意这里是所有的交易（有效的和无效的）都加进来了。然后根据有效的交易改变当前的ledger状态。

---

其实论文附录中还有一个详细的例子来说明Hyperledger Fabric的工作流程，真的是很良心的一篇论文了，推荐还不太理解的同学去论文中看一下那个交易的例子~

ps:本篇博客收录进了专栏【超级账本源码解析】，更多关于超级账本的内容可以去专栏查阅～