如何接收一份封存记录

要接收一份封存记录，你只需分享一个接收地址，让你的软件去找出你的密钥能打开的记录。没有哪个服务器会替你填好信箱。你的客户端扫描公开的 Label 309 信息流，用你的接收密钥逐一尝试每份封存记录，再把成功解密的那些展示出来。

这种反转就是整个思路的核心：你的收件箱是靠解密被发现的，而不是由服务器指派的。链上从不携带可读的接收方字段，网关也无需知道哪些记录属于你。

什么是封存记录？

封存记录就是一份内容经过加密的存在性证明（Proof of Existence）。

公开记录仍然会对明文哈希作出承诺，因此这份证明日后能证明：那份确切的内容在某个公开的区块时间之前就已存在。文件本身经过加密，密文存放在内容寻址位置，例如 Arweave 或 IPFS——绝不在链上。（关于公开证明的运作机制，参见 Label 309 的运作原理。）

任何持有匹配密钥的人都能解密这段密文、还原出原始字节、重新计算明文哈希，并确认解密后的文件与链上承诺一致。没有密钥的人只能看到一份封存记录存在——但应当无法读取其中的内容。

我要给发送方什么？

你给发送方一个接收地址。仅此而已。

对于 Label 309 封存记录，接收地址有两种形式：

age1…——经典的 X25519 接收路径。
age1pqc1…——混合后量子接收路径（在 X-Wing 构造中将 X25519 与 ML-KEM-768 结合）。

接收地址是公开的，可以放心分享。它只能让别人向你加密一份记录，除此之外什么都做不了。它由你的身份派生而来，却不会泄露你的身份。

不要把你的身份种子给发送方。种子是你身份的私有根——那 32 字节是你的签名密钥和接收密钥确定性派生的源头。任何持有它的人都能以你的名义签名和解密。（关于种子为何才是真正的备份，详见你的身份就是一颗种子。）

发送方如何创建这份记录？

发送方的软件在本地完成封存。大致流程如下：

发送方选定一个文件或一条消息。
软件计算明文哈希。
软件生成一个一次性内容密钥，并加密内容。
对每一个接收方，它把这个内容密钥包裹到接收方的接收密钥上，生成一个按接收方划分的密钥槽。
密文被上传到内容寻址存储（例如 ar://）。
一份 Label 309 记录在 Cardano 上发布，携带明文哈希与封存信封。

链上记录证明了时间，并承载着包裹后的密钥槽。存储中的密文则保存着加密文件。能打开你那个密钥槽的，正是你的私钥。同样这套流程——哈希、签名、封存、分享——在哈希、签名、封存、分享中有逐步讲解。

我的客户端如何找到发给我的记录？

你的客户端扫描公开记录，并尝试打开它们。

如果你习惯了普通信箱，这一部分会让人觉得陌生。在托管式收件箱里，服务器知道某条消息属于哪个账户，并据此路由。一份封存的 Label 309 记录则不带这类路由信息。信封里列着包裹后的密钥槽，但对外公开的数据里任何地方都不会出现接收方公钥——根本没有可供读取的收件地址字段。

于是你的客户端同步 Label 309 记录的公开信息流，对其中每一份封存记录，逐一测试是否有某个密钥槽能用你身份的接收密钥打开。这就是本地试解密：尝试解开每一个密钥槽，全程在你的设备上完成。如果某个密钥槽打开了，这份记录就是你的，你的客户端会把它加入你的收件箱。如果没有一个能打开，客户端就忽略它。

还有一个不起眼却重要的后果：密钥槽的排列顺序也不会泄露任何信息。发送方会在发布前打乱密钥槽，因此即便是「主接收方」的位置也不携带任何信号。

试解密非得下载每个文件吗？

不需要。试解密针对的是链上记录里携带的信封，而不是存储中的文件。

包裹后的密钥槽和一小段认证标签就存放在记录元数据本身里。你的客户端仅凭这些链上字节，就能判定某份记录是否发给你——并还原出内容密钥——在获取任何密文之前就能做到。这一点很重要，因为密文可能很大：桌面客户端可以先发现哪些记录属于你，再在你打开时按需懒加载加密文件，或者按你的设置预先缓存。

对于离线优先的客户端来说，这种拆分正是其根基：

同步公开的记录信息流；
针对信封在本地做试解密；
如果你需要，就缓存匹配到的密文；
在你打开文件时按需解密；
让所有已同步的内容在无网络时依然可用。

网关究竟知道什么？

网关知道的，就是任何公开观察者都能知道的内容，再加上它所运行服务的运营细节。

对于托管式网关，这可能包括账户活动、API 使用情况、你的报价与发布流程、上传活动、余额状态、网络层基础设施数据，以及人人都能看到的公开记录元数据。（关于这条边界的全貌，参见 CardanoWall 能看到什么。）

它不需要的，是你的身份种子、你的接收私钥，或任何替你解密封存内容的能力。这里的隐私特性并不是「服务器对一切都一无所知」——那样说就不诚实了。它更窄，也更有用：接收方匹配与解密都在本地进行，因此不会发布任何可读的接收方字段，也绝不会有私钥被发送到网关。网关在设计上对接收方一无所知；任何按接收方筛选记录的尝试都会被直接忽略，因为根本没有可供筛选的接收方列。

为什么不设一个公开的接收方字段？

