零知识证明如何为链上AI交易代理提供可信执行与可验证推理

1. 先聊一个现实问题：链上的交易代理，凭什么让人信任

做DeFi的人都清楚，链上环境是一个典型的零信任世界——代码公开、账本公开、人人可校验。但要在这个环境里跑一个AI交易代理，事情就变得拧巴了。

假设你在某个协议里部署了一个自动化策略：根据行情数据、链上活跃度、资金费率这类信号，模型给出加仓、减仓或者观望的判断，然后路由到借贷协议或者DEX里执行。这个代理跑三个月、表现不错，参与者也赚到了钱。但问题来了——用户凭什么确信你跑的那个“模型”就是你公开宣称的那个模型？你说你在用某个神经网络做推理，可实际上你完全可以在服务器上偷偷写死几条规则：涨了就说看多、跌了就说看空，反正用户看不到你服务端发生了什么。就算你人品没问题，你的服务器被入侵、推理结果被替换，用户同样发现不了。

这就是zkML要解决的场景：用零知识证明把“机器学习推理过程”变成可公开验证的计算完整性证明，让链上的任何人都能验证“交易代理确实按照某个模型跑出了这个结果”，但不需要把模型参数全部公开，更不需要信任某个服务器。

我把这套东西在模拟环境里实际搭了一遍，做了一个可以提交链上信号的可验证交易代理原型。这篇文章把整个链路拆开讲清楚——为什么交易代理需要证明机制、零知识证明是怎么塞进机器学习推理里的、系统架构怎么设计、参数怎么选、有哪些坑是文档里不会写的。如果你想在DeFi里落地一个带可信背书的AI代理，这篇可以直接当参考。

先说清楚一个边界：我不是在说“AI交易稳赚”，也不是在讲某个具体协议怎么用zkML。我想聊的是底层工程问题——如何让一个链下运行的AI推理结果，在链上获得可校验的可信度。这个问题搞明白之后，换什么策略、换什么模型，逻辑都一样。

2. zkML到底在证明什么：机制拆解

很多文章喜欢直接甩定义，但zkML的难点不在“零知识”这三个字，而在“机器学习推理”这件事怎么变成一个可证明的数学对象。我先把这条链路从底层捋一遍。

2.1 推理本身就是一次固定的计算过程

机器学习模型的推理，本质上就是一段确定的计算流程。拿一个最简化的线性模型举例：

score = w1 * x1 + w2 * x2 + w3 * x3 + b if score > threshold: action = "increase" else: action = "decrease"

把同样的输入丢进去，模型权重不变，那么输出永远一样。这就是“确定性计算”。一个神经网络再复杂，无非是把这种计算组织成多层矩阵乘法和激活函数。换句话说，推理不是黑魔法，而是一个可以被写成指令序列的算术过程。

这个特性至关重要，因为零知识证明系统也只能处理“被展开成算术电路的计算过程”。如果AI推理是确定性的，那它就能被电路描述；如果电路能被描述，它就能被证明。

2.2 把模型和推理变成算术电路

所谓算术电路，就是把计算过程拆成一行行的加法和乘法。比如y = w1 * x1 + w2 * x2，可以拆成两步：

t1 = w1 * x1 t2 = w2 * x2 y = t1 + t2

每一条指令都变成电路里的一个门（乘法门、加法门）。神经网络里的卷积、全连接层、ReLU激活，本质上也是一层层的乘法和加法组合，ReLU这类不可导的分段函数，可以拆成“当输入大于0取本身，否则取0”的比较逻辑再电路化。

关键点在这里：模型权重、输入特征、中间结果、最终输出，所有这些变量都变成电路里的“导线值”。证明者知道这些值，验证者只信证明，不看值。

2.3 公开输入、私有输入、证明和验证

一个zkML系统里有两类数据：

• 公开输入（public input）：链上所有人都能看到的。比如当时的时间戳、链上行情快照的哈希、模型版本号、最终的交易动作（加仓/减仓/观望）。
• 私有输入（private witness）：证明者不想公开的。通常是模型权重、部分内部特征、可能还有关键中间结果。

