ZKML：零知识证明让AI推理可信——从zkSNARK到链上可验证大模型的技术全景与工程挑战

摘要

人工智能正在渗透链上金融、去中心化治理与隐私敏感型应用，但其"黑盒"特性催生了根本性的信任危机：用户无法确认云端模型是否被替换、推理过程是否被篡改、输入数据是否遭到泄露。零知识机器学习（ZKML）试图用密码学锁死这道裂缝——它将神经网络的推理过程编码为算术电路，借助zkSNARK或zkSTARK生成零知识证明，让任意第三方在不接触模型参数与原始数据的条件下，以毫秒级开销验证"输出确实由某个特定模型对特定输入产生"。去年下半年，业内开始将这一时期称为"ZKML奇点"，不仅因为EZKL等框架在20M参数模型上的证明延迟从数小时压缩到分钟级，更因为Polyhedra推出的EXPchain首次将可验证大模型推理作为Layer 1的核心叙事，标志着ZKML从实验室概念迈向生产级基建。本文从密码学原理解析入手，系统梳理ZKML的电路化技术路径、主流开源框架的工程实践，以及DeFi AI保险库、去中心化预言机与AI Agent审计等真实落地场景，并冷静评估当前仍存在的性能瓶颈与精度折损，试图为关注这一交叉领域的开发者和研究者提供一幅尽可能完整的导航图。

一、AI的信任赤字：云端推理的不可验证困境

大语言模型与多模态系统的爆发式落地，并未解决一个更古老的命题——信任从何而来。当用户把一段商业机密、医疗影像或交易信号发送给某家云服务商的API时，他实际上同时出让了三项不可验证的假设：

1. 模型一致性：服务商声称调用的是GPT-4级模型，实际运行的是否是蒸馏版或篡改版？
2. 计算完整性：模型对这段输入确实执行了所承诺的运算，中间结果未被恶意注入？
3. 数据保密性：输入在传输与推理全链路中未遭到侧录或滥用？

这三项缺失在传统IT架构中只能靠法律合同与品牌背书填补，但在去中心化世界里，品牌恰恰是最薄弱的环节。2024年涌现的多起预言机操纵与模型投毒事件已经证明，只要有经济激励，链下计算节点就可能偷偷替换模型权重或伪造推理结果。

ZKML的核心洞察就在于把"信任谁"转换为"验证什么"。它不关心模型托管方的身份，而是要求对方提交一段密码学证明——这段证明足以让链上智能合约在几毫秒内确认：给定一个公开承诺的模型哈希、一段公开的输入与输出，存在一个私密但逻辑正确的计算路径将这些元素串联起来。

在这一架构下，用户无需向证明者暴露原始数据，证明者也无需向验证者暴露模型参数与中间激活值，双方仅凭一段零知识证明完成信任传递。下面的架构对比图清晰呈现了这种范式的反转：

图1：通用云推理与ZKML可验证推理的架构对比

在通用云推理的链路中，用户把原始数据完整发送给云服务商，服务商返回结果。但用户拿到结果之后没有任何密码学手段去核验计算过程，唯一能做的大概是比对同批次其他用户的输出，这种间接验证的效力近乎为零。数据泄露风险则更为隐蔽——服务商完全有能力在日志中留存用户输入，用于后续训练或出售。

flowchart LR
    subgraph 通用云推理["通用云推理（Trust-by-faith）"]
        U1[用户 Query + 原始数据] --> C1[云服务商 / 推理节点]
        C1 --> O1[推理结果]
        C1 -.->|不可验证| M1[模型是否被替换?]
        C1 -.->|不可审计| D1[数据是否泄露?]
    end

    subgraph ZKML推理["ZKML 推理（Trust-by-math）"]
        U2[用户 保留私密数据] --> P[Prover 证明者]
        P --> ZP[ZK 证明 π]
        ZP --> V[链上 Verifier 合约]
        V --> O2[可信结果]
        P -.->|零知识| M2[模型承诺 (hash) 公开]
    end

