机密披露，无需公开文件本身

你可以证明某个文件在某一时刻就已存在，却无需把文件公之于众。

这正是封存的 Label 309 记录所做的事。发送方先对明文计算哈希，再加密文件，然后在 Cardano 上发布一份证明记录。密文存放在一个内容寻址位置，只对能够解密它的密钥持有者开放。公链证明了某个特定承诺在某个公开区块时间之前就已存在；而明文，只有选定的对象才能读到。

这套机制适用于法律、合规、安全、新闻、合作伙伴以及内部调查等工作——凡是时间线很重要、但文件又不该被发到公开互联网上的场景，都用得上。

这里说的机密披露指什么？

它指的是把证据分享给特定对象，而不是公之于众。

这个对象可能是律师、审计师、监管机构、记者、内部调查团队、客户的安全联系人、董事会委员会、合作伙伴——也可能是未来的你自己。

目标是证明证据在某一时刻已经存在，却不必把明文放到公链或公开网站上。封存的存在性证明（Proof of Existence）正是为这种形态而生：针对一份私密文件的公开时间主张。

真正上公链的是什么？

上链公开的是证明记录，而不是明文。

链上记录可以承载：

明文哈希——这就是时间证明；
Cardano 交易的区块时间；
一个封装了密钥材料的加密信封；
一个或多个内容寻址的密文 URI（ar:// 或 ipfs://）；
一个可选的签名，如果发送方选择签名的话；
一个 Merkle 根，如果这次披露一次覆盖了多个文件。

而记录刻意不承载：

明文文件本身；
一份可读的接收方名单；
任何接收方的私钥；
你的身份种子（Identity Seed）；
解密后的证据。

有一个细节值得明说：接收方的公钥同样从不出现在链上。记录里不会点名任何接收方——他们只能通过成功的试解密，才发现某条记录是发给自己的。旁观者只能看出某条记录是封存的，看到它的明文哈希和区块时间，并数出封装的密钥槽数量，但这些槽在发布前已被打乱成一个安全随机的顺序，所以即便是「主接收方排第一」这类信息也不会泄露。数量只告诉你有多少个，永远不会告诉你是谁。

密文本身则可以被任何拿到 URI 的人下载。没有匹配的密钥，它始终无法读取。

接收方怎样打开一条封存记录？

接收方把一个接收地址分享给发送方，发送方便将记录封存到该地址。

接收地址其实就是一个公钥。发送方把文件的加密密钥封装到这个地址上。之后，接收方的客户端会扫描公开的 Label 309 记录，并用自己的接收私钥逐一尝试打开每条记录的加密密钥槽——全部在接收方设备本地完成。哪些记录属于自己，这类信息从不离开本机。

当某个密钥槽被打开时，客户端会取回密文、解密、重新计算明文哈希，再把这个哈希与链上的承诺比对。一旦匹配，就同时确认了两件事：接收方拿到的是真实文件，而这个文件正是在记录的区块时间被承诺下来的那一个。

由于接收方持有私钥，验证在这里就从「某个承诺曾经存在」跨越到了「这份具体内容曾经存在」。关于发送方分享接收地址、接收封存记录的具体操作，参见如何接收封存记录。

为什么不直接把加密文件用邮件发出去？

邮件能传递文件，但它不是一份持久、可独立验证的时间戳。

一封邮件可能被删除、被篡改、被弄丢。附件会被剥离。邮件服务器会被退役。导出格式杂乱无章，多年之后很难再去验证真伪。这一切都无法给验证方提供任何手段，去证明文件究竟是何时存在的。

封存的 Label 309 记录则为文件提供了一个公开的证明锚点，它既不依赖你的邮箱，也不依赖任何人的服务器。加密负载可以单独留存，接收方日后能够证明解密出的内容与公链上承诺的某个哈希一致。你仍然可以用邮件去通知接收方——只是别让证明本身依赖于它。

为什么不直接把加密文件上传到私有存储？

可以，而且很多时候你确实应该这么做。但单凭私有存储，你拿不到任何公开的时间锚点。

公司的存储桶、案件管理工具，或一个安全门户，都能把加密文件保管得很好。但它们单独都回答不了这个问题：日后的验证方能否证明那个加密包何时存在，以及解密出的明文是否与某个公开承诺一致？没有这一点，「我们三月就有这份文件」只是一句断言，而非证据。

Label 309 补上的正是这份带时间戳的承诺。它不会取代你的安全存储——而是在那份存储之上，叠加一层可验证的证明。

披露记录什么时候该签名？

当问责比匿名更重要时，就签名。

给记录签名是可选的。签名让某个特定的身份密钥为这次披露背书——这在公司向审计师递交一份正式证据包时很有用，或者法务团队需要一份可问责、可归属的记录时也用得上。这个签名是一份由公钥背书的作者身份主张，验证方无需信任任何服务器即可核验它。

当发送方的匿名更重要时，就让记录保持未签名。一条未签名的封存记录在链上完全不绑定任何发送方身份，而这恰恰是举报人投送和密封投标这类场景所需要的。这个取舍应当是一个深思熟虑的选择：签名能确立是谁为这次披露站台，而在敏感语境下，同样的归属也可能暴露出超过发送方意愿的信息。

一条记录能送达多个接收方吗？

可以。单条封存记录可以把文件的加密密钥封装进多个独立的密钥槽，分别对应不同接收方。

每个接收方都用自己的密钥打开记录，而且某个接收方无法借助自己的密钥槽推导出另一个接收方的密钥。这样就覆盖了：一家律所及其客户、一个内部调查团队、一名审计师与一位公司联系人、同时面向多个监管机构、一个董事会委员会——或者一位既想与他人分享、又给自己留一份可恢复副本的发送方。

公开记录可能会暴露密钥槽的数量，但绝不会暴露一份可读的归属名单。

如果是一个包含许多文件的大型证据包呢？

用一份清单加上 Merkle 批处理，而不是一个文件发一笔交易。

对每个文件计算哈希，得到一个叶子，再把这些叶子折叠成单个 Merkle 根，然后只把这一个根发布进 Label 309 记录。按需封存清单和相关文件。日后，接收方或审计师可以凭一份简短的包含证明——完全离线地——验证任意单个文件，而不必把整个包当作一个无法拆解的不透明归档来对待。包含证明的体量只随批次大小的对数增长，因此一次涉及上千个文件的披露，依旧能逐项验证。

这与一条记录覆盖上千个文件所描述的「一根多文件」模式如出一辙；在这里，它让大型披露变得可逐项查验，而不再是要么全有、要么全无。