Symphony Core 文档

简体中文

English

简体中文

English

Appearance

SCS 系统架构 ​

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

目的 ​

本文档定义 SCS（Symphony Core System）如何将 SCP 协议实现为一个具体的、可部署的系统。

它回答：

  1. 物理节点网络的结构及各节点上运行的内容
  2. 服务如何映射到 SCP 的 3 Planes + 2 Services 架构
  3. 节点之间以及节点与外部用户之间如何通信
  4. 每种节点类型存储哪些数据，以及持久化如何组织
  5. Aptos 上的智能合约如何实现 staking、escrow 和 settlement
  6. TEE 环境如何集成以支持隐私保护计算
  7. 系统如何处理故障、reconciliation 及运维问题

关于本系统必须保持的规范性协议语义，请参见：

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

设计原则 ​

SCS 实现 SCP 定义的协议事实，而非重新定义它。这意味着：

  1. SCP 定义生命周期含义、参与者职责、语义规则和经济不变量
  2. SCS 定义运行时服务、存储、API 和运维机制，在生产环境中保持这些含义
  3. 一个具体部署可以按需合并或拆分服务，只要保持相同的协议语义
  4. SCS 不增加协议概念——每个 SCS 行为都必须可追溯到某个 SCP 要求

Part 1: 部署拓扑 ​

节点网络 ​

SCS 网络由两种节点类型组成，运行在许可制拓扑中：

                    ┌──────────────────────────────────────┐
                    │         Master Node Cluster           │
                    │   (3 nodes, BFT consensus, Symphony)  │
                    │                                       │
                    │  ┌─────────┐ ┌─────────┐ ┌─────────┐│
                    │  │Master-1 │ │Master-2 │ │Master-3 ││
                    │  └────┬────┘ └────┬────┘ └────┬────┘│
                    │       └──────┬────┴────────────┘     │
                    │              │ BFT Consensus          │
                    └──────────────┼───────────────────────┘
                                   │
                    ┌──────────────┼───────────────────────┐
                    │    Inter-Node Communication Layer     │
                    │   (mTLS, authenticated, encrypted)    │
                    └──────┬───────┼──────────┬────────────┘
                           │       │          │
              ┌────────────┴┐  ┌───┴────────┐ ┌┴────────────┐
              │Enterprise-A │  │Enterprise-B│ │Enterprise-C │
              │  (Vault-A)  │  │  (Vault-B) │ │  (Vault-C)  │
              └─────────────┘  └────────────┘ └─────────────┘

Master Node 集群 ​

3 个 Master Node 由 Symphony Foundation 运营。它们共同运行：

  1. Admission Plane 服务 — API gateway、身份认证、consent 验证、语义解析、隐私预算预留、TaskEnvelope 组装
  2. Settlement Plane 服务 — 结果验证、challenge 生命周期、奖励核算、惩罚执行、payout 执行
  3. Governance Service — policy 版本管理、epoch 管理、参与者注册、治理提案
  4. BFT 共识引擎 — 协议最终性要求至少 3 个 Master Node 中的 2 个达成一致

Master Node 不存储私有用户数据。它们仅能看到 commitment、元数据和协议可见的工件。

每个 Master Node 都是完整副本：

  1. 每个 Master Node 运行完整的 master 服务集
  2. 任何单个 Master Node 故障不会中断协议运行
  3. 状态通过 BFT 共识协议同步
  4. 每个 Master Node 独立验证所有协议状态迁移

Enterprise Node ​

Enterprise Node 由经批准的企业运营。每个 Enterprise Node 运行：

  1. Vault 服务（Data Sovereignty Service）— 加密记录存储、consent 管理、隐私预算账本、授权执行
  2. 执行服务（Execution Plane 子集）— Vault 内部计算、可选 TEE 执行、slice 结果生产
  3. 节点代理 — 处理节点间通信、心跳检测以及与 Master 集群的协调协议

Enterprise Node 不运行 admission、verification、settlement 或 governance 服务。这些服务保留在 Master 集群上。

每个 Enterprise Node 独立运营：

  1. 企业控制自己的基础设施、存储和运维实践
  2. 企业数据不会离开 Vault 边界，除非以 commitment 引用或 TEE 处理结果的形式
  3. 企业在其 Vault 内管理数据主体的 consent 记录
  4. Enterprise Node 可以选择性地在自身 Vault 数据之外贡献计算能力

