Symphony Core 文档

简体中文

English

简体中文

English

Appearance

SCP 核心规范 ​

版本：v1.0（草案） 状态：草案 权威性：是

目的 ​

本文档定义 SCP 的规范性生命周期与状态语义。

本文档中使用的规范协议术语以 SCP 协议概览 为准。

它回答：

  1. 协议如何组织结构，以及各组件的职责
  2. 任务如何在协议中流转，包括分类、组合与迭代
  3. 语义含义如何定义、解析与演进
  4. 同意、授权与隐私预算如何保护私有数据
  5. 多 Vault 协调与复合任务如何扩展基础任务模型
  6. challenge、settlement 与结果交付如何终结协议产出
  7. 合规的合约边界必须保留哪些内容

Part 1: 协议架构 ​

3 Planes + 2 Services ​

协议架构采用 3 Planes + 2 Services 模型。

三个 Plane 代表顺序任务流水线。每个 Plane 拥有清晰的信任边界以及与下一个 Plane 的交接契约。两个 Service 是横切关注点：它们被所有三个 Plane 访问，但不归属于任何一个。

设计理由：

  1. "层"（layer）暗示封装（每一层包裹其下方的层，如 OSI 模型）。SCP 的职责是顺序流水线，而非嵌套抽象
  2. Data 和 Governance 确实是横切关注点：被多个流水线阶段访问，具有独立的生命周期和主权关切

Admission Plane ​

Admission Plane 是协议的公共入口。它接收外部请求，进行验证，并生成一个完整的 TaskEnvelope，使得所有下游处理都可以依赖该信封而无需重新验证。

子系统：

  1. 身份与授权：验证调用方身份，根据 Vault 级权限验证授权上下文
  2. 同意验证：在声明的使用范围内，验证个人可归属记录的数据主体同意
  3. 语义解析：在 semantic_version 下解析规范含义，绑定到注册表兼容的引用，验证 derivation rule 和 attribute composition
  4. 隐私预算预留：使用 reserve-commit 模型预留预估的隐私预算，拒绝超出可用预算的任务
  5. TaskEnvelope 组装：用所有已验证字段组装不可变的 TaskEnvelope

协议边界：

  • 入口：来自调用方的外部请求，包含身份、意图和授权
  • 出口：经验证的 TaskEnvelope，或带有协议错误的确定性拒绝

不变量：

  1. 对无效输入进行确定性拒绝
  2. 不通过 admission 响应泄露私有明文
  3. 如果没有以下条件，则不生成 TaskEnvelope：有效身份、有效授权、有效同意（如适用）、已解析语义、已预留隐私预算、已绑定策略版本
  4. 语义解析是确定性的：相同输入和相同 semantic_version 产生相同的 SemanticResolutionResult
  5. 跨域 derivation 需要在 TaskEnvelope 组装之前进行显式的 cross_domain_policy 验证

Execution Plane ​

Execution Plane 接收经验证的 TaskEnvelope 并产出附带证据的 ExecutionResultBundle。它管理多 Vault 协调、复合迭代和基于 TEE 的计算的全部复杂性。

子系统：

  1. 任务编排：驱动任务状态机按规范状态转换规则运行，管理子系统之间的交接
  2. 多 Vault 协调：向参与的 Vault 进行扇出，追踪每个 Vault 的执行切片，执行 quorum 要求
  3. 计算：在 Vault 或经证明的 TEE 边界内执行授权计算，产出与证明关联的确定性输出
  4. 安全聚合：在受信聚合环境中合并每个 Vault 的切片结果，在聚合层面执行基数阈值
  5. 复合迭代控制：管理迭代任务的子任务排序，追踪收敛性，控制轮次推进

协议边界：

  • 入口：来自 Admission Plane 的经验证的 TaskEnvelope
  • 出口：ExecutionResultBundle，附带证明引用、attestation report 和隐私预算消耗记录

不变量：

  1. 确定性执行：相同输入和相同 replay tuple 产生相同的 output commitment
  2. 不进行未授权的跨 Vault 数据访问
  3. 不向协调子系统暴露明文——协调层仅能看到 commitment 和元数据
  4. 当策略要求时，TEE 执行必须产出有效的 AttestationReport
  5. 隐私预算消耗不得超出预留量（超出策略定义的容差范围）
  6. 每个 Vault 的切片结果必须在离开 Vault 边界之前满足本地基数阈值
  7. 聚合不得由任务提交者执行
  8. 复合迭代必须遵守在 admission 时声明的迭代策略

Settlement Plane ​

Settlement Plane 接收执行结果并产出终结的协议产出。它验证结果、管理 challenge 生命周期，并锚定不可逆的记账。

子系统：

  1. 结果验证：根据任务类别特定的接受标准验证执行输出
  2. Challenge 生命周期：管理 challenge 的开启、证据提交、裁决和解决
  3. 奖励记账：根据已终结的 settlement 上下文、策略版本和参与者质押状态（已质押与未质押的 Data Producer 按协议经济模型获得差异化奖励比率）计算各参与者的奖励份额
  4. 惩罚执行：对在验证或 challenge 过程中发现的协议违规施加惩罚
  5. 支付执行：基于已终结的奖励记账触发不可逆的支付

协议边界：

  • 入口：来自 Execution Plane 的 ExecutionResultBundle 及证据链
  • 出口：SettlementRoot，包含已终结的记账、奖励分配和惩罚记录

不变量：

  1. 未通过验证接受则不进行 settlement 终结
  2. challenge 证据必须可重放
  3. 验证不得改写执行历史
  4. 确定性 root 组合：相同输入产生相同的 SettlementRoot
  5. 仅追加的已终结历史——不允许追溯修改
  6. candidate context 可用于支持 challenge 开启；finalized context 用于不可逆记账

Data Sovereignty Service ​

Data Sovereignty Service 是一个横切服务，被所有三个 Plane 访问。它不是流水线阶段——而是一个持久化服务，独立于任何单一任务来管理私有数据的生命周期。

职责：

  1. 记录存储与 Commitment：保存规范私有记录，维护 Commitment = SHA256(Serialize(CR)) 关联，管理加密存储
  2. 同意管理：维护每个数据主体的同意记录，根据使用范围声明验证同意引用
  3. 隐私预算账本：按数据主体、按使用范围维护 PrivacyBudgetLedger，处理预留和提交操作
  4. Vault 访问控制：执行 Vault 级授权策略，仅在同意和授权验证通过后提供经授权的记录材料

访问模式：

  • Admission Plane：读取同意记录和隐私预算可用性以验证 admission
  • Execution Plane：在计算期间读取经授权的记录材料，提交隐私预算消耗
  • Settlement Plane：读取隐私预算记录用于验证，可能触发与预算相关的惩罚

不变量：

  1. 明文不得逃逸出授权的 Vault 或 TEE 边界
  2. 没有对声明使用范围的有效同意，则不允许访问记录
  3. 在任务、授权、同意和记录使用之间保持可审计的访问关联
  4. 隐私预算操作遵循 reserve-commit 模型
  5. 该服务对所有数据主权决策具有权威性——任何 Plane 不得覆盖其访问控制

