Symphony Core 文档

简体中文

English

简体中文

English

Appearance

用例：面向消费者行为的隐私保护模型训练 ​

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

场景 ​

某个模型运营方希望利用分布在多个 Vault 中、受保护的小票与消费历史数据，训练一个面向消费者行为的模型。

模型目标可能包括：

  1. 购买倾向预测
  2. 品类或品牌偏好估计
  3. 优惠券响应建模
  4. 隐私保护用户分群

本文档是说明性用例，用来展示修订后的 SCP 与 SCS 规范如何映射到一个在不暴露原始消费明文的前提下进行模型训练的工作流。

本文档中使用的 canonical protocol term 以 SCP 协议概览 和 SCP 核心规范 为准。

为什么这个用例重要 ​

这个场景很有代表性，因为它同时体现了新版 Symphony 体系中的几条关键性质：

  1. model training intent 与 protocol-recognized training work 不是同一件事
  2. 受保护的源记录可以持续保留在授权 Vault 或 TEE 边界内
  3. 训练过程可以依赖派生 feature、query projection 或受保护计算，而不是任意导出原始记录
  4. model artifact 与 evaluation result 必须关联到可 replay 的 evidence 与版本上下文
  5. 最终模型是受治理训练结果的下游产物，而不是协议真相的替代物

入口区分 ​

这个场景有两层：

  1. 业务侧或研究侧想训练一个模型
  2. 带有明确 policy、semantic 与 privacy 约束的协议认可训练任务

"利用消费数据训练一个行为模型"本身还不是协议事件；只有当系统把它接纳为一项带有明确 feature scope、版本上下文和隐私执行规则的授权训练任务时，它才进入 SCP 生命周期。

与小票上传场景甚至优惠券活动场景不同，本用例涉及：

  1. 包含多个迭代训练轮次的复合任务，而不是单次原子执行
  2. 多 Vault 特征构造，每个 Vault 贡献本地派生的特征
  3. 联邦学习语义下的跨 Vault 梯度或模型更新聚合
  4. 多轮次中跨大量数据主体的显著隐私预算消耗
  5. 每个训练轮次的 TEE 证明执行
  6. 模型产物交付到模型注册中心，而不是向任务提交者返回单一结果

从节点角度看，这个场景同时跨越 master node 和 enterprise node。Master node 驱动 admission、orchestration、aggregation 和 settlement。Enterprise node 托管存储训练数据的 Vault，并在 TEE 边界内运行本地计算。两种节点类型通过 SCS 架构中定义的跨节点通信层进行协作。

协议视角 ​

从协议角度看，这个场景的核心，是把训练意图转化为一个可验证、可治理的模型训练结果。

1. 训练意图与范围定义 ​

请求方先定义训练目标和约束，例如：

  1. 目标预测或分群任务
  2. 适用的用户或市场范围
  3. 允许使用的 feature family
  4. 模型输出类型
  5. evaluation threshold 或 acceptance criterion

在这一步，它仍然只是业务或研究意图，而不是协议事实。

2. 任务接纳、分类与约束绑定 ​

系统把这个请求转化为授权的协议工作。

从高层看，admission 需要明确：

  1. 谁被授权提交该训练任务
  2. 任务分类为 task_class: train，激活复合任务语义
  3. 哪些 record domain、feature family 或 query projection 可以参与
  4. 适用哪些 privacy、policy 与版本约束，包括所有训练轮次的总隐私预算分配
  5. 什么样的输出才算协议要评估的训练结果
  6. 迭代策略：最大训练轮次、收敛阈值和提前停止条件

接纳成功后，Admission Plane 产出一个 TaskEnvelope，携带所有下游关键字段，包括：

  1. iteration_policy：复合训练生命周期的最大轮次、收敛阈值和提前停止条件
  2. coordination_envelope：多 Vault 协调参数，指定参与 Vault、quorum 规则和聚合方法
  3. budget_lock_ref：对 Escrow Contract 中锁定 SYM 的引用，用于覆盖多轮次、多 Vault 计算的预估成本

