Symphony Core 文档

简体中文

English

简体中文

English

Appearance

SCS 数据与集成 ​

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

目的 ​

本文档定义 SCS 如何在持久化、API、schema 与外部集成中实现修订后的 SCP 模型。

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

它回答：

  1. 协议工件在实现层如何打包
  2. 系统必须维护哪些持久化域
  3. replay、幂等与审计性如何以数据形式被保留
  4. 下游链或 payout 集成如何连接到 finalized protocol accounting

契约打包 ​

Markdown 规范集仍然是 canonical semantic source。

同时，SCS 还需要产出机器可读的实现工件，例如：

  1. request 与 response schema
  2. 内部 event 与 message schema
  3. schema_version、semantic_version 与 policy_version 的版本标注
  4. 对语义与生命周期敏感对象的 compatibility metadata
  5. error catalog 与面向实现的 validation contract

这些工件是实现交付物，不替代 SCP 定义的协议含义。

API 与集成面 ​

SCS 应暴露能够实现协议能力的接口面，例如：

  1. task admission 与 task state 查询接口
  2. result、transcript、proof 或 evidence 的读取接口
  3. challenge 提交与状态查询接口
  4. reward 与 finalized accounting 的读取接口
  5. payout intent 或 payout batch 的查看接口
  6. semantic、execution、verification 与 settlement 之间的内部队列或事件流

具体路由形态可以因实现而异，但这些接口必须保持相同的协议语义。

持久化域 ​

为了实现修订后的 SCP，SCS 至少应持久化以下域：

  1. task admission 状态与任务生命周期事件
  2. 语义命名空间数据，包括 domain、canonical attribute 与 candidate 演化工件
  3. query projection 数据，包括查询属性与 audience index 记录
  4. feature 与 model training 数据，包括在 policy 允许下的 training manifest 与 model artifact
  5. execution transcript、result bundle 与 proof reference
  6. verification decision、evidence reference 与 challenge 关联记录
  7. epoch 定义与 window-scoped aggregation metadata
  8. settlement candidate 与 finalized accounting 上下文
  9. reward allocation、adjustment 与下游 payout intent 记录
  10. reconciliation、audit 与 operational trace 记录

语义命名空间持久化 ​

由于修订后的 SCP 显式建模了由 domain 治理的语义演化，SCS 应维护以下实现存储：

  1. domain hierarchy 与 domain status
  2. canonical attribute lifecycle state
  3. 查询属性定义与 projection governance metadata
  4. local attribute pool 与 privacy-safe candidate summary
  5. candidate aggregation window 与 promotion workflow record
  6. semantic_version 下的 compatibility 与 replacement metadata

这些存储使系统可以在不静默改变协议含义的前提下支持语义增长。

Query Projection 与 Audience Index 持久化 ​

当实现需要支持可扩展的资格检索、营销激活或其他受治理的 audience-selection 工作流时，SCS 应维护以下实现存储：

  1. 由语义治理导出的 query projection definition
  2. 以受治理查询信号为键的 audience index 行或 posting 记录
  3. 将每条索引信号关联回 source commitment、record 或 protected computation 的 projection lineage
  4. 规定哪些 actor class 和 workflow 可使用这些 query projection 的 policy metadata
  5. 在查询窗口受时间约束时，用于 projection refresh、revocation 或 expiry 的记录

这些存储必须位于 Vault 隐私边界的下游。它们不是 canonical private record 的替代物。

Feature、Training 与 Model 持久化 ​

当实现需要支持 consumer behavior training 或其他模型构建工作流时，SCS 应维护以下实现存储：

  1. 描述哪些受保护或派生信号可进入训练流程的 feature manifest
  2. feature snapshot、aggregate 或 training-safe dataset manifest
  3. training task definition、版本上下文与 authorization scope
  4. model artifact metadata、model version 与 evaluation record
  5. 足以重建受治理训练流程的 replayable training evidence、lineage 或 audit record

这些存储应始终区分：

  1. 仍保留在 Vault 或 TEE 边界内的私有源记录
  2. 经 policy 批准可用于训练的派生 feature 或 aggregate
  3. 作为训练工作流系统可见输出的 model artifact

Replay 与幂等属性 ​

实现必须保留以下属性：

  1. 在持久化记录中保留对 replay 关键的版本与 epoch 上下文
  2. 对外部重试请求提供幂等的 create 行为
  3. 在 task、semantic resolution、execution artifact 与 verification decision 之间建立确定性关联
  4. 让 settlement 与 reward 相关的 finalized accounting 历史保持 append-only
  5. 通过显式 adjustment 与 reconciliation record，而不是静默修改，来处理纠偏

Settlement、Reward 与 Payout 记录 ​

修订后的 SCP 将 settlement 与 reward 放在协议 accounting 之内，而 payout 位于下游实现层。

因此，SCS 应明确区分以下记录：

  1. settlement candidate context
  2. finalized settlement context
  3. 从 finalized state 推导出的 reward accounting record
  4. 在 finalized accounting 之后生成的 payout intent、payout batch 与 reconciliation record

这种区分必须体现在 schema、持久化域与集成边界上。

链与 Payout 集成配置 ​

SCS 可以通过一个或多个 chain-specific 或 treasury-specific 集成配置来实现下游 payout。

一个实现配置通常应覆盖：

  1. 从 finalized reward record 生成 payout instruction batch
  2. signer 或 treasury authority 的隔离
  3. confirmation tracking
  4. retry 与 reconciliation 行为
  5. 在不改写 finalized protocol accounting 的前提下显式记录失败

链相关实现可以因部署而异，但始终必须位于 protocol truth 的下游。

故障与 Reconciliation ​

系统应能检测并处理：

  1. duplicate submission
  2. partial downstream effect
  3. missing confirmation
  4. reconciliation drift
  5. 不同版本间 semantic registry mismatch
  6. epoch window accounting inconsistency

所有纠正都必须通过 adjustment、reconciliation 或 replay-safe recovery record 显式表达。

与 SCP 的关系 ​

本文档描述的是协议相关数据与集成在系统中的实现方式。

关于语义对象、replay 上下文、settlement 状态与 reward 语义的规范含义，请参见：

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