用例：面向近期瑞幸消费者的定向优惠券活动

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

场景

瑞幸咖啡希望在新加坡发起一场营销活动，面向过去 30 天内有过瑞幸消费的用户发放优惠券。

这场活动的目标，是从合资格用户中选出最多 5000 人，并通过下游业务系统向他们发券。

本文档是说明性用例，用来展示新修订后的 SCP 与 SCS 规范如何映射到一个由广告客户发起的定向人群筛选与发券场景。

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

为什么这个用例重要

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

1. 发起方是广告客户，而不是普通终端用户
2. 资格判断依赖的是处于 Vault 边界内的受保护消费记录
3. 任务本身带有地域、时间窗口与人数上限约束
4. 目标人群结果必须经过验证后，才能成为可被活动使用的可信事实
5. 发券动作位于 finalized protocol accounting 之后的下游

因此，这个用例很适合说明：协议可以支持隐私保护下的营销激活，但不会把原始消费者记录直接暴露成协议可见明文。

入口区分

这个场景有两层：

1. 业务侧的 campaign intent
2. 协议认可的人群资格判断与筛选任务

"瑞幸希望向新加坡过去 30 天内消费过的用户发券"本身还不是一个完整的协议事件。只有当 master node cluster 将其转化为一项带有明确定向约束的授权任务时，它才真正进入 SCP 生命周期。

与小票上传场景不同，本用例涉及：

1. 第三方广告客户访问分布在多个 enterprise node 的 Vault 中的个人消费者数据
2. 多 Vault 协调，其中 master node cluster 将执行扇出至 enterprise node 并聚合结果
3. 数据主体对 marketing 使用范围的显式同意
4. 人群筛选查询的隐私预算消耗
5. 在 enterprise node（per-Vault 切片）和 master node（安全聚合）上的 TEE 执行
6. 结果交付给广告客户的下游活动系统

协议视角

从协议角度看，这个场景的核心，是把一项 campaign intent 转化为一个可验证、可结算的人群筛选结果。

1. Campaign 意图与本地业务输入

瑞幸先定义一场活动，其业务条件包括：

1. advertiser identity：瑞幸咖啡
2. geography：新加坡
3. eligibility window：过去 30 天
4. audience rule：过去 30 天内有过瑞幸消费的用户
5. audience cap：5000
6. downstream outcome：发放优惠券

在这个时点上，它仍然只是业务请求，还不是协议事实。

2. 任务接纳、同意验证与约束绑定

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

从高层看，admission 需要明确：

1. 广告客户是否有权提交这场活动
2. 活动是否绑定了明确的 policy 与 budget 上下文，包括货币 budget lock —— 生成的 TaskEnvelope 携带一个 budget_lock_ref，指向 Aptos 链上的 SYM 托管
3. 任务分类为 task_class: query
4. geography 和时间窗口是否被固定为本次任务的一部分
5. 5000 人的 audience cap 是协议需要评估的任务约束，不是建议性限制
6. 参与 Vault 间是否有足够的隐私预算可用于此查询

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

1. 参与 Vault 中持有的数据主体已授予 marketing 使用范围的同意
2. 仅已同意的记录有资格参与资格评估
3. 已撤回 marketing 同意的用户无论消费历史如何均被排除

只有经过这一步，这项 campaign 才成为协议认可的工作。

3. 语义解析、推导规则与属性组合

在执行任何筛选之前，协议必须先在当前语义上下文中解释这项任务。

这意味着协议需要先确定以下概念在当前 domain 与 semantic_version 下分别代表什么：

1. 瑞幸消费 — commerce 域的 CanonicalAttribute
2. 消费时效性 — 通过 threshold 类型的 DerivationRule 推导（消费日期与 30 天窗口比较），产出 boolean 查询属性
3. 新加坡地域资格 — geography 域的 CanonicalAttribute，可以在 city 空间分辨率下 directly_queryable，或通过 DerivationRule 推导到更粗粒度
4. 活动目标受众成员资格 — 上述属性的组合结果
5. 可用于发券的目标身份或联系方式 — identity 域的 CanonicalAttribute

此场景需要一个跨域 AttributeComposition：

1. operator：AND
2. operand_attributes：[purchase_recency (commerce), singapore_eligibility (geography)]
3. combined_privacy_class：两个操作数隐私等级中的较高者
4. minimum_result_cardinality：策略定义的阈值，低于此值时结果必须被抑制

消费时效性的跨域推导必须引用 commerce 域的 purchase_date 属性，cross_domain_policy: allowed，因为 geography 域在此组合中为只读。

这一步之所以重要，是因为修订后的 SCP 要求共享语义、显式推导规则和已声明的属性组合必须先于受保护计算成立。

4. 多 Vault 协调与受保护的资格评估

由于消费记录分布在多个 Vault 中，本任务需要 SCP 核心规范中定义的多 Vault 协调。

协调信封

协议创建一个协调信封，包含：

1. participating_vault_ids：所有可能持有相关消费记录的 Vault
2. minimum_vault_quorum：结果有效所需的最少 Vault 响应数
3. aggregation_method：带基数上限的 union，因为活动需要跨所有 Vault 选出最多 5000 名合资格用户

