Astrid 存储专利自由实施权（FTO）分级梳理：技术底座、设计规避与防御性公开

Astrid 是一个可移植、具备 capability 安全语义的操作系统，其私有主体存储（private principal store）建立在内容寻址、内容定义分块（CDC）与增量表示之上，天然处于存储专利密集区。本文基于仓库中的 存储专利与 FTO 分诊文档，完整梳理 Astrid 存储机制对应的既有技术（prior art）、通过架构主动规避的活跃专利族、五条设计优先立场（DF-1 至 DF-5），以及需要提交法律顾问的收窄问题清单。读完本文，你将理解 Astrid 如何在写路径性能、安全边界与专利自由实施之间做出工程权衡，并能直接在仓库源码与证据文档中核对每一条结论。

边界声明：本文件是工程分诊（engineering triage），不是法律意见。文档明确要求：任何专利状态与到期估计在做出商业发布决策前都必须独立核实（见 docs/astrid-storage-fto-triage.md）。下文所有专利号均为该文档记录的事实，不构成对专利有效性或范围的结论。

为什么存储层需要一份 FTO 分级清单

存储引擎是 Astrid 中专利密集度最高的模块：去重（deduplication）、内容寻址、增量编码、加密去重等领域存在大量交叉的专利族，且各族的到期时间、活跃状态与权利要求范围差异极大。如果对所有专利一律回避，会导致存储架构丧失基础能力（例如不做分块去重）；如果一律无视，则可能在商用发布时承担法律风险。

Astrid 的应对是把存储机制按风险分成三档，再辅以两条行动线：

• 绿色（Green）：古老或已过期的技术底座，直接沿用并引用公开文献；
• 黄色（Yellow）：活跃专利族，但 Astrid 的架构形态与权利要求在协议层面就不同，无需绕行；
• 琥珀色（Amber）：相邻的活跃专利族，通过明确的设计规避（design-around）——即下文 DF-1 至 DF-5——主动错开权利要求覆盖的形状。

在此基础上，Astrid 保留一份持续更新的"法律顾问清单"（counsel list），只把真正收窄后的少数问题提交律师，其余机制仅做常规的依赖与许可证审查。这种"工程先分诊、律师只回答收窄问题"的做法，正是本文要传达的核心方法论。

绿色区：古老或已过期的技术底座（直接沿用）

原文档将以下机制判定为基础性既有技术，Astrid 可以放心作为地基使用：

源码印证：ASTRID_V1 分块档案

绿色判断在代码中直接落地为 crates/astrid-storage/src/content_dag/mod.rs 中的ChunkingProfile::ASTRID_V1常量：

• 算法族：FastCDC 2020；
• 目标平均块 64 KiB，边界允许 16–256 KiB；
• 归一化级别一（normalization level one）；
• 使用规范的未加盐齿轮表（gear_seed: 0）。

值得注意的细节是，ChunkingProfile的四个字段（最小/平均/最大块长、齿轮种子）全部是**携带身份（identity-bearing）**的：文档注释明确写道"算法代码、实现修订、归一化与齿轮种子都是身份的一部分，改动任何字段都会产生不同的文件对象，即使重建出的字节完全相同"（content_dag/mod.rs）。这解释了为什么"换分块器"在 Astrid 里不是性能调优，而是持久身份的迁移——也正是 DF-5 证据门槛如此严格的原因。

此外，fastcdc_v2020构造器（content_dag/mod.rs）强制校验minimum < average < maximum、各尺寸落在 FastCDC 2020 实现支持的区间内、且 average 必须是 2 的幂；而uses_legacy_fastcdc_v4（content_dag/mod.rs）只为历史上允许奇数尺寸的旧档案保留 FastCDC 4 实现修订——这些约束本身就是"分块参数参与持久身份"这一设计的工程证据。

黄色区：架构形态不同而天然规避的活跃专利族

黄色区与琥珀色区的区别在于：黄色区的专利族不需要专门设计规避，因为 Astrid 的协议形状在架构层面就与权利要求不同。

客户端持有证明（client-side proof-of-ownership）系统

云去重场景的持有证明系统要解决的问题是：客户端只提交一个哈希声明，却并未发送可信字节，服务端如何确认该客户端"确实拥有"这些内容。此类系统引入客户端与服务器之间的 proof-of-ownership 交互协议。

Astrid 的架构直接绕开了整个问题域（docs/astrid-storage-fto-triage.md）：

• 内核亲自读取字节，重新计算身份（identity），并对候选匹配做逐字节比较；
• 不存在可信的客户端身份声明，也不存在任何 proof-of-ownership 交换。

