显微镜下的比特币挖矿

链上分析还包括考虑比特币挖掘。你如何去做？本文的目的是展示如何使用R通过采矿生态系统获得一些信息。

比特币挖矿以及整个节点构成了比特币的骨干。没有矿工，没有新的区块，没有完整的节点，没有区块链。简而言之，矿工的任务是找到满足当前难度要求的区块。矿工将未确认的新交易分组。它们与时间戳，最后一个块的校验和以及称为Nonce的计数器变量一起形成新的校验和。这也称为哈希。如果此哈希值具有由难度定义的零，则矿工已找到有效的块。该块与节点网络共享。

如果您想进一步了解该主题，请参考我们的学院或有关工作证明主题的播客。今天，我们想仔细看看计数器变量或随机数。我们应按照“成为自己的分析师”的座右铭更详细地说明我们如何做到这一点。

Nonce：ASIC Boost或矿工类型的指纹？

乍一看，您可能会认为现时是一个简单的计数变量。但是，如果所有矿工从一个随机数开始计数，则最好与完整节点连接的矿工将始终获胜。互联网连接较差的矿工将没有机会。此外，如果每个人都使用相同的随机数，那么所有矿工的总哈希率（所有人都计算相同的块）将不值多少。

因此，出于某些原因，您应该将随机数视为矿工。但是还有更多的事情要发生：去年，BitMex Research和CoinMetrics报告了随机数分布异常。据发现，在2017年至2019年之间，几乎没有发现带有某些随机数的区块。他们引用了PlanB的推文：

556995块仍然存在奇怪的#bitcoin nonce模式…
我希望随机数是完全随机的，例如100000-400000。但是自从第400000块以来，有4个区域的随机数较少。当然，在100000区块之前，是Satoshi在玩。 pic.twitter.com/XsIRhDXXAq

-PlanB（@ 100trillionUSD）2019年1月4日

直到2019年初，开发工作量如此之大。BitMEX和最初的CoinMetrics的理论认为，这些模式将源于所谓的ASIC Boost的挖掘。就像老人们记得的那样，ASIC-Boost是引入隔离证人的动机之一。在2020年4月开始的时事通讯中，CoinMetrics更正了评估，并怀疑这些异常可能来自Bitmain采矿系列S9。这个ASIC矿机系列现在即将结束，并逐渐被S17s取代。

我们现在要研究的问题是：您还能看到上面的模式吗？在此过程中还有其他有趣的发现吗？让我们看一下上个月的数据块。

区块搜寻：我们如何获得有趣的区块数据？

如果我们要仔细看一下3月31日至4月29日之间的区块，我们必须清楚一件事：我们正在寻找4,000多个区块。不幸的是，仅用一个API调用（如本系列的旧版本中那样）是不够的；我们不必自己获取原始块，但可以下载单个块的元数据。

但是有些解决方案并不包含下载整个区块链。 BTC.com API可以在这里提供宝贵的服务。使用以下形式的API调用：[Blockh?he] 用数字代替）

https://chain.api.btc.com/v3/block/[Blockh?he]

可用于获取有关单个块的不同信息。通过更多的代码工作以及为简单起见的for循环，我们可以在一定时间内保存块信息。我们这样做如下。第一步，我们加载已使用的库（tidyverse和jsonlite），并准备加载哪些块：

图书馆（tidyverse）
库（jsonlite）

今天<-Sys.Date（） dataset_btc <-NULL stop_size_btc_raw <-fromJSON（'https://chain.api.btc.com/v3/block/latest'） stop_size_btc <-as.numeric（stop_size_btc_raw $ data $ height） start_size_btc <-stop_size_btc-（31 * 144）-1 range_btc <-start_size_btc：stop_size_btc

通过简单的计算得出的结果有些晦涩难懂：31 * 144：比特币矿工每天平均发现144个块，因此每月大约有31 * 144个块。

基于此，我们现在可以在表中存储我们感兴趣的数据，如上所述，我们使用for循环进行此操作，该循环使用API??调用来查找每个块的信息。

