Web3安全系列：誤轉到其他鏈上的資金，還能救回來嗎？

在加密世界中，一次点击失误就可能引发一场“数字灾难”。最常见的噩梦之一，莫过于将资产发送到了错误的区块链上。比如，本来想给以太坊 Sepolia 测试网上的地址发送 ETH，结果不小心发到了以太坊主网上的地址。这种情况下，还能从以太坊主网上将误转的资金取回来吗？能否找回资产，关键在于收款地址的类型。本文将根据不同的情况进行分析。

1. 场景一：收款地址是 EOA

EOA (Externally Owned Account) 就是我们常说的、由私钥或助记词直接控制的普通钱包地址。

找回资产前提条件：

• 你将资产转到了一个 EOA 地址。
• 你拥有这个目标 EOA 地址的私钥或助记词。（通常是你自己的另一个钱包地址，或者是朋友的地址，且他愿意配合）。
• 目标链是 EVM 兼容链。

找回资产方法：

收款 EOA 地址私钥持有者直接在目标链上提取资金即可。

2. 场景二：收款地址是合约

这是最令人绝望的场景之一。由于智能合约的地址不是由私钥生成的，因此没有任何人拥有智能合约的私钥，就无法像控制 EOA 那样去控制这个合约。并且如果该合约没有预先编写处理“错误转入资产”的救援函数，那么误转资金可能被永久锁定在合约中，谁也无法取出。

然而在某些情况下，其实也是有一线生机的。接下来，我们会构建一个将 ETH 锁在以太坊主网的场景，然后介绍如何将资金救出来。

2.1. 场景介绍

该场景概括来说，即用户本来想调用 Sepolia 测试网的合约，将 ETH 转入合约来铸造代币，然而发起交易时，错误地连接到了主网，结果导致 ETH 被锁定在了主网的合约中。具体的场景构建过程如下：

1. 在以太坊 Sepolia 测试网上，项目方（EOA）部署了实现合约，假设该合约的主要功能是用户存入 ETH，来铸造相应的 AToken，大致代码如 mintTokens 函数所示。假设部署的地址为 A。需要注意的是，A 中不存在能直接提取 ETH 的函数。

2. 在以太坊 Sepolia 测试网上，项目方（EOA）部署了工厂合约，该合约的功能是根据提供的实现合约地址以及 salt，以最小代理合约（Clones）的方式，部署指向实现合约的代理合约（如函数 deployProxyByImplementation 所示）。假设部署的地址为 B。假设此处我们通过调用 deployProxyByImplementation 函数，以实现合约 A 地址作为 _implementation 传入，部署了指向 A 的代理合约，地址为 C。

3. 用户想在 Sepolia 测试网上通过转入 ETH 来铸造 AToken，于是用户向代理合约 C 地址发起了调用，正常情况下，代理合约 C 会进一步调用到实现合约 A 的 mintTokens 函数，来完成用户的操作。然而用户在调用时，错误地连接到了以太坊主网。于是，用户直接将 ETH 转入到了以太坊主网上的 C 地址上。此时以太坊主网 C 地址上，并未部署任何合约，也没有人拥有该 C 地址的私钥，因此用户的钱，暂时被锁定在主网的 C 地址上了。

2.2. 关键知识点

在介绍具体救援方案之前，先介绍一下救援需要的基本知识点。

2.2.1. create & create2

create 和 create2 是 Solidity 中常见的两种部署合约的方式。

• create 部署合约时，合约地址由交易发起者的地址和该账户的交易次数（nonce）共同决定，与合约的内容无关。
• create2 部署合约时，合约地址的计算不再依赖于交易发起者的 nonce，而是与以下四个参数有关。
• • 0xff
    • 创建新合约的合约地址（address)
    • 作为参数的混淆值（salt）
    • 待创建合约的创建字节码（init_code）

2.2.2. 最小代理合约（Clones）

https://docs.openzeppelin.com/contracts/4.x/api/proxy#clones