在接纳完成前，协议还验证：

  1. 参与 Vault 中持有的数据主体已授予 training 使用范围的同意
  2. 所有轮次的预估总隐私预算消耗不超过受影响数据主体的可用预算
  3. 已锁定足够的货币预算以覆盖多轮次、多 Vault 计算的预估成本

只有经过这一步，训练流程才成为协议认可的工作。

3. 语义解析、特征推导与属性组合 ​

在训练开始之前，协议必须先在当前上下文中解析这项任务的语义含义。

这通常包括确定：

  1. 哪些 domain 定义了受保护的源记录（通常是 commerce、behavior、identity）
  2. 哪些 canonical attribute 为 directly_queryable，可以在不经推导的情况下直接用作原始特征
  3. 哪些特征需要显式的 DerivationRule 定义 — 例如 purchase_frequency 通过 commerce 域交易记录上的 aggregate 规则推导，或 brand_affinity_score 通过组合跨品类购买计数的 composite 规则推导
  4. 需要哪些 AttributeComposition 声明 — 训练特征通常组合来自多个域的属性，需要带有已声明 combined_privacy_class 的跨域组合
  5. 哪些 local-only signal 必须保持私有，以及是否有任何信号有资格成为 vault_scoped_query 属性
  6. 该次运行受哪个 semantic_version 与 policy_version 约束

这一步之所以重要，是因为修订后的 SCP 要求在受保护计算开始之前，先建立共享语义、显式推导规则和已声明的属性组合。在训练上下文中，这意味着特征工程方案必须在协议层面可见且可审计，而不是隐藏在执行运行时内的黑盒变换。

4. 多 Vault 特征构造与迭代训练执行 ​

当语义被确定之后，复合任务开始迭代执行。每个训练轮次作为父复合任务下的子任务实现，遵循 SCP 核心规范中定义的复合与迭代任务语义。

协议为此任务管理一个三级层次结构：

  1. Parent task：在协议层接纳的根复合任务，由 master node Task Orchestrator 管理
  2. Sub-task (round)：每个迭代训练轮次，由 master node Multi-Vault Coordinator 协调并扇出到参与 Vault
  3. Execution slice (per-Vault)：每个 Vault 在单轮中的贡献，由 enterprise node Computation Runtime 在 TEE 内执行

对于一个包含 N 轮和 M 个 Vault 的多 Vault 训练任务，master node 管理：1 个 parent task + N 个 sub-task + (N x M) 个 execution slice。每个层级有自己的生命周期、evidence 和 settlement 上下文。

每轮执行流程 ​

每个训练轮次经历：

  1. Per-Vault 特征构造：每个参与 Vault 在其 TEE 边界内独立从本地记录中导出获准的 feature aggregate
  2. Per-Vault 本地训练步骤：每个 Vault 使用本地构造的特征计算本地模型更新（梯度或参数增量）
  3. 安全聚合：所有参与 Vault 的本地模型更新通过接纳时指定的安全聚合方法（通常为 federated_average）合并，不向其他 Vault 或模型运营方暴露任何 Vault 的个体梯度
  4. 全局模型更新：聚合更新被应用以产出下一轮全局模型参数

每轮产出一个带有独立 ExecutionResultBundle、Commitment reference 和 TEE attestation report 的子任务。

收敛与迭代控制 ​

  1. 迭代策略定义最大轮次、收敛阈值和提前停止条件
  2. 每轮结束后，协调层评估是否满足收敛标准
  3. 若在最大轮次前达到收敛，复合任务进入验证
  4. 若达到最大轮次但未收敛，结果携带显式 convergence_not_reached 标志进入验证

每轮隐私预算消耗 ​

  1. 每个训练轮次为使用其记录的数据主体消耗隐私预算
  2. 所有轮次的累积隐私预算消耗不得超过接纳时声明的分配
  3. 若隐私预算在收敛前耗尽，训练必须提前停止，并以当前状态进入验证
  4. 轮次间状态通过 commitment reference 传递，而不是明文中间产物