这既是更强的安全架构（防止名称抢占 name-squatting），也是协议形态上的实质性差异。文档为此立下一条永久规则：服务端重算不可豁免——性能优化最多缓存一个已验证记录，但永远不得接受来宾（guest）的身份声明。这条规则正是 DF-3 的源头，也与 crates/astrid-storage/src/storage_model/mod.rs 中Chunk/ChunkTree/File的物化对象模型相吻合：身份是存储引擎内部对已接纳字节的推导结果，而非外部的声明。

流复用设备布局（stream-multiplexed appliance layout）

后期 SISL 专利族描述的是"把多条备份流调度进设备段（appliance segments）"的布局。Astrid 的局部性（locality）起点完全不同（docs/astrid-storage-fto-triage.md）：

• 局部性首先来自单个引擎的追加顺序与内容/世系（lineage）关系；
• 持久索引可以保留局部性，但不采纳复用备份流协议。

因此设计文档在引用时应使用更早发表的去重索引文献，并如实描述 Astrid 的实际机制，而不是借用 SISL 后期的协议语言。

琥珀区：相邻活跃专利族与选定的设计规避

琥珀区的三个专利族与 Astrid 的目标功能相邻，但通过 DF-1/DF-2 及存储域隔离的设计规避，得以在不牺牲写路径性能的前提下错开权利要求。

IBM 分块扫描中的相似性推导（US 9,891,857 / 9,892,048 / 9,892,127）

该家族覆盖"通过一次滚动哈希扫描同时推导相似性摘要与分块边界"。Astrid 的选定设计是 DF-1（见下节）：摄取路径只计算分块与身份，相似性是之后在 scrub 或压缩阶段对已验证字节做的一次固定（pinned）变换。这样就从"一次扫描同时产出两类结果"变成了"两次分离的阶段"，协议形状与权利要求不同。文档要求：在 DF-1 最终规范落地、该功能发布之前，应由律师将最终规范与权利要求逐条比对。

EMC 流局部性增量配对（US 8,447,740）

该专利关注"通过流局部性选择增量伙伴（delta partner）"。Astrid 的选择是显式世系优先（DF-2）：替换对象直接命名其前驱（predecessor），因此占主导的近版本场景不需要推断流伙伴；跨名称的草图（sketch）相似性只作为后续补充手段。

Bitcasa 收敛加密组合（US 9,253,166）

该专利将收敛加密、去重、缓存与云服务组合在一起。由于 Astrid 的私有主体存储是单主体本地语义，这一组合"与私有主体存储无关"（docs/astrid-storage-fto-triage.md）。只有当未来的公开/同步内容层带着消息锁定加密（message-locked encryption）真正落地时，它才重新进入律师清单。

设计优先立场：DF-1 至 DF-5

这五条立场是 FTO 文档的工程结论，每条都同时服务于安全、性能与专利规避三个目标。

DF-1：scrub 阶段草图（Sketch at scrub）

写路径不计算任何相似性元数据。相似性草图只在 Refinery 的已验证冷路径遍历中，作为一个固定的 bottom-k 草图变换产出（Derived 证据）。这带来六项收益（docs/astrid-storage-fto-triage.md）：

1. 摄取延迟成本为零；
2. 不存在来宾可观察的相似性计时面（timing surface）；
3. 输出确定、可复现；
4. 与 GC 和淘汰相互独立；
5. 可通过 Muninn 复用；
6. 分块扫描中不出现相似性计算。

即便未来专利审查发现更宽的安全边界，这个选择也保持不变——因为它的根本理由是把可选分析移出写路径，而非仅仅规避专利。

源码侧，Refinery 的草图通道实现在 crates/astrid-storage/src/engine/refinery/sketch/mod.rs：

• BottomKSketchDescriptor::ASTRID_V1（sketch/mod.rs）冻结为"保留 256 个 128 位得分"，与证据文档 docs/astrid-storage-chunker-evidence.md 中选定的描述子一致；
• BottomKAccumulator::observe（sketch/mod.rs）用blake3::Hasher::new_derive_key对"长度 + 字节"派生得分，128 位描述子将其余位清零，维护一个上限为 256 的有序得分表；
• verify_bottom_k_sketch（sketch/mod.rs）对源闭包做确定性重算，任何字节不一致都会产生RecomputedSketchMismatch——草图虽是"建议性"元数据，但仍必须与已验证字节严格一致；
• exact_source_closure（sketch/mod.rs）要求源 File 的完整Owns闭包恰好出现一次，拒绝缺失、重复、环与无关对象；
• 整个通道运行在RefineryResourceBudget（crates/astrid-storage/src/engine/refinery.rs）显式资源上限之下，不会借用主体前台预算。

