# 3.2 可验证证明与预言机网络

#### 3.2.1 证明体系：从现实状态到可结算事实

MetaPower 的证明体系以“可结算事实”为目标对象。可结算事实具备三个必要条件：可观察、可复核、可惩罚。系统不追求收集最大量数据，而是定义最小完备的证明集合，使链上结算可以在明确的证据边界内执行。

证明对象分层如下：

* 资源层证明：设备在线、算力有效性、性能稳定性
* 经济层证明：收益回执、成本账单、净收益口径
* 运维层证明：故障、维修、迁移、维护窗口、SLA 偏离
* 风险层证明：异常波动、对手方违约信号、数据源不一致

证明类型与结算影响的对应关系如下。

| 证明类型 | 证明目标        | 关键输入           | 输出形式        | 结算影响         |
| ---- | ----------- | -------------- | ----------- | ------------ |
| 在线证明 | 可用性与连续性     | 设备心跳、站点监控、网络探测 | UptimeScore | 决定结算权重与降权    |
| 产能证明 | 额定能力与有效产出一致 | 设备指标、回执、抽样校验   | OutputScore | 决定有效收益计入比例   |
| 能耗证明 | 功耗与账单一致性    | 功耗曲线、电价结构、账单   | CostScore   | 决定净收益扣减与阈值触发 |
| 运维证明 | 运维行为可追溯     | 工单、维护记录、事件签名   | O\&MScore   | 决定风险评分与惩罚    |
| 异常证明 | 波动与攻击面识别    | 多源差异、统计异常、规则触发 | AnomalyFlag | 触发熔断/延迟结算/审计 |

证明体系采用统一的评分与门槛结构，避免不同资产包使用不同口径导致不可比较。

评分结构示例：

* Score ∈ \[0, 1]
* Gate：Pass / Review / Reject
* Penalty：None / WeightDown / Slash / Suspend

| 门槛区间                | 判定     | 动作            |
| ------------------- | ------ | ------------- |
| Score ≥ 0.95        | Pass   | 正常结算          |
| 0.85 ≤ Score < 0.95 | Review | 延迟结算，进入抽检队列   |
| Score < 0.85        | Reject | 降权或熔断，触发审计与处置 |

***

#### 3.2.2 预言机网络：多源校验、抗篡改与可用性保证

预言机网络承担现实世界数据进入链上结算的安全边界。其目标是把外部数据从“报告”提升为“可校验输入”，并使系统对单点数据源失效与作恶具备鲁棒性。

预言机网络采用三类数据源与两类校验机制：

数据源分层：

| 数据源层级 | 示例             | 信任假设       | 用途          |
| ----- | -------------- | ---------- | ----------- |
| 直接观测源 | 站点监控、设备遥测、链路探测 | 可被伪造但可交叉校验 | 在线、功耗、温控、网络 |
| 业务回执源 | 矿池回执、任务回执、结算单  | 可能延迟或偏差    | 有效产出、收益     |
| 账单凭证源 | 电费账单、托管账单、维修账单 | 可审计但周期较长   | 成本核验、对账     |

校验机制：

1. 一致性校验

* 同一指标在不同来源的差异必须低于阈值
* 超过阈值则进入隔离队列，不进入当期结算

2. 可信度聚合

* 为每个数据源维护可信度权重
* 权重随历史准确性、延迟、异常率动态变化
* 聚合输出采用加权或中位数机制，避免单点主导

可信度权重更新规则示例：

| 事件            | 影响    | 动作                     |
| ------------- | ----- | ---------------------- |
| 连续 N 次与最终审计一致 | 上调权重  | weight += step         |
| 出现不可解释偏差      | 下调权重  | weight -= step         |
| 延迟超阈值         | 降权并标记 | weight \*= decay       |
| 被判定作恶         | 归零并隔离 | weight = 0, quarantine |

预言机网络输出遵循统一数据包结构，保证链上消费端可静态校验。

数据包结构示例：

| 字段                          | 描述      |
| --------------------------- | ------- |
| bundle\_id                  | 资产包标识   |
| metric\_id                  | 指标标识    |
| window\_start / window\_end | 统计窗口    |
| value                       | 聚合值     |
| sources                     | 来源列表与权重 |
| confidence                  | 置信度     |
| hash                        | 数据包哈希   |
| signatures                  | 多签签名集合  |

链上仅接受满足最小条件的数据包：

* signatures 达到阈值
* window 连续且不重叠
* hash 与签名可验证
* confidence 不低于门槛
* sources 中不存在被隔离源的主导权重

***

#### 3.2.3 结算输入管线：隔离、抽检、降权与熔断

证明体系与预言机网络的最终目的，是为结算引擎提供稳定、可控的输入。为避免异常数据直接影响分配，MetaPower 采用四段式输入管线。

输入管线（文本流程）：

* 采集
* 规范化
* 校验与聚合
* 判定与动作
* 结算或隔离

判定与动作规则表：

| 条件          | 判定   | 动作集合         |
| ----------- | ---- | ------------ |
| 多源一致且置信度达标  | 可结算  | 写入结算队列       |
| 存在轻微差异或延迟   | 待复核  | 延迟结算 + 抽检    |
| 差异超阈值或关键源缺失 | 不可结算 | 隔离 + 降权      |
| 异常触发频发或疑似作恶 | 风险事件 | 熔断 + 审计 + 处置 |

抽检策略采用两类抽样并行：

* 风险抽样：按风险等级与异常率提高抽检概率
* 随机抽样：保证任何资产都有被抽检概率，抑制作恶激励

抽检概率策略示例：

| 风险等级 | 基础抽检概率 | 异常触发加成 |
| ---- | ------ | ------ |
| A    | 2%     | +k·异常率 |
| B    | 5%     | +k·异常率 |
| C    | 10%    | +k·异常率 |

熔断触发条件以阈值集合定义，触发后自动进入状态机的 Suspended 或 Degraded，并冻结当期结算入口。

熔断阈值示例：

| 触发项   | 阈值类型  | 示例        |
| ----- | ----- | --------- |
| 在线率骤降 | 单周期阈值 | 低于下限      |
| 能耗偏差  | 累积阈值  | 连续超限 N 次  |
| 回执差异  | 差异阈值  | 多源差异超限    |
| 对手方异常 | 事件阈值  | 延迟/违约触发   |
| 异常密度  | 频率阈值  | 单周期触发次数超限 |

结算输入的最终执行逻辑采用可审计的确定性规则，便于复核与仲裁。

伪代码示例：

```
function process_window(bundle_id, window):
    pkt = oracle_aggregate(bundle_id, window)

    if !verify_signatures(pkt) or pkt.confidence < CONF_MIN:
        isolate(pkt)
        apply_weight_down(bundle_id)
        return "ISOLATED"

    score = proof_score(bundle_id, window, pkt)

    if score >= PASS_TH:
        enqueue_settlement(bundle_id, window, pkt, score)
        return "SETTLE"

    if score >= REVIEW_TH:
        enqueue_review(bundle_id, window, pkt, score)
        schedule_audit(bundle_id, window)
        return "REVIEW"

    trigger_circuit_breaker(bundle_id)
    schedule_audit(bundle_id, window)
    return "SUSPEND"
```

通过以上结构，MetaPower 将算力资产的现实状态转化为可验证、可控、可治理的结算输入，确保系统在规模扩张过程中保持一致性与抗操纵性。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://metapower-1.gitbook.io/metapower-docs/di-3-zhang-xie-yi-ti-xi-yu-ji-shu-lan-tu/3.2-ke-yan-zheng-zheng-ming-yu-yu-yan-ji-wang-luo.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.