上图右侧的ZKML链路则把原始数据留在了用户本地或可信边缘节点。Prover在本地完成推理后，将模型的公开承诺（通常是一组哈希值）、公开输入/输出，以及一段零知识证明π一起提交到链上。Verifier合约只需要执行一组固定次数的椭圆曲线配对或哈希运算，即可在极短时间内判定证明是否有效。如果有效，智能合约就可以安全地触发后续逻辑——比如释放一笔保险理赔金、执行一笔交易、或者为某个预言机报价赋予权重。

这个模式的精妙之处在于计算不对称性：生成证明的过程可能消耗数分钟乃至数小时的算力，但验证证明只需要毫秒级。Ethereum主网上一个Groth16验证大约消耗28万Gas，合不到一秒的执行时间。这种不对称性恰恰是区块链场景所需要的——证明生成可以交给一台高性能服务器或集群完成，而验证则必须足够轻量，才能在不挤爆区块空间的前提下被全球数千个节点同时执行。

二、zkSNARK的密码学骨架：从算术电路到多项式承诺

要把ZKML讲好，绕不开对zkSNARK底层机制的简要回顾。1985年，Goldwasser、Micali和Rackoff首次形式化定义了零知识证明的三大属性：

• 完备性（Completeness）：诚实的证明者总能说服诚实的验证者；
• 可靠性（Soundness）：虚假陈述无法被伪造的证明通过验证；
• 零知识性（Zero-knowledge）：验证者除了陈述本身的真值外，得不到任何额外信息。

三十多年后，zkSNARKs（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）让这套理论具备了工程可行性。其工作流程可以粗略拆为三步：

1. 算术电路化（Circuit Synthesis）：目标计算——比如一个神经网络的前向传播——被转写为由加法门和乘法门构成的有向无环图。图中每个门的输入、输出都对应有限域上的元素。
2. 约束系统编码：这些门的连接关系被编码为约束系统，早期方案使用R1CS（Rank-1 Constraint System），较新的PlonKish方案则采用更灵活的多项式门表。核心思想是：如果输入满足所有约束，则存在一个低次多项式在特定点上的求值结果与预期匹配；反之，存在至少一个约束被违反意味着相关多项式在这些点上的残差不等于零。
3. 证明生成与验证：证明者通过多项式承诺方案（如KZG、IPA或FRI）隐藏地构造并提交多项式，再借助随机挑战构造一个可以被快速检查的等式。验证者只需做少量多项式求值与承诺校验，即可完成验证。

值得特别指出的是"可信设置"（Trusted Setup）问题的分野：

• Groth16虽然验证极快、证明极小（约192字节），但需要一次性的可信设置仪式来生成公共参考字符串（CRS）。如果参与设置的所有人中存在至少一位诚实删除其秘密废料，整个系统就是安全的。
• STARKs（包括PlonK、Ligero、FRI-based方案）则不需要可信设置，仅依赖公开可验证的随机性，代价是证明尺寸更大（数十到数百KB），验证开销也稍高一些。

对ZKML而言，这种权衡直接影响了工程选型：如果追求链上验证成本最小化，Groth16仍具优势；如果担心可信设置的协调成本，STARKs路线更友好。当前主流框架中，EZKL默认采用Halo2+KZG（Halo2支持IPA，当与KZG配对时需要一次可信设置），而RISC Zero则走FRI-based STARK路线，无需可信设置但证明体积偏大。

下面的流程图展示了从ML模型到链上验证的完整链路，方便理解各个阶段的角色与依赖关系：

图2：ZK证明生成与链上验证全链路

在这个流程中，最耗费算力的无疑是"后端阶段"——多项式承诺与证明生成。一个中等规模的神经网络可能产生数百万到数千万个约束，对应的多项式次数同样巨大，证明者需要执行大量的NTT（Number Theoretic Transform，数论变换，即有限域上的FFT）来构造默克尔化求值。这也是为什么ZKML的瓶颈长期卡在"电路规模"与"证明生成时间"之间。