这与证据报告 docs/astrid-storage-chunker-evidence.md 中的 bottom-k 结论互相印证：调度器只为多分块文件产出草图；在 256 样本下，选定描述子在两个语料上合计只保留约 230 KB 派生元数据，而如果对每个文件都输出单得分记录，则会膨胀到约 73 MB 且不增加任何有用候选。

DF-2：世系优先的增量表示（Lineage-first delta representations）

显式的版本与替换关系本身就能提供增量候选，不需要相似性搜索；DF-1 草图只服务于残余的跨名称/跨世系场景。表示层还必须满足三条不变式（docs/astrid-storage-fto-triage.md）：

• 针对逻辑ObjectId校验重建结果；
• 保持基础闭包（base closure）存活；
• 绝不允许一个更小的 recipe 移除最后一个可恢复表示。

源码印证：世系是对象模型中的一等引用类型。在 crates/astrid-storage/src/content/store/internals.rs 中，每次提交都会写入一条指向previous.commit的ReferenceKind::Lineage引用——替换对象显式命名前驱，正是"无需推断流伙伴"的实现基础。证据报告也确认："合成编辑链与 32 版 CHANGELOG 链都找到了有用的相似候选，但没有一个胜过直接前驱"，因此选定执行策略是"世系优先，草图仅用于残余跨名称/跨世系搜索"（docs/astrid-storage-chunker-evidence.md）。

DF-3：服务端身份重算（Server-side identity recomputation）

引擎从已接纳字节计算身份，并在恢复期间重新验证。这是同时规避名称抢占与 proof-of-ownership 协议族的安全边界。为性能跳过验证的做法被明确拒绝；不可变对象缓存可以把验证移到"可信的缓存填充与 scrub"阶段，但绝不把身份声明委托给来宾（docs/astrid-storage-fto-triage.md）。

这条规则在代码层与 DF-1 的验证路径是同一套机制：无论底层的Chunk还是派生的 sketch 记录，接纳前都要过身份重算（sketch/mod.rs 对每条记录执行identity.identify(record) != *declared校验），错误码ObjectIdentityMismatch直接对应该不变式。

DF-4：密钥化分块原则（Keyed chunking doctrine）

未来的公开/同步层必须使用经过审查的密钥化 CDC（keyed-CDC）构造；Astrid 不发明密钥混合方案。私有主体存储只有在"分块边界、长度、数量、去重结果与接纳差异全部保持在来宾 API 线以下"时，才可以使用公开档案常量（docs/astrid-storage-fto-triage.md）。此外：

• 在格式冻结前预留一个算法标签（algorithm tag）；
• 在公开层具备可接受的威胁模型与一致性测试夹具之前，不得实现密钥化变体。

这解释了为什么ChunkingProfile显式携带gear_seed字段（content_dag/mod.rs），且ASTRID_V1将种子固定为 0——密钥化变体的参数槽已经存在，但当前档案刻意保持未加盐。

DF-5：分块器证据候选（Chunker evidence candidates）

格式门槛（format gate）将比较以下候选的实测表现（docs/astrid-storage-fto-triage.md）：

• 已测量的 FastCDC 档案；
• 一个稳健的哈希化 MinCDC 候选；
• Chonkers 或其他具有实用形式化大小与局部性界（size and locality bounds）的构造。

由证据决定第一个持久档案，而不是算法新颖性。这份证据已经存在：仓库的 分块器证据文档 及其机器报告 benchmarks/astrid-storage-chunker-evidence-v1.json，由非发布型工作区 crateastrid-storage-chunker-evidence生成。

证据结论摘要（docs/astrid-storage-chunker-evidence.md）：

• 保持ChunkingProfile::ASTRID_V1不变：FastCDC 2020、归一化级别一、16/64/256 KiB 界、规范未加盐齿轮表；
• 各 MinCDC 候选对组合保留成本估计的影响仅为 ±0.1% 级别，实质打平；最低成本候选虽改进 0.1086%，却多出 41.58% 的独立分块对象；
• MinCDC 在纯 CPU 标量夹具中显著更快，但在扩展的本地编辑稳定性研究（insert/delete/等长替换 × 7 个边界邻域 × 63 例全部重同步，边界存活率最低 94.48%）中没有材料级胜者；
• Chonkers 目前没有可冻结的、经许可、独立可复现的字节流参考档案，故按"不可用"记录而非虚构行为；
• 该证据 PR 不改变ChunkingProfile、文件头、生产依赖或存储身份。

需要强调的是，astrid-storage-chunker-evidence的决策不是一次性结论，它附带明确的复跑方式与"重新打开条件"（docs/astrid-storage-chunker-evidence.md）：只有在同时隔离"整对象阈值与边界算法、保留字节与对象数/恢复成本、单线程计算与并行摄取管线、以及带黄金切分（golden cuts）与兼容许可证的生产级独立实现"时，才允许基于新证据重开决策。

