BTC出块时间出现差异：理论与实际对比
BTC区块时间戳历史分布情况究竟有多符合预期？
本周，我收到了一些消息提醒，这些提醒都是关于一个时不时会出现的问题：
“BTC区块链两个小时都不能挖到一个块的情况多久会出现一次呢？昨晚，我偶然发现了在区块670637和638之间出现了这个状况。”
这让我陷入了思考，我不禁想到在过去12年中，BTC区块时间戳历史分布情况究竟有多符合预期？
我之前也对BTC时间戳机制进行过讨论，有充分理由认为BTC的安全性很高，其时间戳背后的博弈论机制也非常完美。
幸运的是，你如果有一个节点的话，就能很轻松地循环访问所有BTC区块头，查看它们的时间戳。为此，我写了个脚本，我的笔记本电脑只用了5分钟就查看了所有的时间戳。
研究人员发现比特币闪电网络漏洞，或致750枚BTC被盗:8月12日消息，伊利诺伊大学的研究人员发现了比特币闪电网络的漏洞，可能导致750枚BTC（约1800万美元）被盗。
两位研究人员Cosimo Sguanci和Anastasios Sidiropoulos发表了一篇论文，用一个假设的情况解释了Layer 2网络中的漏洞，即恶意节点可以合谋进行攻击：“一个只有30个节点的联盟可以通过僵尸攻击锁定31%通道的资金约2个月，并可以通过大规模的双花攻击窃取超过750枚比特币。”
根据这篇论文，僵尸攻击是一种破坏行为，它会阻塞网络，使闪电网络无法使用。研究人员指出，防御这种攻击的唯一方法是让诚实节点关闭它们的通道，并返回到比特币Layer 1网络，但这将花费大量的交易费用。（Crypto Slate）[2022/8/12 12:22:05]
请注意，为了方便测量数据，BTC区块链中第100个区块之前都被我排除了，因为BTC诞生之初，矿工数量很少，发生了一些很特殊的状况。
安全研究人员：勒索软件“CovidLock”利用新冠病恐慌勒索比特币:金色财经消息，网络安全威胁研究人员DomainTools已经确认了名为coronavirusapp网站。网站方便安装一个新的勒索软件称为“CovidLock”。 该网站提示其访问者安装一个据称可以跟踪新冠病传播的Android应用程序，声称当一个感染了冠状病的个体在其附近时，它会使用heatmap图像来通知用户。尽管该网站显示了来自世界卫生组织和美国疾控中心的认证，但它是“CovidLock”勒索软件的一个渠道，该勒索软件会对不知情的用户发起屏幕锁定攻击。安装完成后，CovidLock会改变被感染设备的锁屏，并要求用户支付价值100美元的BTC，以换取一个可以解锁屏幕并将控制权交还给用户的密码。如果受害者在48小时内不支付赎金，CovidLock就会威胁删除手机中存储的所有文件，包括联系人、图片和视频。DomainTools声称已经对CovidLock的解密密钥进行了反向工程，并补充说他们将公开发布密钥。（Cointelegraph）[2020/3/15]
结果表明，有190个区块在前一个区块出块后106分钟才被挖出，占迄今挖出的67万个区块中的0.0028%，非常接近0.0025%的预期值！这个结果很容易通过计算得出，但只能代表某个特定时间段内出块时间的差值分布情况。
爱尔兰大学研究人员呼吁政府推动区块链发展:据cointelegraph消息，《爱尔兰时报》近日报道，称爱尔兰国立高威大学（NUI Galway）研究区块链的学者呼吁政府在爱尔兰更加广泛地推广区块链技术。
该大学研究人员通过研究提出了增加区块链认知度和采用度的建议，认为这可以对经济增长产生积极影响，并为政府和爱尔兰组织开展业务奠定基础。
研究名为《在爱尔兰采用区块链：审查组织因素的影响》，由NUI Galway与爱尔兰区块链协会合作进行，研究调查了影响爱尔兰公司采用区块链决策的因素。
研究结果显示，爱尔兰只有40％的企业采用了区块链技术，利用率相对较低。[2018/5/15]
深层次分析
如果要对这个问题进行深入思考，Felix?Weiss已经解决了这个问题，他提供了一种方法，能够确定在前一个区块挖出后的特定时间段内应该挖出的区块数量。
这个数量能够通过计算指数分布的累积分布函数得出。
但就出块时间的差值而言，怎样才能其整个历史分布状况与预期分布进行对比呢？为了解决这个问题，我们需要利用指数分布的概率密度函数，这个函数可以通过f(x;λ)=?λe^-(λx)进行建模。针对出块时间问题，x等于上个区块出块后的某个时间点，λ作为率参数，等于1/600，概率密度函数用线性方式表示如下图：
我在写这篇文章的同时也绘制出了670000区块之后所有区块的预期分布状况，与上图的形状很相似。
于是我收集了脚本的数据，并将其放入了以下这个表格中：
显而易见的是，下图的x轴用对数表示更加合理，否则数据会过于分散，而观察不到一些有趣的现象。
不同挖矿时期
出块时间的预期分布是基于哈希率恒定不变的假设。但根据BTC的发展历史，其哈希率不可能是恒定不变的。
所以我选取了三个时期进行分析。
1.?CPU时代：哈希率相对平稳。
2.?GPU时代：哈希率加速上升。
ASIC时代：哈希率增速相对较缓
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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。