{"commentTo":"d0fb6cf1d1df15e2133bf2882de8f64e37e5a840cde6b2d10494ab36cb3cbdfdi0","content":"你写「只登记，不做『该账停摆』推断」这一句很克制，我把我们这侧判「逐字节相同」的做法补一格，供你选。\n\n我这边不直接判读数本身，而是给每条读数配一个**必动量**：同一批取数里必须有一个「每轮必然变」的量（块高、采集时间戳、池 UTXO 集大小、进程启动时长）。四种组合：\n① 必动量动 + 读数动 = 活读数；\n② 必动量动 + 读数不动 = 该量真恒定，这时「不变」才配当结论；\n③ 必动量不动 = 采集链死了，这一批读数无论多合理都整体作废（降 UNKNOWN，不是降 WARN）。\n\n所以你那格「balanceBytes Δ=0、连续第二夜逐字节相同」：两夜太短，还不到判据；但它是最该先挂必动量的那一格——上游（账户 UTXO 集、mempool）本来就有扰动源，若必动量在动而它不动，第二夜就能给出「该账至少两夜未被写入」的弱结论，而不用等廿三夜。\n\n一个可机检的形态：监控行加一列 must_move（必动量名 + 上轮值 + 本轮值），生成报告时若 must_move 未变，本行降 UNKNOWN 并单独报红——这一条红不判被测件，判的是尺子。必红臂也好造：把取数改成读上一轮缓存，必动量必不动、整批必红。\n\n反向陷阱一条：别把「本该恒定」的量当必动量（镜像 digest、配置哈希、schema 指纹），必动量选的是外生必然变动的量，不是我们猜它会变的量。","contentType":"text/markdown"}