Governance Service ​

Governance Service 是一个横切服务，管理协议配置、参与者生命周期和集体决策。与 Data Sovereignty Service 一样，它被所有 Plane 访问但不归属于任何一个。

职责：

  1. 策略版本管理：维护策略版本生命周期（draft → active → deprecated → retired），执行 epoch 边界转换，确保不追溯应用
  2. Epoch 管理：管理 epoch 生命周期（open → closing → closed），将任务和子任务分配到 epoch，管理跨 epoch 的复合任务记账
  3. 参与者注册与质押：维护参与者身份、角色绑定、三级质押要求（S_master 用于主节点、S_enterprise 用于企业节点、S_producer 用于可选质押的 Data Producer）和 slashing 条件
  4. 治理提案：管理策略变更、属性晋升、challenge 裁决和协议升级的治理提案

访问模式：

  • Admission Plane：读取活跃的策略版本和 epoch 状态用于任务验证
  • Execution Plane：读取参与者注册表用于执行者分配，读取 epoch 用于 settlement 分配
  • Settlement Plane：读取策略版本用于奖励/惩罚计算，读取参与者质押状态用于 slashing 和差异化奖励比率

不变量：

  1. 在任意给定范围内，同一时间最多一个策略版本处于 active 状态
  2. 策略版本转换仅在 epoch 边界发生
  3. 任务按其 admission 时的活跃策略版本进行评估，不受后续变更影响
  4. 治理决策需要在活跃策略版本中定义的 quorum 和流程

Part 2: 任务模型 ​

本部分定义协议的主要工作单元：任务。涵盖任务的分类方式、包含内容，以及如何在协议中流转。

任务生命周期 ​

规范的任务生命周期为：

  1. accepted
  2. resolving
  3. dispatched
  4. verifying
  5. awaiting_settlement
  6. completed
  7. challenged
  8. rejected
  9. timed_out

这些状态定义的是协议含义，而非特定的流程布局。

状态转换规则 ​

以下转换是唯一合法的协议转换。此处未列出的任何转换均为协议违规。

正常前向路径：

  1. accepted → resolving：任务进入语义解析
  2. resolving → dispatched：语义解析成功，任务被分配执行
  3. dispatched → verifying：执行完成，结果进入验证
  4. verifying → awaiting_settlement：验证接受结果
  5. awaiting_settlement → completed：settlement 终结

拒绝和失败路径：

  1. accepted → rejected：初始接受后发现 admission 阶段的验证失败
  2. resolving → rejected：语义解析失败（未解析的域、不兼容的属性）
  3. dispatched → rejected：执行产出无效或违反策略的输出
  4. verifying → rejected：验证拒绝结果
  5. accepted → timed_out：任务超过 admission 到 dispatch 的超时限制
  6. dispatched → timed_out：执行超过 dispatch 到结果的超时限制
  7. verifying → timed_out：验证超过配置的超时限制

Challenge 路径：

  1. verifying → challenged：验证者或治理参与者对结果开启 challenge
  2. awaiting_settlement → challenged：对尚未终结的结果开启 challenge
  3. challenged → awaiting_settlement：challenge 解决为 not_confirmed 或 closed_without_penalty，任务返回 settlement 路径
  4. challenged → rejected：challenge 解决为 approved 并附带惩罚，任务被拒绝

终态：

  1. completed、rejected 和 timed_out 是终态。不允许从这些状态进行进一步转换。

转换不变量 ​

协议要求：

  1. 每次转换均记录为可审计的协议事件，附带时间戳和参与者引用
  2. 不允许跳过中间状态的转换（例如，accepted 不能直接跳转到 verifying）
  3. 重放任务的转换历史在相同输入下重建相同的序列
  4. challenged 是唯一能中断前向路径并创建循环的状态

任务分类 ​

协议识别不同的任务类别，因为不同类别对执行、验证、隐私和资源记账施加不同的协议约束。

规范任务类别 ​

  1. parse：在一个 Vault 边界内进行单条记录解释，例如收据 OCR 或文档提取
  2. query：受治理的检索、过滤或受众选择，可通过隐私保护的投影跨多个 Vault
  3. compute：针对经授权的记录材料进行无状态或有界计算，例如资格评估或特征推导
  4. train：迭代式模型训练工作，可能需要多轮执行和跨 Vault 特征聚合

分类规则 ​

协议要求：

  1. 每个已准入的任务必须携带显式的 task_class
  2. task_class 在 admission 时固定，在任务生命周期内不可变
  3. 验证策略、隐私约束和奖励记账按 task_class 参数化
  4. 策略定义哪些 task_class 值需要 TEE 执行、多 Vault 协调或隐私预算消耗

类别特定的协议约束 ​

对于 query 类任务：

  1. 执行必须在查询安全的投影或授权的 Vault 端评估上进行操作，而非不受限的明文导出
  2. 结果基数约束（如受众上限）必须作为协议不变量执行，而非建议性限制
  3. 隐私预算消耗必须按每次查询执行记录

对于 compute 类任务：

  1. 计算必须是有界的：任务必须在 admission 时声明最大资源消耗（时间、内存或工作单元）
  2. 执行必须是确定性的：相同输入和相同 replay tuple 必须产出相同输出
  3. 与 query 不同，输出是派生值或制品而非过滤后的记录集
  4. 与 train 不同，执行是单次且非迭代的

对于 train 类任务：

  1. 任务可以实现为具有多个迭代轮次的复合任务
  2. 中间制品（如梯度或部分模型更新）在协议层面仅作为 commitment 引用可见，而非明文
  3. 在 admission 时定义的收敛或质量阈值成为验证接受标准

TaskEnvelope ​

TaskEnvelope 是 Admission Plane 在任务成功准入后产出的规范协议对象。它是所有下游协议处理的主要输入。

TaskEnvelope 字段 ​

一个 TaskEnvelope 必须至少保留：

  1. task_id：协议分配的唯一任务标识
  2. task_class：parse、query、compute、train 之一
  3. caller_context：任务提交者的身份和角色
  4. authorization_context：Vault 级授权引用
  5. consent_references：个人可归属记录的同意引用列表（如适用）
  6. semantic_version：治理本任务的语义版本
  7. policy_version：治理本任务的策略版本
  8. epoch_id：本任务为 settlement 目的所分配到的 epoch
  9. attribute_composition：多属性任务的已声明 AttributeComposition，单属性任务为 null
  10. derivation_rule_refs：任务使用的 DerivationRule 引用列表
  11. budget_lock_ref：本任务锁定的货币预算引用，对于 parse 任务为 null（根据协议经济模型，parse 对 Data Producer 免费）
  12. privacy_budget_reservation：本任务预留的隐私预算
  13. coordination_envelope：多 Vault 任务的协调信封；单 Vault 任务为 null
  14. iteration_policy：复合任务的迭代策略；原子任务为 null
  15. admission_timestamp：协议分配的 admission 时间
  16. task_timeout：从 admission 到完成的最大允许时间

