举报证据：只加时间戳，不公开内容

封存的存在性证明（Proof of Existence）可以在完全不公开文件的前提下，保全举报证据。发送方对证据计算哈希，为选定的某一位接收方加密，并在 Cardano 上发布一条 Label 309 记录。链上记录只承载哈希和封装后的密钥——既不含明文，也不暴露接收方的身份。日后，接收方再解密文件，并确认它与已加时间戳的承诺相匹配。

这能证明证据在某个公开时间点之前就已存在，并且送达了某个特定的密钥持有者。但它不会让发送方匿名、保障其安全、授予法律保护，也不能保证任何材料一定会被法庭采纳。请把封存记录看作一个「证明与加密」层，而不是一套可以独立成立的披露策略。

它到底解决了什么问题？

证据是脆弱的。文件可以被删除，文档可以被篡改，截图可以被质疑，数据库导出可以被重新生成并回填日期。举报人常常需要证明：某个特定文件在某次披露、某项报复指控、某次审计或某场诉讼之前就已存在——而且要在不依赖被举报组织善意的前提下证明这一点。

与此同时，明文公开文件可能是危险的、违法的，或干脆就是不该做的事。它可能暴露无关者、商业秘密或医疗记录。

封存的 Label 309 记录把证明与明文分开。时间线可以是公开且永久的，内容则为某一位接收方保持加密状态。你拿到了时间戳，却无需付出公开披露的代价。

封存证明是怎样一步步工作的？

整个流程与哈希、签名、封存、分享中所述的相同，只是应用在敏感材料上：

发送方准备好证据文件，或一份描述多个文件的证据清单。
软件计算明文哈希。
内容被加密给接收方的接收地址——内容密钥以 age 风格的封存信封封装到接收方的公钥上。
密文存放在内容寻址位置（ar:// 或 ipfs://）。那里只存密文，绝不存明文。
一条 Label 309 记录被发布到 Cardano 上，承载哈希和封装后的密钥——不含明文，也不含接收方的公钥。
接收方随后取回密文，并在本地解密。
接收方重新计算明文哈希，并将其与记录中的值比对。

记录证明承诺在何时存在。解密后的文件证明承诺关于什么。两半缺一不可，而后一半只对密钥持有者可见，始终保持私密。

为什么不直接把证据放到区块链上？

因为公链是永久的，而有些证据永远无法安全地公开。敏感材料可能包含个人数据、机密商业信息、医疗细节、商业秘密、凭据、安全漏洞、无关人员的姓名，或受法律限制的内容。一旦这些进入公开账本，就再也无法收回。

封存证明让发送方可以对确切的字节做出承诺，却不必暴露它们。接收方私下接收并验证内容，而世界上的其他人只看到：某条封存记录在某个区块时间被发布过。这与在不公开文件的情况下进行机密披露中介绍的模式相同。

接收方该是谁——又如何送达正确的那个人？

要慎重地选择接收方。可能是记者、律师、监管机构、内部道德办公室、审计员、公民社会组织，或一位可信的调查人员。硬性要求是：发送方必须持有一个确实属于目标接收方的接收地址。

接收地址只是一串公钥（形如 age1…）。它本身并不能证明谁掌控着它——Label 309 有意不规定任何目录，也不设可信的密钥注册表。因此对于敏感证据，发送方应当通过双方早已信任的渠道来确认地址，正如封存文件前先验证接收方所述。

一旦弄错，代价是实实在在的：发给错误的密钥，证据就会无法被你想送达的人读取——或者反而被你不想给的人读到。

发送方该不该为记录签名？

如果目标是避免被归因，那通常不该。

记录级签名会把记录绑定到某个公钥上。当一家公司或一位具名个人希望承担责任时，这很有用；但当发送方需要避免把披露与某个身份关联起来时，这就有风险。

Label 309 中的作者签名始终是可选的。一条未签名的封存记录，仍然能证明证据承诺在某个公开时间点之前就已存在——它只是不做任何公开的作者声明，在链上也完全不绑定任何发送方身份。这一取舍很简单：

已签名记录增加了可问责性；
未签名记录避免了公开的、以密钥背书的归因。

哪一种更合适，完全取决于法律与安全的具体情境，而这是应当与法律顾问商定的决定，不是靠一篇博客文章就能决定的。

封存记录会让发送方匿名吗？

不会。这是最重要的一条限制，所以值得直说。

一条未签名的封存 Label 309 记录，会把明文、接收方的身份以及任何发送方签名都排除在链外，而且全局记录流不会暴露接收方——其中没有任何东西能指回谁能够解密。但要做到匿名，所依靠的远不止一条记录里的那些字节。记录之外的一切，仍然可能暴露发送方：

