Author

Topic: 伦敦大学学院报告:比特币系统效率低下,但1MB区块上限不是主因 (Read 236 times)

sr. member
Activity: 280
Merit: 250
这些都是可以解决的问题
newbie
Activity: 26
Merit: 0
伦敦大学学院(UCL)区块链技术中心的一篇研究报告(币文库全文下载)表明“43%的交易在发送之后需要耗费1小时以上的时间才能写入区块链,而20%的交易甚至在30天之后都无法得到确认,这也证明了比特币系统效率低下。”



UCL的这项研究对比特币网络进行了为期3个月时间的调查,他们发现有12,000个节点在处理大额交易时效率有所提高。

报告提到:

我们发现这一过程(交易确认)的处理速度仍然较慢,不过大部分交易(93%)都能在3小时内完成,30天之后还未得到确认的交易仅占0.1%。
这项研究得出了不少有趣的结论。比如说,在一个星期之内新增的区块数量达到近20万个,但其中只有2,000个区块是“真实的”或者有意义的。UCL助理研究员Giuseppe Pappalardo是这篇报告的作者之一,他向我们解释了这一现象:

当某节点接收到一个区块时,它必须验证区块中的所有交易以及区块本身。如果交易和区块都是有效的,那么该节点就会用INV信息向其它节点公布这一结果。因此,当某节点使用INV信息发送有关区块或交易的消息,这就意味着有区块通过了验证。
节点发送区块信息的原因是,并不是所有节点都持有一份完整的区块链记录,因此部分节点无法验证区块,也有可能是这部分节点的功能根本不是验证区块。
没有合理的验证,旧区块只会循环地在节点之间广播。
很明显,这一现象证明了比特币系统的效率低下,因为很多资源都遭到了浪费。有关交易方面的信息,目前尚不清楚UCL是否研究了手续费的高低以及其在交易处理之中发挥的作用,作者只是说明了小额和大额交易之间存在的区别。

比特币系统无法保证准确的交易处理时间,因为部分交易的确认时间要花上好几个月。我们发现造成这一现象的原因并不是1MB的区块容量上限,也不是因为每个区块中只能包含几千笔交易。目前网络似乎并没有饱和,平均区块容量只有0.8MB,只有3%的区块大小超过了0.99MB,部分区块甚至根本不包含任何交易。
本次研究在去年5月开始,不久之后,Blockchain.info就表示单日的平均区块大小已经达到0.96MB。自从去年开始,交易滞缓就成了普遍现象,目前就有超过200万个比特币(25亿美元)在等待确认。

 

低效的交易处理

 

不过,报告中指出,无论区块容量是否存在限制,“也无法确保交易能够得到及时处理”,因为矿工可以自由选择区块中的交易。

为了确保交易得到及时处理,中本聪的确曾经提出过一种机制,但并不是强制性的,也不属于协议层。这种机制被称为first seen。节点和矿工应该处理自己见到的第一笔交易,通过这一方法排列交易顺序,但随着区块容量的不断增加,这一方法也失效了。在区块容量保持在正常水平时,这种机制不是强制性的,但由于其合理性,大多数矿工还是会采用这一方法。

first seen还能让双花(double spends)变得更加困难(尽管某些矿工还是可能不采用first seen),就算在交易没有得到确认时也是如此。在大多数情况下,这一方法能让比特币交易得到即时处理。

至于这项研究的作者是否知道这一机制的存在还不清楚(这个机制早就被手续费优先化的方法取代)。Pappalardo认为,部分交易为什么迟迟得不到确认还需要进一步的调查:

我们认为矿工并不会因为打包所有交易而得到额外的经济激励,因此部分交易就被忽略了。一段时间以后,矿工就更不可能愿意处理旧交易了。
Pappalardo进一步表示,“尽管对比特币网络效率的故意抹黑仍然存在,UCL区块链技术中心对区块链及其共识机制的潜力坚信不疑。本篇报告的目的是为了呼吁建议正确的经济激励系统,从而打造一个高效的P2P区块链系统,准确并及时地记录交易。”

那么究竟哪一种经济激励系统才是高效的呢?Pappalardo回答“对合理的交易处理和及时的记录不提供经济激励的系统就不可能是高效的”。

 

区块容量之争

 

区块容量之争已经持续了两年。有人认为应该保持1MB区块上限,比特币基础协议的效率本来就应该是低下的,因此他们选择支持闪电网络(LN)。然而其他人则认为应该通过直接提高区块容量上限恢复first seen机制。

那些坚持低效的人不断阻碍任何方案对协议的改变,包括近期的延展区块(extension blocks)提案。这一行为最终导致了目前近半数的比特币交易等待确认时间超过了1个小时,而一些研究也开始揭露比特币支付网络的低效性。

比特币网络的低效性最终是否能够解决还有待观察,不过,我们欢迎任何有助于终结区块扩容之争的基于科学事实和公平态度的独立研究。
Jump to: