Symphony Core 文档

简体中文

English

简体中文

English

Appearance

SCP 核心规范 ​

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

目的 ​

本文档定义 SCP 的规范性生命周期与状态语义。

它回答：

  1. 任务如何在协议中流转
  2. challenge 与 settlement 如何交互
  3. settlement candidate context 与 finalized context 的含义分别是什么
  4. 合规的 contract boundary 必须保留哪些内容

Task Lifecycle ​

canonical task lifecycle 为：

  1. accepted
  2. resolving
  3. dispatched
  4. verifying
  5. awaiting_settlement
  6. completed
  7. challenged
  8. rejected
  9. timed_out

这些状态定义的是协议语义，而不是某种固定进程布局。

Challenge Lifecycle ​

canonical challenge lifecycle 为：

  1. opened
  2. reviewing
  3. confirmed
  4. not_confirmed
  5. approved
  6. closed_without_penalty
  7. penalty_recorded
  8. reopened

challenge evidence 必须可 replay，并能关联到对应 task、verification 和 settlement context。

Settlement Lifecycle ​

canonical settlement lifecycle 为：

  1. collecting
  2. verifying_inputs
  3. candidate_ready
  4. finalizing
  5. finalized
  6. failed

Settlement Candidate Context ​

candidate context 用于：

  1. 打开 challenge
  2. 表示 settlement readiness
  3. 建立 fraud evidence linkage

Finalized Settlement Context ​

finalized context 用于：

  1. reward finalization
  2. 协议审计
  3. payout preparation
  4. 不可逆的 accounting reference

Determinism 与 Replay ​

要保持确定性，需要：

  1. 固定的对象语义
  2. 固定的排序与哈希规则
  3. 稳定的 epoch mapping
  4. version-aware parameter resolution
  5. 可 replay 的 evidence 与 accounting artifact

parameter resolution 必须是以下输入的确定性函数：

  1. epoch_id
  2. semantic_version
  3. policy_version

Epoch 模型 ​

Epoch 是一个稳定的窗口标识，用来把协议事件分组到同一个可 replay 的控制上下文中。

它不是原始数据上传的前置条件，也不是任务存在本身的前置条件。

它主要治理：

  1. settlement window
  2. reward calculation window
  3. payout batching window
  4. local attribute candidate aggregation window
  5. 在需要批处理时的 replay partitioning

它不主要治理：

  1. 原始数据上传到 Vault
  2. 任务能否被创建
  3. semantic resolution 能否开始
  4. 单个授权执行能否启动

Epoch 核心字段 ​

一个 epoch 定义至少应保留：

  1. epoch_id
  2. open_at
  3. close_at
  4. status
  5. semantic_version_set
  6. policy_version_set
  7. settlement scope metadata
  8. reward scope metadata
  9. candidate aggregation scope metadata

Epoch 状态 ​

canonical 的 epoch 状态模型为：

  1. open
  2. closing
  3. closed

在同一个受治理 scope 内，通常最多只应存在一个 open epoch。

开启条件 ​

一个新的 epoch 在以下条件下开启：

  1. 上一个 epoch 已进入 closed
  2. 系统正在创建初始 bootstrap epoch

open 状态的 epoch 是后续 settlement、reward 和 aggregation scope 的活动窗口。

关闭触发条件 ​

当满足以下任一条件时，open epoch 应转入 closing：

  1. 达到配置的最大时间窗口
  2. task、verification、settlement 或 aggregation 的量达到配置阈值
  3. governance 或 policy 要求切换窗口，例如版本切换或受控维护

这是一种混合触发模型：

  1. 时间可以触发关闭
  2. 容量可以触发关闭
  3. 治理可以触发关闭

关闭完成条件 ​

一个 epoch 从 closing 进入 closed，应至少满足：

  1. 该 epoch 的 settlement scope 已冻结
  2. 该 epoch 的 reward scope 已冻结
  3. 该 epoch 的 candidate aggregation scope 已冻结
  4. 未解决项要么已在本 epoch 内完成处理，要么已按 policy 明确延期

