Web3 与 AI 协作：链上验证和链下计算如何分工
新技术可以大胆试，但链上资产、接口状态和回滚条件要写得足够保守。这篇只讨论一个问题：Web3 与 AI 协作：链上验证和链下计算如何分工。
写作边界：围绕“Web3 与 AI 协作：链上验证和链下计算如何分工”出现的数字、事故场景和性能结果均用于演示分析方法，不是特定项目的实测结论。落地时请记录版本、输入、资源、统计窗口和失败路径，再用自己的测试数据复核。
链上与链下：算力、成本与责任的清晰切割
产品在规划 Web3 产品功能时，往往容易把传统 API 架构的习惯带进来。把数据筛选、排序乃至复杂的权限校验全推给智能合约。结果不仅 Gas 消耗高得离谱，还极易引入安全隐患。
责任边界划分需要遵循三个基本规则：
签名验签与 Merkle 证明：安全协作模式
在白名单铸造（Mint）或者特权发放场景中，传统做法是把白名单地址一个个写入合约的 mapping 中。这在产品层面是灾难——每次新增用户都要执行高昂的 Gas 交易。
合理做法是由后端计算 Merkle Root 并部署在合约中，或者直接采用 ECDSA 链下签名。研发与产品对接时，接口只需定义传参的数据格式。
以下是经过生产检验的 Solidity 合约安全验签实现：
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
import "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
contract ProductFeatureVault is Ownable {
using ECDSA for bytes32;
address public signerAddress;
mapping(bytes32 => bool) public executedHashes;
event TaskExecuted(address indexed user, uint256 indexed taskId, uint256 amount);
constructor(address _initialSigner) Ownable(msg.sender) {
require(_initialSigner != address(0), "Invalid signer");
signerAddress = _initialSigner;
}
function setSigner(address _newSigner) external onlyOwner {
require(_newSigner != address(0), "Invalid signer");
signerAddress = _newSigner;
}
function executeTaskWithSignature(
uint256 taskId,
uint256 amount,
uint256 deadline,
bytes calldata signature
) external {
require(block.timestamp <= deadline, "Signature expired");
bytes32 messageHash = keccak256(
abi.encodePacked(msg.sender, taskId, amount, deadline, block.chainid, address(this))
);
bytes32 ethSignedMessageHash = MessageHashUtils.toEthSignedMessageHash(messageHash);
require(!executedHashes[ethSignedMessageHash], "Task already executed");
require(
ethSignedMessageHash.recover(signature) == signerAddress,
"Invalid authorization signature"
);
executedHashes[ethSignedMessageHash] = true;
// 业务逻辑执行
_processUserTask(msg.sender, amount);
emit TaskExecuted(msg.sender, taskId, amount);
}
function _processUserTask(address recipient, uint256 amount) internal {
// 模拟业务处理
}
}
后端 Node.js (TypeScript) 对应的数据签名生成模块：
import { ethers } from "ethers";
interface ClaimParams {
userAddress: string;
taskId: number;
amount: bigint;
deadline: number;
chainId: number;
contractAddress: string;
}
export async function generateContractAuthorization(
params: ClaimParams,
privateKey: string
): Promise<string> {
const wallet = new ethers.Wallet(privateKey);
const packedHash = ethers.solidityPackedKeccak256(
["address", "uint256", "uint256", "uint256", "uint256", "address"],
[
params.userAddress,
params.taskId,
params.amount,
params.deadline,
params.chainId,
params.contractAddress,
]
);
const signature = await wallet.signMessage(ethers.getBytes(packedHash));
return signature;
}
研发与产品推进审计的三阶段工作法
为保障审计高效推进，不能把审计当成“研发写完后抛给第三方的独立阶段”。产品、研发与审计团队需要建立全流程协同节奏。
阶段一：需求设计期（规范 API 边界）
产品经理在输出 PRD 时，必须同步产出数据流动与链上状态表。表中明确指出哪些字段沉淀在链上、哪些事件（Event）用于前端触发、防刷机制落在哪一侧。研发团队根据该表设计接口并完成 ABI 锁定。
阶段二：研发开发期（自动化工具内置）
研发在编写合约代码的同时，要求在 CI/CD 中集成静态分析工具（如 Slither）与自动化测试工具（Foundry）。所有 PR 提交必须满足单元测试覆盖率高于 95%，且不触发任何 High/Medium 级别警告。
阶段三：审计交互期（攻防与修补）
提交给第三方审计机构的，必须是包含完整单元测试、架构图、部署脚本及说明文档的“代码冻结版本”。当审计机构反馈 Issue 列表时，产品与研发共同评估修复方案：
- 是否需要修改链上合约逻辑？
- 修改是否会导致前端与后端 API 接口不兼容？
- 修复方案带来的额外 Gas 成本由哪一方承担？
只要按照这种标准化的责任边界与协作流程切入，产品和研发团队就能避免上线前的推诿扯皮，把大部分漏洞隐患死死封杀在代码部署之前。
