SCP 协议概览

Version: v1.0 (Draft) Status: Draft Authoritative: Yes

目的

本文档介绍 SCP（Symphony Core Protocol）——使去中心化隐私数据平台具备可信性的协议层。

本文档定位为概览而非规范性规格说明。其目标是让读者在一次阅读中建立对协议的完整认知模型，涵盖以下内容：

1. SCP 解决什么问题
2. 协议如何组织
3. 谁参与协议、各自做什么
4. 数据如何从上传流转到结算
5. 经济与治理如何维持系统的诚实性
6. 在哪里阅读详细规则

规范性定义请参见 SCP 核心规范 和 SCP 经济与治理。

SCP 解决什么问题

世界产生着海量隐私数据——小票、交易、行为、偏好——分散在数以百万计的个体和数以千计的企业之间。这些数据对分析、营销和 AI 训练具有重要价值，但使用它面临一个根本性矛盾：

1. 数据持有者（个人、企业）需要隐私、控制权和公平的报酬
2. 数据使用者（品牌、研究者、平台）需要数据的可访问性、质量和规模
3. 双方都不信任一个中心化的中介机构能够做到公平

SCP 通过定义以下协议来化解这一矛盾：

• 数据始终保留在所有者的控制边界（Vault）内，永不以明文暴露
• 计算在可信环境（TEE）内进行，而非将数据移出
• 每一项操作都通过确定性协议规则被验证、结算和激励
• 治理和经济是协议级关切，而非事后补充

最终效果：数据可以被使用而无需被看见，每个参与者由协议而非对某一方的信任来约束。

协议架构：3 个平面 + 2 个服务

SCP 由三个顺序流水线平面构成，辅以两个横切服务：

  Request ──► [Admission Plane] ──► [Execution Plane] ──► [Settlement Plane] ──► Result
                    │                      │                      │
                    ▼                      ▼                      ▼
              ┌─────────────────────────────────────────────────────────┐
              │              Data Sovereignty Service                    │
              │     (record storage, consent, privacy budget, access)   │
              ├─────────────────────────────────────────────────────────┤
              │                Governance Service                       │
              │     (policy version, epoch, staking, proposals)         │
              └─────────────────────────────────────────────────────────┘

Admission Plane ——面向公共的入口。负责验证调用者身份、检查授权与同意、解析语义含义、预留隐私预算，并组装一个不可变的 TaskEnvelope，供所有下游处理信任。

Execution Plane ——计算发生的地方。驱动任务状态机，协调多 Vault 扇出，在 Vault 或 TEE 边界内执行计算，运行安全聚合，并管理复合任务迭代。

Settlement Plane ——结果最终确定的地方。验证执行输出，管理质疑流程，计算奖励与惩罚，并在结算链上锚定不可逆的记账。

Data Sovereignty Service ——横切服务，管理记录存储、同意、隐私预算和 Vault 访问控制。三个平面都访问它，但任何平面都不能覆盖其主权决策。

Governance Service ——横切服务，管理策略版本、epoch、参与者质押和治理提案。它配置协议的行为方式，但本身不处理任务。

节点架构

SCP 运行在分布式节点网络上：

Master Nodes（3 个固定节点） ——由 Symphony Foundation 运营。运行 Admission Plane、Settlement Plane 和 Governance Service。三个 master node 组成一个 BFT 共识组，协议最终性要求至少 2/3 节点达成一致。Master node 质押 S_master SYM。

Enterprise Nodes（审批制成员） ——由经审批的企业运营，贡献内部数据。运行 Vault 存储（Data Sovereignty Service），可选地贡献算力。Enterprise node 通过治理机制申请并质押 S_enterprise SYM。其激励是双重的：当数据被使用时获得任务费用分成，以及积累数据贡献积分以抵扣自身的平台使用。

终端用户（非节点） ——上传数据的个人（Data Producer）和提交任务的人（Task Submitter）。Data Producer 可选地质押 S_producer SYM 以获取全额奖励（100%），而非折扣奖励（50%）。

任务模型

任务是 SCP 的基本工作单元。每一项协议操作——从解析小票到训练 AI 模型——都表示为一个任务。

任务类别

SCP 识别四种任务类别，每种具有不同的协议约束：

Class	功能	示例
parse	单 Vault 内的单条记录解读	小票 OCR、文档提取
query	跨 Vault 的受治理检索或受众筛选	"查找在新加坡购买过咖啡的用户"
compute	针对已授权记录的有界计算	资格评估、特征衍生
train	跨 Vault 的迭代模型训练	消费者行为模型、推荐引擎

任务生命周期

每个任务经历一个确定性状态机：

