在去中心化社交网络的工程实践中，数据复制与身份迁移一直是核心挑战。AT Protocol（Authenticated Transfer Protocol）作为 Bluesky 的底层协议，通过独特的数据模型与身份层设计，实现了无需依赖单一服务器的数据可移植性。本文将从技术架构角度，解析其双向数据复制与可移植身份的实现机制。
身份层设计：DID 与可配置句柄的分离
AT Protocol 的身份体系建立在去中心化标识符（DID）之上，每个用户拥有不可变的 DID 作为账户的规范标识。与传统用户名不同，DID 是加密绑定的身份凭证，不受任何服务器控制。例如，一个典型的 DID 格式为 did:plc:abc123，其中 plc 代表 PLC（Permissioned Ledger Collection）DID 方法。
在 DID 之上，AT Protocol 允许用户配置人类可读的句柄（Handle），通常是一个 DNS 域名。这种设计实现了身份的可读性与安全性的分离：句柄可以随意更改指向，而底层的 DID 保持不变。当用户需要更换服务提供商时，只需更新 DID 文档中的 PDS（Personal Data Server）地址即可，无需通知所有关注者。
DID 文档是整个身份系统的核心，它是一个 JSON 格式的声明文件，包含用户的当前 PDS URL、句柄以及用于签名验证的公钥。文档公开两种关键角色：签名密钥（Signing Key）由 PDS 保管，用于签署用户的数据仓库更新；恢复密钥（Rotation Key）由用户本地持有，可覆盖签名密钥并在无需原服务器配合的情况下将账户迁移至新的 PDS。
数据模型：签名仓库与默克尔有向无环图
每个用户在 AT Protocol 中拥有一个专属的数据仓库（Repository），存储其所有操作记录，包括帖子、点赞、关注和个人资料编辑等。这个仓库在概念上类似 Git 仓库，但针对数据库记录场景进行了优化。仓库采用默克尔有向无环图（Merkle DAG）结构，每条记录通过内容标识符（CID）进行加密寻址，CID 是基于内容本身的哈希值。
仓库的更新采用追加模式，每次提交都会引用前一个提交，形成一条防篡改的哈希链。所有的提交均由账户的签名密钥签名，确保任何接收到数据的第三方都可以验证数据完整性，而无需信任数据传输的中间服务器。这种 “自验证数据” 设计是 AT Protocol 区别于传统中心化社交网络的关键特征。
AT Protocol 使用 Lexicon（词表）定义数据类型的模式，类似于 JSON Schema 或 Protocol Buffers。核心的 com.atproto.* 词表用于仓库同步，而 app.bsky.* 词表提供基本社交功能。这种模式化设计使得不同开发者构建的应用程序可以一致地解释同一数据类型，实现了协议的互操作性。
PDS 角色与复制语义
个人数据服务器（PDS）是用户在网络中的 “主页”，负责托管用户的数据仓库、接受认证的客户端写入请求、更新默克尔结构、签署提交并向订阅者提供同步数据流。PDS 类似于传统社交网络中的后端服务，但关键区别在于：PDS 只是数据的托管者，而非数据的拥有者。
PDS 暴露的仓库同步协议允许其他服务拉取完整快照（历史仓库）以及后续的增量提交流。每个增量提交都包含默克尔证明和签名，接收方可以独立验证数据的真实性。这意味着即使用户更换了 PDS，新的服务提供商也能够从任何保留有历史数据的 relay 或 indexer 处获取完整的账户历史。
值得注意的是，删除操作在 AT Protocol 中被建模为签名的状态转换，而非真正擦除历史。默克尔结构与签名的组合使其他节点能够观察到某条记录曾经存在而后被删除，这对于一致性索引和内容审核语义至关重要。这种设计在保护用户隐私的同时，也满足了合规性和内容治理的需求。
Relay 与 Indexer：大规模数据复制层
在 PDS 之上，AT Protocol 定义了 Relay（也称为 “大聚合器”）。Relay 订阅多个 PDS，接收它们的仓库更新并广播合并后的事件流。本质上，Relay 是大型复制 hub，存储并转发签名的仓库更新。由于数据带有签名和默克尔证明，Relay 无需被信任即可保持数据完整性。
应用层的 Indexer 则在复制的仓库数据上构建信息流、搜索索引、图查询和内容审核视图。这些服务可以是中心化的、联邦的或应用特定的，但都消费相同的底层认证记录。这种 “大小世界结合” 的拓扑结构意味着：少数大型 Relay 有助于性能和发现，但任何人都可以运行自己的 Relay 或 Indexer，任何 Indexer 也可以从任何 PDS 或 Relay 拉取数据。
AT Protocol 将 “言论” 与 “触达” 分离为两个独立层。底层是开放的言论空间，类似于 Web 上任何人都可以建立网站；上层是索引服务，类似于搜索引擎，提供内容聚合和分发能力。这种分层设计既保证了去中心化的可能性，又为用户体验提供了可扩展性。
可移植身份与可信退出机制
AT Protocol 最重要的工程保证是可移植身份（Portable Identity）。由于 DID 独立于任何特定主机，而仓库是签名的默克尔日志，用户可以通过从一个 PDS 导出仓库并导入到另一个 PDS 来完成迁移，然后更新 DID 文档指向新的 PDS 地址。关注该 DID 的用户和依赖 DID 解析的 Indexer 会自动发现新的 PDS 位置，继续从新位置复制数据，同时保留完整的社交图谱和内容历史。
这种 “可信退出”（Credible Exit）是 AT Protocol 的核心去中心化保证：身份和数据是可移植且可验证的，即使索引和用户体验经常为了规模性和可用性而重新中心化到大型 Relay 和应用程序中。大多数 DID 文档发布两种公钥：签名密钥验证用户的数据仓库，恢复密钥断言 DID 文档本身的更改。签名密钥托管给 PDS 以管理用户数据，而恢复密钥可以由用户本地控制，例如打印在纸张上作为备份。
如果用户的 PDS 突然下线，用户可以通过更新 DID 文档并上传数据备份到新的服务提供商来恢复账户。这种设计确保了用户的数字身份不会因为服务提供商倒闭或恶意行为而永久丢失。
工程实践参数
在实际部署中，PDS 需要满足以下工程要求：仓库同步采用 HTTP 和 WebSocket 两种传输协议，事件流使用标准的 JSON 格式传输增量提交；每个仓库提交需要包含前一个提交的 CID、当前提交的 CID、时间戳和签名；DID 文档通过标准 DID 解析器查询，建议缓存 TTL 设置为 5 至 15 分钟以平衡性能与新鲜度；Relay 的订阅推送延迟应控制在秒级以内，以确保信息流的实时性。
数据备份方面，用户可以选择将仓库数据持久同步到本地设备作为备份（取决于可用磁盘空间），或由第三方服务进行镜像。当 PDS 完全消失时，用户应能够通过恢复密钥更新 DID 文档并上传备份数据来完成账户迁移。
资料来源：
- AT Protocol 官方文档（https://atproto.com/guides/overview）
- Bluesky 官方技术文档（https://docs.bsky.app/docs/advanced-guides/atproto）