flowchart TB
    A[ML 模型 + 输入数据] --> B["前端阶段：模型编译为算术电路"]
    B --> C["约束系统：R1CS / Plonkish 门表"]
    C --> D["后端阶段：多项式承诺 + FRI / KZG"]
    D --> E["证明者 Prover：生成证明 π"]
    E --> F["发送 π 到链上 Verifier 合约"]
    F --> G{验证通过?}
    G -->|是| H[接受结果，触发智能合约逻辑]
    G -->|否| I[拒绝，执行共识惩罚或拒付]
    style E fill:#4B5563,color:#fff
    style F fill:#065F46,color:#fff

三、神经网络的电路化：ZKML最核心的工程难题

写代码的人有过PyTorch经验的话应该清楚，神经网络里遍布浮点运算、非线性激活与动态控制流——这三样东西几乎每一条都在与ZK电路的底层假设对着干。

有限域 vs 浮点数。ZK电路运行在有限域 $\mathbb{F}_p$ 上，其中 $p$ 通常是一个接近 $2^{254}$ 或 $2^{256}$ 的大型素数。这意味着所有加法和乘法都对这个素数取模。而神经网络训练通常使用32位或64位IEEE 754浮点数，包含尾数、指数和符号位。直接把浮点运算原样塞进有限域电路，门数会膨胀到不可接受的程度。

激活函数的非线性代价。ReLU看似简单 —— $f(x) = \max(0, x)$ —— 但在有限域中实现取大操作，需要引入范围证明（range proof）来确保中间值非负。每个ReLU单元都可能增加数十到数百个约束门。Sigmoid和GELU这类平滑激活的代价更高，因为它们涉及除法、指数和对数，这些操作在有限域中没有直接的廉价电路实现。

矩阵乘法的门数爆炸。一个全连接层 $y = Wx + b$ 的矩阵乘法，如果输入维度是 $n \times m$，输出是 $n \times k$，大约需要 $n \cdot m \cdot k$ 个乘法门。一个20M参数的小型网络，其前向传播的约束数量可能轻松突破数亿级别。根据Modulus Labs在2024年末发布的基准测试，一个约20M参数的神经网络在EZKL中生成证明需要1到5分钟，占用内存20到60GB。这还远不是大模型——千亿参数的LLM如果全量电路化，约束量会达到天文数字。

工程上的应对策略，当前主流框架集中在三条路线上：

1. 量化与定点化（Quantization & Fixed-point）：把FP32权重和激活值降到INT8甚至INT4，再用定点算术替代浮点。这不仅减小了模型体积，也让加法和乘法能直接用有限域的模运算近似模拟。代价是精度损失——在图像分类任务上INT8量化通常能保住在1%以内的top-1精度下降，但在对数值稳定性敏感的回归或生成任务上，量化后的ZK电路输出可能与原始浮点模型存在显著偏差。
2. 查找表（Lookup Tables）与自定义门（Custom Gates）：PlonKish电路框架支持预定义查找表。比如把Sigmoid函数拆分为一段分段常数或线性插值表，电路只需要证明"每个输入值都落入了某段区间的对应输出"，而不是逐位计算指数。Halo2的lookup argument极大降低了非线性层的约束密度，是当前高性能ZKML方案的关键提速手段。
3. 图级别优化：通过算子融合、死代码消除和层级剪枝，减少电路中冗余的中间变量。EZKL内部会对ONNX计算图做多轮优化，比如把连续的线性感性层合并，把批归一化参数折叠进卷积核。

值得注意的是，这些优化并不是相互独立的。在实际部署中，开发者通常要先在Python里做量化感知训练或后训练量化，导出ONNX，再由ZKML编译器把已量化的静态图进一步翻译成优化后的电路。这个链路越长，调试难度越大——任何一层的数值偏差都可能在证明过程中暴露为验证失败。

四、开源框架的工程实践：从PyTorch到链上验证

2023年到2025年，ZKML开源生态经历了从无到有的快速成型。当前值得开发者重点关注的框架包括EZKL、RISC Zero、Orion以及Modulus Labs的基准测试套件。各框架的技术路线差异极大，选错工具链可能意味着证明时间相差两个数量级。