Per-Vault 执行切片

每个参与 Vault 独立执行：

1. 检查本地消费历史中过去 30 天内的瑞幸消费记录
2. 评估本地记录的新加坡地域条件
3. 过滤仅保留数据主体已授予 marketing 同意的记录
4. 产出包含隐私安全合资格用户信号的 SliceResultBundle，而非原始消费记录

每个切片在 TEE 中执行，因为计算涉及广告客户未运营的 Vault 的记录材料。TEE attestation report 包含在切片 evidence 中。

安全聚合与人数上限执行

Aggregation Runtime 在 master node 上的 attested TEE 中运行。聚合步骤：

1. 合并 per-Vault 切片结果，不暴露哪个 Vault 贡献了哪些用户
2. 在聚合层将 5000 人的 audience cap 作为协议不变量强制执行
3. 若跨所有 Vault 合资格用户超过 5000 人，按 policy 定义的选择逻辑（如随机抽样或按时间加权）选择
4. 若响应 Vault 数量少于法定数量，任务被拒绝而不是在不完整覆盖下继续

隐私预算消耗

1. 每个 per-Vault 切片在 marketing 使用范围下为受影响数据主体消耗隐私预算
2. 隐私预算消耗在执行时记录，在聚合结果形成之前
3. marketing 隐私预算已耗尽的数据主体被排除在查询之外

在整个阶段中：

1. 原始消费记录始终留在授权 Vault 或 TEE 边界内
2. 协议依赖的是 evidence、commitment 与可 replay 的工件，而不是任意暴露明文
3. 所有筛选逻辑都必须绑定于已接纳的 campaign 约束
4. 广告客户永远看不到个人消费记录，只能看到最终的聚合人群筛选结果

5. 验证与被接受的人群结果

协议不会把一份候选受众名单自动视为最终事实。

相反，人群筛选结果还必须经过正确性与完整性验证。从结果角度看，可能是：

1. accepted
2. rejected
3. challenged

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

6. 结算、记账与发券依据

如果结果被接受，它就可以进入 settlement，并沉淀为 finalized protocol accounting 的一部分。

在这个场景里：

1. settlement 的作用是把已接受的人群筛选结果转化为协议认可的活动事实
2. finalized accounting 会成为下游发券的可信依据
3. 锁定的 SYM 从托管中按费用分配公式分配 —— Data Contributors、Vault Operators、Executors、Verifiers 和 Protocol Treasury 各自按 policy 定义的份额获得分配
4. 实际发券动作仍然是下游业务效果，而不是协议事实本身

也就是说，协议负责确定哪份人群结果是可信的；下游业务系统负责把这份可信结果转化为真正发出的优惠券。

7. 结果交付给活动系统

结算完成后，finalized 的人群筛选结果必须交付给广告客户的下游活动系统。

在此场景中：

1. 任务提交者（瑞幸作为广告客户）是授权的交付接收方
2. 交付结果包含可用于发券的联系方式或匿名标识，而非原始消费记录
3. 交付被记录为协议可审计的事件
4. 活动系统随后可基于交付结果发放优惠券，但协议不治理发券机制本身

节点级执行

从 SCS 角度看，同一个场景是由分布在两种节点类型上的协作服务共同实现的：master node（由 Symphony Foundation 运营）和 enterprise node（由经批准的企业运营）。

执行流遵循路径：User → Master → Enterprise（扇出）→ Master（聚合）→ Master（结算）。

Master Node 服务

1. API Gateway

master node cluster 上的 API Gateway 接收瑞幸的活动请求。它终结 TLS、执行限流，并将请求路由到 Admission Plane 服务。API Gateway 仅是路由与保护层 —— 不执行协议逻辑。

2. Admission Plane

Admission Plane 验证广告客户身份与授权，核实参与 Vault 间的同意和隐私预算可用性，解析语义上下文，并组装带有活动约束、budget_lock_ref 和协调信封的 TaskEnvelope。任务进入 accepted 状态。

3. Task Orchestrator

Task Orchestrator 接收经过验证的 TaskEnvelope，驱动任务经历规范状态迁移（accepted → resolving → dispatched → verifying → awaiting_settlement → completed）。由于这是多 Vault 任务，它委托给 Multi-Vault Coordinator。

4. Multi-Vault Coordinator

Multi-Vault Coordinator 将协调信封展开为 per-Vault 执行分配，将每个分配发送到目标 enterprise node，追踪 per-Vault 切片进度，执行法定数量要求，并在足够多切片完成后触发聚合。

5. Aggregation Runtime（TEE）

Aggregation Runtime 在 master node 上的 attested TEE 中运行。它接收 per-Vault SliceResultBundle 输出，执行带基数上限的 union 聚合，强制执行 5000 人的 audience 限制，生成附带加密证明和 AttestationReport 的聚合结果，并在生成聚合结果后清除 per-Vault 输入。

6. Settlement Plane

