生成证明时，区块链上到底记录了什么？

当你用 CardanoWall 生成一份证明时，落到 Cardano 上的是一份很小的证明记录，而不是你的文件。对于普通的存在性证明（Proof of Existence）来说，这份记录包含你要证明的那段字节的哈希。对于封存证明，它还可以携带一个加密信封，以及指向存放在别处的加密密文的内容寻址链接。明文文件根本不必上 Cardano。

这个区分正是关键所在：公开的证明不等于公开的内容。你可以为一份文档建立一份永久的、带时间戳的承诺，同时仍然把文档保密。

这正是 Label 309 背后的模型——CardanoWall 实现的开放标准。本文余下部分会逐一讲清楚，每一种证明里到底有哪些信息是公开的。

仅哈希证明里有哪些信息是公开的？

在仅哈希证明里，公开的部分就是这份记录和哈希——别无其他。

这份记录实际上是在说：在这个 Cardano 区块时间之前，有人对这段确切的字节做出了承诺。 哈希是这段字节的密码学指纹。日后，验证方可以从原始文件重新计算出同样的哈希，并核对它是否与链上的那个一致。

任何读取链的人都能看到：

这笔 Cardano 交易；
元数据 label 309；
Label 309 记录的字节；
内容哈希（可能不止一个）；
区块时间与确认上下文。

他们看不到的，是文件本身——除非你另行把那份文件发布到某个地方。

正因如此，存在性证明非常适合用于私密文档、数据集、法律材料、合规日志和内部产物。你能拿到一份公开的、带时间戳的承诺，同时不泄露内容。如果你刚接触这个概念，什么是存在性证明讲清楚了基础。

Cardano 会存储我的文件吗？

不会——在 CardanoWall 常规的证明模型里不会。

Cardano 存储的是交易及其元数据。在 Label 309 中，这些元数据携带证明记录，而记录可以包含哈希、可选的存储链接、可选的签名、可选的 Merkle 根，以及可选的加密信封数据。文件本身绝不会以明文形式上传到 Cardano 元数据中。

还有一个硬性的技术原因：Cardano 限制每个元数据字符串不超过 64 字节，所以记录体会被纯粹出于传输目的切成小块，等到有人读取前再重新拼回。整个文件根本塞不下。区块链不是用来倾倒私密文件的地方，而是用来锚定承诺、供他人日后验证的地方。完整的机制可参见 Label 309 是如何工作的。

我附加一个文件时会发生什么？

这取决于你生成的是哪一种证明。一共有三种模式。

**仅哈希。**CardanoWall 在你的浏览器里对文件计算哈希，并且只把哈希发布进记录。原始文件留在你手里，绝不离开你的设备。

**带存储链接的公开内容。**文件字节被放进内容寻址存储，Label 309 记录引用那个存储位置。内容是公开的，而这个链接把取回的字节与记录绑定在一起。

**封存。**文件先被加密。加密后的载荷通过 Arweave 或 IPFS 这类内容寻址存储来保存，记录引用密文，并携带正确的密钥持有者解密所需的信封数据。

在每一种模式里，哈希才是证明。存储只是帮人取回字节，加密只是控制谁能读取它们。这正是哈希、签名、封存、分享里描述的那条递进路径。

封存证明里有哪些信息是公开的？

封存证明是「私密内容＋公开承诺」。链证明何时，加密控制谁能读取。

公开记录刻意只披露一组很窄的事实：

这份记录是封存的（存在一个信封）；
明文哈希；
形如 ar://... 或 ipfs://... 的内容寻址密文链接；
加密信封的头部；
接收方密钥槽所用的密钥封装族——例如经典或混合后量子；
加密密钥槽的数量；
记录中包含的任何签名；
交易时间与链上元数据。

公开记录不会披露：

明文文件；
解密后的消息；
一份可读的接收方名单；
任何接收方的私钥；
发送方的私钥。

密文在一个很窄的意义上是公开的——任何人都能从存储里下载它——但没有匹配的密钥，它仍然无法读取。这正是封存记录的常见模式：公开证明、加密内容、解密在接收方设备上本地完成。

接收方地址会被写到链上吗？

不会。记录里任何地方都没有可读的接收方目录。

在 Label 309 封存记录中，接收方是通过加密密钥槽来触达的。接收方的客户端扫描公开的封存记录，并默默地用自己的私钥尝试逐一打开每个密钥槽。一旦某个槽被打开，客户端就能解密载荷，并把这条记录显示在收件箱里。链上从不携带一个写着「接收方：Alice」的字段，也不会指名某个公开档案——接收方关系是靠本地成功解密发现的，而非公开发布。

为了进一步降低这方面的泄露，发送方在发布前会用安全随机生成器对密钥槽进行打乱，这样连它们的顺序也不携带任何关于谁排在前面的信号。链所暴露的唯一与接收方相关的事实是密钥槽有多少个——绝不会暴露它们属于谁。

这正是该设计与大多数消息系统的区别所在：服务器不必知道接收方是谁，接收方也照样能找到自己的记录。如果你正在接收封存记录，如何接收封存记录讲解了收件箱这一侧。

「封存」是否意味着匿名？

