协议演进实录：从明文哈希到 AES-GCM 加密，如何平滑升级？

在上一篇文章《从 0 到 1：我用 300 行代码给 AI 记忆加上了"不可篡改的收据"》中，我开源了 AMP (Attestation Memory Protocol) 的 v0.1 版本。

v0.1 解决了一个核心痛点：审计追踪 。通过 Hash Chain，我们能向用户证明"AI 没有偷偷篡改你的记忆"。但很多朋友在评论区提出了新的疑问：

"如果服务端被攻破，数据是明文的，那哈希链只能证明没被改，不能证明没被偷看啊！"

为了解决这个问题，我把协议升级到了 v0.2.0 ，核心引入了 AES-256-GCM 端到端加密。

但工程上最棘手的点来了：在引入加密的同时，必须保证完全向后兼容（即不能破坏原有的 8 个黑盒一致性测试）。 既然数据加密了，那原来基于明文算出来的哈希值怎么办？

今天就来聊聊我在这套架构设计中的核心思路。

核心设计：密文存储，明文哈希

在传统的数据库加密中，通常加解密是在数据库层面（透明数据加密 TDE），但对应用层来说，返回的依然是一串密文。如果直接把整串密文扔进 Hash Chain 里，由于加密算法引入了随机 IV，相同的明文每次加密出的密文都不一样，这就直接破坏了"证据声明"的确定性。

因此，我采用了 "密文存储，明文哈希" 的设计：

在写入时 ：如果客户端传入 encrypted: true，AMP 会对内容进行 AES-256-GCM 加密，生成 iv、encryptedData 和 authTag，将它们打包成 JSON 存入 content 字段。但用于计算 contentHash 的，依然是用户最初传入的明文内容。
在读取时 ：只有拿到了合法 Grant 权限的客户端，请求到数据后，守护进程才会用派生密钥（scrypt）解密，并将明文返回给客户端。
在验证时 ：任何人依然可以用明文的 contentHash 去和 Hash Chain 里的记录进行比对。

为什么这样设计是安全的？

因为哈希算法（SHA-256）是单向的。即使外部攻击者拿到了完整的 contentHash 和加密的事件日志，他们也绝对无法通过哈希值反推出明文内容。这既保证了隐私（防偷窥），又维持了不可篡改性（防篡改）。

跨设备同步：只追加，不覆盖

除了加密，v0.2 还引入了跨设备同步。

为此新增了两个接口：

GET /v1/sync/export：导出本地的完整事件链和记忆数据。
POST /v1/sync/import：接收其他节点的数据。

同步的最难点在于"冲突处理"。我的设计是只追加合并 ：

当导入一个事件列表时，程序会遍历检查。如果该事件的 hash 在本地已经存在，说明是同源数据，直接跳过；如果不存在，则按序追加到本地的事件链中。这样保证了多个设备的审计链即使存在网络延迟，最终也能收敛成一条最长链。

测试与向后兼容：用结果说话

架构设计得再好，不能跑通也是白搭。我立刻用 v0.1 时期的黑盒测试套件重新跑了这套 v0.2 的代码。

测试用例没有修改哪怕一个字符。

sql 复制代码

PASS write without attestation rejected
PASS grant work scope to app-a
PASS write with full attestation succeeds
PASS read without grant forbidden
PASS read with grant returns attestation
PASS revoke grant
PASS read after revoke forbidden
PASS verify chain ok

8 passed, 0 failed

看到这满屏的 PASS，我才确信这次的协议升级是平滑、安全且完全向后兼容的。

下一步规划：v0.3 与 Merkle Tree

目前 AMP 协议依然保持着 Node.js / Go / Python 三套零依赖实现，以及全绿的 GitHub Actions 自动化流水线。

下一个版本（v0.3），我计划引入 Merkle Tree（默克尔树） 。现在的 Hash Chain 适合单机验证，但如果未来设备节点变多（比如你的手机、电脑、车机都在跑 AMP），我们需要一个更高效的数据结构来验证同步事件的一致性，而 Merkle Tree 就是最优解。

GitHub 仓库 ：github.com/doujiaozh/a... （求个 Star ⭐）
MCP 接入：目前已经支持通过 Model Context Protocol 接入 Cursor 等工具。

如果你对"让 AI 拥有可验证、可携带的隐私记忆"感兴趣，欢迎来仓库提 Issue 交流！