证明者要做的事情是：拿着私有输入和公开输入，完整执行一遍电路，把全部中间值记录下来，生成一个零知识证明。验证者拿到这个证明和公开输入，几毫秒到几秒钟就能确认两件事：

1. 证明者确实执行了那条电路；
2. 电路的最终输出和公开声明的结果一致。

但验证者完全不知道中间发生了什么，不知道权重具体是多少。

用大白话讲一次：我想证明“我按某套规矩算出了这个数”，但我不想把规矩本身告诉全世界。我只需要给一个数学印章，让别人盖一下章就能确信我守规矩了。

2.4 一个容易被误解的点

很多人以为zkML是在证明“我的模型预测得准”，不是的。ZK证明只保证“计算过程没有作弊”，不保证“模型本身在市场上有效”。模型选得好不好、市场环境变没变，这是另一回事。一个完全过拟合的历史模型，照样可以产出合法证明——它证明的只是“你确实用它算了”，而不是“它算得对”。

所以做zkML交易代理时，要把“计算守信”和“策略有效”拆开考虑。你可以用ZK保证前者，后者只能靠模型本身的质量、回测和风控来把关。这个认知差异会影响你整套系统的产品定位——你是卖“模型可信”还是卖“收益保证”？前者可以做，后者无论技术上多牛都不该承诺。

3. 可验证AI交易代理的系统架构设计

理解了机制，下一步是把它落到可运行的系统上。我把整个架构拆成五个模块，逐一说明职责和关键设计决定。

3.1 链下组件：推理节点与证明生成器

交易代理的实际推理运行在链下。原因很直接：链上跑完整神经网络，gas成本高到离谱，而且模型参数上链等于模型完全公开。链下组件负责两大任务——

推理节点：监听链上数据源，比如某个区块时间戳、某交易池的加权价格、某个借贷协议的清算线波动，把原始数据清洗成模型输入特征。推理完成后，得到交易动作。

证明生成器：把“特征输入+模型权重+推理动作”作为中间数据，生成一份零知识证明。证明生成是整条链路里最重计算的一步，需要比较高的CPU/内存配置。在这套系统里，我把推理节点和证明生成器分开部署，避免推理热路径被证明计算拖垮。

3.2 链上组件：验证合约

链上有一个验证合约，它的作用只有一个——验证证明是否有效。具体来说，合约做的事情包括：

1. 校验验证密钥和模型版本是否匹配；
2. 检查公开输入是否正确绑定本次交易（时间戳、数据哈希、动作）；
3. 执行验证函数，确认零知识证明有效；
4. 如果验证通过，允许后续的交易执行逻辑（比如跨协议调用、仓位调整）继续跑。

验证合约不应该直接负责交易执行，应该把它当作一个“门禁模块”。这样设计的好处是：将来换模型、换策略，只要验证密钥更新，不需要动交易执行逻辑。

3.3 重放攻击与公共输入绑定

这是最容易忽略的工程细节。如果我拿到别人某个时刻提交的一个“加仓证明”，能不能自己复制一份，在另一个时间点重复提交？当然不行——那就成重放攻击了。

解决方案是把不可伪造的上下文信息绑定成公共输入。我在系统里用的方案是：

• 把当前链上的某个随机数或区块哈希作为数据源，采样进模型的输入特征；
• 同时把这个哈希也作为公共输入的一部分交给验证合约；
• 合约在验证时，自己取当前链上的哈希比对，不匹配直接拒绝。

换句话说，证明和“当时的环境状态”绑定在一起。只要公共输入里有足够强的时间锚和状态锚，旧证明在下一分钟就会失效，想重放也没门。

3.4 链上数据源与链下信号的处理差异

模型需要的数据分两类：一类是链上本来就有的，比如交易池深度、某个协议的借贷总量、清算历史，这类数据直接从公开节点读取然后哈希上链即可；另一类是链下数据，比如中心化交易所的订单簿深度、情绪指数，这类数据必须依赖预言机喂价上链。

