CardanoWall 能看到什么（又看不到什么）

CardanoWall 能看到普通的服务数据，以及你发布的那些公开证明记录。按照设计，它看不到你的身份种子明文、你的私钥，也看不到你封存文件的明文。最敏感的材料只在你的设备上持有和使用，而不在我们的服务器上。

这才是隐私模型诚实的说法。CardanoWall 是一款基于网关构建的托管产品，因此它确实需要账户、计费、发布和索引数据才能运转。真正值得问的问题不是「CardanoWall 到底看不看得到东西？」——它当然看得到。真正值得问的是：它看到的是「哪一类」数据，又有哪些对我们始终保持加密。

本文将逐类厘清这条界线。

CardanoWall 会存储哪些账户数据？

就是普通的托管服务数据。根据你使用产品的方式不同，这些数据可能包括：

• 你的账户标识符
• 登录标识符，例如邮箱地址或已关联的 OAuth 账户引用
• 计费记录和你的预付余额
• API key 的元数据及其哈希形式（绝不存明文 key）
• 充值用的支付处理方引用
• 账户级设置
• 账户操作的时间戳
• 支持与运维相关的元数据
• 限流与安全日志

这与任何基于账户的服务所持有的数据形态完全一致。其中没有一项是你的身份种子。

它能看到哪些身份数据？

公开的身份密钥——仅此而已，没有任何私密内容。

在 CardanoWall 中，一个身份由单个 32 字节的身份种子确定性地派生而来，而该身份的「公开」密钥正是服务完成本职工作所需要的：列出你的身份、统计它签名过的证明数量、在通过持有证明后将身份与你的账户关联起来，以及在你选择发布公开资料时展示它。

因此，服务能够看到诸如以下的公开身份数据：

• Ed25519 签名公钥
• X25519 接收公钥
• 可选的混合后量子接收公钥
• 该身份在服务数据库中的创建时间
• 账户与身份之间的关联状态
• 你启用的任何公开资料字段

这些都是公开的或服务层面的事实。它们不是私有的签名密钥，也不是私有的接收密钥，而且无法被反推回你的种子。

服务器永远不需要看到什么？

任何能让它冒充你行事的东西。服务器并不需要、也被设计为不以可用形式持有：

• 身份种子明文
• Ed25519 私有签名密钥
• X25519 私有接收密钥
• 混合（后量子）接收私钥
• 你的通行密钥所产生的解锁材料
• 你身份保险库的解密内容
• 封存文件的解密明文

这一切在你解锁之后都只存在于你的设备上，或存在于你自己掌控的备份里。一个身份的便携、规范副本就是它的种子——真正的备份是这一份产物，而不是托管的便利层。

加密保险库会向服务器透露什么？

它存在——除此之外几乎没有别的。

为了让你能在新设备上用通行密钥解锁，CardanoWall 为每个账户存储一行当前的加密保险库。服务器可以读取该行的元数据——它上次更新的时间、版本号，以及与之关联的是哪些已注册的通行密钥凭证——因为它需要这些信息来处理解锁的交互体验和生命周期管理。

服务器做不到的，是解密这个保险库。该保险库是一段 age 风格的密文，仅寻址到你的 WebAuthn 通行密钥解锁因子（PRF stanza）。这里刻意没有任何由密码派生的解锁路径，也没有添加任何公钥接收方，因此存储的密文不会暴露任何服务器能离线穷举的内容。这是一层服务端的便利，而非托管：我们保管的是上了锁的盒子，唯一的钥匙在你的通行密钥手里。

保险库的明文里包含你的身份种子和你的私有显示标签——正是那些绝不能被服务器读取的材料。同样的设计也支配着吊销机制：移除一把通行密钥时，保险库会重新加密到你剩余的因子上，并彻底删除此前的密文，于是被移除的认证器再也打不开「当前的保险库」。这对当前状态而言是真正的吊销，但它不具有追溯性——攻击者此前已经导出、且仍能打开的某个副本，是另一个独立的问题。通行密钥如何保护你的身份保险库对此有更深入的讲解。

哪些证明数据是公开的？

证明本身。Label 309 记录之所以发布到 Cardano 上，正是为了让任何持有交易引用的人都能验证它们。根据记录的不同，公开数据可能包括：

• 内容哈希
• 交易引用
• 链所赋予的区块时间
• 记录的结构
• 当作者选择签名时的签名及签名者公钥
• 批处理记录的 Merkle 根
• 加密信封元数据
• 内容寻址存储的 URI（ar://、ipfs://）
• 加密接收方密钥槽的数量
• 封存记录所使用的密钥交换族

