SCS 系统架构

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

目的

本文档说明 SCS 如何把新修订后的 SCP 协议落实为具体系统。

如果从更高一层叙事来理解，Symphony 是一个去中心化的隐私数据平台，面向海量私有数据的接入、存储、治理、隐私查询、精准营销等商业活动、受保护计算与模型训练。SCS 解释的正是这个平台如何在生产环境中被实现出来，同时不削弱 SCP 定义的协议保障。

它回答：

1. 运行时模块如何实现协议分层
2. 信任、隐私与控制边界在系统中如何落地
3. 系统组件如何支撑从任务接纳到下游 payout 的完整协议生命周期
4. 各类参与者如何通过实现层交互，而不重新定义协议事实

实现原则

SCS 是 Symphony 栈中的实现主线。

它的职责是实现并保持 SCP 定义的协议事实，而不是重新解释协议。具体来说：

1. SCP 定义生命周期含义、参与者职责、语义演化、epoch 行为、settlement finality 与 economics 规则
2. SCS 定义运行时模块、存储边界、API 与运维机制，确保这些含义能在生产环境中被稳定保留
3. 一个具体部署可以按需要合并或拆分模块，只要最终保持相同的协议语义

因此，SCS 应被理解为 Symphony 平台在生产中的实现模型，而不是固定的硬件结构或节点拓扑。

运行时实现模型

在实现层面，SCS 通常通过一组协作模块来实现协议，例如：

1. 面向客户端的接入与 API 边界
2. 协调与生命周期控制模块
3. 语义命名空间与 registry 服务
4. Vault 与受保护数据访问服务
5. 执行运行时与 proof-producing worker
6. 验证与 challenge 处理服务
7. settlement、reward accounting 与下游 payout 集成模块

这些是实现模块，不是新的协议层。它们的存在，是为了实现 SCP 定义的七层逻辑协议模型。

SCP 分层到 SCS 模块的映射

修订后的 SCP 采用七层逻辑模型。SCS 一般按如下方式实现它们：

1. 应用层的实现

典型 SCS 模块：

1. API gateway
2. identity 与 authorization 校验
3. admission policy 执行
4. task intake 服务

实现目的：

1. 校验客户端意图
2. 校验调用者身份与授权上下文
3. 将可接纳的工作封装为符合协议的请求

2. 协调层的实现

典型 SCS 模块：

1. workflow orchestrator
2. state transition controller
3. retry 与 timeout manager
4. task routing 与 handoff 服务

实现目的：

1. 推动任务在 semantic、execution、verification 与 settlement 阶段之间流转
2. 强制生命周期按顺序迁移
3. 保持协议过程可审计

3. 语义层的实现

典型 SCS 模块：

1. domain 与 registry 服务
2. canonical attribute resolution 服务
3. compatibility policy evaluator
4. local candidate aggregation pipeline

实现目的：

1. 在 semantic_version 下解析协议含义
2. 将任务绑定到正确的 domain 与 attribute namespace
3. 支持受治理的语义演化，而不是默默漂移

4. 数据层的实现

典型 SCS 模块：

1. Vault 存储系统
2. 加密记录存储
3. commitment 与 evidence 存储
4. 带授权控制的 record materializer

实现目的：

1. 将私有记录保留在授权 Vault 或 TEE 边界内
2. 仅向下游计算暴露被允许的记录材料
3. 保持记录、访问与协议可见工件之间的密码学关联

5. 执行层的实现

典型 SCS 模块：

1. 受保护计算运行时
2. execution scheduler
3. proof-producing worker
4. transcript 与 result packaging 服务

实现目的：

1. 执行被授权的计算
2. 保持可审计的执行上下文
3. 在相同 replay 上下文下产出确定性的执行结果

6. 验证层的实现

典型 SCS 模块：

1. result checking 服务
2. proof validation 服务
3. challenge ingress 与 evidence pipeline
4. verification decision publisher

实现目的：

1. 在 settlement 前验证正确性与完整性
2. 保留可 replay 的证据
3. 以系统可处理的形式产出 accepted、rejected 或 challenged 的结果

7. 结算层的实现

典型 SCS 模块：

1. settlement assembler
2. root builder
3. finalized accounting writer
4. reward record 与 payout intent 生产模块

实现目的：

1. 锚定已验证状态
2. 组装候选与最终 accounting 上下文
3. 在不重定义协议 finality 的前提下，为下游 reward 与 payout 做准备

SCS 中的参与者交互模型

修订后的 SCP 参与者模型，在 SCS 中体现为面向系统的接口与控制面。

从高层看：

1. data producer 与 task submitter 等 ingress 参与者，主要与 admission、budget 与 quota 相关接口交互
2. Vault operator、executor 与 verifier 等 production 参与者，主要与受保护运行时、evidence 与 settlement 相关接口交互
3. governance 与 treasury 参与者，主要与 challenge、adjudication、accounting 与 payout authority 相关接口交互

SCS 必须保持这些参与者区分，因为它们直接影响 authorization、auditability、economics 落地与运行时隔离。

信任与控制边界

实现必须落实以下边界，才能保持修订后的 SCP 模型：

1. 私有明文只能存在于授权 Vault 或 TEE 边界内
2. 语义与 policy 决策必须具备版本意识，并可审计
3. 协调层必须作为生命周期推进的控制平面
4. verification 与 challenge 的证据必须支持 replay
5. settlement 与 reward 历史在 finalized 后必须保持 append-only
6. payout authority 必须位于 finalized protocol accounting 之后的下游边界

这些边界之所以重要，是因为 SCS 的职责是在真实部署条件下保持协议事实，而不是只在抽象逻辑里成立。

Epoch、Settlement 与下游 Accounting

修订后的 SCP 将 epoch 视为稳定的控制窗口，而不是原始数据或任务存在的前提条件。

因此，SCS 通常会实现带有 epoch 感知的服务，用于：

1. settlement grouping
2. reward calculation window
3. payout preparation window
4. semantic candidate aggregation window
5. 在需要 batching 的场景下进行 replayable partitioning

这意味着系统可以持续接纳与执行工作，而后续 accounting 与 aggregation 则围绕稳定的 epoch 窗口收敛。

实现保障能力

SCS 至少应支持以下能力：

1. execution 与 verification artifact 的 replay
2. settlement root 的可重现性
3. semantic resolution 的可审计性
4. epoch window 的可重建性
5. reward accounting 与下游 payout 的 reconciliation

这些都是在生产环境中保持修订后 SCP 语义所必需的系统能力。

与 SCP 的关系

本文档仅描述实现层如何落地协议。

关于协议分层、参与者、语义演化、epoch 行为、settlement truth 与 economics 的规范含义，请参见：

1. SCP 协议概览
2. SCP 核心规范
3. SCP 经济与治理