终端用户 ​

终端用户（Data Producer 和 Task Submitter）通过 Master 集群的 API gateway 与系统交互。他们不运行节点。数据流向如下：

  1. 数据上传：用户 → API gateway → Master Node 路由到指定的企业 Vault → 在 Vault 内执行解析
  2. 任务提交：用户 → API gateway → Master 上的 Admission Plane → TaskEnvelope → 分派到相关节点

Part 2: 服务架构 ​

服务到节点的映射 ​

ServiceRuns OnSCP Component
API GatewayMaster nodesAdmission Plane entry
Identity & Auth ServiceMaster nodesAdmission Plane
Consent Verification ServiceMaster nodes (reads from enterprise Vaults)Admission Plane
Semantic Registry ServiceMaster nodesAdmission Plane
Privacy Budget Reservation ServiceMaster nodes (writes to enterprise Vaults)Admission Plane
TaskEnvelope Assembly ServiceMaster nodesAdmission Plane
Task OrchestratorMaster nodesExecution Plane (coordination)
Multi-Vault CoordinatorMaster nodesExecution Plane (coordination)
Vault Storage EngineEnterprise nodesData Sovereignty Service
Consent ManagerEnterprise nodesData Sovereignty Service
Privacy Budget LedgerEnterprise nodesData Sovereignty Service
Computation RuntimeEnterprise nodes (+ optional TEE)Execution Plane (computation)
Aggregation RuntimeMaster nodes (in TEE)Execution Plane (aggregation)
Result Verification ServiceMaster nodesSettlement Plane
Challenge ManagerMaster nodesSettlement Plane
Reward Accounting ServiceMaster nodesSettlement Plane
Payout ServiceMaster nodesSettlement Plane
Policy Version ManagerMaster nodesGovernance Service
Epoch ManagerMaster nodesGovernance Service
Actor RegistryMaster nodesGovernance Service
BFT Consensus EngineMaster nodesCross-cutting

Master Node 服务详情 ​

API Gateway ​

  1. 所有外部请求（用户上传、任务提交、结果查询）的单一入口
  2. TLS 终结、速率限制、DDoS 防护
  3. 根据请求类型将请求路由到相应的内部服务
  4. 不执行协议逻辑——仅作为路由和防护层

Task Orchestrator ​

核心状态机驱动器：

  1. 从 Admission Plane 接收已验证的 TaskEnvelope
  2. 驱动任务通过规范状态迁移（accepted → resolving → dispatched → verifying → awaiting_settlement → completed）
  3. 多 Vault 任务：委托给 Multi-Vault Coordinator
  4. 复合任务：管理子任务排序和迭代控制
  5. 为每次状态迁移发出协议事件（可审计、可重放）
  6. 在每个阶段强制执行超时

Multi-Vault Coordinator ​

  1. 将协调信封展开为每个 Vault 的执行分配
  2. 向目标 Enterprise Node 发送执行分配
  3. 跟踪每个 Vault 的 slice 进度并执行 quorum 检查
  4. 当足够多的 slice 完成时触发聚合
  5. 处理部分完成和超时逻辑

Aggregation Runtime ​

  1. 在 Master Node 上的 attested TEE 中运行
  2. 接收每个 Vault 的 slice 结果（commitment 引用和隐私安全输出）
  3. 执行声明的聚合方法（union、intersection、secure_sum、federated_average）
  4. 在聚合层面强制执行基数阈值
  5. 生成带有密码学证明和 AttestationReport 的聚合结果
  6. 在生成聚合结果后不保留每个 Vault 的输入

Semantic Registry Service ​

  1. 存储 domain 层次结构、canonical attribute、query attribute、推导规则
  2. 在任务准入期间处理语义解析请求
  3. 管理属性生命周期迁移（proposed → registered → active → deprecated → retired）
  4. 支持 local attribute candidate 聚合和晋升工作流

Reward Accounting Service ​

  1. 接收已最终化的 settlement 上下文
  2. 使用费用分配公式和 policy version 计算每个参与者的奖励份额
  3. 应用 staking 乘数（staked 为 1.0，unstaked 的 Data Producer 为 0.5）
  4. 计算已解析记录的数据质量奖励
  5. 计算记录贡献的数据使用分红
  6. 生成奖励记录并将 payout 指令提交给 Payout Service