因为公开的接收方字段会泄露社交图谱。

如果每份封存记录都标明它确切是给谁的，观察者无需读取一个字节的明文，就能勾勒出发送方与接收方之间的关系。对于机密工作流——线人联系新闻编辑室、一份封存的投标、托管中的证据——这种暴露本身可能就是全部的风险所在。

Label 309 改用包裹后的密钥槽。记录携带的是加密材料，只有目标密钥持有者才能打开。观察者能看到一份记录是封存的、以及它有多少个密钥槽，但看不到一份可读的接收方名单。

这并非完美的匿名，也不该被当作完美匿名来兜售。密钥槽数量、发布时机和外部元数据仍可能透露一些信息；一个需要击败时间相关性分析的发送方，必须在敏感时间线之外发布。这套设计消除的，是最显而易见的泄露：永久账本上那一栏公开的接收方列。

如果我有好几个身份怎么办？

你的客户端会逐一尝试每一个已解锁的身份。

你或许会为个人记录留一个身份，为公司留一个，为法务收件留一个，再为高风险机密渠道留一个。每个身份都有自己的种子和自己的接收密钥，因此封存给其中一个身份的记录，在尝试那个身份的密钥之前，对其他身份都是不可见的。

离线优先的客户端会独立追踪每个身份在记录信息流中扫描到了哪里。正是这种独立性，让你日后可以导入一颗旧种子，并让客户端为那个身份重新扫描整个信息流——而不是从今天开始，悄无声息地错过导入之前发来的一切。

我恢复一颗旧的身份种子时会发生什么？

兼容的软件会从种子确定性地重新派生出相同的接收密钥。

这意味着一颗旧种子能找回旧的封存记录，只要这些记录仍在链上可供扫描、且密文仍可获取或已缓存。客户端重新扫描公开信息流，对封存信封做试解密，并为那个身份重建收件箱视图。恢复种子，就恢复了识别发给它的记录的能力——网关并不保管什么私有信箱可以交还给你。

这正是种子如此重要的最清晰理由之一，也是身份种子依然值得你重视的原因。如果你丢失了某个接收身份的种子，发给它的封存记录可能会变得无法读取——即便公开证明仍留在链上、仍能持续通过验证。加密在设计上没有任何恢复后门；种子就是那条恢复路径。

桌面客户端能离线接收记录吗？

它能用上自己已经同步好的一切。

CardanoWall Desktop——一款用 Tauri 构建、基于开源 Rust SDK（github.com/cardanowall）的开源 Rust 应用——正是围绕这一点打造的。一旦它同步了记录并缓存了密文，就能在没有网络连接的情况下列出、搜索、验证并解密这些本地数据。如果某份记录尚未同步，或某段密文尚未获取，它就需要网络去取回这些内容——而且会直接坦白说明，而不是悄无声息地失败。

这与一款严肃的电子邮件客户端的行为如出一辙：离线不等于世界停摆。在网络恢复之前，你的本地镜像、缓存和保险库就是事实的来源。（关于离线模型的更多内容：离线证明和 CardanoWall Desktop。）

我该如何验证一份记录是谁发来的？

收到一份封存记录，只能证明你的密钥能打开它。它并不能证明是谁发送的。

在 Label 309 中，作者身份是可选的。如果一份记录带有签名，这个签名表明某个特定密钥为该记录背书——但你仍需要上下文才能判断那是谁的密钥。如果一份记录未签名，发送方可能是有意不绑定任何身份，而这恰恰是某些机密工作流所要求的。

对于敏感材料，要通过带外渠道确认发送方密钥与接收地址：维护一份通讯录，比对密钥指纹，借助一个你早已信任的目录或直接确认。加密保护的是内容；判断你正在与谁的密钥打交道，是另一项独立的、由人来做的信任决策。通讯录的运作机制在通讯录的运作原理中有讲解。

可能出哪些问题？

后果最严重的失败是丢失种子。一旦丢失某个接收身份的身份种子，你可能就会失去解密发给它的记录的能力——对那个身份而言，是永久性的。

其余的都属于运营层面的问题，好的软件应当诚实地把它们呈现出来，而不是藏起来：

密文从未成功上传；
存储位置暂时不可用；
发送方用错了接收地址；
你导入了错误的身份；
本地设备已被攻陷（一台已解锁机器上的恶意程序能读取内存中的秘密——参见公用电脑模式）；
这份记录太新，尚未达到你要求的确认深度；
这份记录有效但未签名，因此无法确立发送方身份。

一套证明系统是靠展示不确定性来赢得信任的，而不是靠把它掩盖过去。

简短版

要接收封存记录：

分享一个接收地址。
妥善保管并备份你的身份种子。
让你的客户端扫描公开的 Label 309 信息流。
让它在本地做试解密。
打开并验证你的密钥能解密的那些记录。

你的收件箱不是服务端那份发给你账户的消息列表。它是你的身份能打开的封存记录的本地视图——而这恰恰是让网关无从插足你私密通信的关键所在。

最后，关于局限，再说一句诚实的话：封存记录为它的密钥持有者保持明文加密，但它并不保证匿名，而且任何解密了它的人都可以事后选择把明文泄露出去。证明所展示的，是特定字节在某个公开时间之前已存在。它不证明真相、所有权或作者身份——参见证明不能证明什么。