Share Difficulty

挖矿会产生哈希，也就是可以当作数字来理解的计算结果。结果要被矿池接受，首先必须不大于设定的目标值。目标值越低，落在这个范围内的结果越少，条件也就越严格。因此，数值目标下降时，Share Difficulty 反而上升。对协议感兴趣的读者还可以了解：Stratum V2 是与矿池通信的一套规则，它通过 SetTarget 消息中的 target 字段传递这个上限。即使不了解消息格式，也能理解核心关系：数值上限越低，矿工越难满足条件。 [1]

假设矿池把佩特拉的难度从 1024 调高到 2048。在算力及换算方式相同的情况下，相同时间内预计只有原来约一半的结果符合要求。机器仍以同样的速度尝试，只是能通过更严格筛选的结果减少了。每次成功之间的间隔仍然是随机的。佩特拉不应期待每个新 share 都恰好要等原来两倍的时间。 [2]

如果只数消息条数，矿池就会把不同的工作证明混为一谈。因此，Braiins 用按难度折算的工作单位解释其记账方式。两个难度为 1024 的已接受结果，合计权重等于一个难度为 2048 的已接受结果。所以消息少了，并不能证明贡献更少。佩特拉也不能把这个记账权重当成机器实际执行计算次数的精确记录：它只是工作的统计证明。具体获得多少报酬，还取决于矿池的规则。 [3]

更改 Share Difficulty 本身不会让 ASIC，也就是矿机中的专用芯片，运行得更快，也不会改变 Bitcoin 区块的网络目标。在独立尝试次数和网络难度相同的情况下，找到区块的概率保持不变。矿池只是在调整它希望持续收到哪些结果。因此，降低 share 难度并不会让 Bitcoin 区块更容易产生。 [3]

在相同设置下，低算力与高算力机器提交的结果数量会相差很大。VarDiff，也就是自动调整难度的机制，会平衡这种差异，减少不必要的通信。Braiins 还允许矿工设置最低难度。最低值是一条下限，并不等于固定分配值：矿池可以根据算力选择更高的难度。佩特拉把设置与当前显示值进行比较时，首先要确认自己看到的是最低值，还是实际分配的难度。 [2]

软件需要知道一次变更对应哪项工作。按照目前的 Stratum V2 规范，SetTarget 适用于之后收到的任务，以及先前已收到、但 ntime_start 为空的未来任务；该字段为空，表示写入区块头的初始时间戳尚未确定，任务还在等待激活。区块头是概括该区块信息的一小段数据。对于已经收到且 ntime_start 已填写的任务，其目标保持稳定。因此，调查结果为何被拒绝时，不能只把它与最新上限相比，而应找到它所属的正确任务。这通常由挖矿软件处理。 [1]

佩特拉还可能遇到 best share 这个指标。例如，Braiins Solo 用它表示一次挖矿会话中找到的难度最高的 share。分配难度说明什么条件足以让结果被提交，而 best share 则描述实际找到的结果有多罕见。纪录并不是一点点积累起来的出块进度。即使得到格外出色的结果，也不会提高下一次独立尝试的成功概率。 [4]

手动设置的最低难度过高，可能让提交变得非常稀疏，导致估算的算力大幅波动。即使 ASIC 仍在正常工作，监控也可能发出警报。短暂没有 share，并不能单独证明机器故障。佩特拉会结合分配难度、观察时长、已接受的工作量及连接状态来判断。把这些信息放在一起，才能更好地区分普通的随机波动和真正的问题。 [2]