Payout Service ​

  1. 将已最终化的奖励记录转换为 Aptos 链上的 PayoutInstructionSet
  2. 管理签名者隔离（多签名 treasury）
  3. 按 epoch 批量处理 payout 指令
  4. 处理提交、重试和确认跟踪
  5. 记录 payout 成功或失败，而不修改已最终化的奖励记录

Enterprise Node 服务详情 ​

Vault Storage Engine ​

  1. 以加密形式存储 canonical private record
  2. 为每条记录维护 Commitment = SHA256(Serialize(CR))
  3. 强制执行静态和传输加密
  4. 仅通过经认证、经授权的通道支持记录检索
  5. 明文不离开 Vault，除非进入 attested TEE
  1. 在 Vault 内存储每个数据主体的 consent 记录
  2. 在任何数据访问前强制执行 consent 检查
  3. 处理 consent 的授予、撤回和过期
  4. consent 状态永远不以明文导出——仅共享 consent 验证结果（是/否）

Privacy Budget Ledger ​

  1. 维护每个数据主体、每个使用范围的 budget 跟踪
  2. 在任务准入期间处理来自 Master 集群的 reserve 操作
  3. 在执行期间处理 commit 操作
  4. 在任务执行前失败时处理 release 操作
  5. 强制已提交的消耗为 append-only

Computation Runtime ​

  1. 对 Vault 内部记录执行经授权的计算
  2. 解析任务：运行 OCR、提取和结构化输出生成
  3. query/compute/train slice：对经授权的记录进行评估并生成 SliceResultBundle
  4. 当 policy 要求时，可委托给本地 TEE 处理跨 Vault 任务
  5. 生成与 commitment 关联的、确定性的输出

Part 3: 节点间通信 ​

通信模型 ​

所有节点间通信使用基于证书认证的双向 TLS（mTLS）。

Master 到 Master ​

  1. BFT 共识消息：状态同步、区块提议、投票消息
  2. 服务复制：配置、注册表和核算状态
  3. 协议：内部共识协议（基于 gRPC）

Master 到 Enterprise ​

  1. 执行分配：TaskEnvelope + 每个 Vault 的执行参数
  2. Consent 验证请求："数据主体 X 是否对使用范围 Y 有 consent？"
  3. 隐私预算操作：reserve、commit、release
  4. Slice 结果收集：Enterprise 在执行后返回 SliceResultBundle
  5. 心跳和健康检查：Enterprise Node 存活性监控
  6. 协议：gRPC over mTLS，带消息签名

Enterprise 到 Master ​

  1. Slice 结果：已完成的执行输出，附带 proof 引用
  2. 隐私预算响应：预留确认、commit 确认
  3. Consent 验证响应：是/否结果
  4. 健康报告：存储容量、计算可用性、运行时间指标

用户到 Master ​

  1. 数据上传：用户通过 REST/gRPC API 上传原始数据（小票图片、文档）
  2. 任务提交：用户通过 REST/gRPC API 提交任务请求
  3. 结果检索：用户查询任务状态并检索已结算的结果
  4. 账户管理：staking、unstaking、奖励查询
  5. 协议：HTTPS REST 或 gRPC，使用 JWT/OAuth2 认证

Part 4: 数据架构 ​

按节点类型的持久化 ​

Master Node 持久化 ​

Master Node 存储协议状态，而非私有数据：

StoreContentsProperties
Task State StoreTask lifecycle events, TaskEnvelopes, state transitionsAppend-only, replicated across 3 masters
Semantic RegistryDomains, canonical attributes, query attributes, derivation rulesVersion-aware, replicated
Settlement StoreSettlement contexts (candidate and finalized), SettlementRoot recordsAppend-only, replicated
Reward LedgerPer-actor reward records, adjustments, payout intentsAppend-only, replicated
Challenge StoreChallenge lifecycle records, evidence referencesAppend-only, replicated
Epoch StoreEpoch definitions, window metadata, aggregation scopesReplicated
Policy StorePolicy version definitions, governance proposalsReplicated
Actor RegistryActor identities, role bindings, staking stateReplicated
Audit LogAll protocol events with timestampsAppend-only, immutable

