用例：上传购物小票到个人 Vault

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

场景

用户将一张购物小票图片上传到自己的个人 Vault，并请求系统将其解析为结构化消费数据。

本文档是说明性用例，用来展示新修订后的 SCP 与 SCS 规范如何映射到一个具体的终端用户流程。

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

为什么这个用例重要

这个场景虽然简单，但几乎覆盖了新版 Symphony 体系里最关键的几条边界：

1. 数据首先进入本地 Vault 边界
2. 只有在任务被授权接纳后，协议流程才真正开始
3. 执行之前必须先完成语义解析
4. 小票明文必须始终留在授权数据边界内
5. 只有被接受并完成结算的结果，才会成为协议可见事实

因此，这个小票上传用例很适合用来区分"原始存储"、"协议认可的工作"以及"下游记账"三者之间的关系。

入口区分

这个场景有两层：

1. 纯粹把文件上传到 Vault 存储
2. 上传后同时触发协议任务去解析小票

数据上传通过 Master Node 的 API Gateway 进行，API Gateway 将数据路由到分配的 Enterprise Node 的 Vault 进行存储。

这里描述的完整协议流程假设的是第二种情况：上传小票的同时触发一个解释小票的任务。

这一区分非常重要。把文件上传到个人 Vault，本质上首先是一个本地系统事件；只有当系统接纳了一个要求对该小票进行授权解释的协议任务时，它才进入 SCP 生命周期。

协议视角

从协议角度看，这个场景可以理解为：将一份私有小票转化为协议认可的工作，并在结果被接受后，进一步转化为已结算的协议事实。

1. Vault 接入与本地托管

用户把小票图片上传到自己的个人 Vault。

在这一步：

1. 原始图片仍然是本地私有数据
2. 小票内容仍然处于 Vault 隐私边界内
3. 此时还没有 reward、settlement 或协议事实可言

这一步是个人托管与协议参与之间的边界。

2. 任务接纳、分类与同意

如果用户请求系统解析这张小票，那么这个请求必须先被接纳为授权的协议工作。Admission Plane 会组装一个 TaskEnvelope，封装该任务的完整授权与语义上下文。

从高层看，admission 需要确定：

1. 谁发起了这项工作
2. 该调用者是否有权使用这张小票内容
3. 数据主体（此场景中即用户本人）已授予 personal_use 范围的同意
4. 想要执行的工作是什么，分类为 task_class: parse
5. 任务应在什么语义与策略上下文中执行

由于 parse 任务对 Data Producer 免费，TaskEnvelope 中的 budget_lock_ref 为 null——admission 阶段不需要 SYM 托管。

只有在这一步之后，小票解析请求才会变成协议认可的工作。

由于这是为所有者本人解析的个人小票，同意模型非常简单：数据主体和任务提交者是同一个参与者，personal_use 同意通过上传并解析的操作隐式授予。这种简单性是本用例特有的，不能推广到跨 Vault 或第三方场景。

3. 在 domain 与版本上下文中完成语义解析

在执行之前，协议必须先确定这些小票字段在当前语义上下文里到底代表什么。

在这个场景里，通常需要先选择合适的 expense 或 personal-finance domain，并把小票字段解析到当前有效的 canonical attribute 上，例如：

1. merchant
2. transaction date
3. total amount
4. currency
5. tax
6. payment method
7. line items

这一步之所以重要，是因为修订后的 SCP 不允许执行阶段悄悄"发明含义"。所有工作都必须在当前 semantic_version 和对应 domain 规则下被解释。

4. 受保护数据访问与执行

当语义被确定之后，系统才可以开始执行被授权的计算。

在这个例子里，执行过程通常包括：

1. 对小票图片做 OCR
2. 提取商户名和日期
3. 归一化金额
4. 结构化字段
5. 将字段映射成面向 expense 的记录

在整个阶段中：

1. 小票明文始终留在授权 Vault 边界内
2. 协议依赖的是记录关联、commitment、evidence 和执行工件，而不是不受限的明文流动
3. 执行始终绑定于已接纳的授权上下文和语义上下文