在整个阶段中：

  1. 原始消费历史始终留在授权 Vault 或 TEE 边界内
  2. 协议依赖的是 commitment、evidence、lineage 与可 replay 工件，而不是任意移动明文
  3. 训练始终绑定于 admission 时确定的 feature、policy 与版本约束
  4. 模型运营方永远看不到单个 Vault 数据或 per-Vault 梯度，只能看到安全聚合后的模型更新

5. 验证与被接受的训练结果 ​

协议不会把某个产出的 model artifact 立即视为最终事实。

由于这是复合任务，验证在两个层级进行：

  1. Per-round 验证：每个子任务的执行和 TEE attestation 被单独验证
  2. 复合验证：整体训练结果（包括收敛状态、总隐私预算消耗和模型质量指标）对照接纳时定义的接受标准进行评估

复合验证必须确认：

  1. 所有子任务的 TEE attestation 有效
  2. 总隐私预算消耗与 per-round 记录之和一致
  3. 模型产物不会记忆或允许提取单条训练记录，可通过协议定义的评估标准（如成员推断抵抗性）验证
  4. 收敛状态与声明的迭代策略一致

从结果角度看，可能出现：

  1. accepted
  2. rejected
  3. challenged

只有被接受的工作，才可能继续进入 settlement。

6. 结算、记账与模型使用基础 ​

如果训练结果被接受，它作为复合结算进入 settlement，将所有子任务结算上下文关联到单个 finalized 复合上下文中。

每个子任务在其被 dispatch 时分配的 epoch 中进行结算。如果某个 epoch 在子任务执行过程中关闭，该进行中的子任务保留其已分配的 epoch；后续子任务被分配到下一个 epoch。复合结算跨各自 epoch 聚合子任务结算，每个子任务的奖励会计遵循该子任务被分配到的 epoch。

在这个场景里：

  1. settlement 的作用是把已接受的训练运行转化为协议认可的训练事实
  2. 复合结算上下文保留到每轮子任务结算、TEE attestation 和隐私预算记录的关联
  3. finalized accounting 会成为后续 model registry 更新、部署或受控使用的依据
  4. 已部署模型仍然只是下游系统后果，而不是协议真相本身
  5. 奖励会计反映所有轮次和所有参与 Vault 的聚合已验证贡献
  6. SYM 分发通过 Aptos 上的 Reward Contract 执行，per-actor 份额由 Reward Accounting Service 在当前 policy_version 下计算

7. 结果交付到模型注册中心 ​

结算完成后，finalized 的模型产物必须交付给请求方的模型注册中心。

在此场景中：

  1. 任务提交者（模型运营方）是授权的交付接收方
  2. 交付结果是训练后的模型产物及其关联质量指标，而非原始训练数据或 per-Vault 梯度
  3. 交付被记录为协议可审计的事件，关联到复合结算上下文
  4. 模型注册中心随后可部署模型用于推理或进一步评估，但协议不治理部署机制本身

节点层面执行 ​

从 SCS 角度看，同一个场景映射到具体的双节点类型拓扑。本节追踪 master node 和 enterprise node 如何协作实现协议生命周期的各个阶段。

Master Node ​