为了不淹没API和不触发任何错误，我们暂停了半秒钟，然后再次运行循环。然后将以这种方式收集的数据保存在一个csv文件中：

对于（i in 1：（31 * 144 + 2））{
??tryCatch（{
????print（paste0（“ Blocks：BTC at”，range_btc[i]））
????block_btc_raw <-paste0（'https://chain.api.btc.com/v3/block/',range_btc[i]） ????block_btc <-fromJSON（block_btc_raw） ????row_btc <-NULL ????row_btc $高度<-range_btc[i] row_btc $ size_mb <-block_btc $ data $ size / 1024/1024 ????row_btc $ n_tx <-block_btc $数据$ tx_count ????row_btc $当<-as.POSIXct时（block_btc $ data $时间戳，原点=“ 1970-01-01”） ????row_btc $随机数<-block_btc $数据$随机数 ????row_btc $费用<-block_btc $数据$ reward_fees ????row_btc $池<-block_btc $数据$临时演员[["pool_name"]]row_btc $增量<-0 ????dataset_btc <-rbind（dataset_btc，as.data.frame（row_btc）） ????dataset_btc $ delta <-c（0，尾（dataset_btc $ when，-1）- ???????头（dataset_btc $ when，-1）） ???? ??}，错误=函数（e）{ ????打印（“错误”） ??}） ??Sys.sleep（0.5） } write.csv（dataset_btc，粘贴（“ BTC _”，Sys.Date（），“。csv”，sep =“”））

包括tryCatch（{…}，错误= …）作为辅助，因此该代码不会由于错误而立即中断。如果有疾病，我们将至少获得部分数据。毕竟，这很重要，要花费几个小时才能运行上面的代码。您可以在家用计算机上执行此操作并让其在此期间运行，或者您可以放心在RStudio Cloud上开设一个帐户。无论哪种方式：时间不只是喝咖啡。

顺便说一下：与我们保存的API相比，该API提供的块信息要多得多。使用fromJSON（paste0（’https://chain.api.btc.com/v3/block/'[Blockh?he]））远远超过此处列出的数据（从而 [Blockh?he] 将被相应的数字代替）。它们为JSON格式。

数据驱动的比特币挖掘

因此，喝咖啡，喝醉的Netflix系列电视节目非常困难，我们想到了一本很棒的自我完善书，这是我们绝对想要阅读的书，因此上面的代码应该已经准备好了。确实：是的。

是时候仔细看一下数据了。我们将使用上述代码创建的csv文件加载到名为“ data”的文件夹中，并将csv文件读入名为“ data”的变量中：

图书馆（tidyverse）
库（润滑）
数据<-read_csv（“数据/ BTC_2020-04-29.csv”）

在深入探讨随机数之前，让我们看一下不同池的性能。我们专注于发现100多个区块的矿池。我们在“未知”下总结所有其他内容。我们还将“大型池”保存在“ large_pools”变量中：

大池 ％group_by（pool）％>％汇总（n = n（））％>％
??排列（desc（n））％>％变异（pool = ifelse（n> 100，池，“未知”））％>％
??group_by（池）％>％汇总（n =总和（n））％>％排列（desc（n））％>％
??变异（池=因子（池，水平=池））

large_pools％>％ggplot（aes（pool，100 * n / sum（n），fill = pool））+
??geom_col（show.legend = F）+
??实验室（x =“”，y =“找到的百分比百分比”）+
??theme_minimal（）+主题（axis.text.x = element_text（角度= 45，高度= 1））

如我们所见，由于这些其他池几乎不会对哈希率产生任何影响，因此我们主要关注较大的池。

随机数如何分布在这些块中？不管池是多少，可以看出，具有高随机数的区块在比特币区块链中比具有低随机数的区块少见：

数据％>％ggplot（aes（nonce / 10 ^ 9））+
??geom_histogram（填充=“＃FFA838”，col =“＃555555”，箱= 100）+
??实验室（x =“ Nonce / billion”，y =“ hit”）+ theme_minimal（）

到目前为止，“简单计数”的论断将得到确认：由于低位随机数开始并且仅在找到一个块之前才改变随机数，因此可以预期会有适当的行为。