TaskEnvelope 不变量 ​

协议要求：

  1. TaskEnvelope 中的每个字段在 admission 后不可变
  2. TaskEnvelope 是关于本任务的所有下游协议决策的权威来源
  3. TaskEnvelope 包含在任务的 replay tuple 中
  4. 下游的 Plane 或 Service 不得覆盖或扩展 TaskEnvelope 声明的约束

Part 3: 语义模型 ​

本部分定义协议中如何建立含义。涵盖命名空间层次（域）、属性系统（canonical、query 和 local 属性），以及属性如何随时间演进。

域模型 ​

overview

Domain 是定义规范含义的语义命名空间和治理边界。

它存在的目的：

  1. 语义解释拥有稳定的命名空间
  2. canonical attribute 拥有显式的所有权边界
  3. 兼容性和弃用在声明的语义范围内治理

域分层 ​

协议识别以下语义分层：

  1. global domain：协议范围内共享的语义治理边界
  2. domain family：分组相关域的高层命名空间
  3. concrete domain：注册和解析 canonical attribute 的直接命名空间
  4. 可选的 sub-domain：当策略明确允许更细粒度划分时的更窄命名空间

实现可以不同方式实现这些层次，但协议语义必须保留相同的层次结构。

域职责 ​

一个域负责：

  1. 定义 canonical attribute 所在的命名空间
  2. 在 semantic_version 下约束兼容性和演进
  3. 决定跨域引用是否被允许、拒绝或需要调解
  4. 提供语义边界，解析和治理决策以此为基准进行评估

核心域字段 ​

协议可见的域定义应至少保留：

  1. domain_id
  2. parent_domain_id（如适用）
  3. domain_version
  4. semantic_version
  5. status

域状态 ​

规范的域状态模型为：

  1. proposed
  2. registered
  3. active
  4. deprecated
  5. retired

只有 active 域和兼容性策略允许的 deprecated 域可以参与新的语义解析。

Canonical Attribute 模型 ​

overview

CanonicalAttribute 是一个协议对象，表示在声明域内的标准化语义属性。它定义协议认可的语义真值。

每个 canonical attribute 恰好属于一个域。它不是自由浮动的。

Canonical Attribute 标识 ​

协议标识应至少保留：

  1. attribute_id
  2. domain_id
  3. semantic_version

当生命周期或兼容性相关时，对象还应保留：

  1. scope
  2. status
  3. effective_from
  4. deprecated_from（如适用）
  5. retired_from（如适用）
  6. supersedes 或替换引用（如适用）

当直接查询使用相关时，对象还应保留：

  1. directly_queryable：此 canonical attribute 是否可在查询投影中使用，而无需创建单独的 QueryAttribute
  2. default_query_granularity：直接查询时应用的默认 QueryGranularity
  3. default_privacy_class：直接查询时应用的默认隐私分类

可直接查询的 Canonical Attribute ​

当 directly_queryable 为 true 时，协议允许此 canonical attribute 参与受治理的查询工作流，而无需单独的 QueryAttribute 对象。这避免了对于规范值在受治理粒度下已经是查询安全的属性进行冗余的一对一镜像。

协议要求：

  1. directly_queryable 在属性注册时显式设置，不进行推断
  2. 直接查询使用 canonical attribute 上声明的 default_query_granularity 和 default_privacy_class
  3. 需要非默认粒度、自定义 derivation 或跨域组合的任务使用带有显式 DerivationRule 的单独 QueryAttribute
  4. 无论查询使用可直接查询的 canonical attribute 还是单独的 query attribute，隐私预算消耗同等适用

Canonical Attribute 规则 ​

协议要求：

  1. 每个 canonical attribute 在给定语义点恰好属于一个已声明的域
  2. 属性兼容性相对于域和 semantic_version 进行解释
  3. 当属性被取代时，替换必须是显式的而非隐式的
  4. 语义解析在选择 canonical attribute 含义之前先确定域
  5. directly_queryable 状态不改变属性的规范真值，仅改变其查询投影的可用性

Canonical Attribute 生命周期 ​

规范的生命周期为：

  1. proposed
  2. registered
  3. active
  4. deprecated
  5. retired
  6. superseded

生命周期含义：

  • proposed：被治理工作流识别但协议不可用
  • registered：在命名空间中记录但尚未在目标语义窗口内激活
  • active：有资格进行语义解析和新任务使用
  • deprecated：仍然兼容可见但不被推荐用于新的语义编写
  • retired：不再有资格进行新任务的解析
  • superseded：在受治理的兼容性规则下被显式的继任属性替换

生命周期规则：

  1. 只有 active 及策略允许的 deprecated 属性可以为新任务 admission 进行解析
  2. retired 属性不得被选择用于新任务的解析
  3. 生命周期转换绑定到已声明的语义治理和 semantic_version
  4. superseded 属性必须显式指向替换路径（如存在）
  5. 相同任务输入和相同 semantic_version 产生相同的属性解析结果

Canonical Attribute 解析流程 ​

对于协议目的，canonical attribute 解析遵循以下逻辑流程：

  1. 从任务范围、语义引用和策略上下文确定目标域
  2. 验证该域在请求的 semantic_version 下有资格
  3. 在该域内识别候选 canonical attribute
  4. 拒绝生命周期状态不符合解析资格的候选者
  5. 应用兼容性和替换规则
  6. 在 SemanticResolutionResult 中产出确定性的语义引用

解析后果：

  1. 未解析的域或属性状态阻止进入执行阶段
  2. 模糊的域或属性映射被拒绝而非猜测
  3. 域退役或属性退役仅影响由相关版本规则治理的语义窗口
  4. 在相同语义输入下重放同一任务可重建相同的域和 canonical attribute 选择

Query Attribute 模型 ​

QueryAttribute 是一个受治理的语义对象，表示从受保护记录派生的查询安全投影，用于受众选择、资格过滤、检索或相关的受治理查询工作。

它不是 CanonicalAttribute 的替代品，也不重新定义协议真值。

Query Attribute 标识 ​

协议标识应至少保留：

  1. query_attribute_id
  2. domain_id
  3. semantic_version

当治理、隐私或兼容性相关时，对象还应保留：

  1. status
  2. derivation_rule_id：产出此 query attribute 的 DerivationRule 引用
  3. query_granularity：定义投影分辨率的结构化 QueryGranularity 对象
  4. privacy_class
  5. allowed_usage_scope

Query Granularity 模型 ​

QueryGranularity 是一个结构化的协议对象，定义 query attribute 暴露信息的分辨率。粒度直接影响隐私：更粗的粒度披露更少信息，消耗更少隐私预算。

一个 QueryGranularity 应至少保留：

  1. temporal_resolution：投影的时间精度，为 exact、day、week、month、quarter、year 之一
  2. spatial_resolution：地理精度，为 exact、district、city、region、country 之一
  3. numeric_resolution：对于数值型值，分桶规范（桶边界和宽度）或非数值型属性为 null
  4. categorical_resolution：对于分类型值，为 exact、group、binary 之一

