当AI Agent获得链上执行权：谁来验证它看到的信息与发出的指令？

一、KelpDAO 事故暴露了什么

2026 年 4 月 18 日，KelpDAO 的 rsETH 跨链桥遭到攻击，116,500 枚 rsETH 被异常释放，事发时价值约 2.92 亿美元。LayerZero 的事故报告显示，攻击者通过社会工程获取开发者会话密钥，污染了 LayerZero Labs DVN 所依赖的内部 RPC，并以拒绝服务攻击压制外部 RPC，使签名服务依据错误数据为伪造消息出具证明。KelpDAO 当时把验证路径从 2-of-2 改成了 1-of-1 DVN。唯一指定的 DVN 一旦出具错误证明，系统便不再需要第二个独立 DVN 对同一条消息进行交叉验证。CrowdStrike 与 Mandiant 以高置信将事件归因于朝鲜相关的 TraderTraitor（UNC4899）。

这类事故不是孤例。许多链上重大安全事件，问题往往不出在密码学假设本身被推翻，而是出在密钥控制、数据来源、验证者配置、协议实现和运维权限这些环节------系统不仅要回答「这个签名是否有效」，还要回答「谁有权签、依据什么信息签，以及签名所对应的状态是否真实发生」。

越来越多 AI Agent 正通过智能账户、策略钱包或受限签名服务获得链上执行能力。一次有效签名只能证明某个授权路径被调用了，证明不了 Agent 依据的数据可靠、决策符合既定策略，或者这笔交易本就该在此刻发生。验证的对象，正在从「签名真伪」扩展到「输入、决策与执行是否一致」。

二、现有方案解决了什么，又留下了什么

现有的几套方案分别解决了一部分信任问题，也各自把剩下的信任，寄托在不同的角色身上：

预言机与争议裁决：Polymarket 的市场结果先由参与者提出，只有在挑战期内遭到质疑，才会进入 UMA 的代币持有者投票裁决。问题不在于「没有复核」，而在于复核是否可靠------当规则含糊、现实事件存在多种解释，或者投票权集中于少数地址时，系统实际上是把「谁来定义事实」的问题，交给了另一套治理结构。

跨链桥多签与 DVN：两者实现方式不同，但都要求应用方明确配置验证者集合和阈值。KelpDAO 把路径配置成 1-of-1 DVN 后，整条验证路径便依赖于单一验证服务；而该服务所依赖的数据源和故障应对机制，又可能形成下一层单点。

MPC 托管：门限签名的卖点是密钥不会完整存在于一处，但密码学上的分片，不会自动带来组织层面的权力分散。据 Multichain 团队当时披露，创始人被中国警方拘留后，团队随即失去了对相关 MPC 节点服务器的访问权限，这些服务器运行在创始人的个人云账户下。云账户、运维权限和应急响应一旦集中在一个人身上，MPC 的门限设计仍可能留下组织层面的单点。

TEE：可信执行环境能够隔离代码和敏感数据，但它没有消除信任，只是改变了信任落点。硬件根信任和微码更新通常依赖芯片厂商，enclave 代码、升级权限与认证策略则可能由项目方或运营方控制。TEE 可以保护计算过程，却不能自动分散这些治理权限。

这些方案的故障模式并不相同，却指向同一类问题：白皮书里写下的门限和去中心化，只有真正落实到数据源、账户权限、升级密钥和治理流程里，才能构成真实的安全边界。

三、CRVA：重新设计验证权的分配方式

DeepSafe 于 2025 年由 Bool Network 更名而来。CRVA 延续了 Bool Network 相关研究者在 2022 年提出的技术思路。相关论文发表于 IEEE Transactions on Information Forensics and Security（IEEE TIFS，Document ID 9903072），提出了一种基于「演化中的隐藏委员会」（evolving hidden committee）的跨链公证平台。

具体做法是：节点通过 Ring-VRF 参与随机抽选，中选者提交证明和临时公钥，外部观察者能验证其资格，却难以识别其长期身份。中选的临时委员会随后通过门限 MPC 共同签名，任何单一节点都无法独立产出结果。密钥管理等关键流程按论文设计运行在 TEE（以 Intel SGX 为例）中，目的是降低主机运营方读取或篡改密钥份额的可能性。委员会还会按 epoch 轮换，新一届通过可验证的密钥交接获得新份额，旧份额随之失效，具体轮换周期由实际网络参数决定。

项目方还希望借助 TEE 隐藏委员会的工作状态，让节点运营者难以判断自己的节点是否参与了某次验证。这一目标能实现到什么程度，取决于现网代码、远程认证、主机侧元数据与侧信道防护，不是「用了 TEE」就能自动成立的结论。

但这些机制解决的是「由谁验证、如何安全地共同出具结果」，并不自动定义「什么结果才是正确的」。放到 AI Agent 场景里，委员会依然要依据预先设定的策略、数据源和可执行的判断规则去下结论------如果这套规则本身有问题、依赖的数据源不可靠，或者验证对象本身不存在可客观判定的答案，再安全的委员会也可能共同确认一个错误结论。

CRVA 试图降低固定验证者长期暴露和签名权限集中带来的风险，但不能彻底消除治理与实现层面的单点。节点准入、协议升级、TEE 认证和软件安全仍需接受持续审计。在旧份额可靠失效、新委员会保持足够独立的前提下，轮换可以缩短针对固定签名组的攻击窗口，但无法覆盖软件供应链或升级权限等系统性风险。

四、技术基础与落地进展

CRVA 的技术脉络可以追溯到发表于 IEEE TIFS 第 17 卷（2022 年）的 Bool Network 论文，DOI 为 10.1109/TIFS.2022.3209546。论文中的协议模型、安全证明和原型评估曾接受同行评审，为动态隐藏委员会、Ring-VRF、门限密钥管理和 TEE 保护等设计提供了学术依据。需要区分的是，同行评审针对的是论文中的模型与实现；DeepSafe 当前部署的 CRVA 与论文方案如何对应，仍需结合现版技术规范、代码审计和网络参数判断。

据 DeepSafe 2025 年 10 月披露，网络当时已累计处理近 1.2 亿次验证，活跃账户超过 265 万。项目方还表示，其生态关系已超过 70 项，涉及钱包兼容、技术集成、投资和市场合作等不同类型。

2025 年 10 月，DeepSafe 宣布完成 300 万美元种子轮，投资方包括 Antalpha Global、ViaBTC Capital 和 Gate 等 1。从时间线看，这轮融资主要对应品牌更名后的技术研发与生态扩展。

五、从验证方案到通用基础设施

随着区块链基础设施逐步模块化，共识、执行、数据可用性、互操作和账户体系开始由不同组件承担。模块化没有让信任问题消失，而是让每一层的安全边界变得更加清晰------开发者不仅要选用哪套技术，还要判断由谁提供这一层的安全保证、出问题时由谁担责。AI Agent 获得链上执行能力后，新的问题随之出现：谁来确认它读取的数据可信、决策没有越权、最终交易与用户授权一致？这些问题不会因为一次有效签名就自动获得答案。

DeepSafe 希望把验证能力从单个应用内部的附属模块，抽象成可供不同协议和 AI Agent 调用的基础设施------「Proof, Not Promises」，用可验证的证据取代执行方的承诺。CRVA 已经把匿名抽选、门限协作与 TEE 组合成了一套技术路径；它能否进一步覆盖预言机、跨链和 AI Agent 等不同场景，并发展为通用验证基础设施，将取决于现网能力、独立审计和真实集成的持续积累。

本文来自投稿，不代表 BlockBeats 观点。