一旦 epoch 进入 closed：

  1. 新事件不得再被归属到该 epoch
  2. replay 必须能够重建相同的 epoch membership
  3. 下游的 reward、payout 和 candidate aggregation 才能基于这个稳定窗口继续推进

Layer-Level Norms ​

协议要求以下逻辑职责存在：

  1. Application 负责验证 client intent 并生成 protocol-valid task
  2. Coordination 负责编排任务流转与 settlement handoff
  3. Semantic 负责在 semantic_version 下解析语义
  4. Data 负责保存 canonical 记录与 Commitment references
  5. Execution 负责执行授权计算
  6. Verification 负责在 settlement 前验证正确性与完整性
  7. Settlement 负责锚定 verified state 并发布 finalized accounting context

这些是协议角色，不要求每个角色一定映射成独立进程。

七层协议模型 ​

overview

这 7 层仍然是 SCP 的核心协议抽象。

它们定义的是职责语义边界，而不是强制性的部署拓扑。

1. Application Layer ​

目的：

  • 校验 client intent
  • 校验 caller identity 与 authorization context
  • 生成 protocol-valid 的 TaskEnvelope

协议输入：

  • caller context
  • authorization context
  • query intent
  • 请求的 policy scope

协议输出：

  • TaskEnvelope
  • 面向客户端的 accepted 或 rejected 状态
  • 协议可见的校验错误

协议不变量：

  • 对非法输入必须 deterministic rejection
  • intake response 不得泄露私有明文
  • 缺少必要 replay tuple context 时不得接纳任务

2. Coordination Layer ​

目的：

  • 编排任务流转
  • 管理 semantic、execution、verification 与 settlement 之间的 handoff
  • 跟踪 canonical 协议状态迁移

协议输入：

  • admitted task
  • semantic context
  • execution result
  • verification decision
  • challenge event

协议输出：

  • execution assignment
  • 被跟踪的 task state
  • settlement submission
  • challenge opening 或状态迁移

协议不变量：

  • settlement finalization 之前不得绕过 verification
  • 不允许 out-of-order 的状态迁移
  • 不允许出现逃逸协议审计的隐藏状态迁移

3. Semantic Layer ​

目的：

  • 在 semantic_version 下解析 canonical meaning
  • 将任务绑定到 registry-compatible semantic reference
  • 在 execution 之前给出 compatibility 结论

协议输入：

  • canonicalized semantic candidate
  • registry state
  • semantic_version

协议输出：

  • SemanticResolutionResult
  • compatibility decision
  • registry-compatible reference

协议不变量：

  • semantic interpretation 必须 deterministic
  • Scope 必须保持 monotonic
  • unresolved 或 incompatible 的 semantic context 不得进入 execution

4. Data Layer ​

目的：

  • 保存 canonical 私有记录
  • 为 execution 暴露授权后的 record material
  • 通过 Commitment reference 保持密码学关联

协议输入：

  • canonical record
  • authorization context
  • execution-bound access request
  • 必要时包含 key context

协议输出：

  • encrypted storage object
  • Commitment reference
  • 授权后的 record material

协议不变量：

  • Commitment = SHA256(Serialize(CR))
  • 明文不得逃逸授权 Vault 或 TEE 边界
  • task、authorization 与 record usage 之间必须具备可审计的访问关联

5. Execution Layer ​

目的：

  • 执行授权计算
  • 生成确定性的、与 proof 相关联的执行输出
  • 保留可审计的数据访问上下文

协议输入：

  • ExecutionAssignment
  • semantic context
  • epoch context
  • 授权后的 record material

协议输出：

  • ExecutionResultBundle
  • transcript reference
  • 在需要时包含 proof reference

协议不变量：

  • 相同输入与 replay tuple 下执行必须 deterministic
  • 不得发生未授权的跨 Vault 访问
  • 缺少可审计 execution context 的结果不得被接纳

6. Verification Layer ​

目的：

  • 在 settlement 之前验证正确性与完整性
  • 对 execution output 作出 accept、reject 或 challenge
  • 保留可 replay 的 evidence

协议输入：

  • result bundle
  • proof reference
  • replay context
  • evidence input

协议输出：

  • VerificationDecision
  • evidence reference
  • accepted、challenged 或 rejected verdict

