挖矿算力38

Ⅰ M1 MAX挖矿性能怎么样

不行。

ethash计算一次需要读取8192字节的数据。M1的带宽是68.25GBps，也就是理论最大算力为68.25GB/S ÷ 8.192KB = 8.3M/S。实测2M多，估计往死里优化可以优化到4，5M这个水平吧。为什么没人做呢？理论最大值只有8M，还没法超频，价值不大。

简介

这次的M1 MAX高达400GBps，理论最大算力400GB/S ÷ 8.192KB = 48.8M/S。估计实际算力在25到30M左右，大致相当于588。

往死里优化可以达到38到43M这个水平，大致相当于不超频的6700或者不超频不锁算力的3060。只不过功耗低得多，可能50w上下。考虑到一台M1 MAX至少2万多，挖矿必然不是一个很好的选择。

Ⅱ 比特币挖矿的难度和算力

难度是对挖矿困难程度的度量，即指：计算符合给定目标的一个HASH值的困难程度。

difficulty = difficulty_1_target / current_target

difficulty_1_target 的长度为256bit， 前32位为0， 后面全部为1 ，一般显示为HASH值：， difficulty_1_target 表示btc网络最初的目标HASH。 current_target 是当前块的目标HASH，先经过压缩然后存储在区块中，区块的HASH值必须小于给定的目标HASH, 区块才成立。

例如：如果区块中存储的压缩目标HASH为 0x1b0404cb , 那么未经压缩的十六进制HASH为

所以，目标HASH为0x1b0404cb时， 难度为：

比特币的挖矿的过程其实是通过随机的hash碰撞，找到一个解 nonce ，使得 块hash 小于 目标HASH 值。 而一个矿机每秒钟能做多少次hash碰撞， 就是其“算力”的代表， 单位写成 hash/s 或者 H/s

算力单位：

比特币系统的难度是动态调整的， 每挖 2016 个块便会做出一次调整， 调整的依据是前面2016个块的出块时间， 如果前一个周期平均出块时间小于10分钟，便会加大难度， 大于10分钟，则减小难度，目的是为了保证系统稳定的每过 10分钟 产出一个块，所以难度调整的时间大概是2周（2016 * 10 分钟）

全网算力是btc网络中参与竞争挖矿的所有矿机的算力总和。当前难度周期全网算力会影响下一个周期的难度调整， 如果全网算力增加，挖矿难度增大，单台矿机固定时间的产出就会减少。目前全网算力大概是24.42EH/s， 一台蚂蚁S9矿机的算力大概是14TH/s

那么， 已知当前全网算力，下一个周期难度将如何调整呢？

根据公式：

因为出块时间要稳定在10分钟， 也就是600s:

那么，在3.46e+12的难度下， 一台算力为14TH/s的矿机平均要花多长时间才能出一个块呢？

根据公式：

有：

结果大概是12270天

Ⅲ 一文了解以太坊挖矿算法及算力规模2020-09-09

以太坊网络中，想要获得以太坊，也要通过挖矿来实现。当前以太坊也是采用POW共识机制，但是与比特币的POW挖矿有点不一样，以太坊挖矿难度是可以调节的。以太坊系统有一个特殊的公式用来计算之后的每个块的难度。如果某个区块比前一个区块验证的更快，以太坊协议就会增加区块的难度。通过调整区块难度，就可以调整验证区块所需的时间。

以太坊采用的是Ethash 加密算法，在挖矿的过程中，需要读取内存并存储 DAG 文件。由于每一次读取内寸的带宽都是有限的，而现有的计算机技术又很难在这个问题上有质的突破，所以无论如何提高计算机的运算效率，内存读取效率仍然不会有很大的改观。因此，从某种意义上来说，以太坊的Ethash加密算法具有“抗ASIC性”。

加密算法的不同，导致了比特币和以太坊的挖矿设备、算力规模差异很大。

目前，比特币挖矿设备主要是专业化程度非常高的ASIC 矿机，单台矿机的算力最高达到了 112T/s（神马M30S++矿机），全网算力的规模达到139.92EH/s。

以太坊的挖矿设备主要是显卡矿机和定制GPU矿机，专业化的ASIC矿机非常少，一方面是因为以太坊挖矿算法的“抗 ASIC 性”提高了研发ASIC矿机的门槛，另一方面是因为以太坊升级到2.0之后共识机制会转型为PoS，矿机无法继续挖。

和ASIC矿机相比，显卡矿机在算力上相差了2个量级。目前，主流的显卡矿机（8卡）算力约为420MH/s，比较领先的定制GPU矿机算力约在500M~750M，以太坊全网算力约为235.39TH/s。

从过去两年的时间维度上看，以太坊的全网算力增长相对缓慢。

以太坊协议规定，难度的动态调整方式是使全网创建新区块的时间间隔为15秒，网络用15秒时间创建区块链，这样一来，因为时间太快，系统的同步性就大大提升，恶意参与者很难在如此短的时间发动51%（也就是半数以上）的算力去修改历史数据。