这些数据公开是有意为之：正是它们让一份证明在无需信任 CardanoWall 的前提下可被验证。对于封存记录，请留意那里「没有」什么——文件的明文绝不会上链。旁观者能看到一份记录是封存的、它有多少个接收方密钥槽、它使用哪个密钥交换族，却看不到接收方是谁，也看不到内容。

存储网关能看到什么？

存储的字节和请求元数据。

如果一份记录指向 Arweave 或 IPFS 上的内容，那么提供这些字节的公开网关就能看到针对它们的请求。对于公开文件，这些字节是明文。对于封存文件，这些字节是密文，在没有接收方私钥的情况下它们应当始终不可读。

网关还能观察到时序、对象大小和请求模式。它们不是可以托付机密性的地方。这正是为什么要在敏感文件进入存储「之前」就把它封存，而不是指望存储层来替你保密。

在你解锁期间，浏览器能看到什么？

它需要的一切，足以让它以你的身份行事——只要会话保持解锁状态。

解锁之后，你的身份种子以及由它们派生出的私钥会驻留在浏览器的会话内存中，好让应用能够签名和解密。当你解密一份封存文件时，明文也会在浏览器里。在锁定或登出时，这些驻留在内存中的材料会尽力而为地被清零。

这是客户端隐私，而且它对自身的局限毫不掩饰。把机密留在你的设备上能让你免于服务器托管，但这也意味着你的设备和浏览器环境很重要。一个恶意的浏览器扩展、有敌意的本地软件，或在解锁会话期间被激活的跨站脚本漏洞，都能读取内存中的内容。严格的内容安全标头、脚本极少的解锁流程，以及仅在明确操作时才解锁，这些做法都能降低这种暴露——但无法将其彻底消除。对于敏感身份，请使用你信任的设备；浏览器存储与会话密钥详细说明了哪些内容会被缓存、哪些不会。

通讯录会暴露什么？

你的联系人列表属于服务数据，它本身也可能是敏感的。

可信联系人是账户本地的条目，省得你每次给某人封存文件时都要粘贴长长的公钥。一个条目可以保存显示名、签名公钥、可选的接收地址（经典与后量子）、你验证该联系人的方式和时间，以及自由格式的备注。

这些都不是身份种子，但一份「你与谁往来」的清单可以揭示关系和工作流。CardanoWall 的日志在编写时就刻意保持沉默：服务端创建和编辑联系人的操作只记录一个请求标识符和你的账户标识符——绝不记录联系人的姓名、密钥、备注或验证方式。

CardanoWall 「不」承诺什么？

它不承诺隐身。

CardanoWall 不是一个匿名网络。区块链、存储网关、支付系统、你的账户登录、你的浏览器，以及你的网络路径，都可能暴露元数据。发布一份「未签名」的封存记录，能让发送方、接收方和明文都不出现在 Label 309 记录本身之中——但那是记录级别的隐私，而非完全的匿名。支付手续费的 Cardano 地址、网关所看到的你的 IP，以及类似的信号，都存在于记录之外，也在这份保证之外。

它同样无法让一台已被攻陷的设备变得安全。如果你已解锁的会话上运行着恶意代码，那段代码就能看到你能看到的一切。

而且，一份已发布的证明在设计上就是公开的。它表明特定的字节在某个特定的公开时间之前就已存在。它本身并不能证明是谁创作了这些字节、谁拥有它们，或者它们的内容是真实的——这一边界请参见证明不能证明什么。

简短版

CardanoWall 能看到服务数据和公开证明数据。按照设计，它看不到你的身份种子明文、你的私钥、你的保险库明文，也看不到封存文件的明文。

所以，在实践中：在敏感文件离开你的设备之前先把它封存，妥善保存一份你的种子副本，只在你信任的设备上解锁，并把你发布到链上的任何东西都当作永久公开来对待。

良好的隐私始于清楚地知道每一类数据究竟存放在哪里——而 CardanoWall 的构建方式，正是让最重要的数据存放在你这里。

延伸阅读

CardanoWall 是 Label 309 的参考实现——一项开放、厂商中立的存在性证明（Proof of Existence）标准。该标准已提交至 Cardano 的 CIP 流程，目前作为元数据类提案正由 CIP 编辑审阅（开放中的 PR）。其密码学核心、SDK 和命令行工具均在 github.com/cardanowall 上开源，因此你可以亲自审计你的设备上究竟计算了什么，而不必只听我们的一面之词。