协议不变量：

  • 没有 accepted verification 就不能进入 settlement finalization
  • challenge evidence 必须可 replay
  • verification 不得改写 execution history

7. Settlement Layer ​

目的：

  • 锚定 verified state
  • 组装 root context
  • 发布 candidate 与 finalized accounting context

协议输入：

  • accepted verification output
  • root input
  • settlement metadata
  • 与 finalization 相关的 challenge state

协议输出：

  • settlement candidate context
  • finalized settlement context
  • settlement event
  • SettlementRoot

协议不变量：

  • root composition 必须 deterministic
  • finalized history 必须 append-only
  • candidate context 可用于 challenge opening，而 finalized context 是不可逆 accounting reference 的前提

域模型 ​

overview

Domain 是协议中的语义命名空间，也是语义治理边界。

它存在的目的是：

  1. 为 semantic interpretation 提供稳定命名空间
  2. 为 canonical attribute 提供明确的归属边界
  3. 在声明的语义范围内治理兼容性、弃用与演进

Domain 的分层 ​

协议认可如下语义分层：

  1. global domain：协议范围共享的语义治理边界
  2. domain family：聚合相关 domain 的上层命名空间
  3. concrete domain：canonical attribute 被注册和解析的直接命名空间
  4. 可选 sub-domain：在 policy 明确允许时使用的更细粒度语义空间

实现可以用不同方式落地这些层级，但协议语义必须保持相同的层次关系。

Domain 的职责 ​

一个 domain 负责：

  1. 定义 canonical attribute 所在的语义命名空间
  2. 在 semantic_version 下约束兼容性与演进
  3. 决定跨 domain 引用是允许、拒绝还是需要中介解析
  4. 为 semantic resolution 和治理判断提供语义边界

Domain 核心字段 ​

协议可见的 domain 定义至少应保留：

  1. domain_id
  2. 在适用时的 parent_domain_id
  3. domain_version
  4. semantic_version
  5. status

Domain 状态 ​

canonical 的 domain 状态模型为：

  1. proposed
  2. registered
  3. active
  4. deprecated
  5. retired

只有 active 的 domain，以及在兼容策略允许下的 deprecated domain，才能参与新的 semantic resolution。

Canonical Attribute 模型 ​

overview

CanonicalAttribute 是协议对象，表示某个声明 domain 内的标准化语义属性。

它不是悬空对象。每个 canonical attribute 都必须归属于某个 domain。

Canonical Attribute 标识 ​

协议标识至少应保留：

  1. attribute_id
  2. domain_id
  3. semantic_version

当生命周期或兼容性相关时，还应保留：

  1. scope
  2. status
  3. effective_from
  4. 在适用时的 deprecated_from
  5. 在适用时的 retired_from
  6. 在适用时的 supersedes 或 replacement reference

Canonical Attribute 规则 ​

协议要求：

  1. 每个 canonical attribute 在给定语义时点只能归属于一个声明 domain
  2. attribute 的兼容性必须相对于 domain 和 semantic_version 解释
  3. 当 attribute 被 supersede 时，替代关系必须显式声明，不能隐式漂移
  4. semantic resolution 必须先确定 domain，再确定 canonical attribute 的语义

Canonical Attribute 生命周期 ​

canonical 生命周期为：

  1. proposed
  2. registered
  3. active
  4. deprecated
  5. retired
  6. superseded

生命周期含义 ​

  • proposed：被治理流程识别，但尚不能作为协议可用对象
  • registered：已记录到命名空间中，但尚未在目标 semantic window 生效
  • active：可参与 semantic resolution，并可用于新任务
  • deprecated：在兼容层面仍可见，但不应作为新语义编写的首选
  • retired：不能再参与新任务解析
  • superseded：在受治理的兼容规则下，被显式 successor attribute 替代

生命周期规则 ​

协议要求：

  1. 只有 active，以及 policy 允许的 deprecated attribute，才能参与新任务解析
  2. retired attribute 不得用于新任务解析
  3. 生命周期迁移必须绑定到已声明的语义治理和 semantic_version
  4. superseded attribute 必须显式指向替代路径
  5. 相同 task input 和相同 semantic_version 必须得到相同的 attribute resolution 结果

