Chainfeeds 导读：
用户应当始终被赋权，并尽可能保持对系统的真实控制权。
文章来源：
https://vitalik.eth.limo/general/2026/04/02/secure_llms.html
文章作者：
Vitalik Buterin
观点：
Vitalik Buterin：最终来看，本地 AI 的能力仍然远远不足，无法完成我关心的许多重要任务。确实存在一类有边界的任务，例如转录、总结、翻译、拼写与语法检查，这些任务即使在性能远低于我测试设备的笔记本甚至手机上，本地 AI 也已经能够很好完成。但还有另一类任务，会持续从「更强的智能」中显著受益，而这些任务目前本地 AI 还远远无法胜任。对我来说，写代码是一个典型例子，复杂的智力工作也是如此。你的设备越弱，本地大模型能胜任的事情就越少。理想情况下，我希望看到一种多层防御的远程大模型使用方式，尽可能减少你暴露的个人信息。这既包括隐藏请求的来源，也包括隐藏请求的内容：1）隐私保护的 ZK API 调用：让你可以在服务器不知道你是谁、甚至无法判断两次请求是否来自同一用户的情况下调用 API。如今去匿名化已经非常容易，因此必须让每次查询彼此不可关联。这可以通过零知识密码学实现；例如我与 Davide 提出的 ZK-API 方案，以及正在构建类似系统的 OpenAnonymity 项目。2）混合网络（mixnets）：通过打乱网络路径，使服务器无法通过 IP 地址将某个请求与其前后请求关联起来。3）在 TEE 中进行推理：可信执行环境（TEE）是一类硬件，可以确保除了程序输出之外没有任何信息泄露，并且可以对外提供加密证明，说明当前运行的程序是什么。因此，你可以验证硬件证明，确认它只是在执行「解密数据→运行大模型推理→加密输出」的流程，而不会在中间进行日志记录。当然，TEE 也经常被攻破，因此不能视为绝对安全；但只要你在本地验证其证明签名，它依然可以显著降低数据泄露风险。ZK-API 与混合网络的组合最初是为隐私保护的大模型推理设计的，但它实际上适用于几乎所有对外部世界的交互。搜索引擎查询会泄露大量个人信息，你也可能需要调用各种 API。如今很多 API 是免费的，但随着 AI 使用量增长带来的压力，它们可能逐渐转为付费。在这种背景下，推动所有付费 API 采用 ZK-API，或者至少提供一个易用的 ZK-API 代理，是合理的方向。如果 API 提供方担心滥用，ZK-API 方案中也包含惩罚机制（slashing），可以对滥用请求进行处罚；如果需要，这些规则甚至可以由事先约定的大模型来裁定，并通过链上智能合约执行。同时，让混合网络成为默认的互联网通信方式，也同样重要。
内容来源
