ASIC硬件错误与拒绝份额:你遇到的究竟是哪种问题?
2026-10-27 16:12

许多矿工看到状态页面上的红色计数、矿池报告的算力下降,或拒绝率上升,就断定某台 ASIC 已经出现故障。然而,这些信号来自挖矿流程中不同的层级,将它们互换使用会导致误判。硬件错误是矿机自身报告的证据。被拒绝的份额则是矿池做出的判定。两者只在部分情况下存在关联。

本文将矿机侧遥测数据与矿池侧份额验证区分开来,说明每一类数据能够证明什么、不能证明什么,并给出一套从正确层级开始排查问题的流程:硬件、固件或调参、本地网络,或矿池连接。

同一挖矿流程中的两个不同层级

一个挖矿任务在被计为已接受的工作量之前,需要经过几个不同的阶段。ASIC 从矿池接收任务,并开始在本地进行哈希计算。其固件会追踪本地状态——芯片数量、板温、风扇转速、本地算力,以及内部硬件错误计数器。随后,矿机会通过 Stratum 连接向矿池提交候选解,即所谓的"份额"(share)。矿池会根据其下发的任务和分配的难度目标,对每一个提交的份额进行验证,然后返回"接受"或"拒绝"的响应,若被拒绝,还会附带拒绝原因。

前两个阶段只能由矿机观察到。后两个阶段只能由矿池观察到。源自某一阶段的故障,并不会自动在另一阶段产生对应的症状。

ASIC 硬件错误实际能说明什么

硬件错误(HW)计数器属于矿机侧遥测数据,通常显示在 ASIC 自身的状态页面或固件界面上。根据比特大陆(Bitmain)对其矿机状态页面的说明文档,在芯片满负荷运行期间,出现一定数量的 HW 错误是可能发生的,矿机可能会在内部自行纠正这些错误,并不中断地继续进行哈希计算(Bitmain 支持页面)。因此,单凭一个非零的 HW 计数值,并不能确凿证明矿机已经发生故障,也不能证明矿池正在拒绝等量的份额。

当 HW 计数值上升与其他信号同时出现时,就更值得密切关注,例如:

  • 同一块板卡或同一台矿机上的本地算力下降;
  • 检测到的芯片数量减少,或出现 ASIC 状态故障指示;
  • 某个算力板缺失或输出为零;
  • 日志中出现过热保护事件或风扇/电源(PSU)故障消息;
  • 反复出现意外重启;
  • 在最近一次调整频率或电压之后,无效份额拒绝率上升。

上述任何一种情况,都没有确立一个适用于所有型号或固件版本的固定"正常"HW 错误计数值,本文也不会给出这样一个数值。更有意义的比较对象,是该设备自身近期的基准水平,而不是某个假定的行业数值。

被拒绝的份额实际能说明什么

被拒绝的份额是一个统称类别,涵盖矿池不予接受的任何提交。具体的拒绝原因比总计数更重要,因为每一种原因都指向系统中不同的部分。

如果矿池报告主要是…… 首先检查……
过期份额(Stale shares) 矿池接入点、延迟、丢包、路由、重连行为、本地网络
无效份额(Invalid shares) 温度、频率/电压设置、固件、供电、算力板状态
低难度份额(Low-difficulty shares) 矿池配置、固件或代理兼容性、调参稳定性
重复份额(Duplicate shares) 矿机软件、代理行为、重试机制、矿工/会话配置
授权或订阅错误 Stratum网址、端口、矿工名称、账户凭证

过期份额(stale share)是指原本对某个任务有效、但矿池已经将该任务替换掉的份额——通常是因为当前的区块链顶端发生了变化,或者是因为矿机的连接延迟导致新任务的下发或解答的回传被拖慢。过期份额并不能证明存在硬件故障;它反映的是矿机与矿池之间连接的时序问题。

无效份额(invalid share)是指未能通过矿池针对其所下发的任务和目标难度所做验证检查的提交。在所有拒绝类别中,这一类最有可能与不稳定或配置不当的 ASIC 相关联。

重复份额(duplicate)和低难度(low-difficulty)拒绝,指向的更可能是矿机软件、代理或配置方面的行为,而非芯片层面的损坏。尤其是重复份额拒绝,并不一定代表新产生了工作量损失,因为原始提交很可能已经被接受。