accepted → resolving → dispatched → verifying → awaiting_settlement → completed
    │          │           │            │               │
    └──rejected └──rejected └──rejected  └──challenged   └──challenged
    └──timed_out           └──timed_out  └──timed_out

正向路径为：admit → resolve semantics → execute → verify → settle → complete。

在任何节点，任务可以被 rejected（验证失败）、timed out（超时）或 challenged（争议开启）。这些是唯一合法的状态转换——协议明确禁止跳过状态。

TaskEnvelope

当任务通过准入后，Admission Plane 生成一个不可变的 TaskEnvelope，包含下游处理所需的一切：任务身份、分类、调用者上下文、授权、同意引用、语义版本、策略版本、隐私预算预留和协调参数。下游平面不得覆盖或扩展它。

语义模型

SCP 不将数据属性视为无治理的标签。它定义了一个三层语义模型，使含义显式、可演进且可审计。

三层属性

Canonical Attributes ——协议认可的语义真值。"这个记录字段意味着什么？"每个 canonical attribute 恰好属于一个 domain，具有生命周期（proposed → registered → active → deprecated → retired → superseded），并在 semantic_version 下版本化。部分 canonical attribute 被标记为 directly_queryable 以支持高效查询。

Query Attributes ——面向检索的受治理投影。"什么信号可以安全地暴露用于搜索？"每个 query attribute 通过显式的 DerivationRule（bucket、hash、boolean、aggregate、threshold 等）从 canonical attribute 衍生，并携带结构化的 QueryGranularity 来控制信息暴露量。

Local Attributes ——尚未成为 canonical 的新兴语义。它们在各个 Vault 内积累，可被提升为 vault 范围的 query attribute（本地使用），或经过跨 Vault 验证和治理审批后提升为完整的 canonical attribute。

Domain

属性按 domain 组织——具有治理边界的语义命名空间。Domain 形成层级结构：global domain → domain family → concrete domain → optional sub-domain。跨 domain 衍生需要显式的治理审批。

属性组合

实际查询通常组合多个属性（例如"新加坡"AND"咖啡"AND"最近 30 天"）。SCP 将组合视为协议级关切，因为组合属性可能将结果集缩小到足以危及匿名性的程度。每个组合声明一个 minimum_result_cardinality，低于该阈值的结果将被抑制。

数据保护

SCP 通过三种互补机制保护隐私数据：

同意与授权

两层条件必须同时满足：

1. Vault 级授权：Vault 运营者允许该参与者和任务类别访问记录
2. 数据主体同意：数据所属个人已同意该使用类别（个人、营销、分析、训练）

同意可撤销。撤销会阻止新任务，但不会追溯性地使已结算的工作失效。

隐私预算

按数据主体、按使用范围的预算约束累计披露量。协议采用预留-提交模型：

1. 准入阶段预留预估预算
2. 执行阶段提交实际消耗
3. 执行前失败释放预留
4. 执行后失败按预估水平提交（信息可能已被披露）
5. 补充仅在 epoch 边界、经治理授权时发生

TEE（可信执行环境）

跨 Vault 计算必须在经过认证的 TEE 内处理——一种硬件强制的安全飞地，证明什么代码在什么输入上运行。协议将 TEE 视为 Vault 隐私边界的临时延伸，而非独立的托管方。TEE 认证是任务证据链的一部分。

多 Vault 协调

当任务需要来自多个 Vault 的数据时，SCP 将其分解为：

1. 包含共享上下文和仲裁要求的协调信封
2. 在每个 Vault 内独立运行的按 Vault 执行切片
3. 在可信环境内合并切片结果的安全聚合步骤

聚合方不得是任务提交者，不得保留每个 Vault 的输出，且必须产生将聚合结果与其输入关联的密码学证明。

复合与迭代任务

训练任务被分解为子任务（轮次）。每一轮本身可以是多 Vault 任务。这创建了一个三级层次结构：

• Parent task → Sub-task (round) → Execution slice (per-Vault)

对于 N 轮 × M 个 Vault 的场景，协议管理：1 个 parent + N 个 sub-task + (N × M) 个 slice。每一级具有自己的生命周期、证据和结算上下文。

结算与质疑

质疑生命周期

任何经过验证的结果在结算最终化之前都可以被质疑。质疑遵循自身的生命周期（opened → reviewing → confirmed/not_confirmed → approved/closed_without_penalty → penalty_recorded）。质疑证据必须可重放。

对于复合任务，质疑可以针对特定的 slice、sub-task、聚合步骤或整体复合结果。

结算

结算将经过验证的执行转化为不可逆的记账：