主流框架横向对比

从上表可以看出，EZKL目前是最接近"开发者友好"定位的选项。它的工作流高度标准化，基本上遵循以下六步：

1. 导出ONNX：在PyTorch或TensorFlow中训练好模型，调用torch.onnx.export得到静态图。
2. 生成设置：ezkl gen-settings 读取ONNX图，自动推断输入输出形状、算子类型与建议量化配置。
3. 校准动态范围：ezkl calibrate-settings 用一批校准数据跑通前向传播，统计每层激活值的min/max，生成最优定点缩放因子。
4. 可信设置：ezkl setup 生成证明密钥（pk）和验证密钥（vk），Halo2+KZG路线需要这一步。
5. 生成本地证明：ezkl prove 用实际输入数据构造witness并生成零知识证明π，这一步最耗时。
6. 链上验证：ezkl create-evm-verifier 部署Solidity验证合约，随后任何合约都可以调用verify()接口来确认证明有效性。

这个流程的最大门槛不在命令行本身，而在调试链路。当ezkl prove失败时，错误信息往往指向"某层约束不满足"，开发者需要同时理解原始PyTorch图的数值语义、ONNX中间表示的算子分解方式、以及最终生成的有限域电路的逻辑。2024年中，社区里常见的求助帖往往围绕"为什么ONNX里的Softmax在EZKL里报错"或"某层量化后精度崩塌导致证明 witness 不合法"。

下面的工程链路图展示了从模型训练到链上验证的完整数据流，帮助理解EZKL在各个环节的作用：

图3：EZKL端到端工程链路

flowchart LR
    PT[PyTorch 模型训练] --> ONNX[导出 ONNX 静态图]
    ONNX --> EZKL1["ezkl gen-settings & calibrate<br/>生成电路配置与量化参数"]
    EZKL1 --> EZKL2["ezkl setup<br/>生成 pk / vk"]
    EZKL2 --> EZKL3["ezkl prove<br/>生成本地 ZK 证明 π"]
    EZKL3 --> ON["将 π + 公开输入/输出 提交到链上"]
    ON --> SC["EVM Verifier 合约<br/>验证 π 的合法性"]
    SC --> OK["验证通过 → 触发 DeFi / 治理 / 保险合约逻辑"]
    style PT fill:#2563EB,color:#fff
    style SC fill:#059669,color:#fff

一个端到端案例：链上可验证MNIST分类

为了把上述抽象概念落地，我们可以设想一个最小可行示例：在Ethereum测试网上部署一个可验证的MNIST手写数字分类器。

• 模型结构：两层全连接（784→128→10），约100K参数。这个规模对ZKML属于"玩具级"，但足以演示完整链路。
• 量化配置：INT8权重与INT8激活，用EZKL的默认校准流程处理。
• 证明性能：在一台配备96GB内存的工作站上，证明生成约需15-30秒，内存占用约4-8GB。Verifier合约的Gas消耗约240k-280k，在当前主网Gas价格下约合几美元到十几美元不等。
• 链上部署：验证合约大小约2-3KB，完全可以作为库合约被其他DApp引用。

这个案例虽然简单，但已经揭示了ZKML在真实部署中的经济账：每推理一次就需要生成一个独立证明，证明生成时长和链上验证成本构成了双重门槛。对于高频、低时延场景（比如实时价格发现、毫秒级交易信号），纯ZKML路线目前仍然太重。Devore等人2024年的论文中提出了一种折中方案：把模型切成"可信部分"和"可验证部分"，只有涉及经济敏感决策的最后几层才生成ZK证明，前面大部分计算用可信执行环境（TEE）或链下 GPU 处理。这种分层架构可能成为中短期内的主流范式。

五、落地场景：DeFi、预言机与AI Agent的信任基建

技术再精巧，若找不到匹配的需求场景，也只是密码学家的纸上游戏。过去两年，ZKML在三个方向上的应用已经有了从概念到原型的实质突破。

