Kaspa 单人挖矿计算器回答两个不同的问题。第一,给定算力在所选时间段内预计能找到多少个区块?第二,在该预期值下,同一时间段内找到零个区块的概率是多少?这两个问题相关但不可互换,混淆二者是解读单人挖矿估算结果时最常见的错误。期望结果为一个区块并不意味着该时间段内一定会找到区块——它意味着如果相同条件重复多次,长期平均值将收敛于每个时间段一个区块。任何单一时间段仍然受随机因素支配。
本文阐述 Kaspa 单人挖矿计算器背后的概率模型,说明如何在既定假设下计算零区块概率,以此作为零区块奖励风险的估算,并解释如何区分"预期结果"与"保证结果"。文章还直接回应了"如何提升 KAS 挖矿运气"这一相关问题:在此语境下,运气既非一种技能,也不是某种可调设置。它是概率分布的结果,在固定的网络目标下,没有任何择时策略能提高单个哈希值满足该目标的概率。
使用当前网络参数
Kaspa 单人挖矿计算器需要四个输入量:矿工的算力(h)、网络的估计算力(H)、协议的目标出块速率(B),以及评估期的时长(T,以秒为单位)。在进行除法运算前,应先将 h 和 H 换算为相同单位;例如,1 PH/s 等于 1,000 TH/s。在假设算力份额稳定、持续运行且网络状况与目标出块速率一致的前提下,该时间段内的预期区块数为:
μ = (h / H) × B × T
自 Kaspa 的 Crescendo 升级以来,协议的目标出块速率为每秒 10 个区块(即每个区块的目标间隔为 100 毫秒),较此前每秒 1 个区块的设计提升了十倍。这一变更在 Kaspa Improvement Proposal 14(KIP-14)中有明确规定。在 h、H、T 保持不变的情况下,若在该公式中使用 1 BPS 而非 10 BPS,将使预期区块数低估十倍。这同时也会高估零区块概率,但该概率并不会按相同倍数变化。
网络算力(H)并非固定不变的常量。它是基于近期出块时间和网络难度调整得出的滚动估计值,会随着矿工加入、退出或调整产出而持续变化。计算器中输入的算力数值应被视为近期的一个快照,而非稳定的长期数值,由此得出的预期区块数和概率输出,其可靠性也仅取决于该快照的时效性。
预期时间与概率
基于相同输入推导出的预期找到区块的时间为:
预期时间 = H / (h × B)
这是一个长期平均间隔,而非一个截止期限。预期间隔为七天的矿工,并不能可靠地保证每七天就能找到一个区块;某些周可能产生多个区块,而另一些周则可能一无所获。平均值与单次实际结果之间的差距,正是概率论——特别是泊松分布——所要刻画的内容。同样的概率框架也构成了比特币原始设计的基础,在该设计中,跨由相互竞争的矿工组成的网络中的区块发现过程,被建模为具有已知平均速率的泊松过程(中本聪,2008)。
该模型估算的是区块发现次数。在"每个被发现的区块均符合奖励条件"这一简化假设下,零区块概率也近似于该时间段内挖矿未获得任何区块奖励的风险。它衡量的并非财务损失的概率,也不是钱包未收到任何转账的概率。实际奖励仍受共识规则和奖励资格规则的约束。
在泊松模型下,若 μ 为某时间段内的预期区块数,则恰好找到零个区块的概率为:
P(0) = e^(-μ)
而至少找到一个区块的概率为:
P(≥1) = 1 − e^(-μ)
算例演示。 采用假设输入值 h = 0.1 TH/s 及 H = 1,000 PH/s;这些仅为示例性数值,并非当前网络的实际快照。将 H 换算后得到 1,000,000 TH/s,因此 h/H = 0.0000001,即网络算力的 0.00001%。以七天为时间段(T = 604,800 秒),按每秒 10 个区块的目标速率计算:
μ = 0.0000001 × 10 × 604,800 = 0.6048
P(0) = e^(−0.6048) ≈ 54.6%
P(≥1) = 1 − 0.546 ≈ 45.4%
尽管该七天期的预期值约为 0.60 个区块,但该矿工在这一周内找到零个区块的概率约为 54.6%。在上述奖励假设下,这同样估算了该周挖矿未能获得任何区块奖励的风险。这正是单人挖矿计算器需要清晰传达的核心事实:预期值与实际实现结果并非同一回事。
下表将同一公式应用于一系列预期区块数取值,方便读者在不重新计算指数运算的情况下,查找与自身计算器输出相对应的结果。
| 预期区块数(μ) | 零区块概率 | 至少一个区块的概率 |
|---|---|---|
| 0.10 | 90.48% | 9.52% |
| 0.25 | 77.88% | 22.12% |
| 0.50 | 60.65% | 39.35% |
| 1.00 | 36.79% | 63.21% |
| 2.00 | 13.53% | 86.47% |
| 3.00 | 4.98% | 95.02% |
| 4.61 | ~1.00% | ~99.00% |
预期区块数约为 4.61 时,只是意味着在该特定时间段内零区块概率降至约 1% 的临界点;这是一个数学上的阈值,而非行业基准或推荐的运营目标。
关于提升挖矿运气这一辅助问题:在固定的网络目标下,每一次独立的哈希尝试满足该目标的概率是相同的。增加算力会增加每秒的尝试次数,而不会提高每次尝试的成功概率。Kaspa 的 PoW 实现会检查所得哈希值是否小于或等于目标值。
在该模型中,μ 取决于算力占比、出块速率以及有效挖矿时间。提高有效算力或减少停机时间,可以增加某一日历周期内的预期发现次数;评估更长的周期同样会提高至少发现一个区块的概率。运营层面的改进有助于使工作成果到达网络并获得获得奖励的资格,但在固定目标下,它们并不会让某一次哈希尝试变得"更幸运"。
考虑不断变化的条件
Kaspa 特有的两个细节会影响应如何随时间解读计算器的输出结果。
首先,网络算力与难度通过 Kaspa 的难度调整算法相互关联,该算法会对近期区块进行采样,以将难度重新调整到协议预期的出块速率。Crescendo 在保留预期 DAA 窗口时长的同时引入了稀疏采样,相关内容见 KIP-14。所显示的网络算力估算值反映的是近期状况,而非永久性的网络状态。如果网络算力上升或下降,今天计算出的计算器结果可能与实际情况出现较大偏差,因此应在条件发生变化时更新输入参数,并将较长时间跨度的输出结果视为情景推演,而非固定预测。
其次,满足网络的 PoW 目标本身并不能保证矿工一定获得奖励。Kaspa 的 BlockDAG 共识机制以及奖励资格规则同样适用。蓝色区块(blue block)并不局限于被选中的链:奖励实现代码会处理 mergeset 中符合资格的蓝色区块。因此,计算器给出的零区块概率应被理解为在上文所述简化假设下对"零区块奖励风险"的近似值,而非对最终奖励的精确建模。
建模停机时间
上述公式假设矿工的算力在整个周期 T 内持续、不间断地投入使用。任何停机时间——无论是硬件故障、网络连接中断、维护还是算力削减——都会减少该周期内实际的挖矿时间,在计算时应以有效在线时间替代 T,而非使用完整的日历周期。举例来说,如果某矿工评估的是 30 天的周期,但累计出现了两天的停机时间,那么在计算 μ 时应使用 28 天作为有效 T,而非 30 天。
由于 μ 与 T 呈线性关系,停机时间会对预期区块数产生成比例的影响,并直接影响零区块概率:有效时间的减少会提高 P(0)。出于规划目的使用独立挖矿计算器的读者,可能会发现分别计算两次结果会更有参考价值——一次假设完全不间断运行,另一次则基于自身设备历史使用较为现实的停机假设——以此了解可能结果的范围,而不是仅依赖单一的最佳情形数值。这是一种实用的建模调整,而非固定的行业要求,适当的停机假设会因设备、网络连接和运行环境的不同而有所差异。
与矿池结算方式对比
真正的独立挖矿(solo mining)是指矿工的设备直接从 Kaspa 节点获取工作,并将已解出的区块提交给该节点;奖励完全取决于矿工自身的算力能否在所评估的周期内产生一个符合条件的网络区块(Kaspa 挖矿指南)。矿池挖矿的运作方式则有所不同:矿池会以一个难度较低的份额目标(share target)分发工作,以便衡量每个参与者的贡献,并在该工作被记入贡献后,根据矿池自身的结算规则向参与者支付报酬。只有当提交的份额同时满足难度大得多的网络目标时,它才会成为网络有效的区块;矿池的份额目标与网络的区块目标并非同一个阈值,如果将二者混为一谈,就会曲解矿池记账方式的实际运作原理。
这一区别直接关系到零奖励风险。在真正的独立挖矿中,上文建模的情形——即整个周期内都有可能完全无法获得奖励的真实风险——正是该方式的核心特征。而在矿池挖矿中,支付是否受矿池层面出块方差的影响,取决于具体的支付方式。ViaBTC 目前将 PPS+ 和 PPLNS 列为其 KAS 支付方式(ViaBTC KAS 矿池信息);截至 2026 年 5 月 20 日,SOLO 作为支付方式已在 ViaBTC 的所有币种矿池(包括 KAS)中停用(ViaBTC 关于停用 SOLO 支付方式的公告)。在 PPS+ 模式下,矿工奖励中的区块补贴(subsidy)部分是根据已提交的工作量结算的,而不是取决于矿池本身在某一特定周期内是否找到区块;而交易手续费部分则按照 PPLNS 方式分配。在 PPLNS 模式下,结算则仍与矿池实际找到的区块更为直接地挂钩。关于两种方式各自如何处理方差的更完整说明,可参阅 ViaBTC 的 PPS+ 与 PPLNS 说明文章。
对于使用独立挖矿计算器的读者而言,这里的实际意义在于:如果在某一现实的算力占比和周期下,零区块概率较高,那么这一结果所描述的是真正的独立挖矿本身所固有的方差,并不能说明使用 PPS+ 或 PPLNS 结算方式的矿池账户的结算表现。
常见问题解答
期望出块值为 1 到底意味着什么?
这意味着,如果在相同条件下重复多次,这些重复试验的平均结果会收敛到每个周期一个区块。这并不能保证某一次周期内一定出块。当 μ = 1 时,零出块的概率约为 36.79%,恰好出一个区块的概率约为 36.79%,至少出一个区块的概率约为 63.21%。“恰好一个”和“至少一个”描述的是不同的结果。
我能否提高每次哈希尝试找到区块的概率?
在网络目标值固定的情况下,时机或配置无法让单次哈希更有可能满足该目标。更高的有效算力能在每秒内提供更多尝试次数,而更长的在线时间则能在评估周期内提供更多尝试次数。网络目标值的变化会改变单次哈希的成功概率;仅仅改变你的算力本身并不会。
为什么 Kaspa 每秒 10 个区块的出块速率对这一计算很重要?
出块速率(B)是期望出块数公式中的直接乘数。在其他输入保持不变的情况下,使用 1 BPS 而非 10 BPS 会使期望出块数低估十倍,并以非线性方式高估零出块概率。在示例计算中,错误的零出块概率约为 94.13%,而使用 10 BPS 计算得出的结果为 54.62%。
更高的出块速率会降低挖矿方差吗?
在相同算力份额和评估周期下,更高的出块速率会增加期望出块数、降低零出块概率,并减小出块数的相对波动。但这并不意味着出块数的绝对方差会下降:在泊松模型下,该方差等于 μ。在任意给定的 μ 值下,零出块概率依然遵循相同的公式。
更多的出块数也不意味着 KAS 产出会按比例增加。Crescendo 会针对更高的 BPS 调整每个区块的补贴,以维持既定的发行计划,具体说明见 KIP-14。
在相同算力下,solo 挖矿是否比矿池挖矿风险更高?
真正的 solo 挖矿会使矿工面临上文计算出的零出块概率,在所述假设条件下,该概率近似于零区块奖励的风险。矿池挖矿根据支付方式的不同会以不同方式分散风险;PPS+ 会独立于矿池本身是否找到区块来结算补贴部分,而 PPLNS 则仍然更直接地依赖于矿池自身的出块结果。