1. collecting → verifying_inputs → candidate_ready → finalizing → finalized

最终化的结算是奖励分发、支付和协议审计的基础。

Token 经济（SYM）

SYM 是原生 token，在协议中按如下方式流通：

SYM 的支出方式

Task Class	定价基础	支付方
parse	免费	协议承担成本
query	基础费 + 每 Vault 费 + 每记录费 + 每 epsilon 费	Task Submitter
compute	基础费 + 计算单元 + 数据量 + 每 epsilon 费	Task Submitter
train	基础费 + 每轮计算费 + 聚合费 + 每 epsilon 费	Task Submitter

SYM 的赚取方式

机制	赚取方	依据
任务费用分配	Vault Operator、Executor、Verifier	按已结算任务中的贡献比例
数据质量奖励	Data Producer	基于可解析性、完整性、新鲜度、去重、领域需求的按记录评分
数据使用分红	Data Producer	其记录被 query/compute/train 任务使用时
节点运营奖励	所有节点	仅在引导阶段（通胀资金来源）

质押 S_producer 的 Data Producer 获得 100% 的奖励。未质押的 Producer 获得 50%。

Token 供应

混合模型：固定创世供应 + 递减的早期通胀（8% → 5% → 3% → 1.5% → 0%，跨越 5 年）。引导阶段结束后，所有奖励来自任务费用的再分配。

智能合约托管

所有协议管理的 SYM 由 Aptos 上的智能合约持有：质押合约、托管合约、奖励合约和金库合约。智能合约托管之外，任何参与者不得代表他人持有 SYM。

治理

Governance Service 管理：

1. 策略版本 ——可配置参数（费率、隐私阈值、质押金额），仅在 epoch 边界变更
2. Epoch ——用于结算、奖励和聚合分组的稳定时间窗口
3. 参与者注册 ——三级质押（S_master、S_enterprise、S_producer），配合渐进式惩罚
4. 治理提案 ——策略变更、属性提升、质疑裁决

所有治理由 3 个 master node 以 BFT 共识运作。

协议配置

策略版本

policy_version 在某一时间点捕获所有可配置的协议参数。任务按其准入时生效的策略版本进行评估，即使该版本后来被废弃。不进行追溯适用。

Epoch

epoch 是用于结算分组、奖励计算和重放分区的稳定窗口。Epoch 由时间、容量或治理触发器关闭。复合任务可跨越多个 epoch。

确定性

SCP 要求相同的输入和相同的重放上下文产生相同的输出。参数解析是 epoch_id、semantic_version 和 policy_version 的确定性函数。

与 SCS 的关系

SCP 定义协议层面什么必须成立。SCS（Symphony Core System）定义如何构建系统以在生产环境中实现这些规则。

关注点	SCP	SCS
任务生命周期	定义状态和合法转换	实现状态机和编排
语义解析	定义解析规则和不变式	实现注册服务和缓存
隐私	定义预算模型和同意规则	实现 Vault 存储和 TEE 集成
结算	定义最终性条件	实现链上结算合约
经济	定义定价、奖励和惩罚规则	实现费用托管、奖励分发和支付

从 Symphony 叙事的角度：

1. Symphony 是去中心化的隐私数据平台
2. SCP 是治理可信数据使用的协议层
3. SCS 是在生产环境中交付这些保障的系统实现层

如何阅读 SCP 文档

以本文档作为入口，然后按照你的问题跟进对应文档：

问题	文档
任务生命周期、语义模型、数据保护、执行、结算	SCP 核心规范
SYM token、定价、奖励、质押、惩罚、治理	SCP 经济与治理
小票上传端到端示例	上传购物小票到个人 Vault
跨 Vault 营销活动示例	面向近期瑞幸消费者的定向优惠券活动
隐私保护模型训练示例	面向消费者行为的隐私保护模型训练
系统架构与实现	SCS 系统架构

总结

SCP 是将分散的隐私数据转化为可验证、可治理且具有经济意义的成果的协议层——全程不暴露明文。

它结合了：

1. 3 个平面 + 2 个服务的架构，实现清晰的关注点分离
2. 四类任务模型（parse、query、compute、train），具有确定性生命周期
3. 三层语义模型（canonical、query、local），具有受治理的演进机制
4. 三重数据保护机制（同意 + 隐私预算 + TEE）
5. SYM token 经济，数据贡献者获得奖励、恶意参与者受到惩罚
6. 分布式节点网络（3 个 master + N 个 enterprise），由质押和 BFT 共识保障

这一组合使 SCP 成为隐私保护数据协作的完整协议，而不仅仅是一个任务 API、一个数据模型或一个奖励方案。