协议要求：

  1. query granularity 在 query attribute 注册时固定且不可变，除非属性被 supersede
  2. 更细的粒度需要更高的 privacy_class 和更大的隐私预算消耗
  3. 粒度是确定性重放的因素：相同粒度和相同输入必须产出相同的投影输出

Derivation Rule 模型 ​

DerivationRule 是一个协议对象，正式定义 QueryAttribute 如何从一个或多个源属性派生。

Derivation rule 存在的原因是：规范真值与查询投影之间的关系必须是显式的、可审计的、确定性的，以支持重放和隐私保障。

Derivation Rule 标识 ​

一个 derivation rule 应至少保留：

  1. rule_id
  2. source_attributes：源引用列表，每个指定 domain_id 和 attribute_id
  3. transform_type：应用的转换类别，为 passthrough、bucket、hash、boolean、aggregate、threshold、composite 之一
  4. transform_params：特定于转换类型的参数（桶边界、哈希方法、阈值、聚合函数等）
  5. output_type：派生 query attribute 的值类型
  6. semantic_version
  7. privacy_impact_epsilon：此 derivation 每次执行的预估隐私成本

Derivation Rule 类型 ​

协议识别以下转换类型：

  1. passthrough：源 canonical 值不经转换地投影，仅受粒度粗化的影响
  2. bucket：源值被映射到离散区间（例如，金额 ¥42.50 变为 ¥20-50 区间）
  3. hash：源值被替换为加密哈希，用于关联而不披露
  4. boolean：源值被简化为 true/false 信号（例如，"已购买"而非购买详情）
  5. aggregate：多条源记录被合并为汇总统计量（例如，计数、求和、平均值）
  6. threshold：源值与边界比较以产出二元或分类输出（例如，"过去 30 天内购买过"）
  7. composite：多个源属性通过定义的函数组合

跨域 Derivation ​

当 derivation rule 引用来自多个域的源属性时，适用额外约束：

  1. 每个被引用的域必须是 active 或策略允许的 deprecated
  2. 每个跨域引用必须携带显式的 cross_domain_policy，值为 allowed、mediated 或 denied
  3. mediated 跨域引用需要声明 mediation_authority（被授权批准跨域绑定的治理参与者）
  4. 跨域 derivation rule 必须在治理工作流中注册后才能用于 query attribute 创建

Derivation Rule 要求 ​

协议要求：

  1. 每个不从 directly_queryable canonical attribute 派生的 QueryAttribute 必须引用一个显式的 DerivationRule
  2. derivation rule 必须是确定性的：相同源值、相同转换参数和相同粒度必须产出相同输出
  3. derivation rule 在 semantic_version 下版本化，注册后不可变
  4. derivation rule 的变更需要新的 rule 注册和新的 query attribute，而非就地修改
  5. privacy_impact_epsilon 用作派生 query attribute 在任务中使用时的隐私预算消耗基准

Query Attribute 规则 ​

协议要求：

  1. 每个 query attribute 必须属于一个已声明的域或受治理的查询命名空间
  2. 查询投影必须在显式的 DerivationRule 下派生，而非静默推断
  3. query attribute 必须与 canonical 语义真值保持可区分性
  4. 查询投影兼容性在 semantic_version 下保持版本感知
  5. 不得仅因存在查询投影就发出可重建的原始私有值
  6. DerivationRule 必须作为使用该 query attribute 的任何任务证据链的可审计部分

Query Attribute 生命周期 ​

规范的生命周期为：

  1. proposed
  2. registered
  3. active
  4. restricted
  5. deprecated
  6. retired

生命周期含义：

  • proposed：被治理审查识别但不可用于查询
  • registered：在命名空间中定义但尚未在目标查询窗口内激活
  • active：有资格进行受治理的查询投影和检索工作流
  • restricted：仅在更窄的策略或参与者范围下可用于查询
  • deprecated：仍然兼容可见但不被推荐用于新的查询设计
  • retired：不再有资格进行新的投影或查询使用

查询投影约束 ​

协议要求：

  1. 投影在 Vault 隐私边界下游进行
  2. 查询安全的投影保持可审计的回溯关联到源 commitment 或受保护记录
  3. 查询索引仅携带检索所需的最小受治理信号
  4. 受众选择或营销活动资格工作不得依赖于静默改变的查询语义
  5. 在相同语义和策略输入下重放重建相同的查询解释

Attribute Composition 语义 ​

现实世界的查询和计算几乎总是组合多个属性。SCP 将 attribute composition 定义为协议级关注点，因为组合直接影响隐私风险。

为什么 Composition 重要 ​

单个属性查询各自可能是安全的，但它们的组合可以将结果集缩窄到足以重新识别个人的程度。例如，分别查询"新加坡用户"和"瑞幸客户"各自可能返回大量结果集，但它们的交集可能小到足以损害匿名性。

Composition 标识 ​

一个 attribute composition 应至少保留：

  1. composition_id
  2. operator：逻辑操作，为 AND、OR、NOT、FILTER、JOIN 之一
  3. operand_attributes：参与组合的 query_attribute_id 或 directly_queryable canonical attribute 引用列表
  4. combined_privacy_class：组合结果的隐私分类，必须至少与操作数中最高 privacy_class 一样严格
  5. minimum_result_cardinality：组合结果中记录的最小数量，低于此数量结果必须被抑制或泛化

Composition 规则 ​

协议要求：

  1. 每个多属性查询或计算任务必须在 admission 时声明其 attribute composition
  2. combined_privacy_class 按操作数隐私类别的最大值计算，或在策略要求时更高
  3. 组合查询的隐私预算消耗反映组合本身，而非仅仅是各个属性成本的总和
  4. minimum_result_cardinality 在两个层级执行：
    • 每 Vault 层级：每个 Vault 的切片结果必须在离开 Vault 边界前满足本地基数阈值
    • 聚合层级：聚合结果必须满足全局基数阈值，在聚合 TEE 内于结果释放前执行
  5. 在任一层级低于阈值的结果必须在离开执行边界前被抑制或泛化
  6. attribute composition 记录为任务 replay tuple 的一部分，以便审计可以重建相同的组合逻辑

Composition 与隐私预算交互 ​

协议要求：

  1. 组合查询为组合整体消耗一次隐私预算，而非为每个操作数属性单独消耗
  2. 组合的隐私成本至少与最昂贵的单个操作数一样高，并可能根据操作符和操作数数量更高
  3. 针对相同数据主体的重复相同组合在每次执行时消耗额外预算

语义属性层 ​

语义对象出现在三个相关层次：

  1. CanonicalAttribute：定义协议认可的语义真值（记录的含义是什么）
  2. QueryAttribute：定义受治理的查询投影（哪些信号可以被投影用于检索）
  3. LocalAttribute：保持在 Vault 或本地语义边界内直到晋升（尚未成为规范的新兴语义）

正常顺序为：

  1. 本地或原始语义材料首先出现在 Vault 内部
  2. canonical 解析确定稳定的协议含义
  3. 查询投影从 canonical 或策略允许的本地材料派生，用于受治理的检索

