第510章 假锚点与“公证时间戳链”（1/2）

假锚点码出现的那一刻，刘曼第一反应是怒——

第二反应却是更现实的担忧：

“如果他们P个码，基层输入一验，万一刚好撞上真的怎么办？群众会以为验证不可靠。”

陈毅立刻否定：“8位码撞真的概率很低，但他们不靠概率。他们会去偷一串真码，再贴到假截图上，让你‘验真却误读’。”

审计旁听的人点头：“这就是更高级的伪造：不伪造签名，只伪造语境。拿真锚点绑定假内容，制造‘官方背书’错觉。”

何经理在视频里更紧：“银行端一旦出现这种‘验真误读’，风险极大。客户会说：你们官方自己这么写的。”

会议室里气压陡降。

林远却抬手示意：“别慌。我们早就知道锚点码本身不是全部，它只是入口。真正的验真，是‘码+内容摘要+时间戳链’一起闭环。”

他在白板上写下三个词：

码

摘要

时间

然后写下新编号：

TS-NOTARY-01｜时间戳链

ANCHOR-BIND-01｜锚点绑定

TEXT-CHECK-01｜语境校验

1）ANCHOR-BIND-01：锚点码必须绑定“内容摘要桶”

陈毅把锚点体系升级成“绑定式”：

锚点码不再只对应 doc_id/doc_ver

还绑定一个 tent_hash_bucket（内容摘要桶）

不是全文哈希（太重、易泄露）

而是对关键段落的摘要哈希（例如标题+前三行+关键定义行）

验证页返回的不再是“码有效/无效”这么粗暴，

而是三段式回执：

1）码存在（doc_id/doc_ver）

2）该码绑定的摘要桶（官方摘要指纹）

3）你输入的截图摘要桶是否一致（由用户手动选择截图里的“标题+首句”，不采集整段内容）

“对手拿真码贴假截图，最怕这一步。”林远说，“因为你要让截图看起来像原文，就得把标题与首句对齐；对齐了，就等于还原官方语境；对齐不了，就会被TEXT-CHECK判不一致。”

刘曼终于明白爽点：“也就是说，真码不能随便挪，挪了就露馅。”

2）TS-NOTARY-01：锚点发布进入“公证式时间戳链”

但林远还不满足。

因为“绑定摘要桶”能挡住大部分伪造，却挡不住一件事：

对手可能提前截到某个版本的真内容，再借此制造“官方旧口径”，拖慢更新传播。

所以他加了时间戳链：

TS-NOTARY-01｜锚点发布时间戳链（试行）

每次发布 doc_ver，会生成一个 ts_proof_id

ts_proof_id由省政务云时间戳服务签发（相当于可核验的“发布时间证据”）

验证页会显示：

发布时间桶（精确到小时）

当前是否为最新ver

变更摘要（ge_id对应）

这样一来，群众不再只问“真不真”，还会问：

新不新。

对手最怕“新不新”。

本章未完，点击下一页继续阅读。