撰文：DeepSafe 研究团队 & 仙壤 GodRealmX
最近两个月注定是 Crypto 的多事之秋。继特朗普上台后暴力加征关税以来，加密市场快速从牛转熊，无数人仓位腰斩，然而厄运不但光顾了散户群体，还降临到了大机构的头上。近期接连发生的 Bybit 和 Infini 被盗案，震惊了整个行业，充分暴露了 Web3 生态内安全设施的脆弱与不完善，为世人敲响了警钟。
这两起案件造成了超过 15 亿美元的巨额损失，甚至让 Safe 钱包本身也遭到了 FUD，人们在对智能合约钱包和多签方案产生怀疑的同时，也认识到了 Web3 在资产安全层面的双重困境：
外部黑客的精密攻击与内部人员的监守自盗，两者防不胜防。如果不对行业内的资产托管工具进行彻底的重塑，类似 Bybit 和 Infini 被盗案的事故只会越来越多。
对此，DeepSafe 研究团队通过对 Bybit 被盗案中暴露出的问题进行分析，尝试向大家揭示现有资产托管工具的痛点与潜在隐患，以及 DeepSafe 基于 MPC 和 ZK 与 TEE 打造的加密随机验证智能体「CRVA」如何构建出更完善的资产管理工具。
Bybit 被盗案中 Safe 等传统智能合约钱包的问题
根据事后的观察结果，Bybit 被盗案中朝鲜黑客组织利用「盲签名漏洞」和「伪装签名界面」，成功绕过了多签验证。Bybit 的冷钱包采用 Safe 的 3/4 多签结构，涉及多个签名者，包括 Bybit 控制的冷钱包和硬件钱包。在正常情况下，管理资产的操作员会收到内部通知，登录签名界面核对交易信息后，再用硬件钱包签署交易。
但据慢雾方面分析，攻击者对 Safe 钱包存放前端代码的 AWS 设施进行了入侵，在 Safe 前端中添加了恶意代码，这段代码专门针对 Bybit 多签钱包。
当多签钱包操作者在 Safe 前端发起交易时，显示的信息看似正常，但实际上发出去的交易内容已被篡改，更改了 Bybit 采用的 Safe 钱包合约的关键设置（如替换 delegateCall 对应的合约地址），使黑客获得了钱包中资产的控制权。
为了让大家更好的理解此次攻击事件的关键，我们在此简单解释下 Safe 钱包的合约部署模式和 Solidity 里惯用的 delegateCall。
我们假设当前系统存在 A 合约、B 合约和 C 合约。假如 A 合约对 B 合约使用 DelegateCall，那么 A 合约就可以把 B 合约中的代码放到 A 的环境里执行，也就是说，B 合约中的代码逻辑可以改写 A 合约中存储的数据。
假如 B 合约代码包含对 C 合约的 call 调用，则 A 合约会在运行 B 合约代码时，也发起对 C 合约的调用。但 C 合约不能直接改写 B 和 A 中存储的内容，只能针对 B 和 A 主动传递给他的数据进行计算并返回结果。
我们可以将 DelegateCall 视为一种借用其他合约代码在本地环境中执行的一种模式。
在 DelegateCall 基础上，以太坊开发者发明了代理部署的模式。举例说明，Safe 钱包的新用户在新建账户时，需要在链上部署专用的智能合约来满足各种复杂的需求。但 Safe 钱包整体包含大量的逻辑代码，直接在一个合约里部署所有的代码，需要大量手续费。
为了节约成本，Safe 官方自己部署了包含复杂代码的 Safe 合约，新建钱包的用户可以通过 DelegateCall，把 Safe 合约的代码放在钱包账户本地环境下执行，这样一来，用户新建钱包的合约账户就可以尽可能精简化。
在开发者角度，我们一般称用户自己部署的合约为代理合约，而 Safe 官方部署的合约为逻辑合约。代理合约内最重要的变量就是 DelegateCall 的目标地址，该地址照理来说是 Safe 官方部署的逻辑合约地址。
在 Bybit 攻击事件中，黑客通过恶意前端，篡改 Bybit 冷钱包操作者发起的交易内容，替换了 DelegateCall 调用的逻辑合约地址，设置为黑客自己部署的恶意合约。此时 Bybit 的 Safe 钱包账户实际上丧失了多签的功能，黑客再通过恶意合约中的 sweepETH 函数，盗取了 Bybit 的 Safe 钱包里所有 ETH 资产。
由于 Safe 钱包签名过程中，签名人实际上是对交易数据的哈希 dataHash 进行签名，看不到交易内容的明文，因此无法判断具体的签名内容，只能相信 Safe 前端显示的信息，而攻击者用伪造的 Safe 前端进行攻击，诱骗 Bybit 的资产管理人员上钩。
除了此次 Bybit 被盗案，与 Safe 钱包相关的供应链与签名流程攻击，在历史上还出现过多次：
2021 年 Habitat 被盗案、2024 年 Radiant Capital 多签钱包被盗案、2024 年的 WazirX 被盗案皆与此类钓鱼攻击和社工渗透有关，受害者均被诱骗签署了恶意交易。即便 Safe 智能合约本身没有内部漏洞，但攻击者会转向恶意前端、钓鱼网站、恶意浏览器插件、木马程序等手段来诈骗签名者。
总结此类事件，我们可以看到以下几个问题:
- Safe 钱包所有的交易都是使用哈希后的结果签名，对于大部分普通用户并不友好，用户很难判断签名内容；
- Safe 钱包往往要求用户用专门设施来协商并聚合多签，再一次性提交。一般来说，用户选择 Safe 前端作为聚合签名的设施，但 Bybit 被黑事件恰恰是 Safe 前端出了问题；
- 对于大多数用户，Safe 钱包账户在创建时会使用代理部署，这种部署模式存在一定的风险，比如黑客就诱导 Bybit 操作者通过恶意交易替换了钱包账户指向的逻辑合约地址。
上述几个问题中，问题 2 尤为严重。近期大量的 Safe 多签被盗事件，本质上都是因为多签协商和聚合平台存在问题。当然，一般用户也会受到问题 1 和 3 的影响，虽然一些专业工具可以防范其中的漏洞，但无法从根源上保驾护航。近期发生的 Infini 被盗案也揭示了监守自盗的危害。为防范此类风险，机构团队应采用多因素验证提高操作门槛，并加强对签名设备的安全防护。
那么我们该如何解决 Safe 钱包等现有资产托管工具的不足？或者说既能抵御外部攻击又能防止家贼自盗？
基于这一需求，DeepSafe 的 CRVA（加密随机验证代理）方案应运而生，CRVA 通过去中心化签名系统、MPC、零知识证明、TEE 和智能风控等一系列配套设施，可以从根本上构建出更为完善的多签方案与自托管工具，为机构级用户和大户鲸鱼保驾护航。
下面让我们详细分析如何用 DeepSafe 的 CRVA 方案来加强多签系统的安全性。
基于 CRVA 的多签系统：为普通多签增设专用的去中心化验证网络
DeepSafe 团队的 EVM 系多签系统示意图
首先，DeepSafe 对 Safe 等传统多签钱包的验证门槛进行了调整。它允许用户继续采用 Safe 等知名的签名聚合设施，但会在此基础上额外添加一道验证，你把聚合后的多签提交上链后，签名的交易内容和聚合后的签名会被提交到链上的 Cosign 合约内，此时链下的 CRVA 网络会捕获用户提交的交易信息和签名信息，对其有效性进行验证。
CRVA 网络内包含大量节点，节点客户端的核心部分运行在 TEE 设备内，会依据用户预先设置的限制条件，对提交到 Cosign 合约中的内容进行校验。比如用户可能设置不允许单笔转账超过 100 ETH，CRVA 便先判断一笔转账是否超过 100 ETH，若无效则不予放行。
如果 CRVA 的多数节点认为该笔交易有效，则会触发门限签名，对验证结果进行签名，并把签名的结果提交到 Cosign 合约。此时 Cosgin 合约内已有用户自己提交的冷钱包签名，和 CRVA 提交的 MPC 签名，满足了 2FA 多因素验证的要求。之后 Cosign 合约才会聚合这些签名信息，调用专门的代码逻辑执行交易。
当然，如果用户前端向 Cosign 提交了不符合预先规则的交易信息，CRVA 会拒绝签名。如果 Cosign 合约没有收集到 CRVA 给出的门限签名，尽管用户用冷钱包提交了多签，最终也会被拒绝执行交易。
至此我们可以理解到，DeepSafe 实质是在传统的多签验证方案上，额外增设了一道验证，满足 2FA 多因素验证的要求。只不过这道额外添加的验证，是由 CRVA 这个靠 TEE 和 ZK 以及 MPC 等多种技术组合而成的去中心化网络来保证。
现在的关键在于，CRVA 本身是否安全？能否防范节点串通作恶或外部黑客攻击？
DeepSafe 的思路是这样：首先通过资产质押，构建出一个去中心化的验证人网络；网络规模足够大后，比如说接入了几百上千台设备，我们定期从网络中随机抽取一些节点充当 CRVA 的验证人。DeepSafe 通过专门研发的环状 VRF 算法，结合 ZK，把选中的验证人身份隐藏在全体候选人中，其简化后表述如下：
- 所有节点在进入 CRVA 网络前，要先在链上质押资产，留下一个公钥作为注册信息。这个公钥又称为「永久公钥」。
- 每过 1 小时，CRVA 网络会通过特定的 VRF 函数，随机挑选出几个验证人，验证上文中说的用户前端发来的交易信息。但在此之前，每个待挑选的候选人要在本地生成一次性的「临时公钥」，同时生成 ZKP，证明该「临时公钥」与链上有记录的「永久公钥」有关联；换句话说，通过 ZK 证明自己存在于候选人名单中，但又不透露是哪一个人；
- 「临时公钥」的作用在于什么？正是为了隐私保护。如果直接从「永久公钥」集合中抽签，公布抽签结果时，大家会直接知道哪些人当选，这个时候安全性会大打折扣。如果大家都临时提交一次性的「临时公钥」，再从「临时公钥」集合中选出几个中签者，你最多只知道自己中签，因为你不知道其他中签的临时公钥对应着谁。
- 这还不算完。CRVA 网络打算这么搞：直接让你不知道自己的「临时公钥」是啥。这该怎么做呢？只要把临时公钥明文放在 TEE 里加密成「乱码」后再发出去，然后只有特定的 Relayer 节点可以解密这些临时公钥，当然解密的流程也是在 TEE 里做的，就连 Relayer 自己都不知道这些临时公钥分别对应着哪个候选人。
5. Relayer 解密出所有人在本地 TEE 里生成的「临时公钥」后，把它们统一归集，提交给链上的 VRF 函数，从中抽选出中签者，由这些人组建验证委员会，验证用户发布的交易信息。
这样一来整体的逻辑其实就清晰了：我们定期的从验证人临时公钥集合中随机挑选几个，充当目前的验证委员会，这个设计被命名为 CRVA（加密随机验证代理）。因为每个节点都运行 TEE，所有的核心计算过程都隐藏在 TEE 环境内，每个人都不知道自己的临时公钥是什么，也不知道别人的临时公钥，当前的验证代理委员会到底包括哪些人，没有人知道，这样可以从根本上防止内部串谋或者外部攻破。
可能有人要问，既然每个节点都不知道自己是否属于委员会，那委员会还怎么协作生成门限签名呢? 其实这很好解决，我们直接在 CRVA 网络内广播，把委员会名单发给每一个人。每台节点的临时公钥都封装在本地 TEE 里，只要在 TEE 内核对委员会名单即可知晓自己是否被选中。
DeepSafe 方案的核心在于，几乎所有的重要活动都在 TEE 内进行，TEE 外部根本不知道发生了什么，包括 TEE 运行者自己。每一个节点都不知道被选中的验证人有谁，防止了串通作恶，并大幅度增加了外部攻击的成本。要攻击基于 DeepSafe 的 CRVA 委员会，理论上除非攻击整个 CRVA 网络才行。
在前文的 CRVA 架构图中，我们可以看到 Escap Hatch 的存在，这个东西是干嘛的？这其实类似于以太坊 ZK Rollup 的强制退出 / 逃生舱。因为 CRVA 只根据用户前端提交到链上的交易内容，以及既定规则来执行相应动作，没有人或机构能和 CRVA 系统串通。但在极端情况下，万一 CRVA 很多节点停机，就需要有一个资金逃离出口，把金库里的资金安全取出来。
图中的 Escape Htach 可以由用户自定义其细则，但默认情况下会有时间锁，用户可以通过专属密钥触发逃生舱功能，申请转移金库内的资金。但时间锁会预留延时窗口，比如在 7 天后资金强制退出才能生效。这样可以防止黑客盗取用户的逃生舱密钥后，立刻卷钱跑路，在时间锁限制期内，用户往往有充分的时间撤回其资金逃离请求。
为 EVM 系多签方案引入 CRVA 来加强安全性，还是很方便和灵活的，DeepSafe 还基于 Taproot 和时间锁等功能，在比特币链上搭建了一套安全的资产托管方案，鉴于该技术比较复杂，我们在此不做赘述，未来将发布专题研报为大家阐述我们的方案设计！敬请期待！