Enterprise Node 持久化 ​

Enterprise Node 存储私有数据和本地协议状态：

StoreContentsProperties
Vault Record StoreEncrypted canonical private recordsEncrypted at rest, access-controlled
Commitment StoreCommitment references for all recordsIntegrity-linked to records
Consent StorePer-data-subject consent recordsNever exported as plaintext
Privacy Budget LedgerPer-subject, per-scope budget entriesAppend-only for committed entries
Local Attribute PoolLocal semantic candidates and stability metricsVault-scoped
Execution Transcript StorePer-task execution evidence and proof referencesAppend-only

Replay 与幂等性 ​

系统必须保持：

  1. 在所有持久化记录上保留对 replay 关键的版本和 epoch 上下文
  2. 对外部重试请求提供幂等的 create 行为（通过 request ID 去重）
  3. 在 task、semantic resolution、execution artifact 和 verification decision 之间建立确定性关联
  4. 已最终化的 accounting 保持 append-only——通过显式 adjustment 记录而非静默修改进行纠正

Part 5: 智能合约架构 ​

Aptos 上的合约 ​

所有协议管理的 SYM 由 Aptos 区块链上的智能合约持有：

Staking Contract ​

  1. 接受 S_master、S_enterprise 和 S_producer 层级的 SYM 存入
  2. 按层级强制最低 stake 要求
  3. 处理来自 Settlement Plane 的 slashing 指令
  4. 管理 unstaking 冷却期（节点 30 天，Data Producer 7 天）
  5. 将 staking 状态变更作为链上事件发出

Escrow Contract ​

  1. 在任务准入时锁定 Task Submitter 的 SYM
  2. 在 settlement 最终化前持有锁定资金
  3. 在最终化的奖励分配后将资金释放给接收方
  4. 对执行前被拒绝的任务将资金退还给提交者
  5. 对执行期间失败的任务支持部分释放

Reward Contract ​

  1. 接收来自 Payout Service 的按 epoch 聚合的奖励分配
  2. 将 SYM 分配给接收方（Data Producer、Vault Operator、Executor、Verifier）
  3. 应用 staking 乘数：staked producer 获得全额分配，unstaked 获得 50%（剩余进入奖励池）
  4. 在链上维护按 epoch 的奖励记录

Treasury Contract ​

  1. 持有 Protocol Treasury 和 Ecosystem Incentives 分配
  2. 仅通过治理批准的提案释放资金
  3. 接收任务费用中的 Protocol Treasury 份额
  4. 在启动阶段为数据质量奖励和运营成本提供资金
  5. 由 3 个 Master Node 多签控制

Inflation Controller ​

  1. 管理递减通胀计划（8% → 5% → 3% → 1.5% → 0%）
  2. 按 epoch 按计划铸造新 SYM
  3. 将铸造的 SYM 分配到奖励池和 treasury
  4. 第 5 年后自动停用

链上与链下边界 ​

ConcernOn-Chain (Aptos)Off-Chain (SCS services)
Staking stateCurrent stake, slashing recordsStaking UI, deposit workflow
Task feesLocked in escrow, distributed on settlementFee calculation, admission validation
RewardsFinal distribution amountsReward calculation, multi-Vault distribution
SettlementSettlementRoot hash anchored on-chainFull settlement context stored off-chain
GovernanceProposal voting resultsProposal creation, discussion, execution

链上层提供最终性和透明性。链下层提供计算、隐私和吞吐量。

Part 6: TEE 集成 ​

TEE 配置 ​

  1. Master Node 维护一个用于安全聚合的 TEE 环境
  2. Enterprise Node 可维护本地 TEE 环境用于跨 Vault 执行
  3. TEE enclave 配置预批准的计算代码（measurement hash 注册在治理注册表中）
  4. enclave 身份和 measurement 在配置时验证

TEE 执行流程 ​

对于跨 Vault 计算：

  1. Master Node 的 Multi-Vault Coordinator 将执行分配给 TEE
  2. Enterprise Vault 使用 TEE enclave 的公钥加密记录材料
  3. 加密数据传输到 TEE 环境
  4. TEE 在 enclave 内解密数据，执行计算
  5. TEE 生成带有 AttestationReport 的结果（enclave 身份、measurement hash、平台身份、freshness nonce）
  6. 结果和 attestation 返回给 Master Node
  7. TEE 在执行后清除所有记录材料

