去中心化人工智能产品的架构取舍

在去中心化 AI（Decentralized AI）与 DApp 的结合探索中，不少工程团队容易走入极端的“技术崇拜”。为了打着“完全去中心化”的旗号，有些产品甚至强行把大模型的矩阵乘法运算搬到 Solidity 智能合约里执行，或者让前端用户每次发送 AI Prompt 时都发起一次以太坊交易。

这些看似优雅、聪明的全栈去中心化做法，上线即瘫痪。高昂的 Gas 费用、长达数分钟的链上确认延迟以及极差的交互体验，直接拉垮了产品的生存能力。

构建去中心化 AI 产品，必须学会解耦“链上价值确认”与“链下高性能推理算力”，避免盲目照搬全量上链的反模式。

反模式一：在合约中直接执行大模型推理

Solidity 设计初衷是处理图灵完备的确定性账本状态改变，而不是浮点数矩阵运算。如果在合约里写卷积神经网络（CNN）或者 Attention 机制，单次计算就会直接爆掉单个 Block 的 Gas Limit。

不适合作为线上实现的矩阵计算

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

// 绝对不要在生产环境中尝试这种代码！Gas 会彻底爆炸
contract NaiveOnChainAI {
    // 企图在 Solidity 里做浮点数模拟与矩阵乘法
    function predict(int256[] memory inputs, int256[][] memory weights) public pure returns (int256) {
        int256 sum = 0;
        for (uint256 i = 0; i < inputs.length; i++) {
            sum += inputs[i] * weights[i][0]; // 极端消耗 Gas
        }
        return sum;
    }
}

链下推理与链上证明验证的分工

真正可用的架构是将 AI 模型运行在 GPU 节点上，生成运算轨迹（Execution Trace），再通过零知识证明（如 ezkl 或 Halo2）把小巧的 Proof 扔给智能合约校验。

下面展示一个链上轻量验证 ZK-ML 推理结果的 Solidity 合约实现：

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

interface IZkModelVerifier {
    function verifyProof(
        bytes calldata proof,
        uint256[] calldata publicInputs
    ) external view returns (bool);
}

contract DecentralizedAIPredictionMarket {
    IZkModelVerifier public immutable zkVerifier;
    address public owner;

    struct PredictionTask {
        bytes32 taskHash;
        uint256 expectedOutcome;
        bool isSettled;
    }

    mapping(bytes32 => PredictionTask) public tasks;

    event TaskVerifiedAndSettled(bytes32 indexed taskId, uint256 outcome, address indexed worker);

    constructor(address _zkVerifier) {
        zkVerifier = IZkModelVerifier(_zkVerifier);
        owner = msg.sender;
    }

    /**
     * 链下 Worker 节点提交 AI 推理结果与 ZK 证明
     */
    function settlePredictionWithProof(
        bytes32 taskId,
        uint256 predictedOutcome,
        bytes calldata zkProof
    ) external {
        PredictionTask storage task = tasks[taskId];
        require(!task.isSettled, "TASK_ALREADY_SETTLED");

        // 构造公共输入 (包含任务 ID 和模型预测结果)
        uint256[] memory publicInputs = new uint256[](2);
        publicInputs[0] = uint256(taskId);
        publicInputs[1] = predictedOutcome;

        // 链上极低 cost 验证 ZK 证明
        require(zkVerifier.verifyProof(zkProof, publicInputs), "INVALID_ZK_PROOF");

        task.expectedOutcome = predictedOutcome;
        task.isSettled = true;

        emit TaskVerifiedAndSettled(taskId, predictedOutcome, msg.sender);
    }
}

反模式二：每次对话都要求用户发起链上交易

如果让用户在 Web3 DApp 里发送每一条消息都弹出一个 MetaMask / Phantom 钱包提示“签名交易并支付 Gas”，产品的使用率会瞬间跌到谷底。

用有限授权降低重复确认

采用 EIP-712 结构化数据签名，用户只需要在进入应用时签署一次 Session Key 授权。之后的 AI 交互全走离线签名与链下调度网关，最后由 Worker 节点定期将 Batch 结果统一打包结算。