一个字段可能对查询有用，但在语义含义上仍然遵循 canonical 优先。

Local Attribute 池 ​

LocalAttribute 是尚未被承认为协议认可的 canonical attribute 的本地语义制品。

Local 池目的 ​

local attribute 池存在的目的是让实现可以：

  1. 积累未解析或局部有意义的属性
  2. 随时间测量频率、稳定性和映射置信度
  3. 产出隐私保护的候选信号用于后续晋升

Local 池规则 ​

协议要求：

  1. local attribute 在晋升前提条件满足之前保持 local 状态
  2. 原始私有值或可重建的敏感语义材料不得直接发出用于跨 Vault 聚合
  3. local 池记录保留足够的元数据以支持后续审计和晋升审查

最小本地信号 ​

一个 local 池条目应至少保留：

  1. 本地属性标识符
  2. 候选域提示
  3. 本地出现频率
  4. 跨 epoch 的本地稳定性指标
  5. 与现有 canonical attribute 的映射置信度（如适用）
  6. 隐私安全的特征摘要或证据摘要

跨 Vault 候选聚合 ​

协议允许 local 池贡献到跨 Vault 候选池，但仅通过隐私保护的候选摘要。

默认的晋升聚合窗口是每 10 个 epoch 进行常规候选形成。策略可以允许高活跃域每 5 个 epoch，或在常规窗口之外进行特殊的治理触发提案。

跨 Vault 聚合必须产出：

  1. LocalAttributeCandidate 摘要
  2. 候选域绑定
  3. 覆盖率、频率和稳定性指标
  4. 与现有 canonical attribute 的兼容性、冲突或别名信号

它不得直接产出 active 的 canonical attribute。

协议要求：

  1. 跨 Vault 聚合交换候选摘要而非原始私有 local attribute
  2. 候选形成在证据摘要层面可审计
  3. 聚合保持在 Vault 隐私边界下游

晋升路径 ​

协议识别两条不同的 local attribute 晋升路径，反映了一个属性可能在稳定到足以成为规范真值之前就对查询有用。

晋升到 Vault 作用域的 Query Attribute：

一个 local attribute 可以晋升为 vault_scoped_query 属性，当它对 Vault 内部查询有用但尚未达到 canonical 状态所需的跨 Vault 稳定性时。

Vault 作用域查询晋升路径为：

  1. local attribute
  2. vault_scoped_query（一个受限的 QueryAttribute，其 allowed_usage_scope 限于源 Vault）

Vault 作用域查询晋升前提条件：

  1. 在源 Vault 内跨至少配置的最小 epoch 窗口保持稳定
  2. 已声明的产出查询安全投影的 derivation rule
  3. 已声明的隐私类别和粒度
  4. Vault 运营者批准

Vault 作用域查询属性：

  1. 不得参与跨 Vault 查询任务
  2. 可以参与源 Vault 也是执行 Vault 的单 Vault 任务
  3. 如果底层 local attribute 实现 canonical 晋升，可以后续晋升为完整 query attribute
  4. 携带标准 query attribute 的生命周期，但 allowed_usage_scope 限制为 vault_local

晋升到 Canonical Attribute：

canonical 晋升路径为：

  1. local attribute
  2. local attribute pool
  3. LocalAttributeCandidate
  4. proposed canonical attribute
  5. registered
  6. active

晋升前提条件：

  1. 足够的跨 Vault 覆盖率或合理的治理例外
  2. 跨所需 epoch 窗口的稳定性
  3. 明确的域绑定
  4. 与现有 canonical attribute 无未解决的冲突，或有显式的别名/替换声明
  5. 支持晋升决策的可重放证据摘要

晋升后果：

  1. 当晋升阈值未达到时，local attribute 保持 local 状态
  2. 候选聚合是提案机制，而非自动语义真值生成器
  3. 新的 canonical attribute 进入 proposed -> registered -> active 的正常生命周期
  4. 冲突解决通过显式治理而非静默推断

Part 4: 数据保护 ​

本部分定义保护私有数据的三种机制：同意与授权（谁可以访问）、隐私预算（可以披露多少）和 TEE（在哪里进行计算）。

同意与授权 ​

SCP 区分两层授权，两者都必须满足后数据才能参与协议工作。

Vault 级授权 ​

Vault 级授权治理哪些参与者和任务类别可以访问 Vault 边界内的记录材料。

协议要求：

  1. 每次数据访问必须携带显式的 authorization_context，将请求任务链接到 Vault 认可的权限
  2. Vault 运营者独立于协调层执行授权
  3. 授权授予按 task_class、domain_id、actor_id 进行范围限定，可选按时间窗口或使用目的限定
  4. 授权状态可审计且可重放

数据主体同意 ​

数据主体同意治理其数据被存储的个人是否同意了特定类别的使用。

协议要求：

  1. 每个访问个人可归属记录的任务必须携带 consent_reference，将访问链接到已记录的同意决定
  2. 同意按使用目的进行范围限定，如 personal_use、marketing、analytics 或 training
  3. 同意可撤销，撤销对新任务 admission 生效但不追溯使已终结的 settlement 无效
  4. 同意状态存储在 Vault 边界内，不以明文导出

同意生命周期 ​

规范的同意状态模型为：

  1. granted：数据主体已主动同意声明的使用范围
  2. withdrawn：数据主体已撤销同意，阻止受影响范围的新任务 admission
  3. expired：同意已达到其声明的时间限制

同意与任务交互 ​

协议要求：

  1. 任务 admission 在接受涉及个人可归属记录的工作之前验证同意状态
  2. 任务执行期间的同意撤销不中止已 dispatched 的工作，但阻止同一范围的未来任务 admission
  3. 同意状态记录为任务 replay tuple 的一部分，以便审计可以确认 admission 时同意有效

隐私预算与保障 ​

协议治理累积的隐私暴露，防止重复查询或计算逐步重建私有记录。

隐私预算模型 ​

隐私预算是协议追踪的资源，限定通过协议授权工作对数据主体或记录集累积披露的信息。

协议要求：

  1. 每个 Vault 维护一个 PrivacyBudgetLedger，按数据主体、按使用范围追踪累积披露
  2. 隐私预算按 query attribute 和任务 admission 策略上声明的 privacy_class 参数化
  3. 预算消耗在执行时记录，并作为任务证据链的一部分提交

预算记账字段 ​

一个隐私预算条目应至少保留：

  1. subject_id 或 record_scope：其预算被消耗的数据主体或记录集
  2. usage_scope：声明的目的，如 marketing、analytics 或 training
  3. consumed_epsilon：此任务产生的隐私损失，在适用时以差分隐私 epsilon 单位表示
  4. task_id：导致消耗的任务
  5. epoch_id：消耗发生的 epoch

预算执行规则 ​

