本文首发在https://zhuanlan.zhihu.com/p/89933683

这篇论文发表在顶会SIGMOD 2019上,题目为《Towards Scaling Blockchain Systems via Sharding》,作者信息为Hung Dang, Tien Tuan Anh Dinh, Dumitrel Loghin Ee-Chien Chang, Qian Lin, Beng Chin Ooi,National University of Singapore

本文章不是论文的直接翻译。本人通过阅读和理解上面论文原文,结合参考其它资料,提取出论文的主体内容,用自己的语言,希望以通俗易懂的方式跟读者分享和交流区块链技术。

读懂这篇论文需要一点基础知识,所以本人先介绍这些基础知识,再进入论文的主要部分。尽量帮忙读者减少阅读障碍。

为什么要分片(Sharding)?

打个比方,如果把所有的商品存放在一个仓库内,该仓库只有一个门用来搬运商品,当有很多工人同时要搬运商品的时候,需要排队。为了提高搬运效率,我们把商品分到十个仓库中,工人分散到这些仓库中搬运商品。

在传统数据库系统中,如下图所示,通过把一个主机上的一个数据库表分片成保存在两个不同主机上的片,来减少数据读写的网络负担和IO负担,来从整体上提高体统的吞吐量。

同样道理,在区块链中,把一个碎片(shard)比作一个仓库,以提高系统的性能。更小的碎片导致更好的整体系统性能,因为(1)一个碎片内节点的通信开销减少,从而提高这个碎片的吞吐量。(2)因为整个系统网络的节点个数一定,那么更小的碎片意味着更多的碎片,因此能够减轻整个系统的压力。(如果N表示整个网络的节点个数;n表示一个碎片内的节点个数,那么整个网络的碎片的个数为k=N/n。所以n表示碎片的大小;k表示碎片的多少。应注意区分)

上图便是传统数据库管理系统和区块链管理系统分片上的区别了。其中一个红圈表示一个碎片,在论文中表示为委员会(committee)。一个委员会包含多个节点,通过拜占庭容错算法来决定这个委员会的共识。共识的作用就是统一意见。这里,可以把一个委员会理解为一个区块链系统。当有一个交易产生时,只需要让一个或者几个委员会来处理这个交易。不同的委员会有时候需要通信,因此我们需要考虑委员会之间通信的问题。

上面便是区块链分片系统的架构了。在该架构之下,有哪一些问题和挑战呢?

(1)一个委员会内的共识算法如何设计?在节点数很多的情况下(>100)拜占庭容错算法速度慢。如下图,当系统节点个数大于67的时候,系统吞吐量下降到了很小的数值。我们是否可以在保证安全共识的情况下尽可能减少一个委员会内的节点个数呢?

(2)需要一个有效且安全的方式来分配节点到各个委员会,避免在一个委员会内有过多的恶意节点。假设整个区块链网络有100个节点,分为5个委员会,每一个委员会有20个节点,且使用的是拜占庭容错共识算法。假设其中恶意节点有10个,并且它们之间相互窜通。如果这些恶意节点全部被分配到一个委员会里面,就会有大问题,它们就能够控着这个委员会的共识结果。解决这个问题的一个方法是将这些恶意节点分散到各个委员会里面,使得每一个委员会所包含恶意节点的数量尽可能少。所以,我们需要解决这个分配问题。在第一次分配好之后,攻击者可能会慢慢把一个委员会内的节点一个一个攻破,使之变成恶意节点,导致这个委员会不再安全。因此需要周期性地重新调整或者说洗牌各个委员会的成员,让恶意节点尽可能均匀分散到各个委员会中。

(3)不同的委员会之间有时候是需要通信的,也就是数据读取或者说跨委员会的交易,我们希望委员会之间的通信具有隔离性和原子性。

本论文针对这三个问题和挑战提出了解决方案,也就是本论文的贡献点了。下面讲解如何解决这三个问题的。根据第一个挑战,提出了:

改进的PBFT算法

论文使用了TEE+PBFT来改进共识算法(TEE,可信执行环境,可参考本人这篇文章)。PBFT算法的安全假设为恶意节点的个数不大于f,其中N=3f+1,N表示一个网络的节点个数,也即是f<N/3。如果使用了TEE+PBFT,可以让f<N/2的前提下实现安全的共识(具体可以查看论文引用17)。这样的好处就是使得这个网络抵抗恶意节点窜通攻击的能力提高了。比如网络中有10个恶意节点,为了实现安全的共识,使用PBFT算法,网络至少需要31个节点,其中包含21个诚信节点;而现在结合TEE,网络至少需要21个节点来实现安全共识,其中包含11个诚信节点。这样子,在一个委会会内,更少节点个数就能实现安全的拜占庭容错共识

为了避免大的可信计算基(TCB,trusted computing base)导致的系统安全隐患,系统没有把整个共识协议放到TEE中执行,而是使用论文17的方式,结合日志、消息摘要和TEE密钥加密来实现安全。这里不深入讲解。