场景一：DeFi AI保险库的可验证策略

2024年，Giza团队推出了RockyBot——一个基于ZKML的链上ETH价格预测机器人，运行在StarkNet上。其核心逻辑是：一个链下模型定期对ETH未来价格走势做出预测，同时为每一次预测生成一个零知识证明，证明"这个预测确实是由特定版本、特定权重的模型在特定输入下产生"。链上保险库合约只接受附带有效ZK证明的预测信号，并据此调整仓位。

这个模式的意义不止于"防作弊"。在传统量化保险库里，策略的权重变化通常由多签钱包控制，投资者只能相信策略管理员不会临时更换模型。ZKML把这份信任从"多签人的品德"降级为"数学的正确性"。只要证明通过，保险库就自动执行对应策略，无需人类审批。

当然，RockyBot的实际表现也暴露了一个残酷现实：模型预测准确率本身与是否可验证无关。ZKML能保证"模型A确实输了这批数据"，但无法保证"模型A的预测是对的"。它解决的是过程信任，而非结果正确性。这一点对产品设计者有根本性影响——不能用ZK证明来替代策略的风控与回测，它只是移除了额外的对手方信任假设。

场景二：去中心化预言机的可验证API

预言机是区块链感知链下世界的咽喉，但也是被攻击最多的薄弱环节。2022年至2024年间，Chainlink和Pyth等多条预言机网络都遭遇过不同程度的数据操纵或延迟喂价攻击。ZKML提供了一条补充路径：预言机节点在返回链下数据时，不仅给出数据本身，还附加一段证明，证明"该数据确实由某台预设的ML模型对多个原始数据源进行聚合与清洗后输出"。

这特别适用于需要复杂数据处理的场景——比如从一段新闻文本中提取情绪指标，或从卫星影像中估算某港口货运量。如果不加证明，这些数据发布节点完全可以伪造清洗规则或数据源权重。而ZKML让"清洗过程的逻辑"与"清洗结果的数值"同时上链接受校验。

场景三：AI Agent行为的密码学审计

可能是ZKML最具想象力的方向。2026年初，业内讨论"Crypto × AI"交汇趋势时，一个高频出现的子话题是：当AI Agent拥有钱包、能自主发起交易、甚至参与治理投票时，如何确保它们的行为符合预设规则？

传统软件审计需要访问Agent的源代码与运行时日志，但日志可以被篡改，源代码可以挂羊头卖狗肉。ZKML允许Agent把每一次"感知-推理-决策"过程编码为可验证电路，并定期向链上提交证明。其他参与者不需要审查Agent的私钥或内部状态，只需验证ZK证明即可确认"该Agent确实按照公开声称的策略行事"。

长期来看，这种可审计性是智能体经济（Agent Economy）中不可或缺的基础设施。如果一个贷款Agent声称"我只给抵押率超过150%的地址放贷"，ZKML证明可以确保它没背地里偷偷给关联方开后门。这不是科幻——Giza和Polyhedra在2025年底的演示中，已经展示了小型决策Agent的ZK化原型。

六、真实的瓶颈：为什么千亿参数LLM还远在天边

ZKML的叙事在2025年被炒得很热，但任何严肃的开发者都应该认清当前的技术天花板。

性能瓶颈是最硬的墙。即便是20M参数的小模型，证明时间已经以分钟计、内存以十GB计。如果试图将GPT-2级别的1.5B参数模型完整电路化，约束数量会膨胀到数万亿级别，证明生成时间可能长达数小时乃至数天，内存需求会突破消费级硬件的上限。对于GPT-4或更新的混合专家模型（MoE），问题更加灾难性——稀疏路由和门控机制产生的动态控制流，对静态电路来说是噩梦。

2026年2月，Polyhedra通过EXPchain试图绕过这一瓶颈：它并非证明整个LLM的推理，而是聚焦于模型合规性验证——比如证明"这个输出确实由某个经过政府备案的模型生成"，或者证明"推理结果包含了特定的数字水印"。这是一种聪明的妥协，把ZKML的应用范围从"验证全部计算"收缩到"验证关键属性"，从而将电路规模压缩几个数量级。

