比特币性能拓展—实现比特币1w倍扩容的prism协议

Posted 2021-06-26 lyz_fish

哈尔滨工程大学 区块链讨论课
2017060210 李英卓
2017060219 王晨
2017060224 张鑫

最早数字货币的比特币一直得到社区的坚定支持，但是它内在的缺陷仍让人们有些遗憾。比特币的扩展性问题导致交易速度低、交易成本高，我们都知道比特币有很好的安全性，但就性能而言，却不是。它每秒只能处理7笔交易，每一个都需要几个小时来确认，严重影响其实际应用。

比特币的可拓展性问题往往与区块链价值主张相结合，因此不能通过改变区块链中的参数来简单地增强可拓展性。比特币社区主要可以调整两个变量来尝试增加每秒事物处理数量（TPS）。一个变量是区块大小，另一个变量是区块生成时间。大多人会发现仅仅增加区块大小或降低挖掘复杂性对于可拓展性提升有限。由于事务传播中继时间，尝试以比旧块更快的速度挖掘新块会导致一些相当大的安全问题。

比特币将性能与安全连接在一起。让我们快速回顾一下比特币共识协议，它使用了最长链规则，每个矿工都会尝试扩展和挖最长的链。当出现一个分叉时，当两个区块意外地连接到同一个父块时，矿工将选择最长的分叉。他们总是选择最长链。

这里涉及了一个名为挖矿率的参数，它定义了矿工挖出新块的平均速度。在比特币中，这个速度是每10分钟1个区块。比特币将这些参数与一个设计参数挖矿率联系在一起。

吞吐量是比特币确认交易的平均速度，以及在一段时间内可以确认多少交易，计算方法是乘以区块大小、每个区块有多少交易、以及挖矿速率（我们挖这些区块的速度有多快）。然后是延时，也就是确认一个交易需要多长时间。这个计算可以通过确定深度和挖掘速率的除法来完成。

为了提高性能，我们可以提高挖矿速率来获得更高的吞吐量和更低的延时。我们还可以增加区块大小以获得更高的吞吐量。然而，因为分叉，这是行不通的，如果我们提高挖矿速率或增加区块大小，我们只能得到更多的分叉。这是因为当网络上的两个节点不能足够快地相互传播消息时，就会发生分叉，这样它们就会意外地在同一个父块上进行挖矿。如果我们提高挖矿速率，两个节点更有可能在短时间内意外地挖出新块。如果我们增加区块的大小，那么区块在整个网络中传播的时间会更长，这将导致分叉率的增加。分叉不是好事，因为会损害安全性。分叉降低了诚实挖矿的能力。 如果我们想要提高性能，那么将在安全性方面遭受很多损失，反之亦然。Prism要做的就是打破这种联系。

现对prism进行解构，我们解除性能和安全的联系是为了提高性能。在比特币中，一个区块实际上有两种作用：第一种是新区块会将一些交易添加到账本中，第二种是更含蓄的，新区块也会对其所有间接和直接区块进行认证。这就好比说，证明某条链是最长链。

因此，第一种作用直接与吞吐量相关。交易提交得越快，账本能包含的交易就越多。第二个角色与确认延时相关：我们投票的速度越快，你对交易的信心就越高。

1. 吞吐量
   在比特币中，我们已经看到了由于分叉而导致的吞吐量有限。如果存在一个根本就没有分叉概念的结构，会怎么样呢？这就是我们引入“交易区块”（transaction block）的原因。
   “交易区块”由矿工以较高的挖矿速率挖出，但是交易区块之间没有任何链结构。所以我们可以非常快地挖出它们，而不用导致分叉，因为在这个设计中根本不存在分叉。
   然后我们将这些“交易区块”带到“申请人区块”（proposer blocks）。这些是轻量级区块，只包含指向这些交易区块的哈希指示。“申请人区块”将以比特币的速度开采，并以比特币最长链连接在一起。因为我们挖矿的速度很慢，而且这些区块很小，所以不管你怎样提高吞吐量，都不会导致分叉增加。
   这就是为什么Prism可以在不牺牲安全性的情况下实现底层网络的物理限制。Prism同时基于最长链和工作量证明。

2. 延时
   为了处理延时，我们首先注意到，即使我们引入了申请人链，投票率也不会增加，因为只有一个申请人链在进行投票。所以让我们再做一次解构，把投票和申请人区块分开。
   我们把申请人区块分成了两部分。一个包含指向交易区块的哈希指示，另一个是投票者区块（voter block），它只包含对申请人区块投票的指示。我们不再在申请人区块中采用最长链结构。相反，我们假设在投票区块中有一个像比特币一样的最长链结构。
   到目前为止，我们还没有改善确认延时，因为我们仍然只有一个投票者链，而且这个投票者链是安全的是非常重要的，所以我们仍然需要等待25个确认，否则攻击者可以像攻击比特币一样攻击投票者链。
   现在我们已经把申请人和投票工作分开了，我们可以引入许多投票者链，比如1000个投票者链。一个有趣的发现是，现在我们有1000个投票者链，我们不需要每一个都是安全的。即使攻击者能够攻击一个投票链的概率为30%，但是攻击者同时攻击500个投票链的概率仍然很低。这就是为什么可以在不牺牲安全性的情况下降低Prism中的确认延时。