Canonical Attribute 解析流程 ​

从协议视角看，canonical attribute 的解析遵循以下逻辑流程：

  1. 根据 task scope、semantic reference 和 policy context 确定目标 domain
  2. 校验该 domain 在请求的 semantic_version 下是否可用
  3. 在该 domain 内识别候选 canonical attribute
  4. 拒绝所有生命周期状态不允许参与解析的候选项
  5. 应用兼容性和替代规则
  6. 在 SemanticResolutionResult 中产出确定性的 semantic reference

解析后果 ​

协议要求：

  1. 无法解析的 domain 或 attribute 状态必须阻止任务进入 execution
  2. 对于存在歧义的 domain 或 attribute 映射，必须 reject，不能猜测
  3. domain retirement 或 attribute retirement 只影响对应版本规则所治理的语义窗口
  4. 在相同 semantic 输入下 replay 同一任务时，必须重建出相同的 domain 与 canonical attribute 选择

语义属性分层 ​

从协议设计角度看，语义对象可以出现在三个相关但不同的层级中：

  1. CanonicalAttribute，用于定义协议认可的语义真相
  2. QueryAttribute，用于定义面向 audience selection、检索和相关查询工作的受治理 query projection
  3. LocalAttribute，用于表示仍留在 Vault 或本地语义边界内、尚未进一步投影或晋升的本地语义

这些层级彼此相关，但用途并不相同。

各层职责 ​

协议要求这几个层级保持区分：

  1. canonical attribute 用于回答一条记录在协议语义下“到底是什么”
  2. 查询属性用于回答哪些受治理的查询信号可以被投影出来，用于跨 Vault 检索、人群筛选或其他受治理查询工作流
  3. local attribute 用于回答哪些未解析或本地专属语义可以继续保留私有，同时支持后续演化

层级顺序 ​

正常的语义顺序是：

  1. 本地或原始语义材料首先出现在 Vault 内
  2. canonical resolution 为任务确定稳定的协议语义
  3. query projection 在策略允许的前提下，从 canonical 或本地材料中导出受治理的检索信号

这意味着，一个字段即使可以被查询，也仍然可能首先是 canonical-first 的语义对象。

Query Attribute 模型 ​

QueryAttribute 是一种受治理的语义对象，用来表示从受保护记录中派生出来、可用于 audience selection、资格过滤、检索或其他受治理查询工作的 query-safe projection。

它不是 CanonicalAttribute 的替代物，也不负责重新定义协议真相。

Query Attribute 标识 ​

协议标识至少应保留：

  1. query_attribute_id
  2. domain_id
  3. semantic_version

在治理、隐私或兼容性相关时，对象还应保留：

  1. status
  2. derivation_rule_ref
  3. query_granularity
  4. privacy_class
  5. allowed_usage_scope

Query Attribute 规则 ​

协议要求：

  1. 每个查询属性都必须归属于某个声明 domain 或受治理的 query namespace
  2. query projection 必须在显式 policy 下导出，而不是静默推断
  3. 查询属性必须始终与 canonical semantic truth 区分开
  4. query projection 的兼容性必须在 semantic_version 下保持可版本化解释
  5. 不得因为存在 query projection 就直接输出可重建的原始私有值

Query Attribute 生命周期 ​

其标准生命周期为：

  1. proposed
  2. registered
  3. active
  4. restricted
  5. deprecated
  6. retired

生命周期含义：

  • proposed：进入治理评审，但尚不可用于查询
  • registered：已记入命名空间，但尚未对目标查询窗口生效
  • active：可用于受治理的 query projection 与检索流程
  • restricted：只能在更窄的 policy 或 actor scope 下被使用
  • deprecated：仍然对兼容性可见，但不推荐用于新的查询设计
  • retired：不再允许用于新的投影或查询

Query Projection 约束 ​

协议要求：

  1. projection 必须位于 Vault 隐私边界的下游
  2. query-safe projection 必须能通过 source commitment 或 protected record 保持可审计关联
  3. query index 只能承载检索所需的最小受治理信号
  4. audience selection 或 campaign eligibility 不能依赖静默变化的 query semantics
  5. 在相同 semantic 与 policy 输入下 replay 时，必须重建出相同的 query interpretation

