通往链上扩容之路：极瘦区块(Xthin)现可安全支持20MB区块

第5部分：大规模链上扩容一开始就支持高达20MB的区块

由Andrew Clifford、Peter R. Rizun、@sickpig、Andrew Stone以及Peter Tschipper撰写，特别感谢蚁池的吴忌寒提供区块资源，感谢@cypherdoc和其他慷慨解囊的捐赠者让我们可以支付位于中国大陆的节点。

本节，我们将对这个5节系列文章做出总结，探讨为何我们相信极瘦区块(Xthin)现在就可以支持链上60tps（每秒交易）和20MB的区块。这将极大地缓解目前严重的网络阻塞（3tps的限制），并为链下扩容方案的成熟带来喘息的空间。最后，我们一窥Bitcoin Unlimited的下一步计划。

每秒60笔交易，20MB的区块

“极瘦区块让高效区块中继成为现实。”

这个系列文章多么令人振奋！在第1节中，我们描述了极瘦区块是如何解决Bitcoin Core的一个长期低效率问题：交易总是被每个节点接收两次，第一次是用户首次广播交易时，第二次是节点稍后下载包含那笔交易的区块时。这样的低效率导致 区块传输慢、消耗大量带宽。通过整理从超过9,000个真实比特币网络中传输的区块的统计数据，我们证明极瘦区块更快（第2节）、受到GFW影响更少（第 3节），且比标准区块更小（第4节）。（我们上周甚至还绕道揭穿了一种所谓的攻击媒介。）极瘦区块可以让高效的区块中继成为现实。

图表1：基于超过9000个真实比特币网络上传输的区块数据，极瘦区块更快、受到GFW影响更少、比标准区块更小。

极瘦区块的这些性能恰好应对了链上扩容的瓶颈问题，我们所知的这些问题的纯数据驱动研究来自：Cornell的扩容立场文件和Jonathan Toomim的“区块大小奥林匹克”(Block Size Olympics)研究文件。

Cornell立场文件

（http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf）

Cornell认为区块与节点的传输问题是最主要的瓶颈所在。他们认为，就已有的区块大小而言，一部分的节点将不能在 10分钟目标区块时间内下载区块，因而落在后面越来越远。基于对比特币网络区块传输的真实测量，他们计算得出，在平均区块大小为4.1MB的情况 下，10%的全网节点会跟不上，而在平均区块大小37MB的情况下，全网一半的节点都会落在后面。他们建议区块大小不应超过4MB.

 “区块与节点的传输问题就是瓶颈所在。极瘦区块可解决之。”

Jonathan Toomim区块大小奥林匹克

（https://toom.im/blocktime）

在Cornell文件之前，Jonathan Toomim已经带领了一项名为“区块大小奥林匹克”的研究，他总结认为目前的网络可以安全地支持4MB大小的区块。Toomim测量了数百个测试网络的 区块传输时间数据，其大小最大为10MB，共有20个不同节点，其中3个位于GFC内侧的中国大陆。和Cornell文件一样，Toomim得出4MB限 制的理由正是区块与节点传输效率低——尤其是与那些被GFC隔离的节点。

极瘦区块可解瓶颈

区块与节点传输问题正是瓶颈，而极瘦区块可解之。如果4MB的区块在标准区块传输区块下是安全的，那么如果广泛应用极瘦区块，安全标准可以远远超过4MB.

图表2：Cornell立场文件和Toomim的“区块大小奥林匹克”研究都认为区块不应超过4MB大（每秒12笔交易）。这两份研究得出的瓶颈在 于区块与节点的传输问题。极瘦区块可以解决这个问题，在我们看来，如果配合Xval使用，安全的区块限制可达20MB（每秒60笔交易）。这个量级的链上 扩容可以为链下扩容方案的成熟带来充足的喘息空间。

极瘦区块提高了区块向节点的传输速度达5.6倍（普通P2P），而通过GFC则为9.7倍。它也可以降低区块传输的带宽 要求达24倍。简单地按比例计算，5.6倍情况下的新区块限制为22MB，9.7倍情况下为39MB，24倍情况下为96MB.（Cornell文件认为 交易-确认和disk-I/O瓶颈远超4MB，所以我们预计瓶颈主要还是与带宽相关联的。）

“我们已经可以安然地设置我们的节点接受最高20MB的区块了。”