由于这是在所有者自有数据上的单 Vault parse 任务，默认策略下不需要 TEE 执行。Vault 运营者可在本地执行解析。多 Vault 协调不适用于此场景。

5. 验证与被接受结果的形成

协议不会把执行输出自动视为最终事实。

相反，执行结果还必须经过正确性与完整性检查。从结果角度看，可能的状态是：

1. accepted
2. rejected
3. challenged

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

6. 结算、记账与可选的下游效果

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

在这个用例里：

1. settlement 的作用是把已接受的工作转化为协议认可的事实
2. 如果解析后的数据满足质量标准，系统会按照 Economics 模型计算数据质量奖励（参见下方的经济流转章节）
3. reward accounting 在 epoch settlement 时最终确认，并通过 Aptos 上的 Reward Contract 进行分发

对于个人小票解析请求来说，正常结果是用户拿到可信的结构化消费记录，并且如果数据满足质量阈值，还会获得数据质量奖励。

7. 结果交付给数据主体

结算完成后，finalized 的结构化消费记录必须交付给用户。

在此场景中：

1. 任务提交者和数据主体是同一个参与者，因此交付授权是固有的
2. 交付结果是从 finalized settlement context 派生的结构化消费记录
3. 交付被记录为协议可审计的事件
4. 原始小票图片和内部 evidence reference 不包含在交付结果中

节点层面的执行

从 SCS 角度看，同一个场景映射到 SCS 系统架构 中定义的两层节点架构。以下将每个协议步骤追踪到负责处理它的节点和服务。

Master Node（3 个，Symphony Foundation 运营）

3 个 Master Node 共同提供 Admission Plane 和 Settlement Plane 服务。在本用例中它们负责：

1. API Gateway —— 通过 HTTPS 接收用户的上传请求和解析触发。执行 TLS 终止、速率限制和请求路由。将原始小票图片路由到分配的 Enterprise Node 的 Vault 进行存储。

2. Admission Plane 服务 —— Identity & Auth Service 验证用户身份。Consent Verification Service 确认 personal_use 同意（读取 Enterprise Node 的 Consent Manager）。Semantic Registry Service 将小票字段解析到当前 domain 和 semantic_version。TaskEnvelope Assembly Service 将已接纳的任务打包，设置 budget_lock_ref: null（parse 免费）。组装好的 TaskEnvelope 传递给 Task Orchestrator。

3. Task Orchestrator —— 驱动任务通过规范状态转换（accepted → resolving → dispatched → verifying → awaiting_settlement → completed）。对于这个单 Vault parse 任务，无需 Multi-Vault Coordinator 参与。Orchestrator 将执行分配分派到目标 Enterprise Node。

4. Settlement Plane 服务 —— Result Verification Service 对执行输出进行正确性和完整性评估，产出 accepted、rejected 或 challenged 的决定。Reward Accounting Service 计算数据质量奖励（如果解析记录满足质量标准）。Payout Service 将奖励指令批量提交，等待在 Aptos 上进行 epoch settlement。

Enterprise Node（分配的 Vault）

托管用户 Vault 的 Enterprise Node 负责数据托管和本地计算：

1. Vault Storage Engine —— 接收并存储加密的小票图片。维护该记录的 Commitment 引用。明文不会离开 Vault 边界。

2. Consent Manager —— 存储并执行用户的 personal_use 同意记录。响应来自 Master Node Admission Plane 的同意验证请求。

3. Computation Runtime —— 在 Vault 边界内执行 parse 任务：运行 OCR，提取字段（merchant、date、amount、line items），归一化数值，并在已解析的语义 schema 下映射为结构化 canonical 记录。产出 commitment 关联的、确定性的执行输出，附带可重放的 transcript。

步骤-节点映射