在一个委员会里面的所有节点的通信方面,论文给出了一个小改进。超级账本Hyperledger的共识消息和请求消息共用一个消息队列,导致大量的共识消息被丢弃,特别是在委员会节点数增加的时候,使得吞吐量下降。所以,论文使用两种队列来分别处理共识消息和请求消息。

针对第二个挑战,提出了如下思路:

委员会成员的分配

SGX(一种TEE产品)有两个函数用于在Enclave处理:sgx_read_randsgx_get_trusted_time,分别用来产生无偏见的随机数和产生一个时间戳。论文借用这两个函数来实现委员会成员分配。

总体思路:假设每一个节点都获取到了一个相同的随机数rnd,那么每一个节点都可以使用rnd作为种子(seed)来获得元素为[1:N]的一个随机全排列。因为种子是一样的,所以每一个节点的随机全排列是一样的。再将划分为k份,每一份便是一个委员会了。

现在问题是,如何让每一个节点都获取到一个相同rnd呢?

本系统是分时期工作的(比如一个时期长24h),每一个时期开始的时候就动态洗牌各个委员会。使用e来表示当前是第几个时期。为了避免攻击者选择性丢弃TEE的enclave的输出结果,导致随机数生成出现偏见,因此每一个时期TEE的enclave只能被调用一次。在每一个时期e开始的时候,执行下列步骤生成一个全网统一的随机数rnd。

  • 1. 生成两个随机数q和rnd,
  • 2. 如果q=0,那么该节点就生成一个包含<e,rnd>的签名证书,广播该证书到其它所有节点
  • 3. 所有节点等待  时间之后,锁定所获收集到的最小的rnd
  • 4. 使用3中的最小rnd来作为当前时期的委员会分配的随机种子seed。

每一个节点拥有一个相同的随机数rnd之后,就可以根据上述的总体思路来确定一个节点属于哪个委员会了,也就是委员会分配问题的解决。

如果所有节点生成的q都不等于0,那所有的节点都不能生成上述步骤2的证书,也收不到被广播的证书,那当前时期就无法重新调整委员会了, 怎么办?

解决思路为,所有节点的e增加,重新执行上面步骤。

另一个问题是,攻击者可能会慢慢一个一个攻破一个委员会中的节点,使得该委员会的恶意节点个数超过安全共识的临界值。所以我们需要每隔一段时期就要根据rnd重新调整委员会的成员。所有的节点同时调整是不可行的,因为会导致系统在这段时间不可用,因此采用分批调整的方式。在调整的过程中,每一个委员会最多有B个节点调整到其它委员会,这B个节点在这期间不参加共识工作。B的的大小设置需要权衡,更大的B值导致更低的系统安全性。

针对第三个挑战,提出了下面思路:

两阶段锁和两阶段提交

论文使用两阶段锁和两阶段提交来解决委员会之间通信的问题,并且满足隔离性和原子性。总体思路如下图所示,委员会之间的通信分为三个阶段,分别是准备,准备提交,提交。R表示参考委员会(Reference Committee),S1,S2,S3便是涉及到本次的transaction的委员会了。参考委员会在构造上面跟其它委员会没有区别,只是它是一个协调者的身份。“协调者”这个角色来自两阶段提交协议,即两阶段里面的协调者和这里的协调者的工作基本是一样的。只是这里的协调者是一个委员会,由很多个节点构成,使用拜占庭容错共识。

传统的两阶段提交和本论文中的两阶段提交算法对比

一个Transaction可能有多个输入和多个输出,这些输入和输出可能涉及到多个委员会,这些委员会在下图表示为S1,S2和S3。

具体的跨委员会交易执行流程是什么呢?

参考委员会自身有一个状态机,如上图所示,用户发送一个交易Tx给参考委员会,这里使用R来表示参考委员会,R就进入Started状态,它向相关的委员会发送PrepareTx,同时等待收集各个委员会的回复,如果所有的回复都为PrepareOk, 那么就进入committed状态,R正式提交交易。如果有任何一个委员会回复PrepareNotOK,参考委员会进入Aborted状态。如果任何一个委员会回复消息过时或者不回复,那么R进入Aborted状态。

参考委员会会成为系统性能的瓶颈吗?论文说不会,通过运行多个参考委员会来并行计算。

R是否会存在可用性问题呢?因为论文的假设是一个委员会的恶意节点数量小于安全共识的阈值,因此R总是能够执行诚信的共识来完成作为协调者的工作。

总结:

这篇论文针对上面三个问题和挑战,借用TEE提出了自己的解决方案。这篇论文包含的信息量比较大,阅读和理解这篇论文有一定的难度,因为作者假设读者已经清楚了一些基本概念,比如区块链分片,参考委员会的构造和管理,拜占庭容错算法,TEE,两阶段提交和两阶段锁等等。论文使用了RapidChain和OmniLeger作为对比来叙述跨委员会交易的原子性和隔离性问题。在阅读这篇论文之前,了解RapidChain和OmniLedger这两篇论文有助于理解这篇论文。

