3. 证据概念

在调度器签名证据校验体系中，证据（Evidence）是连接调度决策与密码学签名的核心载体。它既不是单纯的日志记录，也不是原始的签名数据，而是一个经过结构化封装的、可独立验证的数据单元。本节从定义、意义、完整性要求和不可否认性四个维度，系统阐述证据的本质。

3.1 证据的定义

证据是指由调度器在完成一次调度决策后，将决策内容、上下文信息、时间戳以及调度器签名进行结构化打包，形成的一个自包含、可校验的数据对象。它必须满足以下形式化描述：

Evidence := {
    "schedule_id":       "唯一调度标识",
    "decision":          "调度决策内容（如节点分配、资源配额）",
    "context": {
        "input_state":   "调度输入状态哈希",
        "policy_hash":   "调度策略规则哈希",
        "timestamp":     "决策生成时间（Unix 毫秒）"
    },
    "signature": {
        "algorithm":     "签名算法标识（如 ECDSA-SHA256）",
        "signer_id":     "调度器身份标识",
        "signature_value": "对 evidence 主体部分的数字签名"
    }
}

证据的生成过程遵循“先封装、后签名”原则：调度器先将决策与上下文序列化为规范字节流，再对该字节流施加数字签名，最后将签名值附加到证据结构中。任何对证据内容的篡改都会导致签名校验失败。

3.2 证据在调度中的意义

证据在分布式调度系统中承担三重核心职能，其意义远超简单的“记录”范畴：

从系统架构视角看，证据将调度器的信任边界从调度器自身扩展到了整个分布式系统。任何持有调度器公钥的组件，都可以在不依赖调度器在线的情况下，独立验证证据的真实性。

3.3 证据的完整性要求

完整性是证据可信的基石。一个完整的证据必须满足以下四个层次的要求：

1. 结构完整性：证据必须包含所有必需字段（决策内容、上下文、签名），不允许缺失或空值字段。
2. 内容完整性：证据中的决策内容与上下文必须精确反映调度器当时的真实决策，不允许任何字段被篡改或替换。
3. 签名完整性：签名值必须覆盖证据中除签名本身之外的所有字段，且签名算法必须符合系统安全策略。
4. 链式完整性：当证据之间存在依赖关系时（如调度决策的先后顺序），必须通过哈希链或时间戳序列保证证据间的顺序不被破坏。

完整性校验失败的常见原因包括：网络传输中的比特翻转、存储介质的静默数据损坏、恶意中间人的篡改攻击，以及调度器自身代码缺陷导致的错误封装。系统设计时应采用端到端完整性校验策略，即在证据生成时立即计算校验和，在每次使用前重新验证。

3.4 证据的不可否认性

不可否认性（Non-repudiation）确保调度器在生成证据后，无法否认该证据是由其自身签发的。这一性质依赖于数字签名的私钥唯一性和公钥可验证性。

不可否认性的实现需要满足以下条件：

不可否认性在调度系统中的实际价值体现在：当出现资源分配争议时，调度器无法以“系统故障”“日志丢失”等理由否认其做出的决策。证据的签名值就是调度器对决策的数字承诺，具有法律级别的可追溯效力。