我在原型里只用了链上数据，原因不是链下数据没用，而是zkML的证明是“绑定输入”的——如果输入本身来源不可信，证明再合法也没意义。链下数据的可信度由预言机方案决定，那是另一层信任体系，和ZK的信任假设叠加在一起会让系统复杂度上升一个量级。等核心链路跑稳了，再考虑把预言机喂的数据纳入输入特征表会更稳妥。

3.5 发起一次链上交易动作的完整时序

整个流程走一遍是这样的：

• 第1步：链下监听模块捕获到某区块的状态变化，提取特征向量；
• 第2步：推理节点加载模型权重，计算出交易决策；
• 第3步：证明生成器构建算术电路，把模型权重、特征、中间值作为witness，生成ZK证明；
• 第4步：代理节点组装一笔交易，附带证明和公共输入（动作、数据哈希、验证密钥标识）；
• 第5步：验证合约先验证签名和公共输入绑定，再验证ZK证明；
• 第6步：验证通过后，交易执行模块按预授权逻辑执行动作（比如调整某个仓位的大小）。

其中第3步到第4步之间，还有个“冷身检查”环节——我在代码里加了策略阈值限制，比如最大仓位不能超过某个比例、单次操作不能超过某个幅度。原因很直接：ZK只保证“模型计算没作弊”，但模型可能在极端行情下输出一个风控上不可接受的数字。风控逻辑和模型计算必须解耦，风控规则直接在合约层写死，不做成模型的一部分。

4. 证明方案和参数选型：不是越先进越好

zkML的工程落地，很大程度上取决于你选哪套证明系统。我实测对比了几条路线，各有利弊。

4.1 三种主流路线的对比

先说结论：没有绝对最优，只有场景最合适。

我在原型里先用的是Groth16风格路线，因为模型尺寸小、电路固定，运行效率最高。但是当我想迭代模型、增加一个输入维度的时候，麻烦来了——电路一变，可信初始化参数就得重做，整套验证密钥要重新发布。

后来我把方案切成了Plonk风格，原因是它支持通用参考字符串，模型迭代只需要重新编译电路和更新验证密钥，不需要跑整套复杂的初始化仪式。对交易代理这种需要持续调整模型字数的场景，灵活性比那点gas差更重要。

4.2 模型规模与电路尺寸的博弈

电路尺寸决定了证明生成时间和成本。电路的规模大致等于“乘法门的数量”。一个简单的逻辑：

• 一个只有几层全连接的小网络（比如3层、每层16个神经元），电路可能只有几万到几十万个乘法门，普通笔记本几分钟就能生成证明；
• 到了稍微像样的模型（比如一层LSTM、注意力机制），电路规模直接冲上百万门，证明生成时间变成小时级，内存需求也开始吃紧；
• 如果模型再上一个量级，没有专门优化和并行计算硬件，直接跑不动。

我在做原型时第一次就把模型设计得太花哨——加入了时序特征、注意力加权，结果证明生成时间到了无法接受的程度。后来把模型压缩成两层全连接加一个直接决策头，电路规模降了一个数量级，证明生成时间才回到可以接受的分钟级。

模型精度和证明成本是矛盾关系。交易代理的真实需求未必需要多么前卫的模型——很多情况下，三四个核心特征加一个非线性决策头，已经比一整票直觉操作稳定得多。关键是要找到那个“精度够用、电路可跑”的平衡点，不是越准越好。

4.3 量化与定点运算

零知识证明电路跑的数值运算，和普通机器学习训练用的浮点运算不一样。在电路里，浮点运算复杂且开销高，大多数方案会把权重和输入量化成定点数。

我在实际项目里采用的思路是：把权重缩放到固定的小数位精度，比如保留8位小数，再用整数运算表示整个推理过程。这种处理方式会让模型精度和浮点版本有轻微差异，但通常在可接受范围内。