Settlement Plane 验证聚合结果（包括每个 per-Vault 切片和聚合步骤的 TEE attestation report），保留可 replay 的 evidence，并完成结算。在结算完成时，Reward Accounting Service 计算每个参与方的奖励份额，Payout Service 通过 Aptos 上的 Reward Contract 将 SYM 分配给各接收方。

Enterprise Node 服务

每个 enterprise node 在其自身的 Vault 边界内独立执行以下操作：

1. 授权与同意验证

Vault 服务验证传入的执行分配是否已被授权，本地 Vault 中的数据主体是否已授予 marketing 使用范围的同意，以及每个数据主体是否还有足够的隐私预算。已撤回 marketing 同意或隐私预算已耗尽的用户在任何计算开始前即被排除。

2. Computation Runtime（TEE）

Computation Runtime 在 Vault 或 TEE 边界内，对授权记录评估资格条件 —— 瑞幸消费时效性、新加坡地域和同意。它产出包含隐私安全合资格用户信号（而非原始消费记录）的 SliceResultBundle，附带 commitment 关联的确定性输出和 TEE attestation evidence。

SliceResultBundle 被返回给 master node cluster 用于聚合。

经济流

本节追踪 SYM 在本次活动中的协议流转过程。

预算锁定

在任务进入 admission 之前，瑞幸（作为 Task Submitter）在 Aptos 上的 Escrow Contract 中锁定 SYM。锁定金额根据查询定价公式计算：

query_fee = base_fee_query
          + (n_vaults × per_vault_fee)
          + (n_records_returned × per_record_fee)
          + (epsilon_consumed × per_epsilon_fee)

所有费用参数由当前生效的 policy_version 设定。TaskEnvelope 携带一个 budget_lock_ref 指向该托管。任务在未确认托管锁定的情况下无法被接纳。

结算时的费用分配

当任务完成且结算被 finalized 后，锁定费用按以下方式分配：

Recipient	Share	Basis
Data Contributors	30-50%	proportional to records used and privacy budget consumed against their data
Vault Operators	15-25%	proportional to records served and storage commitment
Executors	15-25%	proportional to verified compute work (per-Vault slices and aggregation)
Verifiers	5-10%	per verification decision
Protocol Treasury	5-10%	fixed protocol fee for sustainability

具体百分比由当前生效的 policy_version 设定。各项之和等于锁定费用的 100%。

数据使用分红

在资格评估中被使用了记录的 Data Contributors 从 Data Contributor 份额中获得数据使用分红：

1. 分配按每个 Data Producer 被使用的记录数量成比例，并以其记录所消耗的隐私预算加权
2. 已质押的 Data Producer（已存入 S_producer SYM）获得其计算分红的 100%
3. 未质押的 Data Producer 获得 50% —— 剩余 50% 返回 epoch 奖励池
4. 分红归属使用 Vault 内部记账，因此协调层永远无法看到具体是哪个 Data Producer 的记录被使用

支付执行

所有分配通过 Aptos 上的 Reward Contract 执行：

1. master node cluster 上的 Reward Accounting Service 生成每个参与方的奖励记录
2. Payout Service 将这些记录转化为 PayoutInstructionSet 并提交上链
3. Reward Contract 向各接收方分配 SYM，并应用质押乘数
4. 支付记录是 per-epoch、仅追加的，可与链上状态对账

语义与资格处理

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

如果活动依赖的某些概念无法被当前 canonical set 直接解释，可能会出现几种情况：

1. 任务会先被阻塞，直到语义被澄清
2. 某些概念会在策略允许的范围内保持本地处理
3. 一些新的 campaign 或 audience 概念之后可能进入受治理的语义演化流程

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

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

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

结算与发券后果

这个用例并不意味着瑞幸一定会直接获得协议奖励。

在协议层面，更核心的后果是：

1. 形成一份可信、被接受、并已结算的人群筛选结果
2. 形成下游发券可依赖的 finalized accounting basis
3. 记录所有被评估数据主体的隐私预算消耗
4. 结算上下文中保留 TEE attestation evidence

如果这条活动流程属于一个带激励的网络路径，那么也可能对某些 production roles 产生 reward 后果，例如：

1. 提供授权数据访问的 Vault operator
2. 执行 TEE 证明资格评估的 executor
3. 验证聚合结果的 verifier

这些后果都必须建立在协议认可的状态迁移之上。

关键边界提醒

广告活动 brief 本身并不自动等于一个完整的协议事件。

只有当系统把这项业务意图转化成一项带有明确 audience、location 和 recency 约束的授权任务时，完整的 SCP 生命周期才会开始。

同样地，真正发出的优惠券也不是协议事实本身；协议事实是那份被接受并完成 settlement 的目标受众结果，而下游系统只是基于这份结果采取业务动作。

本用例展示了协议的完整复杂性：跨 master node 和 enterprise node 的多 Vault 扇出与聚合、第三方数据主体同意验证、在 enterprise node 和 master node 上的 TEE 证明执行、隐私预算消耗、聚合层的人数上限强制执行、通过 Aptos 智能合约的 SYM 托管与费用分配，以及结果交付给下游业务系统。它是理解 SCP 如何在隐私和经济约束下治理跨 Vault 查询工作的参考场景。