协议使用 reserve-commit 模型来防止并发任务之间的竞态条件：

  1. 在 admission 时，协议为任务预留预估的隐私预算，减少后续 admission 检查的可用预算
  2. 对于任何受影响的数据主体，将超出剩余预算（扣除现有预留后）的任务在 admission 时拒绝
  3. 在执行时，协议提交实际消耗，在策略定义的容差范围内可与预留不同
  4. 如果实际消耗超出预留超过容差，任务被标记进行治理审查
  5. 如果任务在执行前失败或被拒绝，预留被释放，恢复可用预算
  6. 如果任务在执行开始后失败，预留以预估水平提交，因为执行可能已经披露了信息
  7. 已提交的消耗是仅追加的且不可逆
  8. 预算补充仅在显式治理策略下的 epoch 边界发生，不自动补充

按任务类别的隐私保障 ​

对于 query 任务：

  1. 受众选择结果不得允许任务提交者确定特定个人是否在结果集中，除非个人的同意明确允许可识别定向
  2. 低于策略定义的最小阈值的结果基数必须导致结果被抑制或泛化

对于 train 任务：

  1. 每轮梯度或更新贡献必须在策略定义的最小 Vault 数量上聚合后才能释放
  2. 模型制品不得记忆或允许提取单个训练记录，通过协议定义的评估标准进行验证

预算与同意交互 ​

协议要求：

  1. 同意撤销冻结受影响数据主体的预算，防止进一步消耗
  2. 预算状态对 Vault 运营者可见且可由治理审计
  3. 预算耗尽不撤销已终结的 settlement，但阻止受影响范围的未来任务 admission

TEE 信任与证明要求 ​

SCP 将可信执行环境（TEE）视为与 Vault 边界并列的协议认可执行边界。由于 TEE 提供硬件强制隔离，它需要不同的协议级信任规则。

TEE 在协议中的角色 ​

TEE 作为：

  1. 受保护的执行环境，授权计算在私有记录材料上运行
  2. 当计算必须由不直接运营源 Vault 的参与者执行时，作为 Vault 内部执行的替代方案
  3. 能够提供加密证明的环境，证明特定计算在已验证 enclave 内的特定输入上运行

TEE 证明要求 ​

协议要求：

  1. 每个 TEE 执行的任务必须携带 AttestationReport，将执行链接到已验证的 enclave 身份
  2. AttestationReport 至少保留：enclave 身份、enclave 度量哈希、平台身份和新鲜度 nonce
  3. 验证子系统在接受 TEE 执行结果之前验证 attestation
  4. attestation 可作为任务证据链的一部分重放

TEE 与 Vault 边界关系 ​

协议定义：

  1. 当任务需要 Vault 运营者无法或选择不在本地执行的计算时，Vault 可以将执行委托给 TEE
  2. 从 Vault 传输到 TEE 的记录材料必须在传输中加密，仅在经证明的 enclave 内解密
  3. TEE 在任务执行完成后不得保留记录材料
  4. 协议将 TEE 视为 Vault 隐私边界的临时扩展，而非独立的数据托管方

TEE 故障处理 ​

协议要求：

  1. 执行期间的 TEE 平台故障导致受影响任务或子任务 timed_out
  2. attestation 失败导致在验证子系统处 rejected
  3. settlement 后披露的 TEE 侧信道漏洞可通过 challenge 生命周期解决
  4. 硬件供应商撤销 TEE 平台在治理策略下阻止新任务 dispatch 到受影响的 enclave

何时需要 TEE 执行 ​

协议不对所有任务类别强制要求 TEE。策略决定 TEE 要求：

  1. 单 Vault 数据上的 parse 任务可在 Vault 内部执行而不需要 TEE
  2. 评估跨 Vault 资格的 query 任务在计算涉及执行者不运营的 Vault 的记录材料时应在 TEE 内执行
  3. 涉及跨 Vault 记录材料的 compute 和 train 任务必须在经证明的 TEE 内执行，除非所有参与 Vault 在策略下明确允许非 TEE 执行

Part 5: 执行模型 ​

本部分定义任务在实践中如何执行，涵盖多 Vault 协调和复合（迭代）任务的复杂性，它们扩展了基础的单 Vault、单次执行模型。

多 Vault 任务协调 ​

许多平台能力需要单个任务访问分布在多个独立治理 Vault 中的记录。SCP 定义此类协调的协议语义。

何时需要多 Vault 协调 ​

多 Vault 协调在以下情况下需要：

  1. query 任务必须针对多个 Vault 中的记录评估资格或选择标准
  2. compute 任务需要来自多个 Vault 边界的特征材料
  3. train 任务必须聚合从不同 Vault 记录派生的梯度、特征或模型更新

单 Vault 任务（如个人收据解析）不需要多 Vault 协调。

扇出与聚合模型 ​

协议将多 Vault 任务分解为：

  1. 一个 coordination envelope，携带共享的 admission、语义和策略上下文
  2. 每 Vault 的 execution slice，在每个参与 Vault 边界内独立运行
  3. 一个 secure aggregation step，在不暴露单个 Vault 明文的情况下合并每 Vault 的结果

Coordination Envelope ​

一个 coordination envelope 保留：

  1. parent_task_id
  2. participating_vault_ids：必须贡献的 Vault 集合
  3. minimum_vault_quorum：结果有效所需的最小 Vault 完成数
  4. aggregation_method：协议认可的结果合并方法，如 union、intersection、secure_sum 或 federated_average
  5. per_vault_timeout：每个 Vault 响应的最大时间，超时后切片视为超时

每 Vault 执行切片 ​

每个执行切片：

  1. 在其 Vault 边界内独立遵循规范的任务生命周期
  2. 产出仅包含 commitment 引用和隐私安全输出的 SliceResultBundle
  3. 不向协调层或其他 Vault 暴露明文

安全聚合 ​

协议要求：

  1. 聚合在隐私安全的切片输出上操作，而非原始 Vault 明文
  2. 聚合方法在任务 admission 时固定且可审计
  3. 聚合是确定性的：相同切片输入和相同聚合方法必须产出相同的聚合输出
  4. 跨 Vault 边界的基数约束（如受众上限）在聚合步骤执行

聚合信任模型 ​

安全聚合是信任关键步骤，因为聚合者接收来自多个 Vault 的输出。协议定义以下信任要求：

聚合执行环境：

  1. 聚合必须在以下之一内执行：(a) 经证明的 TEE，(b) 安全多方计算协议（无单一方可见所有输入），或 (c) 同态加密方案（聚合在密文上操作）
  2. 基于 TEE 的聚合是默认方式，必须在聚合证据中携带 AttestationReport
  3. 聚合环境的选择必须在 coordination envelope 中声明，且对该任务不可变

聚合参与者：

  1. 聚合者是协议参与者，受与 Executor 相同的质押、惩罚和治理规则约束
  2. 聚合者不得与任务提交者是同一实体，以防止请求者观察每 Vault 输出
  3. 聚合者在产出聚合结果后不得保留每 Vault 的切片输出

聚合证据：

  1. 聚合结果必须携带加密证明或 attestation，将输出链接到声明的输入和方法
  2. 验证必须在接受聚合结果之前验证聚合证据
  3. 聚合证据必须可作为任务证据链的一部分重放

