Stale Rate

矿池是一项向矿工分配工作的服务。网络找到新区块后，矿工通常需要转而在新区块之上继续构建。按先前任务算出的结果，已不适用于新的工作。矿机通信协议 Stratum V2 用 SetNewPrevHash 消息处理这一变化：设备开始寻找接在新指定区块之后的区块。之前准备的任务中，只有任务标识 job_id 指定的那个仍然有效。因此，Petra 排查时要看任务是否仍然有效，不能只看结果发送的时间。 [1]

用一个简单例子来看：Petra 提交了 100 个难度相同的结果，矿池接受 98 个，因 stale 拒绝 1 个，又因其他原因拒绝 1 个。被拒绝的 stale 结果占 1%，全部拒绝结果则占 2%。F2Pool 将全部被拒绝的提交占全部提交的比例称为 rejection rate。在这个例子中，stale 只是其中一部分。这些数字用于解释算法，不代表可接受的运行阈值；分类不同，面板上百分比的意义也可能不同。 [2]

Share 难度决定了设备提交的计算结果需要满足多严格的条件。Braiins 把难度为 d 的结果计为 d 个基本工作单位。假设有一个难度为 1 的 stale share，以及一个难度为 9 的已接受 share。按提交次数计算，比例是 50%；按工作权重计算，则是 10%。两种算法本身都没有错，只是在回答不同问题。因此，Petra 比较时要让分子和分母使用相同单位，也要确认采用了相同的难度计算约定。 [3]

F2Pool 的文档区分了有报酬的 Staled 类别和没有报酬的被拒绝 stale shares。因此，标签本身不能说明 Petra 是否损失了钱。这项政策不能套用到每个矿池；需要看具体服务的规则和实际结算。比较服务商时，Petra 先确认结果属于哪一类别，然后才能估计它们对收入的影响。 [2]

阅读运行日志时，很容易忽略一个细节：Stratum V2 允许一条 SubmitShares.Success 消息确认多次提交。new_submits_accepted_count 表示这批新确认的提交数量，new_shares_sum 则累计这些结果的难度。因此，服务器回复次数不等于已接受 shares 的数量。发生拒绝时，SubmitShares.Error 包含标识提交的 sequence_number 和说明错误原因的 error_code。若不作区分，Petra 就可能把每种错误都误认为工作来迟了。 [1]

新区块的消息首先要在验证 Bitcoin 的计算机之间传播。BIP152 描述了 Compact Block Relay：在 P2P 网络中，也就是直接连接的节点之间，以更少的数据传输区块。数据量减少，可能缩短传输延迟。但这是区块传播机制，不是矿池对 shares 的记账方法。因此，未留在主链中的区块比例，并不能用来衡量 Petra 矿机提交结果的过时比例。 [4]

Braiins 提供不同时间窗口的工作统计：shares_5m (最近5分钟)、shares_60m (最近60分钟) 和 shares_24h (最近24小时)。Petra 不能把一个短时段里的过时结果除以全天工作量，再拿这个数与另一台矿机的一小时统计比较。分子和分母必须覆盖同一时段、同一组设备。如果没有观察到任何提交，这个比例就没有定义，并不是测得损失为 0%。监控数据中断或缺少回复，也不能单独证明某个结果是 stale。 [5]

Petra先查看同一时期的任务变化、拒绝原因和连接状况。F2Pool将stale结果与网络条件联系起来。其他拒绝可能源于固件，也就是矿机控制软件的错误，或过度超频。超频是提高芯片的工作频率，试图让它完成更多计算。Braiins建议用ping做一个简单检查：服务器是否会回应网络探测。收到回应并不表示挖矿过程正确，也不能证明报酬已经入账。总体百分比降低，不足以证明原因已消除。关键是弄清变化发生在哪里，并在可比条件下跟踪具体错误。 [2] [6]