CardanoWall 通讯录的工作原理

CardanoWall 通讯录是一份私有的已验证联系人清单，让你按名字向某人封存记录，而不必手动粘贴对方的接收地址。每个条目都保存着你识别某人或某个团队、并向其加密所需的公钥——他们的签名密钥，以及可选的接收地址——再加上一条说明，记录你是如何核实这些密钥确实属于他们的。

它是 CardanoWall 应用里的一层便利与安全机制。它不会改动 Label 309 标准，也不会出现在任何记录中。当你封存一个文件时，通讯录只是你的应用在发布前用来查找正确密钥的地方。

通讯录解决了什么问题？

它去掉了封存记录中最危险的一步：手动粘贴公钥。

封存记录是向一个或多个「接收地址」加密的，这些接收地址是以一长串 age1... 或 age1pqc... 形式书写的公钥。它们本来就不是给人阅读或重新输入的。只要错一个字符，你就可能加密到错误的密钥上——结果要么是目标接收方打不开文件，要么更糟，错误的一方反而能打开。

通讯录把「粘贴这串 60 个字符」变成了「发送给 Alice Legal」。你只需认真验证一次，保存下来，之后反复使用。这带来了便利，但更重要的是：在一个事关重大的文件上，密钥处理出错的机会变少了。

一个受信任的联系人会保存哪些信息？

每个联系人都是一小组公开事实，且限定在你的账户范围内：

一个你自己设定的显示名称；
联系人的 Ed25519 签名公钥（必填——这是联系人的标识符）；
一个可选的经典接收地址（age1...，即一个 X25519 密钥）；
一个可选的混合后量子接收地址（age1pqc...）；
你如何验证该联系人，记录为以下几种方式之一：当面验证、QR 码交接、一条 DNS TXT 记录、一个 .well-known 页面，或一次手动核对；
你验证它的时间；
自由格式的备注。

这里没有任何私钥，也没有任何机密。一个联系人就是你自己关于他人公钥、以及你对其信任程度的记录。

两个接收地址相互独立，且都是可选的。一个联系人可以带其中一个、两个都带，或一个都不带。只有签名密钥的条目仍然有用，可以用来识别那个人的签名，但在添加接收地址之前你无法向它封存文件——在那种模式下，编辑器根本不会把它列为可选的接收方。

为什么要保存 Ed25519 签名密钥？

因为密钥才是身份——名字只是一个标签。

在 Label 309 中，作者身份通过可选的记录签名来表达，而 Ed25519 公钥正是用来验证这些签名的。如果一条已签名记录声称来自你认识的某个人，那么密钥字节才是你的软件真正核对的东西。两个人可以取同一个显示名称；而公钥才是你能精确比对的稳定标识符。

所以联系人保存的是这个密码学标识符，并把你可读的标签固定到它上面。当一条已签名记录到达时，你能看到「这与 Alice 保存的密钥一致」，而不必眯着眼去比对一串十六进制。

为什么要保存接收地址，又为什么是两个？

接收地址是你加密时要「发给」的密钥，CardanoWall 支持两种类型。

经典的 age1... 地址使用 X25519，更短一些。混合的 age1pqc... 地址把 X25519 与一个后量子密钥配对，长得多——这是为长期保存的敏感内容抵御未来量子攻击者所付出的代价。（关于两者的区别，详见什么是接收地址。）

把它们保存在联系人里，能让编辑器根据你正在使用的加密模式提供正确的接收方。如果你用经典方案封存，它会显示带有经典地址的联系人；如果你用混合方案，它会显示带有混合地址的联系人。如果某个联系人在当前模式下没有对应地址，应用不会假装自己能向其加密——它会把这个联系人从列表中排除，而不是凭猜测处理。

保存了联系人，就能证明这些密钥属于一个真实的人吗？

不能。通讯录记录的是「你」相信什么、以及「你」是怎么核对的——仅此而已。

一个条目并不能证明某个密钥属于某个特定的人、公司、新闻编辑室、审计方或监管机构。它做不到这一点；核实这种关联是人工的工作，并且始终是你的责任。通讯录的职责是「保存」你已经做过的验证，让你不必重复一遍——而不是替你去做验证。