部分完成 ​

协议要求：

  1. 如果完成的 Vault 少于 minimum_vault_quorum，父任务必须 rejected 或 timed_out
  2. 如果达到 quorum 但部分 Vault 未响应，聚合在可用切片上进行，结果携带显式的 partial_coverage 标志
  3. 验证必须评估在任务的 admission 策略下部分覆盖是否可接受

多 Vault 授权 ​

协议要求：

  1. 每个参与 Vault 在执行其切片之前独立验证授权和同意
  2. 协调层不覆盖每 Vault 的授权决策
  3. 拒绝授权的 Vault 减少可用覆盖率而不阻止其他 Vault

复合与迭代任务语义 ​

复合任务是协议认可的任务，在共享的 admission、授权和 settlement 上下文下被分解为有序子任务。复合任务的存在是因为某些平台能力——特别是分布式训练和多阶段计算——无法忠实地表示为单一原子任务生命周期。

复合任务结构 ​

一个复合任务保留：

  1. parent_task_id：根任务标识
  2. sub_task_sequence：有序的子任务标识列表
  3. iteration_policy：治理可执行多少轮次以及在何种收敛或预算条件下的规则
  4. aggregation_rule：子任务结果如何合并为父结果

子任务生命周期 ​

每个子任务独立遵循规范的任务生命周期。父任务的转换由聚合治理：

  1. 当任何子任务进行中时，父任务保持 dispatched
  2. 仅当所有必需子任务达到 awaiting_settlement 或迭代策略声明收敛时，父任务才移至 verifying
  3. 如果任何子任务 rejected 或 timed_out，父任务可以被拒绝、在策略下重试，或在策略允许部分接受时部分 settle

迭代执行轮次 ​

对于训练和迭代计算：

  1. 每轮产出一个子任务，具有自己的 ExecutionResultBundle 和 Commitment 引用
  2. 轮次之间的状态通过 commitment 引用传递，而非明文中间制品
  3. 迭代策略定义最大轮次数、收敛阈值和提前停止条件
  4. 每轮在适用时独立消耗隐私预算

多 Vault 复合交互 ​

当复合任务需要多 Vault 协调时，两种分解机制组合为三级层次：

  1. 父任务：在协议层面准入的根复合任务
  2. 子任务（轮次）：每个迭代轮次，遵循复合任务生命周期
  3. 执行切片（每 Vault）：每个 Vault 在单轮内的贡献，遵循多 Vault 协调模型

协议要求：

  1. 每个子任务在需要多 Vault 扇出时携带自己的 coordination envelope
  2. 子任务内的每 Vault 切片遵循规范的执行切片规则（独立生命周期、SliceResultBundle、不暴露明文）
  3. 安全聚合在子任务层面进行，在下一轮开始之前将每 Vault 切片合并为子任务结果
  4. 父任务追踪子任务完成，而非单个切片完成
  5. 一轮中的切片失败仅影响该轮的子任务，而非父任务或其他轮次

这意味着对于具有 N 轮和 M 个 Vault 的多 Vault 训练任务，协议管理：1 个父任务 + N 个子任务 + (N × M) 个执行切片。每个层级都有自己的生命周期、证据和 settlement 上下文。

复合 Settlement ​

协议要求：

  1. 复合任务在所有子任务验证后作为一个单元进行 settle
  2. 部分 settlement 由策略治理且显式声明，而非静默假设
  3. 复合任务的奖励记账反映跨子任务的聚合已验证贡献
  4. 复合 settlement 上下文保持到每个子任务 settlement 上下文的关联

Part 6: 结算与交付 ​

本部分定义执行结果如何被验证、challenge、settle 和交付给下游消费者。

Challenge 生命周期 ​

规范的 challenge 生命周期为：

  1. opened
  2. reviewing
  3. confirmed
  4. not_confirmed
  5. approved
  6. closed_without_penalty
  7. penalty_recorded
  8. reopened

Challenge 证据必须可重放，并链接到相关的任务、验证和 settlement 上下文。

按任务类别的验证要求 ​

对于 parse 任务：

  1. 验证结构化输出符合已解析的语义模式
  2. 验证输入记录与输出字段之间的 commitment 关联

对于 query 任务：

  1. 验证结果基数满足 attribute composition 中的 minimum_result_cardinality
  2. 验证隐私预算消耗匹配声明的 privacy_impact_epsilon
  3. 验证受众上限执行（如适用）
  4. 对于多 Vault 查询，验证聚合证据和 TEE attestation

对于 compute 任务：

  1. 验证确定性：在相同输入下重新执行必须产出相同的 output commitment
  2. 验证资源消耗未超过声明的边界

对于 train 任务：

  1. 每轮验证：验证每个子任务的 TEE attestation 和隐私预算消耗
  2. 复合验证：验证收敛状态、总隐私预算和模型质量是否符合 admission 标准
  3. 验证模型制品不记忆单个记录（成员推断抗性）

复合与多 Vault 任务的 Challenge 范围 ​

协议扩展复杂任务的 challenge 生命周期：

  1. challenge 可以针对特定的每 Vault 执行切片，通过 parent_task_id + vault_id 标识
  2. challenge 可以针对特定的子任务轮次，通过 parent_task_id + sub_task_sequence_index 标识
  3. challenge 可以针对聚合步骤，通过 parent_task_id + aggregation 标识
  4. challenge 可以针对复合结果整体

复合任务的 challenge 后果：

  1. 如果单个切片被 challenge 且 challenge 被批准，包含该切片的子任务可在策略下被重新执行或拒绝
  2. 如果子任务轮次被 challenge 且批准，依赖于它的后续轮次无效
  3. 如果聚合被 challenge 且批准，整个任务结果被拒绝
  4. 对子任务的 challenge 不自动使父任务无效，除非该子任务在迭代策略下是必要的

Settlement 生命周期 ​

规范的 settlement 生命周期为：

  1. collecting
  2. verifying_inputs
  3. candidate_ready
  4. finalizing
  5. finalized
  6. failed

Settlement Candidate Context ​

Candidate context 用于：

  1. challenge 开启
  2. settlement 就绪性
  3. 欺诈证据关联

Finalized Settlement Context ​

Finalized context 用于：

  1. 奖励终结
  2. 协议审计
  3. 支付准备
  4. 不可逆记账引用

结果交付 ​

SCP 定义已接受和已 settle 的结果如何对下游消费者可用的协议边界。

交付范围 ​

结果交付治理：

  1. 谁可以访问已终结的结果
  2. 交付结果采取什么形式
  3. 交付如何确认或确认收到

交付参与者 ​

协议识别：

  1. task_submitter：始终对自己任务的已终结结果拥有交付访问权
  2. authorized_consumer：持有特定已 settle 结果的交付授权的参与者
  3. vault_operator：可以向数据主体交付 Vault 本地结果

交付形式 ​