3 个 master node（由 Symphony Foundation 运营，BFT 共识）共同为此训练工作流运行以下服务：

  1. API Gateway：接收模型运营方的训练请求，执行 TLS 终结、限流，并将请求路由到 Admission Plane 服务

  2. Admission Plane：验证提交者身份和授权，验证参与 Vault 中数据主体对 training 使用范围的同意，在 semantic_version 下解析语义，预留隐私预算，通过 Escrow Contract 锁定 SYM，并组装不可变的 TaskEnvelope（包含 iteration_policy、coordination_envelope 和 budget_lock_ref）

  3. Task Orchestrator：通过 canonical state transition 驱动复合任务状态机。对于此训练任务，Task Orchestrator 管理 parent task 生命周期，排序 sub-task（轮次），将每轮的多 Vault 扇出委派给 Multi-Vault Coordinator，并通过 Composite Iteration Controller 跟踪整体收敛

  4. Multi-Vault Coordinator：将每轮的 coordination envelope 展开为 per-Vault 执行分配，向目标 enterprise node dispatch 分配，跟踪 per-Vault slice 进度并执行 quorum，当足够的 slice 完成时触发聚合

  5. Aggregation Runtime (TEE)：在 master node 上的已证明 TEE 中运行。每轮接收 per-Vault SliceResultBundle 输出（commitment reference 和隐私安全的模型更新），执行 federated_average 以产生聚合的全局模型更新，执行基数阈值，并产出带密码学证明和 AttestationReport 的聚合结果。它在产出聚合结果后不保留 per-Vault 输入。

  6. Composite Iteration Controller：在每轮聚合之后，评估 iteration_policy 中的收敛标准。决定是否进入下一轮、在收敛时提前停止，还是因隐私预算耗尽或达到最大轮次而终止

  7. Settlement Plane：对于此复合任务在两个层级运作。Per-round 子任务验证校验单个 TEE attestation 和隐私预算记录。复合验证对照接受标准评估整体训练结果。Reward Accounting Service 计算 per-actor 奖励份额，Payout Service 向 Aptos 上的 Reward Contract 提交 finalized 的奖励分发

Enterprise Node ​

每个参与的 enterprise node 运行以下服务：

  1. Vault (Data Sovereignty Service)：存储加密的消费历史和小票记录。在任何 training 范围的数据访问前执行同意检查。维护 per-data-subject 隐私预算账本条目。除了进入已证明的 TEE 外，明文不会离开 Vault。

  2. Computation Runtime (TEE)：每轮在 TEE 边界内执行两项操作：

    • 本地特征构造：根据已接纳的 DerivationRule 和 AttributeComposition 声明，从 Vault 内部记录导出获准的 feature aggregate
    • 本地梯度计算：使用本地构造的特征和从 master node 接收的当前全局模型参数，计算本地模型更新（梯度或参数增量）
    • 产出一个 SliceResultBundle，包含 commitment 关联的确定性输出以及 TEE AttestationReport 和隐私预算消耗记录

三级层次结构实践 ​

节点层面执行实现了 SCP 三级层次结构：

层级协议对象管理方数量
Parent task复合训练任务Master node Task Orchestrator1
Sub-task (round)每轮迭代Master node Multi-Vault CoordinatorN（轮次）
Execution slice每轮中每个 Vault 的贡献Enterprise node Computation RuntimeN x M（轮次 x Vault）

每个层级有自己的生命周期、evidence 链、TEE attestation 和 settlement 上下文。Master node 协调上层两级；enterprise node 执行最底层。

经济流 ​

此训练任务遵循 SCP Economics and Governance 中定义的 train 定价模型。本节追踪从预算锁定到奖励分发的完整资金生命周期。

费用计算 ​

模型运营方（Task Submitter）在 admission 时向 Escrow Contract 锁定 SYM。锁定金额按如下公式计算：

train_fee = base_fee_train
          + Σ_round(round_compute_fee + round_aggregation_fee)
          + (total_epsilon × per_epsilon_fee)

其中：

  1. base_fee_train：复合任务设置的最低费用，覆盖 admission、orchestration 和 verification 开销
  2. round_compute_fee：该轮 per-Vault 计算成本之和。Per-round 计算费用在 N 轮和 M 个 Vault 间累积，意味着总计算成本随轮次和参与 Vault 的乘积增长。
  3. round_aggregation_fee：每轮安全聚合步骤（federated_average）的成本
  4. total_epsilon：所有轮次累积消耗的差分隐私预算
  5. per_epsilon_fee：每单位隐私预算的价格，反映 per-data-subject 隐私的有限且不可再生性质