公开层加密研究搁架：绝不进入私有主体存储

FTO 文档将"公开内容加密栈"的研究路线单独隔离，并指向 Future Public Content Crypto Stack 这一冻结路线图。未来的公开/同步内容层可能组合：

• 一个经审查的密钥化 CDC 构造，目前以 Truong 等人的Breaking and Fixing Content-Defined Chunking为主候选；
• 来自既有文献的消息锁定/收敛加密；
• 填充尺寸桶（padded size buckets）以降低长度泄漏；
• 显式的隐私与确认攻击模型；
• 预留的分块档案算法标签；
• 仅在那个刻意公开的信任模型内，内容哈希作为读能力（read capability）。

这套栈不允许进入私有主体存储——在那里，"内容身份永远不是授权"。文档特别强调两点技术事实（docs/astrid-storage-fto-triage.md）：

1. 消息锁定加密会暴露内容相等性，并允许对可猜测内容发起确认攻击（confirmation attack）；填充能缓解长度泄漏，但不能消除相等性泄漏。公开层必须明确承认这一让步，而不能把去重加密描述为普通意义上的"私有"。
2. 内容派生密钥材料应使用适用于全熵哈希输入的提取构造；口令拉伸函数（如 PBKDF2）对内容派生熵不增加安全性，只会造成每对象的额外成本。路线图文档 docs/astrid-public-content-crypto-roadmap.md 对这一点有同样的表述。

路线图还给出了不可协商规则与激活门槛：客户端提供的内容名永不被信任（服务端从已接纳字节重算）；去重不得基于另一信任域的内容改变来宾可见的接纳、逻辑价格或结果元数据；共享密文的擦除移除根与独占表示，而每主体硬擦除需要独立加密域并放弃跨域去重；且该页的任何机制不得以便利性或"临时"特性开关进入私有主体存储。实现要等待完整威胁模型、密码审查、选择时的专利/许可证审查、规范测试向量、跨实现解码、确认攻击分析、迁移与密钥轮换设计，以及目标公开语料上的实测收益。

法律顾问清单：保持法律审查收窄

FTO 文档主张把律师工作限制在四个问题上（docs/astrid-storage-fto-triage.md）：

1. IBM 分块扫描内相似性家族与最终 DF-1 scrub 变换规范的比对；
2. Bitcasa 家族——仅当公开加密去重服务被正式提出时；
3. 证据门槛选定的确切 MinCDC 或其他分块器实现的许可证；
4. 最终公开层消息锁定加密组合及各法域专利状态。

文档同时声明：除常规依赖与许可证审查外，当前私有主体存储机制中没有其他项被识别为需要专门律师介入。这条清单本身就是分诊流程的产出——把"存哪些专利要查"收敛为四个可以并行推进的具体问题。

防御性公开与维护：让 Astrid 自身的组合有记录

FTO 文档的最后一部分是把这套方法论固化为流程（docs/astrid-storage-fto-triage.md）：

• 保持存储世系表最新，并引用实际使用的机制；
• 设计文档一旦审查通过就公开发布，使 Astrid 自身的组合获得带日期的公开记录（defensive publication）；
• 存储相关 crate优先采用 Apache-2.0 或 MIT/Apache-2.0 双许可，使贡献者提供明确的专利授权与报复条款（patent grant and retaliation clause）——这一点与仓库根目录的 LICENSE-APACHE / LICENSE-MIT 双许可安排一致；
• 当公开层、增量表示或文件系统提供方从路线图进入代码时，重跑专利与文献审查；
• 始终把本文档视为工程输入：法律结论由律师作出，而非实现团队。

进一步阅读：在仓库中核对每一层证据

• FTO 分诊主文档：docs/astrid-storage-fto-triage.md
• 公开内容加密栈路线图与激活门槛：docs/astrid-public-content-crypto-roadmap.md
• 分块器证据决策与复跑命令：docs/astrid-storage-chunker-evidence.md（机器报告：benchmarks/astrid-storage-chunker-evidence-v1.json）
• 分块档案常量与验证：crates/astrid-storage/src/content_dag/mod.rs
• bottom-k 草图实现与确定性重算：crates/astrid-storage/src/engine/refinery/sketch/mod.rs
• 世系引用与提交链：crates/astrid-storage/src/content/store/internals.rs
• 证据 harness（非发布 crate）：crates/astrid-storage-chunker-evidence/src/

结论一句话：Astrid 的存储层不是"规避一切专利"，而是用一张绿色底座 + 两条黄色架构差异 + 三条琥珀色设计规避 + 一个公开层隔离搁架，把自由实施风险压缩到四个可核查的问题上——而 DF-1 到 DF-5 同时是安全与性能的优化，而非仅为专利而做的变形。