BTC出块时间出现差异：理论与实际对比
BTC区块时间戳历史分布情况究竟有多符合预期？
本周，我收到了一些消息提醒，这些提醒都是关于一个时不时会出现的问题：
“BTC区块链两个小时都不能挖到一个块的情况多久会出现一次呢？昨晚，我偶然发现了在区块670637和638之间出现了这个状况。”
这让我陷入了思考，我不禁想到在过去12年中，BTC区块时间戳历史分布情况究竟有多符合预期？
我之前也对BTC时间戳机制进行过讨论，有充分理由认为BTC的安全性很高，其时间戳背后的博弈论机制也非常完美。
幸运的是，你如果有一个节点的话，就能很轻松地循环访问所有BTC区块头，查看它们的时间戳。为此，我写了个脚本，我的笔记本电脑只用了5分钟就查看了所有的时间戳。
请注意，为了方便测量数据，BTC区块链中第100个区块之前都被我排除了，因为BTC诞生之初，矿工数量很少，发生了一些很特殊的状况。
a16z Crypto推出以太坊轻客户端Helios:11月8日消息，据官网消息，a16z Crypto推出以太坊轻客户端Helios，基于Rust语言进行编写，在两秒钟内同步，不使用存储，并提供对以太坊的无需信任的访问，且其功能与全节点相同。Helios将数据从不受信任的集中式RPC提供程序转换为可验证安全的本地RPC。Helios与集中式RPC一起工作，可以在不运行完整节点的情况下验证其真实性。[2022/11/8 12:30:56]
结果表明，有190个区块在前一个区块出块后106分钟才被挖出，占迄今挖出的67万个区块中的0.0028%，非常接近0.0025%的预期值！这个结果很容易通过计算得出，但只能代表某个特定时间段内出块时间的差值分布情况。
深层次分析
如果要对这个问题进行深入思考，Felix?Weiss已经解决了这个问题，他提供了一种方法，能够确定在前一个区块挖出后的特定时间段内应该挖出的区块数量。
以太坊状态通道方案雷电网络客户端2.0版本正式上线:以太坊状态通道扩容方案雷电网络 Raiden Network 客户端2.0版本Bespin正式上线，已在以太坊上可用。团队提醒v2.x客户端将无法兼容，且无法执行任何早期版本的传输，现有的客户数据库也不会兼容，所有使用旧版本打开的通道需要关闭、结算和重新打开。[2021/6/15 23:38:12]
这个数量能够通过计算指数分布的累积分布函数得出。
但就出块时间的差值而言，怎样才能其整个历史分布状况与预期分布进行对比呢？为了解决这个问题，我们需要利用指数分布的概率密度函数，这个函数可以通过f(x;λ)=?λe^-(λx)进行建模。针对出块时间问题，x等于上个区块出块后的某个时间点，λ作为率参数，等于1/600，概率密度函数用线性方式表示如下图：
我在写这篇文章的同时也绘制出了670000区块之后所有区块的预期分布状况，与上图的形状很相似。
公告 | TRX客户端升级完成:据OKEx公告，TRX客户端升级完成，现已稳定运行，OKEx将于2018年12月25日12:00(HKT)开放TRX的充提，升级期间发生的充值会在升级完成以后自动入账，不用担心资金丢失。[2018/12/25]
于是我收集了脚本的数据，并将其放入了以下这个表格中：
显而易见的是，下图的x轴用对数表示更加合理，否则数据会过于分散，而观察不到一些有趣的现象。
不同挖矿时期
出块时间的预期分布是基于哈希率恒定不变的假设。但根据BTC的发展历史，其哈希率不可能是恒定不变的。
所以我选取了三个时期进行分析。
1.?CPU时代：哈希率相对平稳。
2.?GPU时代：哈希率加速上升。
ASIC时代：哈希率增速相对较缓
金色财经讯:在过去的24小时里, Bitfinex 交易所完成了12.4亿美元的比特币现金交易。[2017/11/13]
CPU时代
在CPU时代，对于出块时间少于10分钟的区块，实际数量比预期少，为什么会出现这种情况呢？我将在下文进行解释。
GPU时代
请注意，在GPU时代，情况截然相反，实际数量比预期要多，最可能是因为哈希率加速上升。
ASIC时代
在早期ASIC时代，BTC哈希率有大幅上升，我特地选取了距离当今较近的时间段，这样数据不会受到很大影响。我们能从上图看出，BTC出块数量仍然多于预期，但是不能够与GPU时代相比。
整个挖矿时代
如果将670000个区块的数据全部绘制成一张图表会是怎么样的呢？根据下图，实际出块时间与预期是非常吻合的，除了图中左边的部分。
根据上图，我们能得知，父区块挖出后29秒内出块的数量远低于预期，对此有没有合理的解释呢？
深入研究
在这个时间戳范围内的预期出块数量为30497。
另一方面，实际出块数量是22441。
那么为什么出块数量会相差8056？
我们发现，14296个区块的增量是负数，其中有3549个属于-29到0的区间范围内，那么剩下还有大约6000个区块，下文将会对这6000个区块进行详细分析。
通过绘制负增量的时间戳分布情况，我们能得出，下图基本上是正增量分布情况的镜像。
这是因为BTC协议允许负时间戳增量的存在，但这不是根本原因，我们要考虑到实际挖矿的工作过程：
1.?矿池会为下一个区块生成区块元。
2.?矿工向矿池发出工作请求，开始对区块元进行哈希计算。
3.?矿工将完成的工作返回给矿池，形成工作量证明。
所以问题就变成了：区块元的产生频率是多少？时间戳多久更新一次？
但是，我认为背后的答案更加复杂，因为矿工也有可能更新时间戳，这就牵涉到了研究特定ASIC应用的硬件或者固件。
上文提到，还剩下大约6000个时间戳增量是负的区块，对这些区块有合理的解释吗？我认为理论上是能够解释的，原因可能是时钟漂移或挖矿软件没有得到很好的适配。如果你了解BTC挖矿历史的话，早期矿工没有组成矿池，都是单独挖矿。所以矿工配置不能达到企业级别，这些业余矿工无法保证矿机数据与权威渠道定期同步。早期矿池都是由业余挖矿爱好者而不是全职专业人士运营。我认为，如果我的理论合理，那么随着挖矿产业逐渐成熟，矿池软件得到改进，时钟漂移出现的频率也在下降。所以我运行了另外一个脚本，按照时间绘制了时间戳增量为负的区块分布情况图。
根据上图，我们能看出，不仅时间戳增量为负的区块数量在减少，时钟漂移问题也逐渐得到改善，值得特别注意的是，自2017年底后，只有少数区块的时间戳增量为负。
总结
BTC大部分运行机制都基于数学原理。通过分析实际出块时间的分布情况，我们能发现，在过去12年中，10分钟出块时间这个机制运行非常良好，只出现过很少的极端情况，背后的原因也很容易找到。挖矿也形成了产业化，挖矿软件得到逐步改善，出块时间分布状况越来越符合预期。
这就是数学的力量！
本文内容来自于：CypherpunkCogitations
来源：金色财经
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。