有个坑必须提醒：如果模型训练时用的是FP32，推理时直接套量化权重，没有做量化感知训练，精度损失可能比想象中更大。更稳的做法是训练阶段就加入量化噪声模拟，让模型适应低精度表达。我的经验数据是：8位小数量化，经过量化感知训练后，在交易信号任务上的准确率损失可以控制在1%以内，但如果直接拿原模型硬量，损失可能到3%-5%。对交易信号来说，这个差距足以让回测曲线变形，一定要在训练阶段就考虑部署时的精度约束。

4.4 证明生成的硬件门槛

很多人低估了证明生成所需的硬件。我一开始在开发机上做实验，16GB内存、普通CPU，跑一个几十万门的小电路，生成证明花了将近半小时。后来换到高配的云主机（多核CPU + 64GB内存），同样的电路压缩到几分钟。

如果模型规模再大一些，想要把证明生成时间压到分钟级以内，就需要并行计算能力甚至多机并行生成方案。这也是为什么从一个产品视角来看，zkML的模型不可能很大、迭代不可能很频繁——每次迭代的证明生成开销和验证密钥发布流程，都会成为新的约束条件。

5. 实操中踩过的坑与应对方案

这些坑不是从官方文档里看来的，是我在真实搭建过程中一个一个排除出来的。

5.1 电路编译器的选择比证明系统本身更影响调试效率

很多人上手zkML时，精力全放在选证明系统上，结果卡在电路编译环节。我试过用底层方式手写R1CS约束，再逐行约束模型运算。结果就是：写起来极慢、调试极其痛苦，一个括号错误可能找半天。

后来我换成了更高级的电路描述方式，允许用类似普通编程的语法定义约束关系，自动编译成算术电路。体验差别相当于“用汇编写业务逻辑”和“用高级语言写业务逻辑”。电路编译器的体验，直接决定你迭代模型的速度。如果你要连调多个模型版本，这点时间差会放大很多倍。

5.2 模型权重更新和验证密钥的联动

这是我在方案切换时踩的最大的坑。第一次跑通时，我修改了模型权重，但没有重新编译电路，只在代码里换了一个权重文件路径。验证端一直报“证明无效”，找了半天才发现验证密钥还是老的。

在zkML系统里，“模型权重”和“电路结构”是绑定的概念。一旦模型结构变化——哪怕只是增加了一层、改变了一个输入维度——电路结构就会变，验证密钥必须同步更新，所有集成了旧验证密钥的合约也要重新部署。

我后面做了一个版本管理表，每次改动都记录：模型结构版本、电路版本、验证密钥版本、合约地址。发布流程做成半自动的，改模型必须走完整流程，不允许只改权重文件跳过电路编译。

5.3 证明生成时间与交易时效的矛盾

DeFi的很多策略对时效性很敏感，比如清算监控，错过几个区块就意味着机会消失。但zkML的证明生成往往需要几十秒到几分钟，中间的时间窗口非常尴尬。

我的处理方式是折中：不追求每个区块都出证明，而是固定一个执行周期。比如每N分钟批量生成一次证明，只对“当前执行周期内最值得执行的动作”出证明。这样模型输出不必实时连续，交易代理变成了“定期快照评估 + 证明执行”的节奏。对很多交易策略来说，这个延迟是可接受的，但对高频套利类策略，这个模式就行不通了。

如果必须更快的证明生成，唯一的出路就是上更强的算力做证明生成并行化。但在工程上，先想清楚策略的时效需求，再做技术选型，能省掉很多无用功。

5.4 模型参数的隐私性与公开性的再思考

最初我认为模型的权重参数应该作为私有witness保护起来，这正是“零知识”的魅力所在。但实际操作后我发现：在交易代理场景中，模型权重完全不公开反而制造了新的信任问题。

想一想：如果用户看不到模型权重，他们凭什么相信这个模型没有故意嵌入某种异常行为？ZK证明保证“模型确实这么算”，但如果模型本身是在恶意数据上训练的，结果照样有问题。这个时候，完全不让用户看模型的任何内容，并不能真正解决信任问题。