论文中涉及到一些定量的计算问题,比如如何设置合适的委员会大小,这里不给予讲解了。

对于区块链分片的方案,可以参考:

  1. ELASTICO

http://people.cs.georgetown.edu/~cnewport/teaching/cosc841-spring19/papers/new/sharding.pdf​people.cs.georgetown.edu

2. Near Protocol,在油管有专门的视频讲解

NEAR Protocol​github.com

3.Monoxide

SweetCandy:区块链相关论文研读4: Monoxide异步共识组​zhuanlan.zhihu.com

4. RapidChain, OmniLeger,Zilliqa,Cosmos,Harmoney,具体百度或者google一下就可以找到相关的论文。

谢谢!点个赞呗 = =

区块链相关论文研读7:通过分片(Sharding)扩展区块链相关推荐

  1. 区块链相关论文研读6: FASTKITTEN,关于比特币的实用智能合约

    这篇文章首发于知乎专栏:https://zhuanlan.zhihu.com/p/89090472 这篇论文发表在顶会USENIX Security Symposium 2019上面,题目为<F ...

  2. 区块链相关论文研读5:分布式隐私保护可审计的账本,zkLedger

    这篇文章首发于知乎专栏:https://zhuanlan.zhihu.com/p/87900715 这篇论文在2018年发表在顶会NSDI上面,题目为<zkLedger: Privacy-Pre ...

  3. 区块链相关论文研读2 - vChain,关于可验证的查询

    这是在2019年7月发表在顶会SIGMOD上的论文,题目为<vChain: Enabling Verifiable Boolean Range Queries over Blockchain D ...

  4. 区块链相关数据报表_区块链相关论文研读5:分布式隐私保护可审计的账本,zkLedger...

    这篇文章在2018年发表在顶会NSDI上面,题目为<zkLedger: Privacy-Preserving Auditing for Distributed Ledgers>,作者为Ne ...

  5. 区块链相关论文研读4: Monoxide异步共识组

    这篇论文今年(2019)二月份发表在顶会NSDI上面,题目叫<Monoxide: Scale out Blockchainswith Asynchronous Consensus Zones&g ...

  6. 区块链相关论文研读1- 关于边缘计算

    今天跟大家分享一篇关于区块链的技术论文,该论文被发表在顶刊IEEE transactions on parallel and distributed systems(TPDS)中,时间为2019年4月 ...

  7. 区块链相关论文研读3- 关于超级账本Hyperledger Fabric的性能优化

    这是2019年6月发表在顶会Sigmod上面的论文,论文题目为<Blurring the Lines between Blockchains and Database Systems: the ...

  8. 简要介绍SIGMOD2021接收的区块链相关论文

    SIGMOD 2021 将于6月20日到6月25日在西安召开,作为数据库领域毋庸置疑的顶会,今年收录了7篇区块链相关的论文,其中1篇 demo paper,6篇 research paper.这篇博客 ...

  9. 【区块链基础知识系列】 第6课 区块链之分片技术(sharding)-区块链扩容问题的良方

    进行区块链扩容的一个答案就是分片技术(Sharding).分片技术承诺通过改变网络验证的方式来增加吞吐量.分片技术独特于其他解决扩容的链上技术的关键特性,就是它可以进行水平扩容,也就是说,网络的吞吐量 ...

最新文章

  1. C语言中auto,register,static,const,volatile的区别
  2. 视频: 猫和老鼠真实版
  3. avformat_alloc_output_context2 -22错误
  4. 天池实验室Python能力测验
  5. 深度学习-Tensorflow基本介绍01
  6. C++实现一个简易的线程池
  7. 计算机考研:计算机组成原理考点分析
  8. 如何从WebSocket服务器收到的数据判断出有哪些客户端需要广播
  9. angularjs mysql_AngularJS SQL
  10. 3D印花芭蕾舞鞋为舞者科学地保护双脚
  11. 风控人必知必会的征信知识
  12. 运用js解决java selenium元素定位问题
  13. 项目开发经常使用PHP功能
  14. MyBatis拦截器实现SQL打印
  15. iOS开发-Xcode8兼容iOS7手记
  16. 64 位 Microsoft Windows 驱动程序清单
  17. 直播第三方美颜sdk是什么?
  18. C语言开发打气球小游戏
  19. JS对浏览器地址的操作
  20. 如何考取谷歌分析证书 (google analytics individual qualification)

热门文章

  1. ae制h5文字动画_AE动画在H5设计中的应用研究
  2. EasyUI DataGrid根据字段动态合并单元格
  3. 不学无数——SpringBoot入门Ⅱ
  4. [JavaEE笔记]Cookie
  5. Struts2——学习(5):页面跳转
  6. js递归函数使用介绍
  7. 启动过程以及故障排除
  8. 多线程技术(四)线程的优先级
  9. Linux下的QQ截图
  10. 基类与接口混合继承的声明问题 [C#, Design] -Allen Lee's Magic