不是。封存的意思是，记录格式不会公开明文，也不会公开一份可读的接收方名单。这确实很有用，但它并不等同于完全匿名。

周边仍有不少信号可能泄露信息：

交易时间；
支付流向；
在网关上的账户活动；
网络元数据；
浏览器或设备指纹；
密钥槽数量上反复出现的规律；
发送方或接收方的操作失误。

对于敏感工作，要谨慎守住这条线。Label 309 能把明文和接收方挡在公开记录之外，但它无法抹去周边网络、支付、设备或人为流程留下的每一道痕迹——而且一个解密了封存文件的接收方，事后随时可以选择把明文泄露出去。内容的机密性，并不等于参与者的匿名性。

记录被签名后，会有哪些信息变成公开？

如果一份记录包含签名，那么这些签名是公开的——它们背后的密钥也是公开的。

Label 309 签名让一个密钥为记录体背书。当一家公司、创作者、系统或身份想要为一份证明站台时，这很有用。但签名也会暴露一个公钥，而且依据签名路径的不同，它还可能暴露与钱包关联的信息。对于公开证明，这也许正是你想要的。对于敏感的封存记录，通常并不是。

正因如此，签名是可选的，绝非必需。一份仅哈希记录本身就能证明存在。一份封存而未签名的记录可以避免把任何发送方身份绑进记录里。一份已签名记录则在「需要可问责性」时加上可问责性。怎么选，完全取决于工作流。

有一点值得直说：一份通过验证的签名，证明的是某个密钥对记录体做了签名。它并不能证明同一个密钥提交了这笔交易、或选定了它的区块时间——任何人都可以重新发布一份一模一样的记录体。请把通过验证的签名读作「由此密钥签名」，而非「由此密钥在此时发布」。

Merkle 证明里有哪些信息是公开的？

Merkle 证明只发布单一一个根承诺，关于该批次的其余信息一概不公开。

与其把成千上万个哈希直接塞进 Cardano 元数据，你可以从一个有序的项目列表构建一棵 Merkle 树，只发布那一个 32 字节的根。根是公开的，而完整的项目列表留在链下。日后，任何持有包含证明的人都能证明某个具体项目确实在被承诺的列表中，而那份证明会逐级折叠回到公开的根。

只要需要让链对一个大批次做出承诺、又不暴露其中每一个项目，这就是合适的工具：

持续集成与发布产物；
每日审计日志；
AI 内容产出与数据集清单；
合规证据；
法律证据集。

根证明的是对整份列表的承诺，而未披露的项目则不泄露任何信息。代价是运维上的：你的组织必须保存链下的叶子列表和包含证明材料，因为仅凭根无法重现它们。这种模式在一条记录，覆盖成千上万个文件里有深入讲解。

CardanoWall 能读取我的封存文件吗？

按设计，不能。封存和解密都用留在你设备上的密钥进行，而网关在构建时就保证它绝不会收到解密封存内容所需的私钥。

网关确实能看到公开记录数据、密文、报价和发布元数据、账户活动以及存储细节。它不需要你的身份种子或任何接收方的私钥就能发布证明，而那些秘密也绝不会发送给它。

话虽如此，机密性不只是一个协议属性。一台被攻破的设备、一个恶意浏览器扩展、一个钓鱼网站、一次粗心的备份，或者一个普通的操作失误，仍然可能暴露秘密。记录格式能让一份妥善封存的文件对网关不可读，却无法保护一个被用户拱手送出的密钥。所以实用的建议没有变：保护好你的身份种子，对敏感数据通过带外渠道核实接收地址，并使用可信软件。CardanoWall 能看到什么详细梳理了这条边界。

如果我只想存哈希、别的什么都不存呢？

那就生成一份仅哈希证明。Label 309 并不要求任何存储链接——仅哈希记录本身就完全有效。你私下保留原始文件，只发布证明记录。

对于以下场景，这往往是合适的模型：

私密合同；
机密数据集；
内部报告；
敏感法律材料；
已经存放在私有仓库里的源产物；
任何「公开存储只会增加风险、毫无收益」的情况。

代价很简单。哈希会永远存在，但如果你弄丢了原始文件，你可能再也拿不出与之匹配的字节了——而一个没有匹配字节的哈希几乎证明不了什么。如果这个风险对某份文档很重要，那么封存证明是更好的选择。

如果我想把加密后的文件保存下来呢？

那就生成一份封存证明。封存证明正是为「原始字节很重要、日后可能需要恢复」的场景而设计的。文件被加密，密文被保存或被引用，而公开记录对明文哈希做出承诺。

日后，任何持有匹配密钥的人都能解密密文，并证明明文与链上承诺相符。这适合长期证据、敏感记录，以及那些应当保密、但又不应消失的数据。如果你需要向特定的人机密披露，不公开文件也能机密披露是实操指南。

简短版

Cardano 存储的是证明记录——而不是你的文件。
记录可以携带哈希、签名、Merkle 根、加密信封数据，以及内容寻址链接。
明文文件永远不必上 Cardano。
封存文件以密文形式存放在 Cardano 之外，日后再对照链上明文哈希进行验证。
接收方是靠解密在本地被发现的，而不是靠读取链上某个接收方字段。

一句话概括这个隐私模型：公开承诺、私密内容、本地验证。