说起来也是很巧合的一件事情,去年暑假自己一个人在宿舍学习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:本篇博客收录进了专栏【超级账本源码解析】,更多关于超级账本的内容可以去专栏查阅~