在去中心化社交网络领域，AT Protocol（以下简称 ATProto）提出了一种不同于 ActivityPub 的数据组织范式。其核心创新在于将用户的全部社交数据抽象为「仓库（Repository）」，并通过加密签名的记录（Record）模型实现数据可移植性与完整性验证。本文从协议层面剖析这一架构的技术细节，为工程实践提供可落地的参数与监控建议。
仓库模型的架构定位
ATProto 将每个用户的社交数据存储在 Personal Data Server（PDS）上，PDS 本质上是用户自行拥有或委托运营的数据服务器。与传统社交平台由平台方掌控全部数据不同，ATProto 的设计理念是让用户真正拥有自己的数据副本。用户的仓库是一个自包含的、仅追加的日志结构，其中记录了发帖、关注、点赞等所有公开社交行为。
仓库的物理存储采用 Merkle Search Tree（MST）—— 一种内容可寻址的确定性数据结构。MST 与传统 Merkle 树的核心区别在于：它将键值映射存储为键排序结构，支持高效的范围查询与追加操作。树中每个节点通过 SHA-256 哈希算法计算键的深度（depth），进而决定该键属于哪一级子树的分支。具体而言，深度计算方式为：对键进行 SHA-256 哈希后，计算二进制输出中前导零的个数并除以 2（向下取整），结果即为该键的深度值。这一设计使得树结构在键分布相对随机时能够保持平衡，但在极端情况下（如刻意构造键）可能产生畸变结构。
仓库中的每条记录都遵循 <collection>/<record-key> 的路径结构。Collection 对应业务语义（如 app.bsky.feed.post 表示帖子），Record Key 则唯一标识该集合下的具体记录。协议推荐使用 Timestamp ID（TID）作为 Record Key—— 一种基于时间戳的逻辑时钟。TID 的采用确保了同一集合内的记录按时间顺序存储，使得枚举操作天然具备时序性，同时追加操作的效率优于随机插入。
加密签名与可验证性
仓库的每一次变更（创建、更新、删除记录）都会生成新的提交（Commit）对象。提交对象包含以下关键字段：did（账户去中心化标识符）、version（仓库格式版本，当前为 3）、data（指向 MST 根节点的 CID 链接）、rev（修订号，TID 格式，单调递增）、以及 sig（加密签名）。
签名的生成过程是理解可验证性的关键：首先构建不带签名的提交对象，将其序列化为 DRISL CBOR 格式，然后对序列化后的字节进行 SHA-256 哈希，最后使用账户当前的签名密钥对哈希值进行签名。签名密钥的信息存储在账户的 DID Document 中，这意味着每次密钥轮换后都应当生成新的提交对象以确保历史可验证。
这种设计带来了一个重要的工程特性：自证明存储（Self-Authenticating Storage）。由于每条记录、每个节点、每次提交都通过密码学哈希关联，攻击者无法在不被检测的情况下篡改历史记录。当用户将仓库从源 PDS 迁移到目标 PDS 时，目标服务器可以通过重新计算哈希链来验证完整性和真实性 —— 这一过程不需要信任源服务器，只需持有提交对象的签名即可。
数据迁移的技术路径
ATProto 定义了标准的数据导出格式：CAR（Content Addressable aRchives）v1。CAR 文件是一个包含元数据头部的二进制容器，其中记录了一组以 CID（Content Identifier）索引的数据块。仓库导出时，CAR 的根 CID 指向当前最新的提交对象，随后按前序遍历顺序包含所有 MST 节点和记录数据块。
迁移流程可分解为以下步骤：用户在源 PDS 上请求导出完整仓库的 CAR 文件；用户将 CAR 文件导入目标 PDS；目标 PDS 解析 CAR 并重建完整的 MST 结构，同时验证每条记录的签名链与哈希完整性；若验证通过，目标 PDS 在网络中声明该账户的新位置（通过更新 DID Document）。
值得注意的是，协议还定义了「diff」格式 —— 即两个修订之间的增量变化。Diff CAR 文件仅包含变更的数据块，可用于增量同步场景。在迁移场景中，完整 CAR 与 diff 的组合使得「仅同步自上次同步以来的变更」成为可能，这对于拥有大量历史记录的老账户尤为重要。
工程实践参数与监控要点
在实现或集成 ATProto 仓库迁移功能时，以下参数与监控点值得关注：
仓库大小方面，协议设计目标是支持百万级别的单用户记录数。超出此规模后，CAR 文件的序列化和网络传输成本将显著上升。建议对记录数超过 50 万的账户实施预检，评估迁移耗时与带宽消耗。
签名验证的超时配置需要权衡安全性与可用性。由于提交对象的 rev 字段采用 TID（基于时间戳），协议允许接收方对「未来时间」的提交进行有限度的容忍 —— 通常建议配置 5 秒至 30 秒的 fudge factor，超出此范围的未来提交应予以丢弃或警告。
MST 平衡性监控是防范 DoS 攻击的关键。攻击者可能通过精心构造 Record Key 使树结构呈现极端的非平衡形态。实现时应设置每个节点的条目数上限（建议不超过 256），并对树的深度进行监控（建议单棵树的深度不超过 16 层）。
CAR 导入过程中的资源限制不可忽视。CBOR 解码时应设置最大对象大小（建议 64MB）、最大递归深度（建议 32 层）以及单次解析的内存预算上限（建议 512MB），防止恶意构造的 CAR 文件导致服务资源耗尽。
迁移完成的标识不仅取决于 CAR 导入成功，还应验证新提交对象的签名可被当前 DID Document 中的密钥正确验证。DID 文档更新存在延迟（通常由区块链或服务阵列的确认时间决定），因此建议在 DID 更新传播完成后（通常等待 1-2 个区块确认时间）再标记迁移完全成功。
与传统联邦协议的差异
对比 ActivityPub（Fediverse 使用的协议），ATProto 的 repo 模型在数据可移植性上具有本质优势。ActivityPub 的数据存储由各服务器自行决定，跨服务器迁移通常意味着「重新关注」和「重新拉取历史」，用户无法将其完整的社交图谱与历史内容无缝转移到新服务器。而 ATProto 通过将数据所有权下沉到用户层面的仓库，配合标准化的 CAR 导出格式与加密验证机制，实现了真正的数据「随账户而动」。
当然，这一设计也引入了新的权衡：仓库的完整性验证需要目标 PDS 具备一定的计算资源（用于哈希重算与签名验证），且随着历史记录的累积，迁移成本呈线性增长。Relay 层在网络中的中心化角色也引发了关于「协议去中心化程度」的讨论 —— 尽管数据归属是分布式的，但事件聚合与分发的 Relay 层面存在一定的架构集中度。
小结
AT Protocol 通过 Merkle Search Tree 与加密签名的组合，为去中心化社交网络提供了一套可验证、可迁移的数据模型。其核心价值在于将数据主权归还用户的同时，仍能通过密码学保证跨服务器迁移的完整性。工程实践中，重点关注仓库大小评估、MST 平衡性约束、CBOR 资源限制以及 DID 传播确认，是确保迁移安全可靠的关键。
资料来源：AT Protocol 官方规范（atproto.com/specs/repository）及 Bluesky 架构概述。