4. 调度器签名机制：调度器为何需要签名、签名时机、签名对象、签名存储方式

调度器签名是分布式调度系统中证据链完整性的核心保障。调度器作为任务编排与资源分配的中心节点，其发出的每一条指令都必须具备不可否认性和可追溯性，签名机制正是实现这一目标的基础设施。

4.1 调度器为何需要签名

在无签名的调度系统中，存在三类核心风险：

• 指令伪造：攻击者冒充调度器向执行器下发恶意任务。
• 指令篡改：中间人修改调度参数（如资源配额、执行时间）。
• 责任抵赖：调度器否认曾下发某条关键指令。

4.2 签名时机

调度器在以下三个关键时间点执行签名操作：

4.3 签名对象

调度器签名的对象并非原始指令文本，而是经过规范化编码的二进制数据。签名对象包含以下字段：

// 调度指令签名对象结构
message SignedScheduleInstruction {
    // 元数据
    uint64    version       = 1;  // 协议版本号
    uint64    timestamp     = 2;  // 签发时间（Unix毫秒）
    bytes     scheduler_id  = 3;  // 调度器身份标识

    // 指令核心
    string    task_id       = 4;  // 任务唯一ID
    string    action        = 5;  // 操作类型：ASSIGN / CANCEL / SUSPEND
    bytes     payload       = 6;  // 具体参数（资源分配、执行脚本等）

    // 上下文
    bytes     parent_hash   = 7;  // 前序指令哈希（链式结构）
    uint32    nonce         = 8;  // 防重放计数器

    // 签名
    bytes     signature     = 9;  // 调度器私钥签名结果
}

签名对象的设计原则：

• 确定性编码：使用 Protobuf / CBOR 等确定性序列化格式，避免 JSON 字段顺序不确定性。
• 链式哈希：包含 parent_hash 字段，使签名形成哈希链，防止重排序攻击。
• 防重放：nonce 字段确保同一调度器不会产生两条相同的签名指令。

4.4 签名存储方式

签名存储分为本地持久化和链上存证两个层次：

4.5 调度器签名流程架构

下图展示了调度器从决策到签名存储的完整流程：

4.6 签名存储的链式结构

调度器签名的存储采用链式哈希结构，确保任意一条指令的篡改都会被后续签名检测到：

4.7 签名验证的依赖关系

调度器签名的验证并非孤立操作，而是依赖以下上下文：

• 调度器公钥：验证方需提前获取调度器的公钥证书（通过 PKI 或链上注册）。
• 链式哈希：验证当前指令时，需同时校验 parent_hash 是否与本地存储的前序指令哈希一致。
• nonce 单调性：验证方需维护每个调度器的 nonce 状态，拒绝 nonce 回退的指令。
• 时间窗口：签名中的 timestamp 必须在当前系统时间的 ±5 分钟窗口内，防止重放攻击。