我最终的折中方案是：公开模型结构和权重摘要（哈希承诺），权重细节不公开。用户至少能验证“用承诺值对应的权重推理”。更进一步说，如果想做完全透明的代理，直接把权重公开也不是不行——零知识在这里的真正价值，其实更多体现在保护“输入数据和中间结果”的隐私上。这个理解比“保护模型权重”更符合DeFi应用的实际需求。

5.5 链上验证的成本实际感受

我记录了几组gas数据（不同方案、不同电路规模）：

• 小电路、Groth16风格：单次验证大约20万gas级别，换算成普通网络下的费用，在可接受范围内；
• 同电路的Plonk风格方案：验证gas大约高30%-50%；
• STARK风格方案：验证gas明显高出一个量级，基本上只能作为备选。

所以如果你关心长期运行成本，Groth16风格的性价比目前是最突出的，代价是要处理可信初始化。如果是小规模试验或模型迭代频繁，Plonk风格更务实。另外一个细节：如果不想让每次交易动作都单独验证，可以做成“有效证明缓冲池”，比如一个证明覆盖一批历史信号，然后在合约层做聚合验证，但这会引入更复杂的电路结构。

6. 从Demo到可落地：我建议的推进顺序

如果你打算自己做一套类似的原型，我建议按下面这个顺序推进，不要一上来就追求完整平台化。

6.1 第一步：用一个极小模型跑通全链路

先用最简单的线性模型或两层全连接，输入特征不超过5个，直接把“特征提取 → 推理 → 证明生成 → 链上验证”整条链路走通。这个阶段的目标不是性能，而是确认每一个环节之间的数据格式不脱节。我当时在这个阶段花了最多时间调试的其实不是证明部分，而是链上合约、推理输出、公共输入三者的字段命名对齐问题。先把这条链路打通，后面的优化才有意义。

6.2 第二步：换一个更真实的交易策略模型

链路通了以后，把模型换成更贴近真实场景的版本，比如加入资金费率、借贷利率变化率这类信号。这个阶段会暴露性能问题——证明生成时间、gas成本、模型精度损失都会一起冒出来。不要同时调整太多变量，一次只改一个。

6.3 第三步：加入防重放和风控逻辑

这是从“技术演示品”迈向“可用工具”的分水岭。把区块哈希绑定、风控阈值、模型版本管理全部加上。我测试过不加防重放直接跑是什么状态——攻击者完全可以把历史证明重新提交，造成重复执行。这类问题不解决，系统不能算真正可用。

6.4 第四步：考虑多策略、多模型的并行扩展

等到单策略跑稳了，再做扩展：不同模型分配不同验证密钥，每个策略独立证明、独立验证、共享一套交易执行层。扩展的关键是赌上“验证合约模块化”——把验证逻辑和策略执行逻辑完全分离，新策略接入不需要动老逻辑。

关于要不要把运行节点全部去中心化、由谁来运营证明生成器这类问题，我的建议是：别在Demo阶段为这个分心。先把单信任假设下的技术链路跑通，验证清楚“证明有效、结果可信、成本可接受”，然后再讨论多节点协作。你不可能在证明生成的性能问题还没解决时，就规划一个分布式证明集群，那是把顺序搞反了。

最后分享一个我自己的习惯：每次调完模型，我会记录三组数字——浮点版本的准确率、量化版本的准确率、生成一份证明的耗时。这三组数字放在一张表里，长期跟踪。因为zkML系统的每一个技术环节都会互相影响，只有把数字记下来，才能在“模型改复杂了”和“证明变慢了”之间准确找到瓶颈。这套系统还有太多东西可以优化，比如递归证明、批量验证、多策略互斥等等，但最基本的信任链路已经足够扎实——只要你愿意公开你的验证密钥和模型版本，任何人都能自己检查，你那个跑在链下的交易代理，到底有没有老老实实数胡萝卜。