Bitcoin Unlimited拒绝需要有协议强制性区块大小限制的观念。相反，它提供工具促进一个“有效限制”机制的萌芽，根据每个节点操作员手头的信息，他们可以 调整自己的最大区块限制设置。依靠极瘦区块和其它Bitcoin Unlimited做出的进步（包括Xval），以及通过我们进行这些实验得出的信息，我们已经可以安然地设置我们的节点接受最高20MB的区块了。

人人都爱极瘦区块

6个月前，高效区块-节点中继只是一个概念。那时的辩论在于这究竟算不算个好主意。

感谢Peter Tschipper、@sickpig和Andrew Stone的大量努力，高效区块中继已经成为现实。来自各方的、包括Classic、Core和XT的开发者们不仅一致认为这是个好主意，他们还希望各自将它（或者非常类似的东西）实装。

开发者社区目前正在争论细节问题。

图表3：只需要极少的代码修改，开发者就可以添加和移除极瘦区块的特征，满足他们客户的需求。

比如，有些开发者希望通过移除布隆过滤器来均匀字节（代价是更长的传输时间和更多轮的数据往返），而有些开发者希望对哈希添加salting以作为额外的安全措施（代价是额外的CPU循环和代码复杂性）。

 “就让自由市场来为细节打嘴炮吧。”

Bitcoin Unlimited的一个中心原则就是，全网应该基于人们自由选择运行的代码而进化。本着这样的原则，我们认为用户有需求而开发者有兴趣的所有极瘦区块特性都应得到部署。就让自由市场来为细节打嘴炮吧。

一窥Bitcoin Unlimited实验室

下述4个项目正在推进中。欢迎任何人加入Bitcoin Unlimited，为这些点子做贡献（或是带来你自己的点子）！

Optimistic Mining

指在PoW得到验证之后，而整个区块被下载验证之前，按区块头(block header)挖矿。这样做的矿工比其他矿工有一点利润优势。该技术也能摧毁所有依赖于降低矿工竞争对手区块速度的“攻击”。根据Gavin Andresen提出的头优先(headers-first)技术，Thomas Zander创造了术语Optimistic Mining.

eXpedited Block Relay

快速区块中继

快速区块中继(eXpedited Block Relay)在于开发“延迟知晓”矿工节点和中继节点。不像极瘦区块这样的比特币inv/getdata方法，一个Bitcoin Unlimited节点向得到eXpedited服务的节点发送瘦区块，不需要预先询问这些节点是否愿意接收。这可以带来少到0.5趟的区块传输数据往 返，代价则是更大的带宽消耗。

“Long Tail” Block Propagation Times

“长尾”区块传输时间

在我们的区块传输实证研究过程中，我们发现一小部分区块需要无规则的长时间来传输。这个问题的起因可能多种多样，包括与全球网络的连接性问题、 GFC追踪、软件BUG等。在许多实体工程原则中，标准做法是将实证研究的结果带入设计中，创造迭代设计流程。虽然比特币客户端只是一个电脑程序，但比特 币整体作为一个复杂的系统，是建构在一个包含实体光缆\铜缆连接全球数据中心和家庭的互联网基础上的。我们认为一个实证、再设计循环可以有效优化比特币系 统。我们已经开始通过调查这些“长尾”区块传输时间来进行我们的迭代再设计。

Subchains

子链（www.bitcoinunlimited.info/resources/subchains.pdf）

子链是一个弱区块应用，减少孤块风险、增强零确认安全性。子链可以与极瘦区块一道促进链上扩容到100MB甚至更大。

 “欢迎任何人加入Bitcoin Unlimited”

尾声

最后我们希望感谢我们的读者和整个比特币社区。正是你们对这一伟大实验改变世界的期许带动着这一切滚滚向前。

捐赠

为了推动Bitcoin Unlimited的链上扩容项目，敬请酌情考虑捐赠，以帮助我们维护VPS网络，包括我们在上海和深圳的节点。捐赠达1BTC或更多的捐赠者会在未来的文章中得到署名感谢。

Bitcoin Unlimited捐赠地址是3AtbpAikJ6C11ZCHiYbEKcSjyoVjzfxYwU，这是一个2/3多重签名地址，签名秘钥由 Andrew Clifford、Andrew Stone和Peter Rizun持有。（译注，请与原文再三核对。）

声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。