文档 / 08

了解证据如何运作

消息内容可能会发生变化，但您所观察到的记录应始终可核查。

请在下方探索两个小型实验。它们使用虚构的消息，完全在您的浏览器内运行，且绝不会连接到 Telegram。

一条消息，三点观察

当 Telegram 发送新消息、编辑通知或删除通知时，采集器会分别追加三条独立的记录。编辑操作不会替换最初的记录，删除通知也不会将其清除。

01 / 消息流转示例流程

当前聊天视图消息 #42

消息已删除

该消息已从聊天界面中消失。

观察日志 3 条记录

01
message.new
10:00 见面
✓
02
message.edited
11:00 见面
✓
03
message.deleted
关于 #42 的删除通知
✓

所有三条已接收的记录均保留在日志中。

针对已选定来源的简化路径。操作记录也会同步到真实的日志中。捕获内容取决于该账户的可见范围以及 Telegram 实际发送的内容。

删除通知既不提供可靠的删除时间，也不说明是谁删除了该消息。保持这些值的未知状态，有助于区分“观察”与“猜测”。

修改一条记录。追踪哈希值。

每条记录都包含前一条记录的哈希值。其自身的哈希值涵盖了事件字段，包括该链接。一个外部保留的检查点固定了日志的特定长度和起始哈希值。

02 / HASH-CHAIN SANDBOX真实的 SHA-256 · 记录示例

记录 01消息已收到h₁ = SHA-256(e₁)链接至 64 个零

记录 0211:00 见面h₂ = SHA-256(e₂)包含 h₁

记录 03观察到删除操作h₃ = SHA-256(e₃)包含 h₂

保留在其他地方3 条记录 · 头部 h₃请将此固定边界与提供的日志进行对比。

修改某条事件会改变其哈希值。重建链条会改变其头部。移除尾部会使其长度短于保留的检查点。

查看记录 2 及完整哈希值

这是本示例中经过哈希处理的精确 UTF-8 JSON 数据。数值均为虚构；其中的九个字段及序列化格式均与日志格式一致。

已保存记录 2 的哈希值
重新计算的记录 2 哈希值

此沙盒仅计算哈希值，不生成签名。真正的验证器还会检查每个事件的 Ed25519 签名、序列号和链接。仅凭哈希值的重建无法在受信任密钥下生成有效的签名。

实际规则，简要概述如下

哈希值 + 签名

h₀ = 0⁶⁴
h_i = hex(SHA-256(C(e_i)))
σ_i = Ed25519.Sign(sk, unhex(h_i))

C 将九个事件字段序列化为 UTF-8 格式的 JSON：键按顺序排列，无额外空格，不进行 ASCII 转义，且不包含 NaN/无穷大值。该事件的 previous_hash 值为 h_i−1。显示的 h0 表示 64 个零字符；签名覆盖了 32 个原始摘要字节。

这九个字段分别为 seq、observed_at、source_at、kind、chat_id、message_id、actor_id、payload 和 previous_hash。这是 TgWitness 文档中记载的 JSON 编码格式；哈希值和签名本身并非哈希输入字段。