import { ethers } from 'ethers';

// EIP-712 Session Key 签名生成器
export class AISessionSigner {
  private domain = {
    name: 'Decentralized-AI-Agent-Network',
    version: '1.0.0',
    chainId: 1, // Ethereum Mainnet / Arbitrum
    verifyingContract: '0x1111111111111111111111111111111111111111',
  };

  private types = {
    AISession: [
      { name: 'userAddress', type: 'address' },
      { name: 'sessionKey', type: 'address' },
      { name: 'maxTokenBudget', type: 'uint256' },
      { name: 'expiration', type: 'uint256' },
    ],
  };

  /**
   * 引导用户生成仅用于 AI 推理调度的无 Gas 离线签名
   */
  public async createSessionSignature(
    signer: ethers.Signer,
    sessionKeyAddress: string,
    maxTokenBudget: number,
    durationHours: number = 24
  ): Promise<{ signature: string; payload: any }> {
    const userAddress = await signer.getAddress();
    const expiration = Math.floor(Date.now() / 1000) + durationHours * 3600;

    const value = {
      userAddress,
      sessionKey: sessionKeyAddress,
      maxTokenBudget,
      expiration,
    };

    // 弹窗请求用户签署结构化消息（无 Gas 费用）
    const signature = await signer._signTypedData(this.domain, this.types, value);

    return {
      signature,
      payload: value,
    };
  }
}

反模式三：缺少结果争议的处理机制

在分布式 AI 节点网络中，多个算力节点（Node Workers）可能对同一个推理 Prompt 给出微小差异的输出（例如因为 GPU 浮点精度不一致导致 Token 采样微小偏移）。

如果遇到争议就直接在链上重跑整个模型，链上资源会迅速耗尽。

解决冲突的正确方式是引入 Optimistic 验证与挑战期（Fraud Proof Period）：

1. 乐观假设：算力节点提交推理结果并在链上质押代币（Stake），系统默认相信其正确性并预分配收益。
2. 争议挑战：在 24 小时挑战窗口内，任何验证节点（Verifier Node）若发现结果与模型哈希不符，可提交异议并触发零知识/二分法精细挑战。
3. 惩罚作恶：若挑战成功，作恶节点的质押代币被 Slash（罚没），并奖励给挑战者。

架构取舍需要明确的边界

1. 算力与结算彻底解耦：永远不要尝试在智能合约里跑复杂的 AI 推理矩阵，让链下 GPU 跑计算，让链上只做验证。
2. UX 必须平滑：通过 EIP-712 与 Session Key 隐藏掉每一次 AI 调用的 Web3 签名弹窗。
3. 建立经济学约束：利用质押（Staking）与 Slash 机制处理跨角色节点冲突，比纯靠技术算法强行硬碰撞更经济实用。

避开这些伪聪明的做法，去中心化 AI 产品的架构设计才能步入正轨。

先确认哪些事实需要链上证明

不是所有模型输出都值得上链。先区分三类数据：需要公开结算或可验证归属的结果、只供用户即时阅读的生成内容、以及含有隐私或版权限制的输入。第一类才需要考虑证明、质押或争议流程；第二类通常更适合由链下服务处理；第三类还要评估数据是否适合公开承诺。这个分类能避免为了“去中心化”而增加不必要的签名和存储成本。

零知识证明也不是一个通用的性能按钮。需要事先明确模型版本、量化方式、输入承诺、证明生成时间和验证成本，并在目标链的测试环境中测量。模型更新后，电路或验证键可能随之变化，前后版本的结果是否可比较也要写入协议规则。若证明生成时间无法满足交互需求，可以把证明留给批量结算，把即时回答当作待确认结果显示。

会话授权的权限范围应尽量窄：限定可调用的方法、额度、有效期和撤销方式，并让用户能查看及撤销已有授权。争议窗口、质押金额和惩罚规则则要和参与者的成本相匹配，不能只复制其他协议的参数。先用小规模任务验证结算、撤销和争议这三条流程，再决定是否扩大网络规模，会比把所有环节一次性上链更稳妥。