TEE Attestation 验证 ​

  1. Master Node 上的 Result Verification Service 验证每个 AttestationReport
  2. 验证检查：enclave measurement 与已注册代码匹配、平台未被撤销、freshness nonce 有效
  3. attestation 失败导致任务被拒绝
  4. TEE 平台撤销在治理注册表中跟踪

Part 7: 运维关注 ​

监控与告警 ​

系统应监控：

  1. 节点健康：Master 和 Enterprise Node 存活性、资源利用率
  2. 任务吞吐量：准入速率、执行延迟、settlement 时间
  3. 隐私预算：每个 Vault 的预算利用率、接近耗尽警告
  4. Staking：stake 水平、接近最低值警告、slashing 事件
  5. 共识：BFT 轮次时间、错过的投票、view 变更
  6. 链上：交易确认时间、gas 费用、合约状态

故障处理 ​

Master Node 故障 ​

  1. 单个 Master 故障：其余 2 个 Master 维持共识和协议运行
  2. 两个 Master 故障：协议暂停，直到至少 2 个 Master 可用（安全优先于活性）
  3. 故障 Master 通过从幸存节点进行状态追赶来重新加入

Enterprise Node 故障 ​

  1. 任务执行期间 Enterprise Node 故障：受影响的 slice 超时
  2. 如果剩余 Vault 仍满足 quorum：任务继续，覆盖范围部分缺失
  3. 如果 quorum 被打破：任务被拒绝或在 policy 下重试
  4. Enterprise Node 持续故障：治理可能暂停该节点并重新分配受影响数据主体的 consent 记录

链上故障 ​

  1. Aptos 链拥堵：payout 批次排队直到确认
  2. 合约故障：payout 在不修改链下奖励记录的情况下重试
  3. 链重组：reconciliation 服务检测并重新提交受影响的交易

Reconciliation ​

系统必须检测并处理：

  1. 重复提交（幂等去重）
  2. 部分下游影响（不完整的 payout 批次）
  3. 缺失的确认（payout 已提交但未确认）
  4. reconciliation 漂移（链下奖励记录与链上 payout 状态之间）
  5. epoch 窗口核算不一致

纠正始终通过 adjustment 记录显式进行，绝不通过静默修改。

升级与迁移 ​

  1. Master Node 上的服务升级：滚动升级，一次一个节点，全程保持 2-of-3 共识
  2. 智能合约升级：通过治理提案，在 Aptos 上使用 upgrade proxy 模式
  3. 协议版本迁移：在 epoch 边界进行，提前一个 epoch 通知
  4. Enterprise Node 软件升级：与 Master 集群协调，设有版本兼容的宽限期

Part 8: 实现保障 ​

必需的系统能力 ​

SCS 至少必须支持：

  1. Replay：执行和验证工件可以被重放，以在相同输入下重现相同结果
  2. Settlement root 可重现性：SettlementRoot 可以从相同的 settlement 上下文中独立计算
  3. 语义解析可审计性：任何任务的语义解析路径可以被重建
  4. Epoch 窗口可重建性：任何 epoch 的确切成员可以被重现
  5. Reward accounting reconciliation：奖励记录可以与链上 payout 记录进行对账
  6. 隐私预算可审计性：每个主体的预算消耗可以通过任务证据链进行审计

契约打包 ​

Markdown 规范集仍然是 canonical semantic source。

SCS 还必须产出机器可读的实现工件：

  1. 所有外部和内部接口的 API schema（OpenAPI/gRPC protobuf）
  2. 所有协议事件的 event schema（任务迁移、settlement、reward、penalty）
  3. schema_version、semantic_version 和 policy_version 的版本标注
  4. 协议错误族到 HTTP/gRPC 状态码的 error catalog 映射
  5. 所有 Aptos 合约的智能合约 ABI
  6. 所有已批准计算代码的 TEE enclave measurement hash

与 SCP 的关系 ​

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

关于协议架构、任务生命周期、语义模型、数据保护、settlement 和 economics 的规范含义，请参见：

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