BCH首席开发Amaury:关于BCH的出块时间

【前言】

一个星期之前我和BCH的首席开发者Amaury在微信上有过一次交流，具体请看我的上一篇文章。那次他保证会抽空写一篇关于BCH区块时间的文章，昨天晚上，这篇文章写好了，我特意翻译成中文给大伙看一下

【以下是译文】

最近，我注意到缩短BCH区块时间这个话题在中国社区依旧很热门。看起来，围绕这件事的各种争论很多都缺乏相关的知识，所以在这篇文章里面，我希望把事情说清楚一点。

为什么需要更快的出块速度？

较短的区块时间确实有一些让人无法立刻反驳的优点。

当区块产生的速度变得更快时，产生一个区块所需的工作量也会相应减少。举例，如果我们把区块时间缩短到1分钟，那么每个区块产生的难度就会容易10倍。而在较长的时间范围内，两者的安全性是一样的。10个难度为100的区块和100个难度为10的区块是一样的。但是在较短的时间内就不一样了。1个难度为100个区块的安全性远低于10个难度为10的区块。背后的数学原理有点复杂，简单来说就是前者让攻击者有10分钟的时间来进行攻击，而后者只有1分钟。

在较短的时间范围内具有更高的安全性可以使支付处理器和交易所们更快的处理转账，从而使BCH产生更多用例。因为扩容的原因，我们不可能把出块时间降到非常低（备注:比如秒级），所以这不会成为即时支付的解决方案，但是这对套利以及降低商户承受的价格波动风险非常有用。

缩短出块时间的另外一个重要好处是为难度调整算法（DAA）提供了更多信息。DAA根据过去的若干区块来估算BCH的算力，并且相应的调整挖矿难度。然而，单个区块的出块时间存在非常大的差异，所以必须使用多个区块来做出决策。使用的块数越多，做出的决策越好，但是这也会耗费更长的时间。所以这里面有一个平衡点，通过给算法提供更多区块，来更快更精准的调整难度。

考虑到以上所有因素，如果我重新开发一个币，我会选择一个比10分钟更短的时间，可能是2.5分钟，也可能是1分钟，但不会更低，我以后会解释这个原因。但是，当缩短时间涉及到BCH，我们必须明白现有的系统存在某些弊端，因为我们希望从修改区块时间中获得的好处远远大于坏处。

为什么更快的区块会阻碍扩容？

任何比特系网络的出块时间都需要远远大于全网实际处理一个区块的时间。如果不是这样的话，那么全网达成共识的能力会严重受损。当区块产生的速度比全网处理区块的速度更快的时候，就会发生最极端的情况，每个矿工都会分叉出一条链。但是，即便在这种情况发生之前，网络质量也会因为孤块率的增加而下降。

从直觉上来说，我们期望的是如果更快的产生区块，那么每个块就会变得更小，因此也就更加容易广播。在某种程度上这是对的，但是这忽略了一个事实:广播区块存在一个固定的时间开销。这个开销和区块的大小是没有关系的。为了方便理解，我们假设A，B，C三个节点互相同步区块:

A到B: 你好，B，我刚获取了一个新的区块，哈希值是00012345af，你要吗？

B: 你好，A，我不知道这个区块是什么，请把它发送给我

A: 那好吧，这个区块的第一笔交易是……..

B到C: 你好，C，我刚获取了一个新的区块，哈希值是00012345af，你要吗？

C: 你好，B，我不知道这个区块是什么，请把它发送给我

B: 那好吧，这个区块的第一笔交易是……..

这和一个新的区块刚被发现时，节点之间发生的事情非常相似。正如我们所看到的，除了区块本身的传播，在各个节点之间还有相当多的信息交互。而这些信息交互是必须的，如果没有这些，当一个新区块出现时，所有节点就会立刻开始向所有人发送区块，整个网络会因此崩溃。虽然有各种技巧来改善这种情况，比如ABC团队的紧凑区块技术，但是固定的时间开销依旧存在。

如果把区块时间从10分钟缩短到1分钟，这个固定的时间开销将会变成原来的10倍，这会对安全的扩容产生限制。

更快的确认速度呢？

虽然更快速的出块可以改善确认时间，但是这对于很多应用场景来说并不起作用。对于任何面对面的交互，确认速度需要降到3秒以下才有意义，靠缩短出块时间是不可能完成这点的。但是像avalanche这样的技术可以实现这点，目前已经存在的原型可以使交易在2秒以内获得确认。

虽然像套利之类的应用场景会从中受益，但是这可能和BCH的核心价值不一致，无法证明为此改变区块时间这类核心参数是合理的

难度调整呢？

更快的出块速度可以帮助设计更好的难度调整算法，因为他们提供更多的区块数据。明显不利之处在于，这会产生更多的数据，导致SPV这类系统的负载增加，同样也会严重限制类似智能卡这轻量级系统的性能。

这些多出来的数据当然不是无法处理，但是人们在BCH上建立生态时会先假设（参数不变），而打破这些假设对于生态的增加有害。

为什么在现成的系统上修改区块时间会更加困难？

我之前说过，如果我从头开始开发一个新币，我会选择低于10分钟的区块时间。然而，BCH上已经存在了很多用户。BCH有一个基于时间的脚本系统，比如在币可以花费之前，会被锁定一段时间。

这些功能对于许多智能合约非常重要，尤其是支付渠道或者像是Mecenas这样的循环支付解决方案。这些智能合约没有时间来源，因此他们将BCH区块链本身作为时钟。改变出块时间，会破坏建立在这个时钟基础上的智能合约系统。

更具挑战性的是，BCH支持P2SH脚本，这意味着我们并不了解所有和已挖出的币有关联的脚本。解析整个区块链数据并且设计一种适用于所有现存脚本的系统是不可能做到的，因此我们被迫设计一种适用于所有可能已写入合约的系统。不确定能否在没有严重缺陷的情况下实现，但是可以确定的是没人有时间/资源来进行真正的尝试。

如果这个问题没有解决办法，我们就不会有一个具体的方案用来讨论改变出块时间。

结论

改变出块时间面临很多挑战，其中一些目前尚未解决。综合考虑缩短区块时间的利弊，尤其是存在更好方案的前提下，花费资源在这些未解决的问题上面似乎不是正确的方向。

根据目前的路线图，我们预计可以在2年内实现avalanche。但是，如果资源允许，我们希望尽快完成。毕竟，Avalabs已经有了一个确实可用的实现。所以，没有理由预期avalanche永远“还有18个月”去完成。（备注: 18个月的梗来自于比特币的闪电网络项目）

原文:

【后记】

文章翻译完了，总的来说，Amaury还是考虑要“顾全大局”，避免因为缩短时间对BCH系统造成损害。

但是就我个人看来，这其实是因小失大。目前BCH的用户绝大多数来自于交易所，而缩短出块时间就是为了服务这个最大的用户群体。如果无法让绝大多数用户获得良好的用户体验，而是去照顾那些没几个人使用的智能合约，如何发展壮大？自己先把自己束缚住了，未来服务于几十亿人也只能停留在口号层面，失去了实际意义。

彷佛回到了几年前，当时BTC的开发者一定要反对大区块，坚决走闪电网络的路线；而现在BCH开发者又坚持要进行avalanche的开发，反对缩短出块时间。明明两者可以并存的，非要二选一，真是令人无语。