本地属性池 ​

LocalAttribute 是一种本地语义工件，尚未被承认为协议认可的 canonical attribute。

它可以存在于 Vault 内部或本地语义边界中，但它本身不是跨协议共享的 semantic truth。

本地池的目的 ​

本地属性池存在的目的是让实现能够：

  1. 累积尚未解析或仅在本地有意义的 attribute
  2. 随时间测量其频次、稳定性和映射置信度
  3. 产出可用于后续晋升的隐私安全候选信号

本地池规则 ​

协议要求：

  1. 在晋升前提满足之前，local attribute 必须保持为本地对象
  2. 不得直接将原始私有值或可重建敏感语义的信息用于跨 Vault 聚合
  3. 本地池记录必须保留足够的元数据，以支持后续审计和晋升评估

最小本地信号 ​

本地池条目至少应保留：

  1. local attribute 标识
  2. 候选 domain 提示
  3. 本地出现频次
  4. 跨 epoch 的本地稳定性指标
  5. 在适用时相对于现有 canonical attribute 的映射置信度
  6. 隐私安全的特征摘要或证据摘要

跨 Vault 候选聚合 ​

协议允许本地池通过隐私安全的候选摘要参与跨 Vault 候选池，但不能直接上传原始本地语义对象。

聚合窗口 ​

默认的晋升聚合窗口为：

  1. 每 10 个 epoch 进行一次常规候选形成

policy 可允许：

  1. 在高活跃 domain 中每 5 个 epoch 聚合一次
  2. 在特殊治理触发下绕过常规窗口发起例外提案

允许逐 epoch 进行本地累积，但不以逐 epoch 的全局晋升作为默认协议路径。

聚合输出 ​

跨 Vault 聚合必须产出：

  1. LocalAttributeCandidate 摘要
  2. candidate 的 domain 绑定
  3. 覆盖度、频次与稳定性指标
  4. 相对于现有 canonical attribute 的兼容、冲突或别名信号

它不能直接产出 active 状态的 canonical attribute。

聚合约束 ​

协议要求：

  1. 跨 Vault 聚合交换的是候选摘要，而不是原始私有 local attribute
  2. candidate 形成过程必须在证据摘要层面可审计
  3. 聚合流程必须始终位于 Vault 隐私边界的下游

晋升为 Canonical Attribute ​

canonical 晋升路径为：

  1. local attribute
  2. local attribute pool
  3. LocalAttributeCandidate
  4. proposed canonical attribute
  5. registered
  6. active

晋升前提 ​

只有在 protocol policy 至少确认以下条件时，候选项才能晋升：

  1. 足够的跨 Vault 覆盖度，或有正当治理例外
  2. 在要求的 epoch 窗口内表现出稳定性
  3. 具备清晰的 domain 归属
  4. 不与现有 canonical attribute 存在未解决冲突，或已显式声明 alias/replacement 关系
  5. 具备支持晋升决策的可 replay 证据摘要

晋升后果 ​

协议要求：

  1. 未满足晋升阈值的 local attribute 必须继续保持本地属性
  2. candidate 聚合是提案机制，而不是自动生成 semantic truth 的机制
  3. 新 canonical attribute 必须进入标准生命周期 proposed -> registered -> active
  4. 冲突解决必须显式治理，不能静默推断

Contract Boundary ​

合规实现至少必须覆盖：

  1. task 与 semantic messages
  2. execution 与 verification messages
  3. settlement messages
  4. reward records
  5. payout instructions 与 events

当前 canonical source of truth 仍然是 Markdown 规范集。machine-readable schema artifact 属于由 SCS 定义的实现交付物。

Canonical Error Families ​

协议可见错误族包括：

  1. SCHEMA_*
  2. VERSION_*
  3. AUTH_*
  4. POLICY_*
  5. EXECUTION_*
  6. PROOF_*
  7. VERIFY_*
  8. SETTLEMENT_*
  9. REWARD_*
  10. PAYOUT_*
  11. GOVERNANCE_*
  12. INTERNAL_*