去中心化 AI 模型推理的链上验证：从黑盒到可审计

一、AI 推理的"黑盒信任"：链上合约如何验证链下推理

去中心化 AI 应用面临一个根本性挑战：智能合约无法直接运行 AI 模型（Gas 成本过高），推理必须在链下执行。但链下推理结果是"黑盒"——合约无法验证推理过程是否正确，只能信任推理节点的输出。这种信任假设与 Web3 的"Don't Trust, Verify"理念相悖。

链上验证的目标是：在不执行完整推理的前提下，验证链下推理结果的正确性。当前的主流方案包括：零知识证明（zkML）、乐观验证（Optimistic Verification）和可信执行环境（TEE）。每种方案在安全性、成本和通用性之间做出不同的权衡。

二、链上验证的三种范式

flowchart TD
    A[链下 AI 推理] --> B{验证方案}

    B --> C[zkML：零知识机器学习]
    B --> D[乐观验证：挑战期 + 仲裁]
    B --> E[TEE：可信执行环境]

    C --> C1[生成推理证明]
    C1 --> C2[链上验证证明]
    C2 --> C3[成本高、延迟大、安全性最强]

    D --> D1[提交推理结果 + 质押]
    D1 --> D2[挑战期内可被质疑]
    D2 --> D3[争议时上链重算]
    D3 --> D4[成本低、延迟低、安全性依赖挑战者]

    E --> E1[TEE 内执行推理]
    E1 --> E2[输出签名结果]
    E2 --> E3[成本低、延迟低、安全性依赖硬件]

zkML 通过零知识证明将推理过程压缩为可链上验证的证明，安全性最强但成本极高（生成证明可能需要数分钟）。乐观验证假设推理结果正确，设置挑战期允许任何人质疑，争议时在链上重新执行推理，成本低但依赖活跃的挑战者。TEE 方案将推理放在可信硬件中执行，硬件保证执行过程未被篡改，成本低但信任假设转移到硬件厂商。

三、工程化实现

3.1 乐观验证方案

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract OptimisticAIOracle {
    struct InferenceResult {
        address prover;
        bytes32 modelId;
        bytes inputHash;
        bytes output;
        uint256 stake;
        uint256 submittedAt;
        uint256 challengeDeadline;
        bool verified;
        bool challenged;
    }

    uint256 public constant CHALLENGE_PERIOD = 1 hours;
    uint256 public constant MIN_STAKE = 0.1 ether;
    uint256 public constant CHALLENGE_STAKE = 0.2 ether;

    mapping(uint256 => InferenceResult) public results;
    uint256 public resultCount;

    event InferenceSubmitted(
        uint256 indexed resultId,
        address prover,
        bytes32 modelId
    );
    event InferenceChallenged(
        uint256 indexed resultId,
        address challenger
    );
    event InferenceVerified(uint256 indexed resultId);
    event InferenceRejected(uint256 indexed resultId);

    // 推理节点提交结果
    function submitInference(
        bytes32 modelId,
        bytes calldata inputHash,
        bytes calldata output
    ) external payable {
        require(msg.value >= MIN_STAKE, "Insufficient stake");

        uint256 resultId = resultCount++;
        results[resultId] = InferenceResult({
            prover: msg.sender,
            modelId: modelId,
            inputHash: inputHash,
            output: output,
            stake: msg.value,
            submittedAt: block.timestamp,
            challengeDeadline: block.timestamp + CHALLENGE_PERIOD,
            verified: false,
            challenged: false
        });

        emit InferenceSubmitted(resultId, msg.sender, modelId);
    }

    // 挑战者质疑结果
    function challengeInference(uint256 resultId) external payable {
        InferenceResult storage result = results[resultId];
        require(block.timestamp < result.challengeDeadline, "Challenge period over");
        require(!result.challenged, "Already challenged");
        require(msg.value >= CHALLENGE_STAKE, "Insufficient challenge stake");

        result.challenged = true;
        result.stake += msg.value;

        emit InferenceChallenged(resultId, msg.sender);
    }

    // 挑战期结束后确认结果
    function verifyInference(uint256 resultId) external {
        InferenceResult storage result = results[resultId];
        require(block.timestamp >= result.challengeDeadline, "Challenge period not over");
        require(!result.challenged, "Result is challenged");
        require(!result.verified, "Already verified");

        result.verified = true;

        // 返还质押
        payable(result.prover).transfer(result.stake);

        emit InferenceVerified(resultId);
    }

    // 争议解决：由仲裁委员会判定（简化实现）
    function resolveChallenge(
        uint256 resultId,
        bool isProverCorrect
    ) external {
        InferenceResult storage result = results[resultId];
        require(result.challenged, "Not challenged");

        if (isProverCorrect) {
            // 推理正确：返还给证明者，惩罚挑战者
            payable(result.prover).transfer(result.stake);
        } else {
            // 推理错误：惩罚证明者，奖励挑战者
            // 简化：将质押发送到仲裁合约
            result.verified = false;
        }

        emit isProverCorrect
            ? InferenceVerified(resultId)
            : InferenceRejected(resultId);
    }
}