所有费用参数由当前 policy_version 设定，可能因 usage_scope 而异。

费用分配 ​

复合结算时，锁定的费用在协议参与者之间分配：

接收方份额依据
Data Contributors30-50%按所有轮次中使用的记录数和消耗的隐私预算按比例分配
Vault Operators15-25%按参与 Vault 中服务的记录数和存储承诺按比例分配
Executors15-25%按已验证的计算工作量（per-Vault 训练 slice + 聚合）按比例分配
Verifiers5-10%按验证决定次数（sub-task 和 composite 层级）分配
Protocol Treasury5-10%用于可持续性的固定协议费用

具体百分比由 policy_version 设定。总和必须等于锁定费用的 100%。

奖励会计 ​

此复合任务的奖励会计反映所有轮次和所有 Vault 的聚合已验证贡献：

  1. 每个参与的 Vault operator 按其在所有轮次中服务的记录数和为其数据主体消耗的隐私预算获得比例份额
  2. 每个执行 per-Vault 训练 slice 的 executor 按这些 slice 已验证的计算工作量获得奖励
  3. 聚合 executor（master node TEE）为每轮聚合步骤单独获得奖励
  4. 被 stake 的 Data Producer 其记录被使用时获得其计算数据使用分红的 100%；未 stake 的 Data Producer 获得 50%（余额返还奖励池）
  5. 被授权但在某轮中超时或失败的 Vault 不获得该轮 slice 的奖励

结算时序 ​

  1. 每个子任务（轮次）在其被 dispatch 时分配的 epoch 中结算
  2. 如果某个 epoch 在子任务执行过程中关闭，进行中的子任务保留其已分配的 epoch；后续子任务被分配到下一个 epoch
  3. 复合结算跨各自 epoch 聚合子任务结算
  4. 每个子任务的奖励会计遵循该子任务被分配到的 epoch

链上执行 ​

所有 SYM 分发通过 Aptos 上的智能合约执行：

  1. Escrow Contract：在 admission 时锁定模型运营方的 SYM；在 settlement finalization 前持有资金
  2. Reward Contract：从 Payout Service 接收 finalized 的奖励分发；向 Data Contributors、Vault Operators、Executors 和 Verifiers 分发 SYM；对 Data Producer 应用 staking 乘数
  3. Treasury Contract：接收 Protocol Treasury 份额

没有任何协议参与者在智能合约托管之外代持其他参与者的 SYM。

语义与特征处理 ​

这个场景也是受治理语义解释的一个典型例子。

如果某个模型依赖的概念无法被当前 canonical set 或 query set 直接解释，可能会出现几种情况：

  1. 该任务保持阻塞，直到语义被澄清
  2. 某些 feature logic 继续在策略允许下保持为本地处理
  3. 新出现的行为语义或 query 概念之后进入受治理的语义演化流程

因此，这个用例会自然触及：

  1. domain
  2. CanonicalAttribute
  3. QueryAttribute
  4. local attribute handling
  5. governed candidate evolution

关键在于，训练逻辑不能私下或悄悄改写协议含义。

关键边界提醒 ​

单纯想基于消费者行为训练模型，还不自动等于一个完整的协议事件。

只有当系统把这项训练意图转化成一项带有明确 feature、privacy 与 evaluation 约束的授权协议任务时，完整的 SCP 生命周期才会开始。

同样地，训练出的模型也不会自动等于协议真相；协议真相是那个被接受并完成结算的训练结果，而下游系统再据此决定是否部署或激活该模型。

本用例行使了最高复杂度的协议路径：带迭代子任务的复合任务、每轮多 Vault 扇出、联邦安全聚合、累积隐私预算管理、所有 Vault 和所有轮次的 TEE attestation、关联所有 round-level evidence 的复合结算，以及模型产物交付到下游注册中心。它作为 SCP 协议复杂度的上限参考场景。