协议步骤	节点	服务
1. Vault 接入	Enterprise Node	Vault Storage Engine
2. 任务接纳	Master Node	API Gateway → Admission Plane（Identity、Consent、Semantic、TaskEnvelope Assembly）
3. 语义解析	Master Node	Semantic Registry Service
4. 执行	Enterprise Node	Computation Runtime
5. 验证	Master Node	Result Verification Service
6. 结算	Master Node	Reward Accounting Service → Payout Service
7. 结果交付	Master Node → 用户	API Gateway

经济流转

小票上传与解析场景走的是协议中最简单的经济路径。完整的定价与奖励模型定义在 SCP 经济与治理 中。

Parse 对 Data Producer 免费

1. 用户上传和解析数据不需要任何 SYM
2. 解析的计算成本由协议承担：
   • 引导阶段：由 Protocol Treasury 和 Ecosystem Incentives 分配资金
   • 长期：由 Protocol Treasury 从 query、compute 和 train 任务收取的 task fee 中获得的份额资助
3. 这一设计消除了数据入驻的摩擦，数据入驻是生态系统供给侧的核心驱动力

数据质量奖励

如果解析后的小票记录满足质量标准（可解析性、非重复、完整性、新鲜度），Data Producer 将获得数据质量奖励：

data_reward = base_reward
            × (1 + completeness × 0.3 + freshness × 0.2)
            × domain_demand_multiplier
            × staking_multiplier

其中：

1. base_reward：每条有效记录的最低奖励，由 policy_version 设定
2. completeness（0.0–1.0）：已填充的可选字段占已解析 schema 中全部可选字段的比例
3. freshness（0.0–1.0）：基于数据年龄相对于解析时间的评分（24 小时 = 1.0，在可配置窗口内衰减）
4. domain_demand_multiplier（0.5–3.0）：由治理设定的按 domain 区分的乘数，反映当前生态系统需求
5. staking_multiplier：
   • 已质押的 Data Producer（持有 S_producer 质押）：1.0（100% 奖励）
   • 未质押的 Data Producer：0.5（50% 奖励；剩余 50% 返还至 epoch 奖励池）

质押是可选的。Data Producer 可以在不质押的情况下参与并获得奖励，但获得的支付金额会减少。

未来分红

解析后的小票记录不会在初始质量奖励之后就停止产生收益。当该记录后续被下游的 query、compute 或 train 任务使用时，Data Producer 会获得 task fee 的一部分作为数据使用分红。分配比例与使用的记录数量以及针对这些记录消耗的隐私预算成正比。

结算与分发

1. 数据质量奖励在 epoch settlement 时由 Master Node 上的 Reward Accounting Service 计算
2. 奖励分发通过 Aptos 区块链上的 Reward Contract 执行
3. 如果单个 epoch 的奖励池耗尽，剩余符合条件的记录将排队等待下一个 epoch

这个场景中的语义演化

小票解析也是一个很好的例子，可以说明修订后协议中的语义增长是如何发生的。

如果小票里出现的字段或标签，无法被当前 canonical set 直接映射：

1. 它可能保持 unresolved，并要求更严格的处理
2. 它也可能在策略允许的前提下，继续作为 Vault 内部的本地数据存在
3. 它之后还可能演化为一个隐私安全的 LocalAttributeCandidate

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

1. domain
2. CanonicalAttribute
3. Vault 内部的 local attribute handling
4. 在治理规则下进行的 candidate 演化

关键在于，语义上的新内容可以先存在，但不会自动变成共享的协议事实。

关键边界提醒

单纯把小票图片上传到 Vault，并不自动等于一个完整的协议事件。

只有当系统把这个上传对象转化成一项被授权接纳的协议工作，并要求它经历语义解析、执行、验证和结算时，完整的 SCP 生命周期才会真正开始。

同样地，最终得到的结构化消费记录，也不是因为系统跑过一次 OCR 或解析流程就自动成为协议事实；只有在结果被接受并完成结算后，它才具有协议认可的地位。

本用例是最简单的协议路径：单 Vault、单 parse 任务、自我同意、无隐私预算消耗、无 TEE 要求、结果直接交付给数据主体。它作为基线，应与更复杂的多 Vault 和迭代场景进行对比。