但是，如果我们查看不同的池，我们也会看到不同的模式。我们专注于九个最大的池：

`％nin％` <- Negate(`%in%`) daten %>％筛选器（pool％nin％small_pools $ pool）％>％
??ggplot（aes（nonce / 10 ^ 9，fill = factor（pool，level =
????large_pools $池[large_pools$pool!=”Unbekannt”]）））+
??geom_histogram（show.legend = F，bins = 100）+
??facet_wrap（factor（pool，level =
????large_pools $池[large_pools$pool!=”Unbekannt”]）?。，scales =“ free_y”）+
??实验室（x =“ Nonce / billion”，y =“ hit”）+ theme_minimal（）

F2 Pool，OKExPool和HuobiPool等一些矿池证实了正在考虑的趋势。但是，像Poolin，BTC.com和Antpool这样的其他公司并没有表现出这种下降。

但是，我们也看到结构，尤其是F2Pool和AntPool的结构，使人联想到上面提到的PlanB结果。我们发现随机数减少了约10亿和25亿。这些图像比PlanB的噪声更大，但这也与硬币计量学的解释相吻合：S9矿工正在从比特币的矿池中逐渐消失。

看看较小的比特币矿池

只是为了避免完全忽略较小的矿池：我们以与以前类似的方式进行操作，查看这些较小的矿池，并将其保存在名为“ small_pools”的变量下。我们看到：即使其中最大的BTC.TOP在四月份也没有找到百分之二的区块。

小水池 ％group_by（池）％>％
??总结（n = n（））％>％排列（desc（n））％>％
??过滤器（n<100) small_pools %>变异百分比（池= ifelse（池==“未知”，“其他”，池））％>％
??变异（池=因子（池，水平=池））％>％
??ggplot（aes（pool，100 * n / 4466，fill = pool））+ geom_col（show.legend = F）+
??实验室（x =“”，y =“找到的百分比百分比”）+ theme_minimal（）+
??主题（axis.text.x = element_text（角度= 45，高度= 1））

现在，很有趣的是，您是否可以就随机数分布对这些小池说些什么特别的话。由于单个小型比特币矿工的统计数据非常低，因此我们不区分单个矿池。汇总后的结果也很清醒：

data％>％过滤器（pool％in％small_pools $ pool）％>％ggplot（aes（nonce / 10 ^ 9））+
??geom_histogram（show.legend = F，bins = 100）+
??实验室（x =“ Nonce / billions”，y =“ hits”）+
??theme_minimal（）

稍加想象，仍然可以发现上述行为的伪像，但距离实际上并不远。看来，Antpool尤其是F2pool仍有一些S9股票。无论如何，基于此分析和Coinmetrics的解释，这将是一个合适的结论。

只是旅程的开始

我们下载了许多有关比特币的数据-但只查看了随机数和池。当然，您可以使用此数据做更多的事情。区块中的交易数量和区块时间之间是否有联系？

数据％>％变异（n_tx =舍入（log（n_tx）/ log（10），0））％>％
??ggplot（Aes（delta，fill = as.character（n_tx）））+
??geom_histogram（bins = 40）+
??facet_grid（as.character（n_tx）?。，scales =“ free_y”）+
??实验（x =“ block time / s”，y =“ blocks”，fill =“ log（交易）”）+
??theme_minimal（）

一个人可能对此争论不休。在上图中，我们显示了您需要等待多长时间。我们区分交易少于十个，交易少于一百个，交易少于一千个，交易少于一万个的区块和交易更多的区块。我们看到，至少基于这些统计数据，具有大量事务的数据块趋向于变慢，而这些统计数据肯定不是很大。

由于比特币中的较大块需要更高的随机数，而块组装和（如果需要）传播需要更长的时间，这将较少。

这只是查看哈希率分布或随机数下一步要做的另一个示例。根据座右铭“做自己的分析师”，您现在可以接管。

—-

原文链接：https://www.btc-echo.de/bitcoin-mining-unter-der-lupe/

原文作者：globalcryptopress

编译者/作者：wanbizu AI

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。