量化精度损失也是一个被低估的问题。在视觉和简单分类任务上，INT8量化通常够用，但在自然语言理解与生成任务中，模型对权重精度极为敏感。已有实验表明，把某些LLM层从FP16压缩到INT8后，perplexity会显著上升，输出质量出现明显劣化。而当这些已劣化的结果被进一步塞进有限域电路时，误差会被进一步放大。目前缺乏一个系统性的理论来量化"给定电路规模限制下，最大可容忍的精度损失是多少"。

跨框架的碎片化也让工程团队头疼。EZKL、RISC Zero、Orion的电路表示、量化策略和验证机制互不兼容。一个在EZKL上跑通的模型，迁移到RISC Zero几乎需要重新设计量化方案与电路结构。行业目前缺少一个统一的中间表示层，类似ONNX之于深度学习框架——尽管EZKL以ONNX为起点，但ONNX本身并不包含任何关于"如何高效ZK化"的语义信息。

与替代方案的冷静对比

从上表可以看出，ZKML在"最小信任假设"和"公开可审计性"两个维度上具有不可替代性，但在延迟与资源消耗上明显处于劣势。短期内更现实的架构可能是混合方案——用TEE处理高频、低延迟的批量推理，只在关键决策点生成ZK证明以供公开审计。

七、前沿突破：硬件加速、递归证明与分层验证

瓶颈虽然真实，但攻关方向同样清晰。

硬件加速方面，2024至2025年涌现了Cysic、Ingonyama和Fabric等多家专注于ZKP加速的ASIC/FPGA团队。Ingonyama的ZPU架构针对NTT与MSM（多标量乘法，zkSNARK证明生成的核心瓶颈）做了专用电路优化，初步基准显示证明生成时间可以缩短至原来的1/10到1/20。虽然消费级硬件尚难触及，但云服务商开始提供ZKP专用GPU/FPGA实例——比如AWS对特定型号FPGA的支持、以及多家ZK-focused云服务（如Risc0的Bonsai网络）的上线。

递归证明（Recursive Proofs）与聚合（Aggregation）是另一条关键路径。与其为每次推理生成一个独立证明，不如把一段时间内的多个推理证明递归压缩成一个单一证明，再一次性提交到链上。Halo、Plonky2等框架支持递归组合，可以在保持安全性的前提下，将百个甚至千个独立证明的验证开销压缩到一个证明的量级。这对于AI保险库等日频或更低频的场景极具吸引力。

分层验证则是针对大模型的工程妥协，前文已提到。只验证模型的最后几层输出，或只验证某个注意力头的行为，可以把电路规模从"全模型数十亿参数"降到"数百万至数千万参数"的可处理范围。EXPchain的策略本质上就是这种思路的商业化包装。当然，这种分层验证需要额外的安全性论证——你需要确信未经验证的前几层不会引入后门或对抗性扰动。

下面的时间线图展示了ZKML从学术研究到生产基建的演进脉络，也可以作为判断当前所处阶段的粗糙坐标：

图4：ZKML技术成熟度演进路线

gantt
    title ZKML 技术成熟度演进时间线
    dateFormat  YYYY-MM
    section 学术萌芽
    第一篇ZKML概念论文 :2020-01, 2022-06
    早期小规模验证（决策树/XGBoost） :2022-06, 2023-06
    section 框架涌现
    EZKL / Orion / Giza 等开源工具出现 :2023-03, 2024-06
    ONNX 导入与工程化工具链成型 :2023-09, 2024-12
    section 基准爆发
    Modulus Labs 系统性能评测发布 :2024-03, 2024-12
    ZKML 在 DeFi / 游戏等场景的原型落地 :2024-06, 2025-06
    section 生产基建
    EXPchain 等可验证 AI 专用链上线 :2025-06, 2026-06
    递归证明与硬件加速开始商用 :2025-12, 2026-12
    section 规模化挑战
    千亿参数 LLM 的 ZK 验证仍处于研究阶段 :2026-06, 2027-12

