这篇文章主要内容:
- 分析BTC通过修改参数可以如何影响其可扩展性, 以及一些限制.
- 想要扩展区块链, 可以通过哪些方面思考 (个人觉得这部分参考价值很高)
1.引言比特币的吞吐量(Throughput)主要由"最大区块大小除以区块生成间隔"决定. 这意味着, 随着交易量越来越多, 平均区块大小会越来越趋近最大区块大小, 然后BTC的吞吐量就会达到顶峰(之前交易量小的时候, 实际区块大小实际上小于最大区块大小). 文章预测在2017年达到顶峰.
目前, BTC平均出块时间为10分钟, 吞吐量最大7笔交易/秒. Visa信用卡平均吞吐量2000笔交易/秒, 最大曾达到56000笔交易/秒.
先看看文章的结论:
- 吞吐量上限: 根据现在平均10分钟的区块间隔, 区块大小不能超过4MB. 这个区块大小意味着最大吞吐量为27笔交易/秒
- 延迟下限: 要想充分利用网络带宽的话, 区块间隔不应该小于12s.
2.比特币的可扩展性先放一些现在的数据:
最大吞吐量: 3.3-7笔交易/秒
延迟: 以交易被记录到区块的时间间隔为延迟的话, 10分钟.
然而实际上, 大家一般以6个确认(即再有5个区块追加到当前交易区块之后)作为交易确认的时间点, 这实际上就是1个小时了.
启动时间: 按照亚马逊t2.medium的机器来算, 需要4天同步所有交易.
每笔确认交易的开销: Cost Per Confirmed Transaction (CPCT). 在最大吞吐量情况下, CPCT为1.4-2.9, 其中57%开销在电力上. 按照BTC目前的吞吐量来算, CPCT是$6.2.
![]()
image.png3.通过修改参数进行扩展, 及其限制Bitcoin Improvement Proposals (BIPs)比特币完善提议.
其中100, 101, 102, 103都是修改区块大小, 要求硬分叉. 区别只是
- 开始时机(固定时间还是根据矿工的接受度)
- 区块增大策略(一次性, 线性, 不断翻倍, 甚至选择性减小).
Segregated Witness能够达到对区块增大不到2倍的效果, 但它只需要软分叉即可, 即旧节点无需升级, 但隐含地相信矿工的交易验证.
[h1]3.1. 度量[/h1]2012年的一次研究中, BTC节点接收一个新区块所需要的时间: 中位数为6.5秒, 90百分位为26秒.
区块传输时间的决定性因素:
- 网络延迟 (对于小于20KB的小区快)
- 网络吞吐量 (对于大于20KB的区块)
理解: 对于小区块来说, 它们没有达到网络吞吐量的上限, 所以只受到网络延迟的影响. 但是对于大区块来说, 它们可能已经达到了网络吞吐量的上限, 所以发送大区块需要分多个包而增大时间开销.
当时平均区块大小87KB. 这意味着想要接收一个1MB的区块, 90%的节点需要5分钟的时间.
计算方法: 1MB / 87KB * 26s ≈ 5min
后来作者在2014, 15年又做了实验, 区块传输时间: 10分位为0.8秒, 中位数为8.7秒, 90分位为79秒 (都增加了).
同时, 平均区块大小增大到了540KB. 增大了6倍.
想要接收1MB的区块的话, 90%的节点需要2.4分钟.
计算方法: 1MB / 540KB * 79s ≈ 2.4min
X% Effective Throughput
X%有效吞吐量 := 区块大小 / X%区块传输延迟
比方说最短的那50%的区块传输延迟为1s, 区块大小为1MB, 则50%有效吞吐量为1MB/s.
含义: 给定平均区块大小和区块传输延迟, 要满足50%的节点能够正常接收区块, 网络的吞吐量需要达到1MB/s.
![]()
image.png图表显示, 这次的区块大小分界线为80KB. 即小于80KB的小区块, 延迟是区块传输时间的主要影响因子; 大于80KB的区块, 则是网络吞吐量.
![]()
image.png[h1]3.2. 通过修改参数进行扩展的限制[/h1]吞吐量上限: 根据 "区块大小 / X%有效吞吐量 < 区块间隔" 的要求, 我们可以得到:
已知区块间隔10分钟, X=90时, 区块大小不应该超过4MB; X=50时, 区块大小不应超过38MB.
计算方法:
90%有效吞吐量为55Kbps = 6.875KBps, 10min = 600s, 所以600s * 6.875KB/s = 4.125MB.
50%有效吞吐量为496Kbps = 62KBps, 所以600s * 62KB/s = 37.2MB
结论: 目前区块间隔10分钟的情况下, 区块大小不应该超过4MB, 相应的吞吐量至多为27笔交易/秒
延迟下界: 由于传输小于80KB的小区快无法充分利用网络带宽 (此时未达到吞吐量上限), 我们对80KB的区块进行分析. 80KB / 6.875KB/s = 11.63s (其中6.875KB/s是90%有效吞吐率), 所以延迟大概是12s.
结论: 想要充分利用网络带宽, 达到至少90%的有效吞吐率, 区块间隔不应该小于12秒.
其他难以度量的数据:
举例:公平性.
目前全网前10%的节点比垫底的10%节点能够提前2.4分钟收到一个1MB的区块, 这样明显会导致不公平, 即某些节点可以先进行hash碰撞. 事实上, 现在很多矿场中, 不是每个节点都监听交易信息, 而是用一个中心化的节点进行交易的接收和验证, 然后广播到矿池内的其他节点, 其他节点不验证直接记录到交易池中. 这样可以大大增加效率, 因为交易验证的时间开销在BTC交易延迟中占据了非常大的比例.
[h1]3.3. 瓶颈[/h1][图片上传失败...(image-16b492-1532915051437)]
可以看到, 网络带宽远远大于有效吞吐率, 硬盘读写也吞吐率很高, 交易验证的时间开销是一大瓶颈.
4.对于可扩展区块链的思考5个维度, 网络, 共识, 存储, View, Side
[h1]4.1. 网络层[/h1]从3.3可以看到, BTC没有充分利用网络带宽.
- 为了避免非法交易DDOS, 每个节点都必须要验证每一个交易.
- 每个交易都要全网广播两遍. 第一遍是交易产生时, 第二遍是区块生成时.
策略:
- 避免交易广播两遍. 详见论文.
- 参考矿池, 使用中心化的节点进行验证.
另一个方向是通过P2P的优化, 强化诚实节点之间的连接. 对于不常变化的网络, 解决方法已知. 但是对于区块链这种频繁变化的网络, 还有待研究.
另外一点, 是在网络层上引入激励措施.
[h1]4.2. 共识层[/h1]共识层的作用: 确定全网认同的一批待处理交易, 并且确定它们的顺序(全序/偏序).
POW
三要素之间的平衡: 速度, 带宽, 安全性.
如果增加前两项, 会导致安全性下降, 即分支变多, 算力分散, 不公平更容易发生.
GHOST的DAG方法, 使用算力最重作为共识, 而不是比特别的链最长.
POS
根据冻结的资金数目作为权重. 缺乏对系统归一能力的形式化验证.
联盟链
PBFT对于节点数目少的小网络效率很高, 在一些机构联盟内部可以舍弃一部分去中心化, 用更少的节点, 组建联盟链, 达到更高的效率.
分片 Sharding
从数据库的可扩展性借鉴过来的方案. 将网络分割为多个不同的区域(分片), 将要达成共识的任务分割到每个分片, 利用上小网络能达到更高效率的特点.
一个研究方向是, 如何提升分片之间达到共识的效率. 分片越多, 花费在分片之间达到共识的开销可能就越大.
对于非拜占庭环境, 对于片间共识可以采用不同的共识算法, 比如Paxos.
但是在拜占庭环境中, 片间共识需要不少开销, 这是一个研究方向.
信任代表(Delegation of Trust), 侧链
侧链可能更加中心化, 因此效率更高.
侧链研究的三个挑战:
- 侧链需要提供独立于主链的安全性
- 如果侧链增多, 跨链交易的可能性就增大, 可能导致开销增大.
- 跨链可能导致的高延迟.
[h1]4.3. 存储层[/h1]从两种类型的接口上思考:
BTC的写入接口只支持追加, 不支持删除. 读取接口要下载整个区块链历史. 所以BTC的存储层效率很低.
参考论文38: 对UTXO进行分片.
但是这种分片机制如何扩展到一般的数据类型, 是个问题.
Distributed Hash Table (DHT) 分布式哈希表可能是一个方向.
[h1]4.4. View层[/h1]BTC中的View为UTXO池, 即当前所有个体的余额. ETH的智能合约定义了链的状态.
View层: 一个记录全网状态 (状态来自整个区块链历史的交易结果) 的数据结构.
View作为存储层中的数据, 它的内容应该由共识层决定, 又对于读取View的节点需要提供验证方法.
实现View层的方法:
复制
BTC, ETH都要求每个节点下载所有交易历史. 优点, 高可用性, 安全; 缺点, 低效.
外包
由第三方提供View. 第三方需要提供能够自证其正确性的方法.
Verifiable Computation Techniques: Succinct Non-interactive Arguments of Knowledge (SNARKs).
[h1]4.5. Side层[/h1]利用侧链.
闪电网络
|
|
转播