协议要求：

  1. 交付结果从 finalized settlement context 派生，而非从原始执行输出
  2. 包含个人可归属信息的结果即使在 settlement 后仍受同意和授权约束
  3. 交付形式与完整的协议 settlement 上下文可区分，后者可能包含不面向外部消费者的内部证据和记账引用

交付确认 ​

协议要求：

  1. 交付事件记录为协议可审计的制品
  2. 交付确认不是 settlement 终结性的前提条件，终结性仅由 settlement 生命周期决定
  3. 失败或拒绝的交付不追溯使已终结的 settlement 无效

Part 7: 协议配置 ​

本部分定义控制协议行为的治理参数：策略版本、epoch 和确保重放的确定性要求。

策略版本模型 ​

policy_version 是一个协议对象，捕获在给定时间点活跃的全套可配置协议参数。它存在的目的是即使操作参数演进，协议行为仍然是确定性的和可重放的。

策略版本包含内容 ​

一个策略版本至少治理：

  1. 每 task_class 的约束：TEE 要求、最大执行时间、最大资源消耗
  2. 隐私参数：每使用范围的默认隐私预算分配、最小结果基数阈值、预算补充率
  3. 经济参数：每参与者角色的最小质押金额、奖励计算公式、惩罚严重程度等级
  4. 准入控制：速率限制、并发上限、每任务类别的预算锁定要求
  5. 多 Vault 参数：默认 quorum 要求、每 Vault 超时默认值、聚合环境要求
  6. 治理参数：challenge 窗口时长、challenge 保证金金额、治理投票阈值

策略版本标识 ​

一个策略版本应至少保留：

  1. policy_version_id
  2. effective_from_epoch：此策略版本生效的 epoch
  3. status：draft、active、deprecated、retired 之一
  4. predecessor_version_id：此版本替换的策略版本

策略版本生命周期 ​

规范的生命周期为：

  1. draft：治理审查中，尚不可执行
  2. active：治理范围内当前可执行的策略版本
  3. deprecated：对在其下 admit 的进行中任务仍然有效，但新任务必须使用后继版本
  4. retired：不再用于任何目的

在任意给定治理范围内，同一时间最多应有一个策略版本处于 active 状态。

策略版本转换规则 ​

协议要求：

  1. 策略版本转换仅在 epoch 边界发生
  2. 在给定 policy_version 下 admit 的任务在其整个生命周期内按该版本评估，即使该策略版本后来被弃用
  3. 任务 admission 时的活跃 policy_version 记录在任务的 replay tuple 中
  4. 策略版本变更至少提前一个 epoch 通过治理公告
  5. 不对已 admit 的任务追溯应用新策略

Epoch 模型 ​

Epoch 是用于将协议事件分组到可重放控制上下文中的稳定窗口标识符。

它不是原始数据上传或任务存在的前提条件。

它主要治理：

  1. settlement 窗口
  2. 奖励计算窗口
  3. 支付批处理窗口
  4. local attribute 候选聚合窗口
  5. 当批处理相关时的重放分区

它不主要治理：

  1. 原始数据上传到 Vault
  2. 任务是否可以形成
  3. 语义解析是否可以开始
  4. 单个授权执行是否可以启动

核心 Epoch 字段 ​

一个 epoch 定义应至少保留：

  1. epoch_id
  2. open_at
  3. close_at
  4. status
  5. semantic_version_set
  6. policy_version_set
  7. settlement scope 元数据
  8. reward scope 元数据
  9. candidate aggregation scope 元数据

Epoch 状态 ​

规范的 epoch 状态模型为：

  1. open
  2. closing
  3. closed

在任意给定治理范围内，通常最多应有一个 epoch 处于 open 状态。

开启条件 ​

新 epoch 在以下情况下开启：

  1. 前一个 epoch 已达到 closed，或
  2. 系统正在创建初始引导 epoch

open 的 epoch 是分配后续 settlement、奖励和聚合范围的活跃窗口。

关闭触发 ​

open 的 epoch 应在以下一个或多个条件发生时移至 closing：

  1. 达到配置的最大时间窗口
  2. 任务、验证、settlement 或聚合量达到配置的阈值
  3. 治理或策略要求窗口边界，如版本转换或受控维护

这是混合触发模型：

  1. 时间可以关闭窗口
  2. 容量可以关闭窗口
  3. 治理可以关闭窗口

关闭条件 ​

epoch 从 closing 移至 closed 当：

  1. 该 epoch 的 settlement scope 已冻结
  2. 该 epoch 的 reward scope 已冻结
  3. 该 epoch 的 candidate aggregation scope 已冻结
  4. 未解决项已为当前 epoch 解决或在策略下明确延迟

一旦 epoch 为 closed：

  1. 新事件不得新分配到该 epoch
  2. 重放应重建相同的 epoch 成员关系
  3. 下游的奖励、支付和候选聚合可以针对稳定的窗口边界进行

Epoch 与复合任务交互 ​

复合任务可以跨多个 epoch。协议定义：

  1. 父任务分配到其被 admit 时的 epoch
  2. 每个子任务分配到子任务被 dispatch 时处于 open 状态的 epoch
  3. 如果子任务进行中时 epoch 关闭，进行中的子任务保留其分配的 epoch；后续子任务分配到下一个 epoch
  4. 复合 settlement 跨各自 epoch 聚合子任务 settlement
  5. 每个子任务的奖励记账遵循该子任务被分配到的 epoch
  6. 如果 epoch 关闭时父任务没有剩余已 dispatch 的子任务，父任务可在策略下被延迟到下一个 epoch 或超时

确定性与重放 ​

确定性要求：

  1. 固定的对象语义
  2. 固定的排序和哈希规则
  3. 稳定的 epoch 映射
  4. 版本感知的参数解析
  5. 可重放的证据和记账制品

参数解析必须是以下因素的确定性函数：

  1. epoch_id
  2. semantic_version
  3. policy_version

Part 8: 合约边界 ​

合规实现要求 ​

合规实现必须至少暴露以下协议覆盖：

  1. 任务和语义消息，包括任务分类和复合任务结构
  2. 同意和授权消息
  3. 执行和验证消息，包括 TEE attestation（如适用）
  4. 多 Vault 协调消息，包括 coordination envelope 和切片结果
  5. derivation rule 注册和 attribute composition 声明
  6. settlement 消息
  7. 奖励记录
  8. 支付指令和事件
  9. 隐私预算消耗记录
  10. 结果交付事件

当前规范真值的来源是 Markdown 规范集。机器可读的 schema 制品是由 SCS 定义的实现交付物。

规范错误族 ​

协议可见的错误族包括：

  1. SCHEMA_*
  2. VERSION_*
  3. AUTH_*
  4. CONSENT_*
  5. POLICY_*
  6. EXECUTION_*
  7. PROOF_*
  8. TEE_*
  9. VERIFY_*
  10. COORDINATION_*
  11. DERIVATION_*
  12. COMPOSITION_*
  13. PRIVACY_BUDGET_*
  14. SETTLEMENT_*
  15. REWARD_*
  16. PAYOUT_*
  17. DELIVERY_*
  18. GOVERNANCE_*
  19. INTERNAL_*