在保存联系人之前，合理的验证方式包括：

当面交换密钥，或面对面扫描一个 QR 码；
从你信任的某个域名上的 DNS TXT 记录或 .well-known 页面确认它；
对照一份已签名的公开档案核对它；
拨打一个已知号码，或使用一条既有的安全渠道，回读密钥；
遵循某家公司既定的密钥交换流程。

对于敏感文件，请通过两条彼此独立的渠道确认密钥，而不是只用一条。在封存文件前验证接收方对此有更深入的讲解。

通讯录是公开的，还是存在链上的？

都不是。它是账户本地的服务数据，永远不会离开 CardanoWall。

你的联系人不会被写入 Label 309 记录，也永远不会接触区块链或 Arweave。一条封存记录包含的是加密槽——封装给各接收方的密钥——而不是一份可读的通讯录条目；旁观者无法从已发布的内容中重建你的联系人清单。

话虽如此，通讯录本身仍然是敏感的。名字、备注和验证方式都可能暴露关系与工作流。CardanoWall 把每个联系人都限定在你的账户范围内，使其不会跨账户泄露，而服务端也会把这些细节排除在日志之外：联系人操作记录中只有一个请求标识符和你的账户标识符，绝不包含密钥、名字或备注本身。

通讯录如何帮助编辑器？

它把保存的公钥变成一份按名字挑选的接收方列表。

当你创建一条封存记录时，编辑器会加载那些在当前模式下带有接收地址的联系人，让你按名字选择接收方。应用会自动填入正确的地址；你永远不必重新输入。这让反复进行的投递大大降低了出错的几率：

反复出现的法律披露和电子取证（e-discovery）交接；
审计方与合规投递；
新闻编辑室或举报人受理；
合作伙伴之间、团队之间的证据共享；
某位客户的安全联系人；
你自己的备份接收方。

手动粘贴一长串密钥的次数越少，粘贴错密钥的机会就越少。

联系人的备注里该写什么？

只写那些日后能帮你信任这个条目的内容——并且不写任何机密。

好的备注会记下你「如何」以及「何时」验证，这样一位同事（或未来的你）就能判断是否可以依赖它：

「2026-06-02 在里斯本办公室当面验证」；
「已在 example.com 上核对 DNS TXT」；
「视频通话时由 Alice 出示的 QR 码」；
「来自该公司已签名的安全页面」；
「由以 ab90 结尾的旧密钥轮换而来」；
「法律文件请使用后量子地址。」

切勿在备注里写入机密。通讯录不是身份保险库——备注是普通的服务数据，所以把它当作一张通讯录名片来对待，而不是密码库。

联系人轮换密钥时会怎样？

把新密钥当作一个需要重新验证的全新事实，绝不要当成一次自动更新。

密钥会变：一家公司会轮换它的接收地址，一个团队会从经典地址转到混合地址，或者一个被攻破的身份会被替换掉。你如何更新联系人，取决于「哪个」密钥变了。

一个新的接收地址可以就地编辑进现有联系人——签名密钥仍然标识着同一个人。
一个新的签名密钥实际上就是一个新身份，所以它会成为一个新的联系人条目；旧条目你可以按需保留或删除。

无论哪种情况，步骤都是一样的：

在保存之前，通过一条受信任的渠道验证新密钥；
在备注里记下你是如何验证它的；
停止向旧地址发送敏感文件；
留一条关于此次轮换的简短备注，让历史清晰可查。

要避免的陷阱是：仅仅因为新密钥来自同一条渠道，就信任它——而那条渠道本身可能已经被攻破。一份轮换通告的可信度，取决于它所经由的渠道。

简短版本

通讯录是为人服务的一层安全机制。Label 309 以公钥运作；而人是以名字和关系来打交道的。CardanoWall 的通讯录把两者连接起来——把一个已验证的联系人保存一次，之后按名字挑选接收方，从发送封存记录的过程中剔除失误。

它本身并不能证明任何人的身份，而一份证明也始终只表明特定的字节在某个给定时间之前存在，并不表明谁拥有或撰写了它们。通讯录所做的，是保存你已经完成的验证工作，让你能够安全地重复使用它。