四十年前,Shafi Goldwasser、Silvio Micali 与 Charles Rackoff 提出了一个看似违反直觉的问题:能否在不泄露任何额外信息的前提下,让别人相信你知道某个秘密,或者相信某个陈述是真的?
这个问题的答案,催生了密码学史上最优雅的构造之一——零知识证明(Zero-Knowledge Proof, ZKP)。
第一部分:零知识证明的数学基础
1. 起源:1985 年的奠基性论文
1985 年,Shafi Goldwasser、Silvio Micali 与 Charles Rackoff 在 STOC 发表了一篇改变密码学走向的论文:《The Knowledge Complexity of Interactive Proof Systems》。
这篇论文首次系统性地形式化了一个问题:在一个交互式证明系统(Interactive Proof System)中,证明者(Prover,记作 )如何说服验证者(Verifier,记作 )相信某个陈述是真的,同时不泄露任何“使该陈述为真”的额外信息?
这个看似矛盾的目标——“让对方相信,但又不告诉对方秘密本身”——后来被证明不仅在数学上可行,而且在工程上极具价值。Goldwasser 和 Micali 也因在概率证明、密码学与复杂性理论方面的奠基性贡献获得了 2012 年图灵奖。
2. 形式化定义
设 是一个语言(language), 是一个陈述(statement), 是 的一个证据(witness)。一个针对 的交互式证明协议 通常需要满足以下三条核心性质:
2.1 完备性(Completeness)
若 且证明者 诚实执行协议,则验证者 应以极高概率接受:
其中 表示可忽略函数, 为安全参数。
直观含义:
真命题在诚实执行协议时,会以极高概率被验证者接受。
2.2 可靠性(Soundness)
若 ,则对于作弊证明者 ,验证者 被欺骗并接受的概率应当非常低:
直观含义:
假命题几乎不可能蒙混过关。
需要注意的是,在经典交互式证明系统中,可靠性可以是信息论意义上的;而在现代工程中更常见的 zk-SNARK、zk-STARK 等系统,很多属于 argument system,其可靠性通常是计算意义上的,即只要求任何多项式时间的攻击者难以伪造证明。
2.3 零知识性(Zero-Knowledge)
这是最微妙、也最核心的性质。
零知识性要求:验证者从协议交互中学到的内容,不应多于“这个陈述是真的”这一事实本身。
形式化表达借助“模拟器”(Simulator)的概念:存在一个概率多项式时间模拟器 ,对任意可能作弊的验证者 , 能够在不访问证据 的情况下,生成一个与真实协议交互分布不可区分的“伪造记录”:
其中 表示计算不可区分(computationally indistinguishable)。
直观含义:
如果一段协议交互记录可以在不知道秘密的情况下被模拟出来,那么这段真实交互本身就不应泄露关于秘密的额外信息。否则,模拟器在没有秘密的情况下生成相同分布记录这件事就会变得不可能。
根据不可区分强度,零知识性还可以细分为:
- 完美零知识(Perfect Zero-Knowledge):真实分布与模拟分布完全相同;
- 统计零知识(Statistical Zero-Knowledge):两者统计距离可忽略;
- 计算零知识(Computational Zero-Knowledge):任何多项式时间敌手都无法区分两者。
3. 直觉理解:Ali Baba 洞穴
在进入更数学化的协议之前,经典的 “Ali Baba 洞穴” 是最广为流传的 ZKP 直觉说明之一。这个例子由 Jean-Jacques Quisquater 等人在 1989 年提出,用来解释零知识协议的核心思想。
入口
│
─────┴─────
A B
\ /
\ /
\ /
[魔法门]
(需要密语)
假设 Peggy(证明者)想让 Victor(验证者)相信她知道打开魔法门的密语,但不想告诉他密语本身。协议如下:
- Victor 在洞口外等候,Peggy 随机选择 A 或 B 进入;
- Victor 走到分叉口,随机喊出“从 A 出来”或“从 B 出来”;
- 如果 Peggy 真的知道密语,无论 Victor 喊哪边,她都能走到正确出口;
- 如果 Peggy 不知道密语,她只能祈祷 Victor 恰好喊中她原本进入的那一边——这件事发生的概率是 50%;
- 重复 次后,作弊者连续成功的概率为 。当 时,欺骗概率已经低于 。
这个例子直观展示了 ZKP 的三大性质:
- 诚实的 Peggy 可以通过验证,体现完备性;
- 不知道密语的 Peggy 很难连续骗过 Victor,体现可靠性;
- Victor 始终不知道密语是什么,体现零知识性。
4. 经典协议:Schnorr 的离散对数知识证明
Ali Baba 洞穴适合理解直觉,而 Schnorr 协议则是最经典、最具工程影响力的 Sigma 协议之一。它也是理解现代 Schnorr-style 签名、身份认证,以及部分非交互式证明系统的重要入口。
4.1 设定
设 是素数阶 的循环群, 是 的生成元。证明者 知道秘密:
公开信息是:
希望向 证明:
我知道一个秘密 ,使得 成立。
但 不希望泄露 本身。
这个问题的安全性依赖于离散对数问题(Discrete Logarithm Problem, DLP)的困难性:已知 和 ,求出 在计算上是困难的。
4.2 协议流程:交互式三步
Step 1:Commitment(承诺)
证明者 随机选取:
计算并发送:
Step 2:Challenge(挑战)
验证者 随机选取:
并发送给 。
Step 3:Response(应答)
证明者 计算:
并发送 给 。
Step 4:Verify(验证)
验证者 检查:
如果等式成立,则接受;否则拒绝。
4.3 三大性质说明
完备性
若 诚实执行协议,则:
因此:
验证等式成立。
可靠性:基于知识抽取器
Schnorr 协议具有一种更强的性质,通常称为知识可靠性(knowledge soundness)或特殊可靠性(special soundness)。
假设某个作弊证明者 对同一个承诺 ,能够回答两个不同挑战 ,并分别给出 ,使得:
两式相除可得:
由于:
所以:
于是可以抽取出:
由于 为素数,且 ,因此 在 中存在。
这意味着:如果某个证明者能在同一个承诺下应对多个不同挑战,那么我们就可以从它的回答中抽取出秘密 。这就是 Schnorr 协议知识可靠性的核心。
零知识性:构造模拟器
对于诚实验证者,Schnorr 协议满足诚实验证者零知识(Honest-Verifier Zero-Knowledge, HVZK)。
我们可以构造一个不知道 的模拟器 :
- 随机选取 和 ;
- 计算:
- 输出记录:
验证时有:
因此验证等式必然成立。
同时,模拟生成的 与真实协议中的 在分布上相同。因为真实协议中的 是均匀随机的,模拟协议中的 和 也是均匀随机的。
这说明:即使模拟器不知道秘密 ,也能生成与真实交互不可区分的记录。
因此,验证者从真实交互中没有获得关于 的额外信息。
需要注意的是,上述证明展示的是诚实验证者零知识。如果要面对任意恶意验证者,则通常需要更完整的模拟技术,例如回绕(rewinding)等方法。
5. 从交互到非交互:Fiat-Shamir 启发式
Schnorr 协议本身是交互式的,但在区块链、数字签名、公开验证等场景中,证明者和验证者往往无法实时交互。
1986 年,Fiat 与 Shamir 提出了一个极具影响力的启发式变换:
用密码学哈希函数替代验证者发出的随机挑战。
以 Schnorr 协议为例,可以把挑战 替换为:
其中 是公开的密码学哈希函数, 是待绑定的消息。
这样,证明者就可以独自生成完整证明 ,任何验证者都可以重新计算哈希值并验证等式。
Fiat-Shamir 变换是 Schnorr-style 签名、部分非交互式证明系统,以及大量区块链可验证计算协议中的核心思想之一。它通常在随机预言模型(Random Oracle Model, ROM)下证明安全。虽然 ROM 是一个理想化模型,但在实际工程中,SHA-256、SHA-3 等哈希函数经常被视为随机预言的合理近似。
6. 现代 ZKP 家族:三类主流构造对比
Schnorr 协议适合证明“我知道某个离散对数”这类特定陈述。过去十多年 ZKP 领域真正重要的突破,是出现了可以对更复杂计算,甚至任意 NP 陈述进行证明的通用构造。
下面是三类常见 ZKP 构造的简化对比:
| 构造 | 全称 | 证明大小 | 验证时间 | 可信设置 | 后量子安全 |
|---|---|---|---|---|---|
| zk-SNARK | Succinct Non-interactive Argument of Knowledge | 极小,Groth16 证明约为常数大小(BN254 曲线上约 128–192 字节),PLONK 约数百字节 | 很快 | 许多经典方案需要,不同方案要求不同 | 通常不具备 |
| zk-STARK | Scalable Transparent Argument of Knowledge | 较大,常见为几十 KB 到数百 KB 量级 | 较快 | 不需要可信设置 | 通常被认为具备更强后量子潜力 |
| Bulletproofs | — | 中等,通常为 | 相对较慢 | 不需要可信设置 | 通常不具备 |
zk-SNARK
zk-SNARK 以证明短、验证快著称。Groth16、PLONK、Marlin、Halo2 等都属于广义上的 SNARK 系统。
它们非常适合链上验证、Layer 2 扩容、隐私交易等场景。
不过,不同 SNARK 对可信设置的要求不同:Groth16 通常需要电路特定可信设置,PLONK 一类方案则更多采用通用或可更新设置。
zk-STARK
zk-STARK 的核心优势是透明性(transparent),即不需要可信设置。它通常基于哈希函数和多项式承诺等技术构建,因此也被认为具备更强的后量子安全潜力。
代价是证明体积通常更大,证明生成和验证也需要结合具体系统进行优化。
Bulletproofs
Bulletproofs 不需要可信设置,证明大小较短,常用于范围证明(range proof),例如证明某个金额在合法范围内,但不泄露具体金额。
它在隐私加密货币、机密交易等方向有重要应用,但验证成本相对较高,不一定适合所有大规模链上场景。
第二部分:ZKP 走出学术圈——从理论到工程的跨越
在早期几十年里,ZKP 更多出现在密码学会议、理论计算机科学论文和少量身份认证方案中。真正让它被更大范围的工程社区关注,主要来自过去十年的三波浪潮。
1. 第一波:加密货币的隐私诉求
Zcash 在 2016 年上线,是最早大规模采用 zk-SNARK 的公链项目之一。它利用零知识证明隐藏交易发送方、接收方和金额,在不公开交易细节的情况下证明交易合法。
这让 ZKP 第一次从学术系统走向大规模公开网络,也让更多工程师意识到:
零知识证明不只是理论,它可以真正支撑一个复杂系统的安全运行。
2. 第二波:以太坊 Layer 2 与可扩展性
随后,ZKP 在区块链世界的定位发生了变化。
它不再只是隐私工具,也开始成为可验证计算工具。
以 zkRollup 为例,系统可以把大量交易放到链下执行,然后向以太坊主链提交一份简洁证明,证明:
这批交易的状态转换是合法的。
这样,主链不必重新执行所有交易,只需要验证证明即可。
zkSync、Starknet、Scroll、Polygon zkEVM 等项目,都是这一方向的代表。
这一阶段,ZKP 的价值从“隐藏信息”扩展到了“压缩计算”和“验证计算”。
3. 第三波:AI 与数据主权
AI Agent 的出现,让 ZKP 面临一个新的场景。
过去,ZKP 主要服务于链上资产、交易隐私和可扩展性。
而在 AI Agent 时代,智能体开始接触用户越来越多的敏感数据:
- 邮件;
- 照片;
- 聊天记录;
- 健康数据;
- 财务信息;
- 工作文档;
- 本地文件系统;
- 第三方账号授权。
于是,一个新的问题浮现出来:
如何在不暴露原始数据的情况下,证明某项计算确实发生了,而且结果可信?
这正是 ZKP 在 AI 时代重新变得重要的原因。
第三部分:AI Agent 时代,为什么我们需要 ZKP?
1. 问题一:数据可用,但不可见
假设你希望一个第三方 Skill 帮你分析健康数据,但你不想把原始健康数据交给它。
传统方案通常只有两个选择:
- 放弃这个功能;
- 把数据交出去,然后相信对方不会滥用。
但 ZKP 提供了另一种思路:
数据可以在本地完成计算,外部验证者只验证计算结果是否满足某个声明,而不直接接触原始数据。
需要特别强调的是:ZKP 本身并不等同于“对加密数据做计算”。
如果要直接在密文上计算,通常需要结合全同态加密(FHE)、安全多方计算(MPC)或可信执行环境(TEE)等技术。
ZKP 的核心作用是:
证明某个私有数据满足某个公开关系,或者证明某个计算被正确执行,而不泄露私有数据本身。
2. 问题二:可验证推理
当 AI Agent 替你完成一项重要判断时,例如:
“本月预算审核通过。”
用户可能会继续追问:
- 这个结论真的是基于我授权的数据吗?
- 它是否使用了我指定的模型?
- 中间有没有被篡改?
- 是否调用了不该调用的外部服务?
- 是否访问了声明之外的本地文件?
传统方案里,用户通常只能选择相信服务商,或者相信本地代码没有被篡改。
ZKP 则提供了一个更进一步的方向:
让系统对某些关键计算步骤生成证明,使外部验证者可以确认:
这个输出确实来自某个被声明的输入、模型或规则计算过程。
这就是 zkML(Zero-Knowledge Machine Learning)所关注的问题。
不过,必须客观看待当前阶段的工程现实:
对小模型、规则模型、压缩模型或特定计算图生成 ZK proof,已经有不少实验和项目在推进;但对大规模 LLM 的完整端到端推理生成证明,成本仍然很高,还没有到普通消费级设备实时无感运行的阶段。
因此,短期内更现实的 zkML 落地方式,不是证明整个大模型推理过程,而是证明其中更小、更关键、更结构化的部分,例如:
- 某个分类器确实运行过;
- 某个风险评分确实按规则计算;
- 某个摘要结果确实来自已承诺的数据集合;
- 某个权限判断确实符合访问控制策略;
- 某个小模型推理输出确实对应指定输入。
3. 问题三:身份与授权
AI Agent 经常需要代表用户访问外部服务,例如:
- 读取日程;
- 查询邮件;
- 调用 API;
- 同步本地文件;
- 操作第三方应用。
传统做法通常依赖 OAuth token、API key 或长期凭证。
但这些凭证一旦泄露,就可能带来严重风险。
ZKP 可以在部分场景中提供新的授权方式:
用户不直接暴露身份或长期密钥,而是证明自己拥有某个属性、某项权限或某个私钥。
例如:
- 证明“我年满 18 岁”,但不暴露生日;
- 证明“我是某个服务的订阅用户”,但不暴露完整账号;
- 证明“我持有某台设备绑定的私钥”,但不传输私钥本身;
- 证明“我拥有某个组织的访问权限”,但不泄露组织内部身份细节。
这类能力不会完全取代 OAuth,但可以在一些高隐私、高安全要求的场景中,作为传统授权体系的重要补充。
第四部分:为什么本地智能设备是 ZKP 的重要落地场景?
ZKP 的价值很清晰,但它也有一个现实问题:
生成证明的成本通常远高于直接执行计算。
不同证明系统、不同计算规模、不同硬件条件下,ZKP 的开销差异非常大。
在一些复杂场景中,生成证明可能比直接执行计算慢几个数量级。
这意味着:
- 如果所有证明都放在云端生成,用户仍然需要把数据上传到云端;
- 如果所有证明都放在普通消费级设备上生成,算力和功耗可能成为瓶颈;
- 如果试图对完整大模型推理生成证明,当前阶段成本仍然较高。
因此,更现实的方向是:
在云边端协同架构中,把 ZKP 用在关键节点,而不是试图证明所有计算。
本地智能设备的优势在于:
- 数据更靠近用户;
- 设备可以长期在线;
- 可以结合本地加密、本地权限控制和本地审计;
- 可以在用户无感或低感知的后台任务中生成部分证明;
- 可以只向云端上传必要的证明、摘要或脱敏数据,而不是上传完整原始数据。
这也是本地智能设备与 ZKP 结合的真正意义:
ZKP 不是替代所有安全机制,而是成为本地智能系统中的一层“可验证信任层”。
它应该与以下能力共同工作:
- 本地数据加密;
- 代码签名;
- 权限沙箱;
- 可信执行日志;
- 哈希承诺;
- 设备密钥;
- 远程证明;
- 云端验证;
- 用户授权策略。
第五部分:ZKP 在脑花 AI NPC 这类本地智能设备上的实现
看到有关报道,端脑的脑花 AI NPC 把 ZKP 引入了本地智能设备,其价值不应被理解为“所有 AI 计算都用 ZKP 证明一遍”,而应被理解为:
在涉及隐私、授权、审计和跨端协同时,对关键计算过程生成可验证证明。
这类设备面临的工程约束包括:
| 约束维度 | 工程要求 |
|---|---|
| 证明生成时间 | 前台交互尽量低延迟,后台任务可接受更长时间 |
| 证明体积 | 适合在本地设备、APP 与云端之间传输 |
| 可信设置 | 消费级场景中应尽量降低部署复杂度 |
| 安全模型 | 明确证明什么,不证明什么 |
| 硬件兼容 | 结合 CPU、GPU、NPU 或其他加速能力进行评估 |
| 用户体验 | 不应让用户感受到明显卡顿 |
| 可审计性 | 关键日志、代码版本和权限边界应可追溯 |
从技术选型上看,更稳妥的方向不是押注单一证明系统,而是采用混合架构:
- 用 哈希承诺 绑定本地数据;
- 用 数字签名 证明设备身份与代码版本;
- 用 权限沙箱 限制 Skill 的资源访问;
- 用 审计日志 记录关键操作;
- 用 Sigma 协议 / Schnorr-style 协议 处理轻量身份与授权证明;
- 在关键计算场景中引入 zk-SNARK、zk-STARK 或 Bulletproofs;
- 对复杂 AI 推理,只证明关键摘要、规则计算、小模型推理或中间结果,而不是一开始就证明完整大模型推理。
这种组合更符合当前 ZKP 的工程成熟度,也更适合本地智能设备逐步落地。
场景 A:云端协同任务中的数据脱敏证明
本地智能设备不意味着完全不使用云端。
很多复杂任务仍然需要云端大模型、知识库、搜索服务或更强算力。
关键问题在于:
云端需要参与任务,但云端不一定需要看到原始数据。
假设用户让设备处理一份包含敏感信息的文档。
设备可以先在本地完成脱敏,例如:
- 姓名替换为占位符;
- 手机号只保留后四位;
- 身份证号转换为哈希或区间属性;
- 金额转换为范围;
- 地址只保留城市级别;
- 具体日期转换为月份或季度。
然后,本地设备可以生成一份证明,证明:
上传到云端的数据确实由本地原始数据经过某个公开脱敏函数生成。
用更形式化的方式表达就是:
其中:
- 是本地原始数据;
- 是上传到云端的脱敏数据;
- 是公开的脱敏函数;
- 是对原始数据的承诺。
云端不需要看到 ,只需要验证:
- 这份脱敏数据确实由某个已承诺原始数据生成;
- 脱敏函数按声明执行;
- 上传内容满足约定格式。
这可以让“数据主权”从单纯依赖信任,部分转向“代码签名、执行审计与数学证明共同验证”。
当然,这里也不能过度承诺。
ZKP 可以证明“某个脱敏函数被正确执行”,但不能天然证明“没有任何语义信息泄露”。真正的数据安全还需要结合脱敏策略、数据最小化原则和安全审计。
场景 B:身份与授权的零泄露验证
当用户通过 Lucy APP 远程调用脑花 AI NPC 这类设备时,系统需要确认:
当前 APP 操作者确实拥有调用这台设备的权限。
传统方案通常依赖长期 token 或云端会话。
但长期 token 一旦泄露,就可能被重放或滥用。
一种更安全的思路是使用 Schnorr-style 的 Sigma 协议,让 APP 证明:
我持有与这台设备绑定的私钥。
但 APP 不需要把私钥发给设备,设备也不需要保存可重放的明文凭证。
基本流程可以是:
- 设备保存 APP 绑定公钥;
- APP 本地持有对应私钥;
- 设备发起随机挑战;
- APP 生成响应;
- 设备验证响应是否与绑定公钥匹配;
- 验证通过后才允许执行远程操作。
这个过程的优势在于:
- 私钥不出 APP;
- 每次挑战不同,降低重放风险;
- 设备不需要依赖长期明文 token;
- 可以与设备绑定、时间戳、权限范围结合使用。
但这里的前提是:
设备已经安全保存了 APP 的公钥或绑定凭证。
ZKP 解决的是“证明我持有某个秘密而不泄露秘密”,并不凭空解决身份发行、设备绑定和权限管理本身。
第六部分:未来展望
ZKP 从 1985 年的理论构造,到 2016 年前后在加密货币中获得大规模关注,再到今天逐渐进入 AI、数据安全和本地智能设备语境,已经走过了接近四十年。
接下来 5–10 年,我认为值得关注的方向主要有四个。
方向一:zkML 的性能突破
zkML 的目标是让机器学习推理结果变得可验证。
但当前阶段,对大规模神经网络,尤其是大语言模型的完整推理过程生成证明,成本仍然很高。
更现实的路线是从小模型、规则模型、特定算子和关键中间结果开始。
未来,随着以下方向发展,zkML 的可用性会逐步提升:
- 更高效的 arithmetization;
- 更适合神经网络的证明系统;
- GPU、FPGA、ASIC 等硬件加速;
- 面向模型结构的专用优化;
- 递归证明和证明聚合;
- 与模型压缩、量化和蒸馏结合。
短期内,zkML 更可能先在金融风控、身份验证、链上 AI、隐私评分、小模型推理等场景落地,而不是直接证明完整大模型对话过程。
方向二:递归 ZKP 与证明聚合
递归 ZKP 的核心思想是:
用一份证明来证明另一份证明已经被正确验证。
这听起来有点绕,但它非常重要。
如果一个系统每天产生 1000 份证明,验证者逐一验证成本会很高。
递归证明可以把这些证明聚合起来,生成一份更高层级的证明:
我已经验证过这 1000 份证明,它们都是合法的。
这对区块链扩容、批量审计、AI Agent 日志压缩、本地设备证明上传等场景都非常重要。
对于本地智能设备来说,递归 ZKP 未来可能让设备把大量本地操作压缩成周期性证明,例如:
- 今日所有远程调用均符合权限策略;
- 本周所有云端协同任务均完成脱敏;
- 某个 Skill 在一段时间内没有越权访问;
- 某批健康数据统计结果均来自已承诺数据源。
这会让个人 AI 设备从“只会执行任务”,进一步变成“可以自证清白的智能体”。
方向三:端侧 ZKP 与 AI Agent 融合
AI Agent 的核心矛盾之一是:
它越有用,就越需要接触用户的敏感数据;
它越接触敏感数据,用户就越需要验证它没有滥用数据。
本地智能设备可以缓解这个矛盾,因为数据可以留在本地。
但“数据留在本地”本身还不够,因为用户仍然需要知道:
- 哪个 Skill 访问了数据?
- 访问了哪些字段?
- 是否上传了数据?
- 是否调用了云端模型?
- 是否遵守了用户授权?
- 生成的结论是否来自正确计算?
ZKP 在这里的价值,就是把一部分“相信系统没有作恶”转化为“验证系统确实按规则执行”。
这意味着,未来的个人 AI 基础设施可能不只是由模型、算力和交互界面组成,还会包含一层“可验证信任层”。
本地智能设备,尤其是像脑花 AI NPC 这类云边端协同设备,正好提供了一个新的工程载体:
- 数据在本地;
- 权限在本地;
- 日志在本地;
- 执行环境在本地;
- 证明可以在本地或边缘侧生成;
- 云端只验证必要证明。
这可能是 ZKP 从区块链走向个人 AI 设备的重要路径。
方向四:标准化与监管友好
ZKP 不应被简单理解为“反监管工具”。
更准确地说,它是一种“可配置的隐私与合规边界工具”。
它既可以实现强匿名,也可以实现选择性披露。
例如:
- 用户可以证明自己满足某个年龄条件,但不暴露生日;
- 企业可以证明某项财务指标满足监管要求,但不公开完整账本;
- 医疗机构可以证明某项统计结果来自真实病例数据,但不泄露患者隐私;
- AI 系统可以证明某次调用符合授权策略,但不暴露全部原始内容。
因此,ZKP 未来更大的机会不一定在“完全匿名”,而在“最小披露”。
这正是金融、医疗、教育、政务和企业数据治理最需要的能力:
能证明该证明的,能隐藏该隐藏的。
结语:从 1985 到 AI Agent 时代,一个优雅构造的长尾
回到开头那个看似矛盾的问题:
能否在不泄露额外信息的前提下,让别人相信你知道某个秘密,或者相信某个陈述是真的?
四十年前,密码学给出了数学上的答案:
可以。
十年前,区块链给出了工程上的答案:
可以,而且可以部署在公开网络上。
今天,AI Agent 和本地智能设备正在提出新的问题:
当 AI 开始处理我们的邮件、照片、健康数据、财务信息和工作文档时,我们能否既获得智能服务,又保留数据主权?
ZKP 不是这个问题的唯一答案,也不应该被神化为解决所有安全问题的银弹。
它无法替代加密、沙箱、权限控制、代码审计、可信硬件和安全工程。
但它提供了一种极其重要的新能力:
让系统不仅能执行任务,还能证明自己按规则执行了任务。
这也是 ZKP 在 AI Agent 时代重新变得重要的原因。
当本地智能设备逐渐成为个人 AI 的入口,ZKP 最应该从“区块链世界的隐私工具”,演化为“个人 AI 基础设施的信任层”。
这不是终点,而是一个新阶段的起点。
参考文献与延伸阅读
- Goldwasser, S., Micali, S., & Rackoff, C. (1985). The Knowledge Complexity of Interactive Proof Systems. STOC ’85.
- Schnorr, C. P. (1991). Efficient Signature Generation by Smart Cards. Journal of Cryptology.
- Fiat, A., & Shamir, A. (1986). How to Prove Yourself: Practical Solutions to Identification and Signature Problems. CRYPTO ’86.
- Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2018). Scalable, Transparent, and Post-Quantum Secure Computational Integrity.
- Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., & Maxwell, G. (2018). Bulletproofs: Short Proofs for Confidential Transactions and More.