八、结语：2026年，ZKML为什么重要

回望过去五年的轨迹，ZKML的演进速度超出了许多密码学家的早期预期。从2020年Daniel Kang等人的开创性论文，到2023年首个可运行的小模型ZK化原型，再到2025年EZKL等框架将证明延迟压到分钟级——这条曲线的斜率正在变陡。

但更重要的问题不是"ZKML能不能更快"，而是"为什么必须这么做"。

因为在AI能力渗透到链上金融、去中心化治理与私人数据处理的每一个角落时，我们无法再依赖传统意义上的机构背书。一个声称自己运行公平信贷评估模型的DeFi协议，一个号称用AI优化国库支出的DAO，一个号称保护隐私的医疗诊断Agent——它们都需要某种超越"截图自证"或"多签担保"的信任机制。ZKML不是唯一的选项，但它是目前唯一能在密码学最小假设下实现公开可验证与信息零泄露双重目标的路线。

2026年之所以被称为拐点，不是因为LLM能够被完整ZK验证了——那还差得很远。而是因为行业终于开始围绕ZKML构建专用基础设施：从专用链（EXPchain）、到证明市场（Bonsai）、再到硬件加速云实例。这意味着ZKML从实验室玩具变成了可以被产品团队正常调用的云API。

当然，前路依然漫长。量化精度、电路规模、跨框架兼容性、以及证明成本经济账，每一个都是硬骨头。但至少，开发者现在有了一个明确的路线图：先用EZKL跑通最小可行模型，再在生产中引入分层验证或TEE混合架构，同时跟踪硬件加速与递归证明的商用进展，逐步扩大可验证计算的边界。

对于关注密码学与AI交叉领域的研究者来说，这片土地的表层已经被开垦，但深层的问题——比如大模型电路化的理论极限、最优量化与证明系统的联合优化、以及密码学与机器学习理论的交叉证明——仍然充满未知。机会恰恰在这里。

参考与延伸阅读

1. Daniel Kang, Tatsunori Hashimoto, Ion Stoica, and Yi Sun. "Scaling up Trustless DNN Inference with Zero-Knowledge Proofs." arXiv preprint, 2022. —— ZKML早期奠基性工作之一，验证了在现有硬件上对小型DNN生成零知识证明的可行性。
2. PANews 研究团队. "专研四十载，2万字回顾零知识证明技术发展里程碑." 2024. —— 中文世界最完整的ZKP技术史综述，涵盖从Goldwasser-Micali-Rackoff到zkSNARKs/STARKs再到ZKML的完整脉络。
3. Extropy Academy. "The zkML Singularity: A Comprehensive Analysis of the 2025 Singularity." 2025. —— 对2025年ZKML行业拐点的系统性分析，涵盖框架演进与商业机会。
4. EZKL Blog. "Benchmarking ZKML Frameworks." 2025 Q2. —— EZKL团队发布的跨框架基准测试报告，包含EZKL、Orion、RISC Zero的详细性能数据对比。
5. 界面新闻. "ZKML技术：迈向可验证人工智能的未来." 2025. —— 中文技术视角对ZKML商用场景的深度报道。
6. ABMedia. "Polyhedra推出EXPchain，解析AI模型上链必要性." 2025. —— 介绍EXPchain作为ZKML专用Layer 1的定位与技术取舍。
7. Springer ACM. "A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning." 2024. —— 2017-2024年间ZKML学术论文的系统综述，适合研究者入门。
8. Kordan Ou (Twitter/X). "2026年看Crypto × AI的七大交汇点." 2026. —— 宏观战略视角下对Crypto与AI融合趋势的系统性梳理，ZKML被定位为核心基建之一。

本文基于公开学术文献、开源框架文档与行业报告整理而成，技术细节随框架版本演进可能有所变化，建议读者直接参考各框架官方文档以获取最新信息。