MTFS 与高性能

  • KJ
  • 更新于 2020-01-10 20:27
  • 阅读 2750

上一篇文章我们提到了 MTFS 的实时性实际上来源于高性能和扩容方案的成功,换言之,实时性是一个副产品。那么 MTFS 是怎么做到的呢?

提到高性能和扩容,这个话题被多少区块链项目反复的讨论。

其实,比特币完全没有扩容需求,它早已成功,成为一种电子黄金。真正在扩容方面有迫切希望的是以太坊,有了高性能和大容量,以太坊就可能成为重要的金融工具。除此之外,EOS已经证明了石墨烯的TPS达不到很高,Libra也宣称每秒交易量大概会在一千左右。其他的区块链,大多在考虑二层扩容或者链下扩容。

下面我们回到 MTFS。上一篇文章我们提到了 MTFS 的实时性实际上来源于高性能和扩容方案的成功,换言之,实时性是一个副产品。那么 MTFS 是怎么做到的呢?

我们来用通俗的例子理解一下。早上出门前,小明的妈妈和小红的爸爸各给他们十块钱,这是两笔转账。然后小明和小红都拿着十块钱去同一家早餐店买了早餐,又发生了两笔转账。

前两笔转账和后两笔转账有什么不同呢?小明和妈妈之间的转账与小红和爸爸之间的转账,完全不需要考虑先后关系,因为没有重叠的交易人,所以完全不需要考虑交易谁先谁后,这类没有交集的交易甚至都不用检测双花。

而小明与早餐店的交易,是不可能与小红的交易同时发生的,早餐店需要一笔一笔的进账,交易记录一定有先有后。

这样的原理很简单,再来看看区块链,它的本质上是哈希链,是一种线性的数据结构。它要求,世界上所有要上链的交易,都按照顺序排列成一队,分出先后来。即使完全不相关,比如父母给零用钱的这些交易,也都需要分出先后,打包进区块链。如果借用巴士和公路的例子,这条公路一定又长,又窄,车多了必然拥堵。

在我们提出论文 Improve Blockchain Performance using Graph Data Structure and Parallel Mining 之前,我们对链式数据结构做过研究,在不修改数据结构的前提下,从根本上提高区块链的性能和容量,是一件很困难的事情。目前的二层网络扩容,DPOS,链下扩容方案等,都没有根本的提升区块链性能或容量。我们提出的图数据结构(经后续研究表明,这种结构几乎等价于多链结构),则有希望同时完成提升性能和容量,更有可能完成分片(分片这个词被以太坊使用了,我们这里指更加通用的数据库分片)以及实时性。

简单说分片,如果每一个全节点都需要把全世界的数据都放在自己这里存储,就算这个区块链是高性能的,也是不可扩展的,因为没有人的硬盘是无限大的。只有分片可以让节点合作存数据,这就是分片的重要性。

关于高性能呢?按照目前的做法,每隔一定时间,从全世界的所有矿工中选择一个出来,对过去这段时间内的交易进行打包。所以,目前区块链即使做到了高性能,也必然是高延迟的。那么我们能不能通过选举一个矿工的方法,对未来一段时间的交易打包负责,甚至可以按需生成新区块呢?(这样就不会有空块)

这样的想法很好,但是遇到新问题,一个在线的矿工可以保证完成目前的任务,但是矿工无法保证自己在未来一段时间内肯定在线。各种不可抗因素,比如断电,断网,遭受黑客攻击,硬件故障都会让矿工下线,那么没有人能保证自己可以在未来完成指定的工作。一旦被选举出来的矿工失效了,这样的单点故障会使得整个网络拥堵。

为了解决这个问题,在最初的设计中,采用了并行挖矿这个说法,其实是想允许有多个矿工同时服务于整个区块链网络,为区块链网络提供了冗余。

改变模式,矿工本来对过去一段时间内的交易负责,改成对未来的交易负责,以满足交易的低延迟,实时性。但是多个矿工协作的算法是什么?如果他们是各自处理不同的区块,还是做相同的工作?当某个矿工掉线的时候,另外的矿工如何替补?在这个问题上,我们花了很长时间思考,18年有很长一段时间,都是在解决这个问题。在经过多次尝试以后,我们无法设计出一个比pBFT更好的方案,所以我们沿用了经典方案,并加以的组合:使用PoW做选举(滑动窗口模式),使用pBFT让多个leaders同时出块。

我们的创新点,在于引入了新数据结构,实现了分片,去掉了批处理模式,避免了过长的确认时间,目前这套系统正处于测试阶段,我们将持续更新。

点赞 0
收藏 0
分享

0 条评论

请先 登录 后评论
KJ
KJ
密码学和区块链博士研究生