可验证算力协作层
该层构建于通信加密层与身份认证层之上，确保每一份算力都具备可追溯性与经济激励归属。
DF Protocol 的可验证算力协作层是将加密通信与经济激励连接起来的技术中枢。该层负责接收来自各节点的算力贡献数据，并通过一套基于密码学与链上合约的机制，对算力的真实性、时效性与归属进行验证，从而实现“算力即资产”的可信确权。
该层由以下关键模块组成：
安全算力验证模块（PoSW: Proof of Secure Work）
PoSW（安全算力证明）是 DF Protocol 的核心共识逻辑之一，负责判断每一份算力上报是否为节点真实完成的计算任务。相比传统的 PoW（工作量证明）或 PoS（权益证明）模型，PoSW 更侧重“计算行为的真实性”而非计算难度或资产抵押，通过签名、随机抽验与链上确权相结合的方式，实现算力产出的可验证、安全化与抗造假。
1）设计目标
确保每份算力上报数据为节点独立计算的结果，不可仿造、拷贝或批量篡改；
避免无算力真实贡献的节点获取收益，防止“假矿机”与“无效节点”耗尽激励；
提供可拓展、多任务结构兼容的标准化算力验证路径。
2）核心验证流程
Step 1：身份合法性验证
系统从数据包中提取 node_id（DH-ID），查询链上注册表，确认该节点具备活跃身份。
Step 2：签名校验 读取签名字段，使用链上登记的公钥对任务摘要与时间戳进行签名验证，确保数据未被篡改且归属于该节点。
Step 3：时效性校验
验证上报时间戳与当前区块时间差是否在设定的 T 秒时效窗口内，防止重放攻击与滞后数据重复计分。
Step 4：任务内容一致性审查 若任务类型为结构化计算（如哈希、推理、模型验证），系统会对任务摘要字段执行二次重算（或基于 ZK 快速一致性验证），确保结果真实性。
Step 5：随机抽验机制（Sampling Challenge） 引入基于 VRF（Verifiable Random Function）或链上熵源生成的抽验逻辑，对部分节点上报任务执行二次验证。
若验证通过，记为有效算力；
若抽验失败，则当轮所有任务作废，计入信誉惩罚。
3）数据结构验证模型
每笔算力上报最终将生成以下结构（映射入链）：
struct SecureWork {
bytes32 nodeId;
bytes32 taskHash;
uint64 timestamp;
uint32 computeUnits;
bool verified;
}该结构通过事件 ComputeProofSubmitted 写入链上，构成可信算力账本。
4）多维防护能力
身份伪造
依赖链上注册 DH-ID + 签名校验，身份不可伪造
签名攻击
所有数据包签名必须与注册密钥对匹配，确保一致性
数据伪造
使用任务摘要重计算与时间戳窗口机制拒绝假数据
抽验逃避
抽验概率不公开、节点不可预测；违例自动降低信誉
同步攻击
所有提交含 nonce 与链上随机值避免重复记账
任务数据封装模块（Compute Payload Composer）
任务数据封装模块是 DF 节点本地运行的轻量级构建器，专用于构造标准化算力上报数据包。该模块承担链下计算结果向链上可信数据格式转换的桥梁角色，确保所有传输数据具备统一结构、加密处理与可验证性，是 DF 架构中通信安全与算力验证的起点。
1）设计目标
将节点完成的计算任务数据封装为结构化、可签名、可加密的数据报文；
为算力验证、加密通信与上链确权提供基础数据单元；
抵御数据重放、伪造、修改与归属不清等攻击风险。
2）数据包结构
任务数据包由以下字段组成：
compute_hash
bytes32
节点对任务输入+输出内容的哈希摘要（如 `SHA256(task_input
timestamp
uint64
本次任务完成时间戳（Unix 格式），用于时效性校验
node_id
bytes32
节点的 DH-ID（即 SHA256(pubkey_ECDH)）
sig_node
bytes
节点私钥对 compute_hash + timestamp 的签名
payload_meta
bytes
附加信息（如算力类别、输入规模等），可用于算力加权与向量分类
nonce
bytes12
AES-GCM 的随机 IV，用于加密内容防重放
cipher_data
bytes
通过共享密钥加密后的完整数据体
3）封装流程
Step 1：计算任务摘要 节点完成计算后，对输入与输出执行摘要生成：
compute_hash = SHA256(task_input || result)Step 2：附加元信息构建 如任务类型、参与周期编号、算力规模等放入 metadata：
{
"task_type": "static_compute",
"cu_size": 100,
"version": "v1.0"
}Step 3：签名构建
使用节点控制的钱包或 DH 私钥对 (compute_hash || timestamp) 签名：
sig_node = Sign(sk_wallet, H(compute_hash || timestamp))Step 4：加密打包
使用从通信层派生出的共享密钥 K_AB 对 metadata + compute_hash + sig_node 执行 AES-256-GCM 加密：
cipher_data = AES_GCM_Encrypt(K_AB, plaintext, nonce, aad=node_id)最终生成完整结构化数据包，作为算力验证模块的输入。
4）防攻击设计
重放攻击
强制 timestamp 不得落后于上链窗口/轮次
假数据注入
所有字段加密、签名校验，必须匹配 DH-ID 所属私钥
内容篡改
AES-GCM 自带认证标签（auth_tag）确保报文完整性
跨节点伪冒
节点身份与公钥绑定，签名+链上注册双重验证
加密签名与上报模块
加密签名与上报模块负责将任务数据包在本地完成签名处理，并通过加密通道将算力数据发送至网络中指定的验证节点或中继器。该模块直接继承通信加密层与身份认证层的信任基础，实现算力数据的“不可否认性”和“抗篡改性”，并为算力验证过程提供结构化、安全的数据输入源。
1）模块目标
使用链上注册身份对应的私钥对算力上报包进行不可伪造签名；
确保数据归属节点身份（DH-ID），与签名、钱包地址可一致性校验；
通过安全加密信道上传报文，防止内容在传输过程被监听或替换；
支持异步重发、批量压缩与多路径广播机制，确保上报的高可用性。
2）签名机制
默认使用椭圆曲线签名算法（如 ECDSA / Ed25519）对封装数据进行加密签名，推荐过程如下：
message = SHA256(compute_hash || timestamp || payload_meta)
sig_node = Sign(wallet_sk, message)签名与 DH-ID 绑定，钱包地址作为链上注册身份验证源；
验证节点通过链上注册表获取 DH-ID → wallet → 公钥路径，完成签名校验；
支持将签名加入数据包原始结构或另附独立字段进行外包验证。
3）上报路径与通道
DF 提供两种上报模式：
Direct Submit
节点直接将签名数据包通过 HTTPS/WebSocket 发送至验证服务端
p2p Broadcast
节点将数据包通过 libp2p/gossipsub 广播给网络邻居，等待采样
所有数据包均需通过 AES-256-GCM 加密通道发送，并附带加密元字段（IV、AAD、auth_tag）。
4）冗余容错与异步重试机制
若在指定时间内未收到验证确认，可自动重新发起提交；
每个数据包附带
nonce + seq_id，防止重复上链；重发次数受限于合约内设定的“每轮最大上报次数”，防止恶意 DDoS。
示例提交格式（JSON 报文）：
{
"node_id": "0xb14e...e3f",
"compute_hash": "0x8c3ab...",
"timestamp": 1716900000,
"payload_meta": {
"task_type": "static",
"cu": 100
},
"signature": "0x3045...",
"cipher_data": "0x9ab9...",
"iv": "0x77c1fa...",
"auth_tag": "0xde88..."
}Last updated