单人最佳份额却不是区块:eCash RTT
你的 eCash 单人份额超过了网络难度却什么也没拿到。原因是 Real-Time Targeting。官方公式,已用真实节点日志验证。
eCash 的 Real-Time Targeting,人称 Heartbeat,是一条共识规则:它在每个区块之后约两分钟内抬高所要求的挖矿目标,然后让它衰减回公开难度。一个超过浏览器所示难度的份额,只有在这段衰减之后到达才是有效区块。这是 XEC 单人矿工看到破纪录份额却一无所获的最常见原因。
核心要点
- 在稳定节奏下,eCash 在每个区块之后约 115 秒内要求高于公开值的难度。
- 这个要求起点高得离谱,并按经过时间的五次方下降。它永远不会比标准难度更容易。
- 浏览器显示的是每个区块被挖出时的难度——即下限值。不存在任何公开的实时要求数据源。
- 我们用官方公式对照一台生产节点自身的日志做了 15 次测量复现:最大偏差 0.002%。
- 今天单人矿工撞上的陡峭初期斜坡,完全源于 2025 年 11 月 15 日的升级,该升级新增了一个单区块滤波窗口。
为什么我的份额超过网络难度却没找到区块?
一位矿工写信给我们,提出了一个精确且完全合理的申诉。他曾以约 80 亿难度的份额解出一个 eCash 区块,当时公开的网络难度约为 73.6 亿。几小时后他的矿机记录到一个好得多的份额——约 118.7 亿——却什么也没发生。他检查了此后链上的每一个区块。公开难度整晚都保持在 71 亿到 74 亿之间。按 Bitcoin 的规则,那个份额就是一个区块。
他在数字上是对的,在规则上是错的。在 eCash 上,浏览器公布的难度并不是你提交那一刻必须超过的难度。它是地板。
他那个 118.7 亿的份额在前一个区块之后约 100 秒到达——仍在斜坡之内。那一刻网络要求的是 148.5 亿,所以这个份额只值所需的约 80%。十五秒之后斜坡走完,要求降到 73.3 亿,同样这个份额本可以获胜。他缺的不是算力。他缺的是一刻钟里的十五秒。
什么是 eCash 的 Real-Time Targeting?
Real-Time Targeting 随 2024 年 11 月 15 日的 Heartbeat 升级启用。它所解决的问题是少数派 SHA-256 链所特有的。
eCash 与 Bitcoin 和 Bitcoin Cash 共用算法,因此算力会追逐收益在它们之间流动。当 eCash 难度下降时,外部算力涌入并接连挖出好几个区块——涡轮区块。标准难度算法以抬高难度作出反应;来访的算力随即离开;这条链被搁浅在高难度和一小部分算力上,产生可能长达数小时的出块空档。充值卡住。确认变得难以预料。
Heartbeat 攻击的是这个循环的前半段。通过让紧跟前一个区块之后挖出的区块失效,它移除了突击挖矿的回报,于是基础算法压根就不会过度修正。这一设计受到 Tom Harding 关于 Real-Time Block Rate Targeting 研究的启发。
这套机制之所以能运作,全靠 Avalanche。实时目标依赖每个节点自己对区块何时到达的测量,而这本质上是主观的。Avalanche 的后共识把这些主观视角协调成单一的网络决定,同时不触碰区块头,也不改动中本聪共识。
eCash 的实时目标是怎么计算的?
这条规则在 Bitcoin ABC 中被实现为一项停放策略,而非有效性规则。相关源码位于 src/policy/block/rtt.cpp,核心公式就写在该文件自己的注释里:
target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)
RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)
RTT_K 为 6,所以目标按经过时间的五次方缩放。T 是该滤波窗口的目标间隔。经过时间从节点收到前面每个区块头的那一刻起算,而不是从区块头里写的时间戳起算。
公式在五个窗口上同时求值,最严格的结果胜出:
| 窗口 | 间隔 T | 常数因子 |
|---|---|---|
| 1 个区块 | 150 秒 | 5.0372626864e-11 |
| 2 个区块 | 600 秒 | 4.9192018423e-14 |
| 5 个区块 | 2400 秒 | 4.8039080491e-17 |
| 11 个区块 | 6000 秒 | 4.9192018423e-19 |
| 17 个区块 | 9600 秒 | 4.6913164542e-20 |
这些窗口长度都是质数,相邻两项之间跳过一个。源码解释了原因:这是为避免串联一系列滤波器所产生的共振频率而做的尽力尝试。序列止步于 17 个区块,是因为更多的窗口已不会对滤波器的选择性带来任何有意义的改变。
有两条性质对矿工要紧。所有窗口中最低的那个目标生效,因此由最苛刻的约束说了算。而且结果有上限:实时目标永远不会高于——也就是永远不会比——标准目标更容易。难度只能被往上推,绝不会往下走。
用 gamma(1 + 1/6) = 0.9277193336 反推常数,可以把公布的五个系数全部复现到十位有效数字。
紧接前一个区块之后,eCash 区块究竟难多少?
这是别处都没有的一张表,按官方公式在稳定的十分钟节奏下算出。倍数作用于浏览器将会公布的那个难度。
| 距上一个区块的时间 | 所需难度 |
|---|---|
| 5 秒 | 6,352,657× |
| 10 秒 | 198,521× |
| 20 秒 | 6,204× |
| 30 秒 | 817× |
| 45 秒 | 107.6× |
| 60 秒 | 25.5× |
| 75 秒 | 8.37× |
| 90 秒 | 3.36× |
| 105 秒 | 1.56× |
| 115 秒 | 1.00× |
| 300 秒 | 1.00× |
一个在前驱区块之后一秒就被找到的区块,大约需要公开难度的两百亿倍。到第十秒是二十万倍。这条曲线陡得残酷,然后就那么停住了:约 115 秒之后,要求与公开难度完全相等,并停在那里。
当最近的区块到达得快于十分钟时,每个窗口都从更短的经过时间起算,斜坡既起得更高、也持续得更久。这不是副作用。这是反涡轮区块机制在干活。
这个公式和真实节点的实际行为对得上吗?
我们测过了。下面是我们某台 eCash 节点在一个区块之后两分半内记录的数值,旁边是仅用同一份日志中可见的区块到达时间、由公开公式推算出的数值。
| 时刻 | 节点报告值 | 公式预测值 | 偏差 |
|---|---|---|---|
| +9 秒 | 2,394,590,057,379,161 | 2,394,589,432,518,570 | 0.000% |
| +29 秒 | 6,893,721,996,585 | 6,893,719,674,153 | 0.000% |
| +59 秒 | 197,780,812,534 | 197,780,536,483 | 0.000% |
| +79 秒 | 45,952,404,186 | 45,952,395,103 | 0.000% |
| +99 秒 | 14,868,517,720 | 14,868,516,386 | 0.000% |
| +109 秒 | 10,200,095,597 | 10,200,094,382 | 0.000% |
| +129 秒 | 8,113,651,430 | 8,113,457,205 | 0.002% |
| +149 秒 | 7,130,533,560 | 7,130,533,560 | 0.000% |
在全部十五次记录的测量中,最大偏差为 0.002%。公开的公式不是对节点行为的近似——它就是节点在做的事。
有一个细节值得单独拎出来。头 99 秒里,起约束作用的是单区块窗口。直到 109 秒,双区块窗口才接手,再过 40 秒标准难度定下了地板。
2025 年 11 月 15 日改了什么?
在那次升级之前有四个窗口,从两个区块起步。2025 年 11 月 15 日的升级加入了间隔为 150 秒的单区块窗口。
把两种配置都放进公式,在稳定的十分钟节奏下跑一遍,结果相当醒目:
| 距上一个区块的时间 | 4 个窗口(之前) | 5 个窗口(如今) |
|---|---|---|
| 30 秒 | 1.00× | 817× |
| 60 秒 | 1.00× | 25.5× |
| 90 秒 | 1.00× | 3.36× |
| 105 秒 | 1.00× | 1.56× |
| 115 秒 | 1.00× | 1.00× |
在正常节奏下,四窗口配置根本不产生斜坡。它只在区块本就来得太快时才起作用——这正是它当初狭义的用途。今天一位单人矿工在一条其他方面都健康的链上撞到的那道陡峭初期斜坡,完全源自 2025 年 11 月新增的单区块窗口。
如果你在那个日期之前单人挖过 eCash 且从没遇到过这种情况,原因就在这里。
为什么我的矿池显示的难度和浏览器对不上?
因为在 eCash 上它们本就是两个数字,而挖矿软件也是这么说的。
Bitcoin ABC 的 eCash 单人挖矿软件在每次 getblocktemplate 调用中读取 rtt.nexttarget,把它转成难度,并且——仅对 eCash——用这个值作为它所报告和记录的网络难度。其他任何 SHA-256 链则改用区块头里的难度位。
这单单一个分支就解释了每位 eCash 矿池运营者都会看到的现象:一个区块到达之后,报告出的网络难度高得离谱,接下来约两分钟里每十秒掉一个数量级,然后在浏览器最终会公布的那个值上走平。
节点运营者还有第二个选择:用区块模板中都存在的 rtt.prevheadertime、rtt.prevbits 和 rtt.nodetime 在本地计算目标。两条路径都记录在 eCash 挖矿页面上。
违反实时目标的区块会怎样?
它会被停放,而不是被拒绝。节点给它打上标记为 policy-bad-rtt 的策略违规并搁到一边,然后由 Avalanche 轮询决定网络其余部分是否认同。如果该节点属于少数派,它会翻转自己的立场。整个过程中区块头原封不动,中本聪共识也不被修改。
在 eCash 节点上运行 getchaintips,会看到这些区块与活动链并列显示,标着 status: parked。在我们其中一台节点上,这个调用返回了跨越区块高度 940,265 到 960,666 的 262 个被停放的分支尖端——约 20,400 个区块,也就是说该区间内约 1.3% 的区块至少被停放过一次。
这个数字是实时目标违规的上界,而不是对它们的计数。eCash 出于多种原因停放区块,Avalanche 也会停放一场普通分叉竞赛中落败的一方。但在一条同高度出现两个竞争区块本就罕见的链上,超过百分之一的停放尖端比例告诉你:这套机制是活跃且在干活的,而不是闲着。
这适用于 Bitcoin、Bitcoin Cash 或其他 SHA-256 链吗?
不适用。在 SHA-256 各链之中,这一行为为 eCash 独有,因为它依赖 Avalanche 层来协调主观的时序。
| 链 | 难度调整 | 一个间隔内的要求 |
|---|---|---|
| Bitcoin | 每 2016 个区块 | 恒定 |
| Bitcoin Cash | ASERT,每个区块 | 恒定 |
| eCash | ASERT 加上 RTT | 每个区块后升高,随后衰减 |
在 Bitcoin 和 Bitcoin Cash 上,高于网络难度的份额就是区块,没有别的说法。如果你在挖多条链,并且在互相比较各自的最佳份额数值,那么 eCash 这一列是唯一一个把时序算进去的。我们的单人挖矿概率解析和网络雷达都使用公开难度,作为长期概率的依据这是正确的——斜坡会随时间被平均掉。
对单人矿工来说死区有多大?
任何在斜坡走完之前落下的份额都白费了,不管它有多好。在稳定节奏下:
| 份额强度 | 自何时起有效 | 死区 |
|---|---|---|
| 等于公开难度 | 1 分 55 秒 | 间隔的 19.2% |
| 1.5× | 1 分 46 秒 | 17.7% |
| 2× | 1 分 40 秒 | 16.7% |
| 5× | 1 分 24 秒 | 14.0% |
| 10× | 1 分 13 秒 | 12.2% |
| 100× | 0 分 46 秒 | 7.7% |
对于一个刚刚越过难度的份额来说,每个区块间隔里大约五分之一是用不上的。更强的份额更早穿过斜坡,这就是为什么真正巨大的份额几乎从不被浪费。
这不会以任何你能据此采取行动的方式改变你的期望收益。它已经体现在这条链实际的出块情况里,因而也体现在难度本身之中。你的矿机配置里没有任何东西能影响它。
单人矿工究竟该为此做什么?
对大多数人来说,诚实的答案是什么都不做——但要把自己的数字读对。
- 你矿机上的最佳难度显示是在找到哈希的那一瞬间本地算出来的,早于矿池作出回应。不论那个份额本来能否有效,它都会记录下这个值。它还是一个全时段数字,找到区块也不会清零。
- 在 eCash 上,一个高于公开难度的历史最佳份额并不是区块被错过或被偷走的证据。若想确认某个区块是否存在,去看链上的 coinbase 交易。在非托管矿池中,你的地址在开始哈希之前就写进了 coinbase,所以真实区块会以你自己的名义显示,谁也动不了。
- 如果你好奇自己曾经差多少,我们的最佳份额详解一文讲了怎么读这些数字,概率计算器则把算力换算成现实的预期。eCash 矿池页面列出了当前难度和所有区域接入点,配置生成器会为你生成 stratum 设置,区块与矿工的实时数据则在矿池面板上。
如果你为单人挖矿运行自己的 eCash 节点,有一项配置很重要。节点需要 17 个区块的已记录区块头到达时间,才能计算实时目标。在凑齐之前,它可能以过低的难度构建模板,结果区块被停放。设置 persistrecentheaderstime=1 会把这些参考时间存到磁盘并在重启时重新加载,从而补上这个缺口。
来源
- eCash 挖矿文档 — 区块模板的 RTT 字段、目标计算的参考实现,以及公布的滤波系数
- Heartbeat Upgrade: A Steady Pulse for eCash — 其理据、跳链挖矿问题,以及 Avalanche 后共识的角色
- Bitcoin ABC 源码 —
src/policy/block/rtt.cpp,其中包含公式、窗口常数和停放策略 - eCash 单人挖矿软件 — 实时目标如何成为 eCash 上所报告的网络难度
本文中的验证数字,是在 2026 年 8 月 2 日对一台运行中的 eCash 节点的日志求值公开公式、并逐值比对结果而得出的。
常见问题
为什么我的份额超过了 eCash 网络难度却没有找到区块?
因为 eCash 在公开难度之上还执行一个 Real-Time Target。在每个区块之后约头两分钟内,所要求的难度高于浏览器显示的数字。在那个窗口内越过公开难度的份额,并不是有效区块。
什么是 eCash 的 Real-Time Targeting?
Real-Time Targeting 也叫 Heartbeat,是自 2024 年 11 月 15 日网络升级起生效的共识规则。它根据前面几个区块到达得有多近来抬高挖矿目标,然后让它衰减回标准难度。其目的是阻止逐利跳链的矿工制造一连串涡轮区块。
eCash 的 RTT 斜坡持续多久?
在稳定的十分钟节奏下,斜坡持续约 115 秒,之后要求就与公开难度完全相等。当最近的区块到达快于十分钟时,斜坡起点更高、衰减也更久,而这正是它被设计出来的反涡轮区块行为。
我的矿池报告的难度和浏览器上的一样吗?
在 eCash 上不一样。为 eCash 打造的单人挖矿软件报告的是来自区块模板的实时目标,而不是标准难度。这就是为什么区块之后这个数字每十秒变动一次、随后才稳定下来。浏览器公布的是每个区块被挖出时的难度,那是下限值。
Real-Time Targeting 适用于 Bitcoin 或 Bitcoin Cash 吗?
不适用。RTT 是 eCash 特有的,并依赖其 Avalanche 层来在节点之间协调主观的区块到达时间。Bitcoin 每 2016 个区块重新调整,Bitcoin Cash 每个区块使用 ASERT,但两者都不会在一个区块间隔内抬高要求。在那些链上,高于难度的份额永远是区块。
矿池能藏起一个违反实时目标的区块吗?
没有什么可藏的,因为根本不存在区块。低于实时目标的份额永远不会作为区块提交到网络。在非托管矿池中,付款地址在开始哈希之前就写入了 coinbase,所以任何真实区块都会以矿工本人的名义显示在链上。
违反实时目标的区块会怎样?
它会被停放,而不是被直接拒绝。节点把 RTT 作为停放策略来应用,随后 Avalanche 轮询在全网协调这一决定。由于每个节点对区块到达时间的测量是主观的,正是这一共识步骤让实时目标变得可行。
RTT 会改变我找到 eCash 区块的概率吗?
它略微减少了每个区块间隔中可用的比例,因为落在斜坡里的份额无法获胜。在稳定节奏下,对于恰好等于公开难度的份额,十分钟间隔中约有 19% 是死区。你的矿机配置中没有任何设置能改变这一点。