什么是存在性证明？

存在性证明（Proof of Existence）是一种证明某份精确数据在某个时间之前就已存在的方法，它借助一个任何人都能核验的公开时间戳来实现。

方法很简单。先对数据计算哈希，把这个哈希发布到一份带公开时间戳的记录里，之后任何持有原始数据的人都能重新计算哈希，再与记录中的哈希比对。如果两个哈希一致，验证方就能确认相同的字节在该记录的时间之前就已存在。他们无需信任你、你的服务器或你的账户——只需相信那份公开记录和数学本身。

文件本身永远无需公开。证明可以是公开的，而内容始终保持私密。

存在性证明能证明什么？

它只证明一项狭窄而实用的主张：

这些精确的字节在这个公开时间之前就已存在。

基础证明所断言的就只有这一点——而它的力量，恰恰源自它如此具体。

几乎任何东西都能被归约为一个加密哈希：文档、图像、视频、数据集、源码归档、构建产物、合同、日志文件、模型输出，或清单文件。哈希是某一段精确字节序列的简短指纹。哪怕只改动一个字节，指纹也会彻底改变。

当这个哈希被锚定到一份公开记录中时，这份记录就成了一个时间见证。之后，如果你把原始文件出示给某人，他们会再次对它计算哈希。如果新算出的哈希与记录中的一致，他们就能确认眼前这份文件与此前承诺的是同一份数据——在该记录的时间戳当时或更早就已存在。

这让存在性证明在凡是时间点重要的场景下都极具价值：

表明一份文件在争议发生前就已存在；
表明一份报告在审计期限前就已存在；
表明一个软件产物在发布时刻就已存在；
表明一份数据集快照在被修改前就已存在；
表明一份 AI 输出、提示词集合或媒体文件在被质疑前就已存在。

这份证明并不是对文件的描述。它是对文件精确字节的加密承诺。

为什么文件不需要公开？

因为对外公开的是哈希，而不是文件。

一个优秀的哈希函数就像一枚单向指纹。任何人都能从文件算出哈希，但只看到哈希的人却无法据此还原出文件。这正是私密文档能够携带公开证明的原因：记录所说的是「某人在这个时间对这些精确字节做了承诺」，却不会泄露这些字节。

举个例子，一家公司可以对一份机密数据集清单计算哈希，并只发布这个哈希。数据集本身保持私密。之后，如果公司需要证明那份快照包含哪些内容，它可以披露完整清单、其中的一个子集，或单个条目的包含证明——视具体情形而定。

这也是存在性证明适合法律、合规与安全团队的原因：它能创建一个外部时间戳，又不必把私密证据放进一个公开数据库。想深入了解这一模式，可参阅无需公开文件的机密披露。

区块链在其中扮演什么角色？

区块链是那个公开的时间见证——这个部分谁都无法悄悄篡改，连发布者本人也不行。

如果哈希只存在于你自己的数据库里，那么这份证明就完全取决于你的系统。当时间戳日后受到质疑时，别人有理由追问：数据库是否被改写过、是否从备份恢复过、是否被管理员编辑过，或是否被回填了日期。而公开区块链能消除这种疑虑。一旦交易被确认，这份带时间戳的记录就对任何人可见，不再由发布者单方面控制。

在 CardanoWall 中，证明记录被锚定到 Cardano 交易元数据里，归于元数据 label 309 之下。验证方从自己选定的任一公开 Cardano 浏览器获取该交易，读出记录，再用原始字节去核对内容哈希。这一核对过程不涉及任何 CardanoWall 服务器——其要义正在于：这份证明无需依赖我们也能成立。

区块链并不理解你的文档，它也不需要理解。它只记录证明数据；含义来自验证方重新计算哈希并确认字节一致。

最简单的证明是什么样的？

最简单的证明是仅哈希（hash-only）形式。

你选定一个文件。软件计算出一个哈希，比如 SHA-256 或 BLAKE2b-256。这个哈希被写入一份发布到 Cardano 元数据中的记录。之后，验证方对原始文件重复一遍哈希计算，如果摘要一致，证明便通过。

于是，第一层可归结为三个事实：

内容存在。
它的哈希被锚定到链上。
任何持有原始内容的人都能验证两者是否一致。

对许多用途来说，这就够了。带时间戳的哈希之所以强大，恰恰因为它简单——几乎没有什么可配置错的地方，也没有什么需要信任。

什么时候仅有哈希还不够？

一个裸哈希能很好地回答一个问题，却无法回答每一个问题。

它无法说明是谁创建了文件。它只表明字节曾经存在过。如果两个人手里都有同一份公开的 PDF，他们任何一方都能发布它的哈希；单凭哈希，对作者归属只字未提。

它无法保存文件。一旦丢失原始字节，你手里仍有一个公开的哈希，但可能再也没有任何东西能与它比对了。

它也无法把文件递交给任何人。如果另一个人需要原始数据，裸哈希并不会把数据交到他手上。

这正是底层记录格式采用分层设计的原因。仅哈希记录完全有效，但该标准同时还支持签名、封存（加密）载荷、按接收方寻址的递交，以及 Merkle 批处理——每一项都在时间戳之上叠加一种能力。

签名如何改变这份证明？

签名会叠加一项由密钥背书的声明。

一份已签名记录所说的，不止于「这些字节在这个时间之前就已存在」。它还能说明「这个密钥对这份记录做了签名」。这对作者归属、审批、内部控制和业务流程都很重要：一个组织可以用签名密钥来表明某个特定系统、团队或身份为某份记录做了背书，而创作者也可以对一份证明签名，把自己的身份与一件作品关联起来。