硬件不稳定何时会导致拒绝份额\n不稳定的 ASIC 可能会产生无效运算或格式错误的提交,而这正是硬件状态与矿池端拒绝之间存在实质关联的唯一领域。激进的频率或电压设置、芯片温度过高、供电裕量不足、电路板损坏以及固件不兼容,这些情况都可能首先在硬件遥测数据中显现,随后又与无效份额拒绝率的上升同时出现。\n\n就诊断目的而言,这种关联只是单向的:硬件错误的存在使得对无效份额进行排查变得有意义,但这并不能证明同一时期内过期份额(stale shares)的同步上升是由硬件引起的。即使过期份额和无效份额出现在同一时间段内,也应分别加以排查。\n\n## 拒绝份额并非硬件问题的情形\n过期份额是最典型的一类拒绝份额,通常与芯片健康状况无关。当比特币网络产生新区块时,此前的挖矿任务即告过时,矿池会根据新的链尖分发最新的工作任务,以便矿工继续朝着有效目标进行计算(比特币开发者指南,挖矿部分)。如果矿工的网络连接延迟接收到该更新任务,或者其提交的解在矿池已经切换到新任务之后才送达,矿池就会将这一本来有效的工作量证明判定为过期份额而拒绝。\n\n这种情况可能在同一时间影响同一场地中多台本身状况良好的矿机,这是一个有用的诊断线索:硬件故障通常只局限于单台设备,而共享的网络链路、矿池接入点或路由问题则可能同时拉高多台矿机的过期份额计数。ViaBTC 关于降低过期份额的指导意见指出,应重点排查矿池接入点选择和网络路由问题,而非芯片状态,这才是针对此类拒绝的主要排查方向(ViaBTC)。\n\n## 本地算力与矿池报告算力的比较\n本地 ASIC 算力与矿池报告算力的计算方式不同,不应将二者视为同一数值进行比较。ASIC 使用固件定义的逻辑以及并非在各型号间统一的平均周期来报告自身的运行情况。而矿池则是根据其在自身报告窗口期内收到的份额来估算算力。\n\nViaBTC 的文档说明,其实时算力数据基于前 10 分钟的数据计算,而其日算力数据则基于前 24 小时的数据计算(ViaBTC)。如果一台矿机在该窗口期内曾重启、重新连接,或出现短暂的拒绝率激增,即便其当前的本地算力已恢复正常,矿池估算出的数值仍可能偏低。在断定数值不匹配反映了硬件问题之前,应先确认这两个数值所对应的时间窗口是否可比,以及该时间段内是否包含重启、停机或近期的接入点变更。\n\n## 审慎使用的拒绝率计算方法\n当矿池针对同一定义周期显示已接受和已拒绝的份额数量时,可按以下方式计算原始拒绝率:\n\n原始拒绝率 = 已拒绝份额数 ÷(已接受份额数 + 已拒绝份额数)× 100\n\n这是一个基于份额计数的诊断性数值,而非标准的盈利能力指标。只有当已接受和已拒绝的总数覆盖相同的时间段及可比类别时,该计算才有意义,并且该方法假定所统计份额的难度相同;如果份额难度存在差异,原始计数就无法准确反映与按难度加权计算结果相同比例的底层工作量。不应将拒绝率直接换算为假定的 BTC 收益损失百分比,因为支付方式、拒绝类型以及会计处理方式都会以不同方式影响最终结果。

实用故障排查流程

  1. 在对总拒绝率做出反应之前,先查看矿池给出的具体拒绝原因。
  2. 确定影响范围:是单台矿机、单个机架,还是整个矿场受到影响。
  3. 查看矿机自身的状态页面和日志,了解芯片数量、板卡状态、温度、风扇转速、电源(PSU)信息以及近期的重启记录。
  4. 检查最近有哪些变动——固件更新、频率或电压调整、散热维护、网络变更,或是新的矿池接入点。
  5. 对于过期份额(stale shares),先从连接性入手:确认矿池当前官方公布的接入点,并比较相同的运行时间段,然后再假定是硬件原因。
  6. 对于无效份额(invalid shares),检查散热、供电、固件版本以及近期的调优改动;在适当情况下,回退到此前稳定的配置有助于锁定变量。
  7. 对于芯片缺失、板卡缺失、持续的热保护关机或电源故障,应按照制造商提供的诊断和维修流程处理,而不要将其当作连接问题来对待。

结论

硬件错误是矿机自身报告的证据,而拒绝份额则是矿池做出的判定。二者可能源于同一根本原因,但往往并非如此,若用同一套排查清单来诊断,就会造成无谓的精力浪费——比如为了一个路由问题去刷写固件,或者为一块出故障的算力板去排查网络问题。拒绝原因、矿机自身的日志,以及匹配一致的测量时间窗口,三者结合在一起,才能比孤立地看任何单一指标提供更可靠的诊断依据。

常见问题

硬件错误(HW-error)计数很高,是否意味着我的ASIC正在出故障?

不一定。部分硬件错误可能在正常满负荷运行期间发生,并可由矿机自行纠正,不影响持续挖矿。如果计数不断上升,同时伴随算力下降、板卡缺失或温度报警,则需要进一步检查;仅凭计数本身并不能确认硬件故障。

过期份额(stale shares)是否意味着硬件损坏?

通常不是。过期份额是针对矿池已经替换掉的任务所提交的一份有效工作量证明,通常是由网络延迟、丢包或任务下发延迟造成的,而非芯片层面的故障。

为什么矿池报告的算力与我本地统计的算力不一致?

这两个数值采用不同的测量方式和时间窗口。本地算力反映的是ASIC自身固件读取的数据;矿池报告的算力则是在矿池所声明的统计周期内,基于份额提交情况估算得出的。在重启或重新连接之后出现的暂时性差异,并不能单独说明存在硬件问题。

拒绝率能否告诉我损失了多少BTC收益?

不能直接得出。原始的拒绝率只是一个基于计数的诊断指标,它假定各份额难度相同且统计周期一致;若不考虑拒绝类型、支付方式以及份额难度的差异,它并不能换算出准确的收益数字。

调优改动之后无效份额增多,应该先检查什么?

应检查芯片温度、频率和电压设置、供电情况以及固件兼容性,并考虑先回退到最近一次已知稳定的配置,再测试进一步的改动。

参考资料