阅读约 7 分钟
哈希、签名、封存、分享:CardanoWall 证明的四个层级
CardanoWall 用四个层级来构建证明:纯哈希时间戳、可选的签名、加密后的封存副本,以及面向特定接收方的私密投递。你只需启用某个场景真正需要的层级。

CardanoWall 证明在实践中分为四个层级,你可以自行决定要往上走多远:
- 哈希证明某段确切的字节在某个公开时间之前已经存在。
- 签名在此之上加一层有密钥背书的声明,表明某个特定身份为这条记录背书。
- 封存对原始文件加密,让它能与证明一起被私密保存。
- 分享把封存后的文件按特定接收方封装,使他们日后能用自己的密钥发现并解密它。
每一层都建立在下一层之上,而支撑它们的同一套标准就是 Label 309。这是理解 CardanoWall 最简单的方式:它不只是一个把哈希放上区块链的地方,而是一套分层的方法,让记录变得持久、私密、可验证——从一个纯粹的时间戳起步,只在某个场景真正需要时才叠加相应的保护。
第 1 层:哈希——证明确切的字节在某个时间之前已经存在
第一层就是经典的存在性证明。
你拿出一份文件、消息、数据集、媒体素材、构建产物、报告或清单。CardanoWall 会对这段确切的字节计算一个密码学哈希,并把这个哈希发布到 Cardano 上的一条 Label 309 记录里。
日后,任何持有同一份原始字节的人都能再算一次哈希。如果它与记录中的哈希一致,验证方就能确认这段确切的字节不晚于该交易的区块时间已经存在。这项检查针对公开的 Cardano 链进行——它不需要 CardanoWall 账户,也不信任任何 CardanoWall 服务器。
有用之处在于:文件本身永远不必公开。一份私密合同、一个数据集快照、一份软件发布清单,或是一个法律证据包,都可以携带一份公开的证明。记录所说的是这段字节曾经存在,而不必展示这段字节。
哈希证明适合用在什么场景?
当问题关乎时间与完整性时,哈希证明的力量很强。它能回答这类问题:
- 这份确切的文件是否在截止期限之前就已存在?
- 这是不是上个月被加过时间戳的那份 PDF?
- 这份发布清单是否在事故发生之前就已经提交?
- 这个数据集快照是否在模型用它训练之前就已存在?
- 这份媒体文件是否在被编辑或引发争议之前就已存在?
它们还很高效。一份数 GB 的文件会被压缩成一段短短的摘要,而一份私密文件无需披露内容就能变成一份公开的承诺。
局限同样重要:哈希并不能证明文件由谁创建、文件内容是否属实,也不能证明文件归谁所有。它证明的是确切的字节在某个公开时间之前已经存在——仅此而已。对许多工作流来说,这已经足够。对其余的场景,CardanoWall 会叠加接下来的层级。
第 2 层:签名——为记录附上身份密钥
第二层加入了签名。
签名让一个密钥为记录背书。除了证明字节曾经存在,记录还能表明某个特定的身份密钥对这份证明做了签名。在 Label 309 中,这是一份对记录主体的可选的、分离式 COSE_Sign1 签名,而且作者身份从不是必需的——一条没有签名的记录,仍然是一份完整、可被充分验证的证明。
这个选项改变了它在实践中的含义。对个人创作者来说,一条已签名的记录可以把一件作品与创作者的 CardanoWall 身份关联起来。对企业来说,它可以表明一个获批的密钥为某份报告、发布清单、合规快照或数据集承诺背书。对自动化工作流来说,它把「有人给这份文件加了时间戳」与「我们的系统作为流程的一部分给这条记录做了签名」区分开来。
签名并不取代哈希;它叠在哈希之上。
- 哈希说的是:这段确切的字节曾经存在。
- 签名说的是:这个密钥对发出该声明的那条记录做了签名。
签名不能证明什么?
签名很强大,但它不是魔法。
签名证明的是在签名那一刻对某个密钥的掌控。它本身并不能证明那个密钥背后的人或公司在现实世界中的身份。那个身份来自上下文:密钥是如何创建的、如何公布的、组织如何管理它,以及他人如何逐渐信任它。
签名同样不能证明签名者支付了交易费用,或是把交易提交到了 Cardano。在 Label 309 中,签名覆盖的是记录主体,而非整笔 Cardano 交易。这是刻意为之,也正是它让记录保持可移植的原因:一个网关、一套自动化系统,或任何第三方,都可以发布一条已签名记录,而不会因此成为内容的作者。一份通过验证的签名读作「由这个密钥签名」——绝不是「这个密钥提交了交易」。
简单地说:当你希望证明不仅说出「这曾经存在」,还说出「这个身份为这份证明背书」时,就用签名。
第 3 层:封存——把加密副本与证明一起保存
第三层加入了加密保存。
纯哈希证明有一个实际的弱点:验证方仍然需要原始字节。一旦文件丢失,或哪怕只改动了一个字节,你就再也拿不出能与记录匹配的内容了。
封存通过对文件加密,并把加密后的载荷与证明一起保存在内容寻址位置(如 Arweave 或 IPFS)来解决这个问题。链上记录承诺的依然是明文哈希——绝不是密文——因此时间戳声明保持不变。文件从不以明文形式公开。任何持有正确密钥的人,日后都能取回密文、解密、重新计算明文哈希,并证明这就是那条记录背后的文件。
这改变了使用体验。用纯哈希证明时,你要自己保管原始文件。用封存证明时,你可以把原始文件的加密副本作为证明工作流本身的一部分保存下来。
什么时候值得做封存?
当原始文件足够重要、重要到丢失它就会削弱证明的程度时,封存就有意义了。可以想想这些情况:
- 法律证据包与已签署的合同;
- 合规报告与敏感的事故日志;
- 原始创意文件与研究数据;
- 数据集清单、AI 提示词与输出,以及发布产物。
在每一种情况里,哈希都有用,但原始字节才是你日后可能需要拿出来的东西。封存式存在性证明让你能把这些字节加密保存,同时时间戳保持公开。链证明时间线,加密保护内容。
第 4 层:分享——把封存文件投递给特定接收方
第四层加入了面向接收方的私密投递。
有时证明不只是为了你自己。你可能需要把加密后的证据发给律师、审计方、合作伙伴、记者、客户、监管机构,或内部团队。
如果你知道接收方的接收地址,CardanoWall 就能创建一条封存记录,让接收方日后能用自己的密钥打开它。这条记录依然带有公开的时间戳,依然承诺明文哈希,依然可以保存一份加密文件。但现在,加密后的载荷可以由特定接收方打开,而不只是发送方。正是在这里,CardanoWall 开始不太像一个加时间戳的工具,而更像一套安全的记录投递系统。
没有公开通讯录,私密投递是怎么实现的?
接收方投递不需要链上的公开通讯录,任何接收方的公钥也绝不会作为可读字段写进记录里。
流程是这样的。接收方拥有一个接收地址。发送方通过带外渠道获得它——直接从接收方处,或从个人资料、公司页面,或另一条可信渠道。当发送方构建一条封存记录时,信封里会携带按接收方划分的加密密钥槽,只有目标接收方才能打开。
在接收一侧,接收方的软件会扫描公开的封存记录并试解密——它在本地用自己的密钥逐个尝试每个密钥槽。当某个槽被打开时,这条记录就会出现在该接收方的收件箱里。服务器从不解密消息,也无需知道接收方是谁。(接收方一侧的细节,参见如何接收封存记录。)
这并不是对完美匿名性的承诺。时机、支付流、网络元数据、浏览器行为以及操作失误,都仍可能泄露信息,而接收方在解密之后随时可以把明文分享出去。这套设计真正提供的东西更窄、也更实在:Label 309 记录本身既不公布明文,也不公布人类可读的接收方名单——观察者只能看到某条记录是封存的、它携带了多少个密钥槽,却永远看不到发给了谁。
后量子加密为什么属于「分享」这个故事的一部分?
封存记录可能存续很长时间。如果加密内容被永久或半永久地存储,攻击者并不需要今天就破解它:他们可以现在就把密文存下来,等日后用更好的硬件和更强的密码分析再试。这就是「先收集、后解密」的问题。
正因如此,Label 309 认真对待算法敏捷性。接收地址有两种形式——一种是经典的 X25519 地址,另一种是可选的混合后量子地址,它把 X25519 与 ML-KEM-768 结合在一起(一种 X-Wing 式的构造)。混合方案把经典 X25519 的安全性作为底线保留下来,同时增加了对未来量子攻击者的抵抗力,因此对于那些注定要比当下密码学假设存续得更久的内容,它是更好的默认选择。重点不在于宣称永久的安全性——任何诚实的人都做不到这一点——而在于避免设计出一套假定「今天的密码学安逸会永远成立」的证明系统。
面向用户的版本则保持简单:保护好你的身份种子,当接收方公布了混合后量子接收地址时优先使用它,剩下的密码学交给软件处理。
这四个层级如何协同工作?
这些层级不是各自独立的产品。它们是同一套标准之上的若干层:
- 当你只需要一个时间戳时,发布一份纯哈希证明。
- 当你希望一个身份密钥为记录背书时,加上签名。
- 当保存确切的原始字节很重要时,对文件做封存。
- 当特定接收方需要私密访问时,分享这份封存文件。
由于同一套底层标准支持每一种选择,你可以从简单起步,只在场景需要时才伸手去拿更强的层级。
你该用哪个层级?
- 当原始文件容易保管、而唯一的问题是这段字节是否在某个时间之前已经存在时,用哈希。
- 当你希望一个有密钥背书的身份为证明站台时,用签名。
- 当原始字节足够敏感或重要、值得把加密副本与证明一起保存时,用封存。
- 当其他人需要接收加密内容并在日后验证它时,用分享。
此外还有第五样工具,它横跨这四层:Merkle 批处理,用于当你的哈希太多、不便逐一发布时——CI/CD 产物、每日日志、数据集快照、生成的媒体,或任何需要把成千上万个项目承诺在同一条记录与同一个根之下的工作流。
这些证明仍然无法证明什么?
即便用上全部四个层级,存在性证明对自己的声明依然保持精确。
它能证明确切的字节曾经存在、某个密钥对记录做了签名、加密内容被保存了下来、内容被投递给了特定的密钥,并且——配合一个 Merkle 根——某个项目属于一个已承诺的批次。
但它本身并不能证明内容属实、不能证明任何人持有合法所有权、不能证明数据集是合法采集的,也不能证明一个薄弱的流程是稳健的。关于这些边界的更多内容,参见证明不能证明什么。CardanoWall 给你一层持久的证明;围绕这份证明的业务流程依然重要。
一句话版本
- 哈希是时间戳。
- 签名是身份声明。
- 封存是加密保存。
- 分享是私密投递。
它们合在一起,把存在性证明从链上一个光秃秃的哈希,变成一套可用的工作流,覆盖文件、数据集、证据、软件发布、AI 输出以及机密记录——而且因为 Label 309 是一套带有开源工具的开放标准,同样这四个层级在网站上、在 CLI 里,或在任何其他人的实现中,都同样有效。
延伸阅读
- 什么是存在性证明? ——深入讲解哈希这一层。
- 如何接收封存记录 ——「分享」中接收方的一侧。
- 一条记录,对应成千上万份文件 ——横跨四个层级的 Merkle 批处理。
- 证明不能证明什么 ——需要牢记的边界。
- Label 309 ——这套开放标准,已提交至 Cardano CIP 流程,正由 CIP 编辑审阅(PR #1205)。
- github.com/cardanowall ——开源的 SDK 与
cardanowallCLI。