最小代理合约，也常被称为克隆合约（Clones），核心思想是用极低的成本（Gas）部署一个代理合约，该代理合约指向指定的实现合约。在 Clones 合约中，可以通过 create 或者 create2 的方式部署代理合约，比如通过 cloneDeterministic 函数部署代理合约，就是采用 create2 的方式进行部署。

在 cloneDeterministic 函数中，创建出的代理合约的字节码非常简短，格式为：0x363d3d373d3d3d363d73<实现合约地址>5af43d82803e903d91602b57fd5bf3，直接将实现合约的地址硬编码到了字节码中，并将调用到该代理合约的调用都 delegatecall 到该实现合约。

从 cloneDeterministic 函数看出，其采用了 create2 的方式创建代理合约，创建出的代理合约的地址与合约创建者地址、salt、实现合约的地址、固定的一串字节码有关，其与实现合约的字节码无关。

2.3. 救援方案

接下来介绍如何救援用户在主网 C 地址上的 ETH。主要思路是，在以太坊主网 C 地址上，部署上合约代码，接管主网 C 地址，将 ETH 提取出来。具体的操作步骤如下：

**1. 在主网部署与测试网上相同地址 B 的工厂合约。**之所以需要相同的工厂合约地址，是因为在后续调用 cloneDeterministic 部署代理合约时，代理合约的地址计算与工厂合约地址有关。通过查看 Sepolia 测试网上部署工厂合约的交易，获取到这笔交易中部署者（项目方地址）的 nonce，在主网上，将项目方（EOA）地址的 nonce 推进到部署工厂合约前的 nonce，然后在主网上部署工厂合约，由于部署者的地址以及 nonce 均与测试网上部署交易相同，因此在主网上部署的工厂合约地址也为 B。

**2. 在主网部署与测试网相同地址 A 的实现合约。**在#最小代理合约（Clones）#部分提到，通过 Clones 合约的 cloneDeterministic 函数部署代理合约，其计算出的代理合约地址，与入参 salt、实现合约地址有关，与实现合约的字节码无关。因此，**我们只需要将一个合约部署在地址 A 上即可，合约的具体内容并不影响代理合约地址的计算。**那么我们可以直接在地址 A 上部署一个具备提取 ETH 功能的合约，代码如下所示。

在测试网上，实现合约 A 是由项目方地址（EOA）部署的，因此同样的，实现合约 A 的地址只与交易发起者及其 nonce 有关，因此，观察测试网上部署实现合约 A 的交易，找到相关 nonce，将主网上项目方地址（EOA）推进到指定的 nonce，然后部署实现合约 A 即可。

**3. 在主网上部署与测试网相同地址 C 的代理合约。**观察测试网上部署代理合约 C 的交易，获取到 salt 信息，调用工厂合约 B 的 deployProxyByImplementation 函数，将实现合约 A 的地址、salt 作为参数传入，即可在主网上的地址 C 上部署上代理合约。

**4. 调用主网代理合约 C 进行取款。**项目方地址（EOA）调用代理合约 C 的 withdraw 函数，并指定资金接收者，成功取出代理合约 C 中被冻结的 ETH，然后还给相关的用户。

2.4. 总结

从上述救援方案可以看出，资金能被救出来的情况，需要同时具备很多条件，比如合约部署者在目标链上的相关 nonce 未被使用、困住资金的合约上具备取款函数或者可以通过各种方式部署上取款的函数（合约可升级或使用 Clones 这种代理等）等。

因此，大家在交易时，一定要万分小心，仔细核对发起的每一笔交易，与合约进行交互之前，可以使用 ZAN 提供的 AI SCAN 漏洞扫描工具，检测合约的安全性。如果不小心出现资金被锁住的情况，也不要慌张，可以联系 ZAN 的合约安全审计团队尝试帮您进行资金救援。

本文由ZANTeam （X 账号 @zan_team） & AntChain OpenLabs（X 账号 @AntChainOpenLab）的Cara（X账号@Cara6289）撰写。