不过措辞必须保持精确。签名表明的是这个密钥对记录做了签名——而非现实世界中是谁持有这个密钥。把一个密钥与某个人绑定，取决于在记录之外建立起来的上下文。（CardanoWall 在设计上让签名始终可选；任何人都能发布，验证方也从不需要信任发布者。）

封存如何改变这份证明？

封存证明会叠加经过加密的保存能力。

在一份封存记录中，链上证明依然承诺的是明文的哈希。但文件本身可以被加密，并存放在一个内容寻址位置——一个 ar://（Arweave）或 ipfs:// 地址——记录里只保留它的引用。链上永远看不到明文。

当原始文件一旦丢失就会让哈希难以使用时，这一点尤为关键。有了封存证明，持有正确密钥的人之后就能取回存储的密文，将其解密，重新计算明文哈希，并确认解密出的文件正是链上承诺的那份内容。由于存储地址是从字节本身派生出来的，接收方还能判断存储网关返回的字节是否正确，而无需信任那个网关。

公开链永远不必暴露明文。加密后的载荷随证明一同传递，而解密密钥则留在它应当归属的那个人手中。

面向接收方的递交如何改变这份证明？

面向接收方的递交，让一份封存记录可以为他人加密。

如果你知道某个接收方的接收地址（一个他们已分享出来的公钥），你就能发布一份封存记录，使其只有他们用自己的密钥才能打开。值得注意的是，记录里并不携带任何写着「这是给某某的」的字段。链上根本不存在任何收件人标识。接收方的软件会扫描公开记录，悄悄对那些可能寻址到自己密钥的记录做试探性解密，只打开真正属于自己的那些。

这让存在性证明不再局限于个人的时间戳记录。它可以支撑机密披露、法律证据交换、私密合规材料包，以及内部审计交接——这些流程要求时间线公开，但内容绝不能公开。不过，在你把任何东西封存给某人之前，值得先确认那个密钥确实属于他；参见在封存文件前先验证接收方。

有一条要老实说明的限制：加密保护的是字节，而不是人。封存只能让明文仅对密钥持有者可读，但它并不保证匿名性；而且接收方一旦解密，随时都能把明文泄露出去。

系统不必为每个文件单独发起一笔交易，而是可以对成千上万乃至数百万条目计算哈希，把这些哈希折叠进一棵 Merkle 树，再发布一个 32 字节的 Merkle 根。之后，一份包含证明就能表明某个特定条目曾是被承诺批次的一部分。验证方不需要把每个文件都放上链：Merkle 根就是那份公开承诺，而一份简短的包含证明——其大小仅随批次规模的对数增长——把单个条目回溯链接到那个根上。批次里的其他每个条目都保持私密。

这契合高吞吐量的流程：

CI/CD 产物与发布清单
每日合规日志
大规模生成的 AI 内容
数据集快照
审计证据文件夹
媒体与出版归档

Merkle 模式让链上记录保持极小，同时让一份证明就能覆盖一个庞大的条目集合。想看一个实际示例，可参阅用一份记录覆盖数千文件。

存在性证明不能证明什么？

这一节是让证明保持诚实的地方。带时间戳的承诺之所以强大，是因为它具体——而正因为具体，也就意味着有些主张它根本不会做出。

它不能证明一份文档为真。一份虚假文档和一份真实文档一样，都能轻易被打上时间戳。

它不能证明所有权。任何人都能对一份并不属于自己的文件计算哈希。

它本身也不能证明作者归属。作者归属需要在其上叠加签名、密钥管理与现实世界的上下文。

它不能证明一次软件构建是安全的。它能表明某个产物、SBOM、日志或清单在某一时刻存在过，但安全性取决于构建过程以及围绕它的各项控制。

它不能证明一份数据集是合法采集或使用的。它能表明某份数据集承诺曾经存在过——这可能是重要证据——但法律权利是另一个问题，取决于你所在的司法管辖区以及你的法律顾问。

简而言之：存在性证明给你的是时间点与完整性，而不是真实性或权利。任何进一步的主张都必须在这一基础之上谨慎构建。证明不能证明什么更深入地讲清了这条界线究竟划在哪里。

为什么 CardanoWall 构建在 Label 309 之上

一份证明的价值，取决于它的可移植性。一份只能在单一网站内部生效的证明算不上真正的证明——一份认真的证明，应当能被独立工具读取、能从公开基础设施进行验证，并能被原始服务从未编写过的软件所理解。

这正是 CardanoWall 构建在 Label 309 之上的原因——它是一个面向 Cardano 存在性证明的开放、厂商中立的标准。持久存续的产物是 Label 309，而不是 CardanoWall 应用；网页应用、命令行工具和各种 SDK 都是其下游的参考实现。该标准定义了一种记录格式，能从一个裸时间戳逐级扩展：

仅哈希证明，用于简单的存在性；
已签名证明，用于由密钥背书的作者归属主张；
封存证明，用于加密保存；
接收方封存证明，用于私密递交；
Merkle 证明，用于高吞吐量的批次；
具名的算法标识符，让密码学方案能够随时间演进，而不破坏旧有记录。

这一格式也正在接受公开评审：归于元数据 label 309 之下的存在性证明已提交至 Cardano CIP 流程，并作为元数据类别的提案处于 CIP 编辑的评审之中。（元数据 label 309 是链上标识符；CIP 编号由该流程另行分配。）完整的标准、它的参考实现，以及全部开源代码，都以宽松许可证公开存放在 github.com/cardanowall。

CardanoWall 是界面。Label 309 是记录格式。这份证明被设计为比两者都更长寿——比这个界面，也比那家帮你发布它的公司更长寿。