3.2 推理节点服务

// inference-node.ts
import { ethers } from 'ethers';

class InferenceNode {
  private signer: ethers.Wallet;
  private oracleContract: ethers.Contract;

  async submitInference(
    modelId: string,
    input: Float32Array,
    model: InferenceModel
  ): Promise<number> {
    // 1. 执行链下推理
    const output = model.predict(input);

    // 2. 计算输入哈希
    const inputHash = ethers.sha256(
      ethers.toUtf8Bytes(JSON.stringify(Array.from(input)))
    );

    // 3. 编码输出
    const encodedOutput = ethers.toUtf8Bytes(JSON.stringify(output));

    // 4. 提交链上
    const tx = await this.oracleContract.submitInference(
      ethers.id(modelId),
      inputHash,
      encodedOutput,
      { value: ethers.parseEther('0.1') }
    );

    const receipt = await tx.wait();
    const resultId = receipt.logs[0].args.resultId;

    // 5. 等待挑战期
    await this.waitForChallengePeriod(resultId);

    // 6. 确认结果
    await this.oracleContract.verifyInference(resultId);

    return Number(resultId);
  }

  private async waitForChallengePeriod(resultId: number): Promise<void> {
    const result = await this.oracleContract.results(resultId);
    const deadline = Number(result.challengeDeadline);
    const now = Math.floor(Date.now() / 1000);
    const waitTime = Math.max(deadline - now + 10, 0) * 1000;

    return new Promise((resolve) => setTimeout(resolve, waitTime));
  }
}

四、链上验证的 Trade-offs

zkML 的工程成熟度：zkML 仍处于早期阶段，支持有限的模型架构（主要是小型 MLP 和 CNN），对 Transformer 等大模型的支持尚不完善。证明生成时间可能长达数分钟，不适合实时推理场景。

乐观验证的活跃性假设：乐观验证的安全性依赖"至少有一个诚实的挑战者"。如果所有挑战者都离线或被收买，错误结果将自动确认。建议设置激励池，奖励成功挑战者，确保挑战的经济动力。

TEE 的硬件信任：TEE 方案将信任假设从软件转移到硬件（如 Intel SGX、ARM TrustZone）。硬件后门和侧信道攻击是已知风险。对于高价值场景，TEE 不应作为唯一的验证手段。

Gas 成本与实用性：链上验证的 Gas 成本是最大的实用性障碍。即使是最简单的证明验证，也需要数万 Gas。对于高频推理场景（如实时推荐），链上验证的成本可能超过推理本身。

五、总结

去中心化 AI 推理的链上验证是 Web3 AI 应用的核心基础设施。三种方案各有适用场景：zkML 适合高安全性低频率场景，乐观验证适合中等安全性中等频率场景，TEE 适合低延迟高频率场景。落地路线上，建议先用乐观验证快速上线，再根据安全需求逐步引入 zkML 或 TEE。关键原则：没有完美的验证方案，只有适合业务场景的权衡选择。