网络元数据和 IP 地址；
浏览器或设备指纹；
被入侵的设备；
支付痕迹；
网关账户的活动；
多次发布之间的时间相关性；
文件、文档和相机的元数据；
写作风格；
操作上的失误；
用来与接收方沟通的渠道。

密码学无法解决这些问题。它们属于专门的消息源保护工具、运营安全实践和法律建议的范畴。不要把封存的存在性证明当作一套匿名系统——把它当作一种加时间戳并加密的手段，再为其他所有方面配上合适的工具。

接收方拿到文件后能验证什么？

持有匹配私钥的接收方，可以核查整条声明链：

这条 Label 309 记录确实存在于 Cardano 上；
该记录的区块时间和确认情况；
自己的密钥能打开信封中的某个密钥槽，从而恢复出内容密钥；
重新计算出的明文哈希与链上承诺的哈希一致；
一份 Merkle 包含证明——如果该证据是更大批次中的一个叶子；
一份记录签名——如果发送方选择了签名。

任何没有匹配密钥的人——包括公开验证方——仍然可以确认这条记录存在、它的信封格式良好，以及密文 URI 可达。他们做不到的，是解密它或得知它承诺的是什么。这一分隔正是关键所在：链见证一份承诺，而只有密钥持有者才能确认这份承诺的内容。

封存证明不能证明什么？

时间戳的作用是有意收窄的。封存记录并不证明：

证据为真；
发送方受举报人法律的保护；
这次披露是合法的；
接收方可信，或会对明文保密；
文件是以合法方式获取的；
发送方是匿名的。

而且一旦接收方解密了内容，就没有什么能阻止他们去分享它——加密保护的是文件在传输和存储中的安全，而非接收方事后的自我约束。

封存记录确实能证明的东西既精确又有用：一份对特定字节的、带时间戳的承诺，已送达某个特定的密钥持有者。它不能替代法律建议、新闻业的消息源保护实践、安全通信工具或一套安全方案。关于这一边界的更多内容，参见证明不能证明什么。

为什么要封存一份清单，而不是单个压缩包？

证据通常以一整批的形式出现，而非一个干净利落的文件。与其封存一个不透明的压缩包，发送方不如构建一份证据清单，其中记录：

文件名或中性标识符；
每个文件的哈希；
采集时间；
来源与保管链备注；
脱敏状态；
接收方信息；
Merkle 叶子和包含证明。

敏感条目本身也可以被加密。这份清单帮助接收方理解披露了什么，并在日后逐一验证各个文件。对于大批量的集合，一个 Merkle 根就对整批做出承诺，同时仍允许每个文件被单独核查——这正是一条记录对应上千个文件所采用的做法。

组织该如何准备好接收封存披露？

组织应当在邀请他人发送敏感证据之前，就把基础工作做好。这意味着：谨慎地发布接收地址，必要时轮换或停用它们，端到端地验证地址的归属，保护好那些能解密的接收方种子，明确界定谁有权解密，并把封存证据的处理流程记录在案。

它们也应当对消息源坦诚地说明其局限。接收地址并不是一套完整的安全投递系统；它只是接收流程中的一个组件。一个想要支持真正高风险披露的组织，需要在密码学之外，再包裹上法律、安全和运营层面的程序——光有密码学是不够的。

这在日后发生争议时有何帮助？

它确立了证据的时间线。如果日后出现疑问，接收方或许能够出示：

Cardano 交易引用；
Label 309 记录及其区块时间；
加密载荷；
解密后的证据；
相匹配的明文哈希；
对于批量文件，还有 Merkle 包含证明；
该承诺在某个特定日期之前即已存在这一事实。

这能为一项调查、一份报告、一次法律审查或一套内部问责流程提供支撑——而且由于验证只需要交易元数据、字节本身以及一个公开的 Cardano 浏览器，即便 CardanoWall 不复存在，验证也照样成立。这是关于存在性与完整性的证据，而不是关于谁有理。对于时间敏感的企业披露，相关模式在安全事件时间线中有介绍；更宏观的法庭语境则见法律证据与电子取证。

一句话版本

封存的 Label 309 记录，让举报人与选定的接收方能够私密地保全证据。它为一份承诺加上时间戳，把文件加密给某一位接收方，并让该接收方日后能够证明解密出的字节与公开记录相符。

它不保证匿名、合法、安全或真实，而且接收方可能泄露其解密出的内容。请把它当作一套更广泛、经过充分咨询的披露流程中的一个审慎环节——绝不要把它当作全部方案。