温馨提示：本站仅提供公开网络链接索引服务，不存储、不篡改任何第三方内容，所有内容版权归原作者所有
AI智能索引来源：http://www.bee.com/zh_cn/61288.html
点击访问原文链接

Web3 Security Series: Can funds mistakenly transferred to other blockchains be recovered? | Bee Network

进入原网站 导航首页
Web3 Security Series: Can funds mistakenly transferred to other blockchains be recovered? | Bee Network Login 热门新闻 备忘录启动板 人工智能代理 德西 TopChainExplorer 给 Newbee 100 倍金币 蜜蜂游戏 重要网站 必备应用程序 加密货币名人 德平 新手必备 陷阱探测器 基本工具 高级网站 交流 NFT 工具 你好、, 签出 Web3 宇宙 游戏 DApp 蜂巢 成长平台 生态 搜索 英语 充值金币 登录 下载 Web3 大学 游戏 DApp 蜂巢 生态 家•分析•正文 Web3 Security Series: Can funds mistakenly transferred to other blockchains be recovered?分析3 个月前更新怀亚特 15,283 7 1. Scenario 1: The receiving address is an EOA

An EOA (Externally Owned Account) is what we commonly refer to as a regular wallet address that is directly controlled by a private key or mnemonic phrase.

Prerequisites for asset recovery:

You have transferred your assets to an EOA address. You possess the private key or mnemonic phrase for this target EOA address. (This is usually another wallet address of your own, or a friend’s address that they are willing to cooperate). The target chain is an EVM-compatible chain.

Methods to recover assets:

The holder of the private key to the receiving EOA address can directly withdraw funds on the target blockchain.

2. Scenario 2: The receiving address is the contract.

This is one of the most desperate scenarios. Because the smart contract’s address is not generated by the private key, no one owns the smart contract’s private key and therefore cannot control the contract in the same way they control the EOA. Furthermore, if the contract does not have a pre-written rescue function to handle “accidentally transferred assets,” the mistakenly transferred funds may be permanently locked in the contract, and no one can retrieve them.

However, in some cases, there is indeed a glimmer of hope. Next, we will construct a scenario where ETH is locked on the Ethereum mainnet, and then explain how to rescue the funds.

2.1. Scene Introduction

In summary, this scenario involves a user intending to invoke a contract on the Sepolia testnet to transfer ETH into the contract for token minting. However, during the transaction initiation, an incorrect connection was made to the mainnet, resulting in the ETH being locked in the mainnet contract. The specific scenario construction process is as follows:

1. On the Ethereum Sepolia testnet, the project team (EOA) deployed an implementation contract . Assume the main function of this contract is for users to deposit ETH to mint corresponding A代币s, with code similar to the “mintTokens” function. Assume the deployment address is A. Note that there is no function in A that allows direct ETH withdrawal.

2. On the Ethereum Sepolia testnet, the project team (EOA) deployed a factory contract . This contract’s function is to deploy a proxy contract pointing to the implementation contract (as shown in the function “deployProxyByImplementation”) using minimal proxy contracts (Clones) based on the provided implementation contract address and salt. Assume the deployment address is B. Here, we call the “deployProxyByImplementation” function, passing the implementation contract A address as `_implementation`, to deploy a proxy contract pointing to A at address C.

3. A user wants to mint ATokens on the Sepolia testnet by transferring ETH. The user initiates a call to the proxy contract C. Normally, proxy contract C would further call the “mintTokens” function, which implements contract A, to complete the user’s operation. However, during the call, the user incorrectly connects to the Ethereum mainnet. Consequently, the user directly transfers ETH to address C on the Ethereum mainnet. At this point, no contract is deployed on address C on the Ethereum mainnet, and no one owns the private key for address C. Therefore, the user’s funds are temporarily locked in address C on the mainnet.

2.2. Key Knowledge Points

Before introducing the specific rescue plan, let’s first introduce some basic knowledge points needed for rescue.

2.2.1. create & create2

`create` and `create2` are two common ways to deploy contracts in Solidity.

When deploying a contract using the `create` function, the contract address is determined by the address of the transaction initiator and the account’s transaction count (nonce), and is unrelated to the contract’s content. When deploying a contract using create2, the calculation of the contract address no longer depends on the transaction initiator’s nonce, but is related to the following four parameters. 0xff The contract address for creating a new contract. The obfuscation value (salt) used as a parameter The creation bytecode (init_code) of the contract to be created.

2.2.2. Minimal Agent Contracts (Clones)

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

Minimal proxy contracts, also known as clone contracts, are based on the idea of deploying a proxy contract with extremely low cost (Gas) that points to a specified implementation contract. In a clone contract, the proxy contract can be deployed using either the `create` or `create2` method. For example, deploying a proxy contract using the `cloneDeterministic` function employs the `create2` method.

In the “cloneDeterministic” function, the bytecode of the created proxy contract is very short, in the format: “0x363d3d373d3d3d363d735af43d82803e903d91602b57fd5bf3″. The address of the implementation contract is directly hard-coded into the bytecode, and all calls to the proxy contract are delegated to the implementation contract.

As can be seen from the “cloneDeterministic” function, it uses the create2 method to create a proxy contract. The address of the created proxy contract is related to the address of the contract creator, the salt, the address of the implementing contract, and a fixed string of bytecode, but it is unrelated to the bytecode of the implementing contract.

2.3. Rescue Plan

Next, we’ll explain how to rescue a user’s ETH held in the mainnet C address. The main idea is to deploy contract code on the Ethereum mainnet C address to take over the address and extract the ETH. The specific steps are as follows:

1. Deploy a factory contract on the mainnet with the same address B as on the testnet. The reason for needing the same factory contract address is that when subsequently calling “cloneDeterministic” to deploy the proxy contract, the address calculation of the proxy contract is related to the factory contract address. By examining the transaction deploying the factory contract on the Sepolia testnet, obtain the nonce of the deployer (project address) in this transaction. On the mainnet, advance the nonce of the project owner’s (EOA) address to the nonce before deploying the factory contract. Then deploy the factory contract on the mainnet. Since the deployer’s address and nonce are the same as the deployment transaction on the testnet, the factory contract address deployed on the mainnet will also be B.

2. Deploy the implementation contract on the mainnet at the same address A as on the testnet. As mentioned in the #Minimum Proxy Contract (Clones)# section, deploying a proxy contract using the “cloneDeterministic” function of the Clones contract calculates the proxy contract address. The calculated proxy contract address depends on the input parameter `salt` and the implementation contract address, but is independent of the implementation contract’s bytecode. Therefore, we only need to deploy one contract on address A; the specific content of the contract does not affect the calculation of the proxy contract address. We can then directly deploy a contract with ETH extraction functionality on address A, as shown in the code below.

On the testnet, implementation contract A is deployed by the project owner’s address (EOA). Therefore, the address of implementation contract A is only related to the transaction initiator and its nonce. Thus, by observing the transactions that deploy implementation contract A on the testnet, finding the relevant nonce, pushing the project owner’s address (EOA) on the mainnet to the specified nonce, and then deploying implementation contract A, you can proceed.

3. Deploy a proxy contract on the mainnet at the same address C as the testnet. Observe the transactions of the proxy contract C deployed on the testnet, obtain the salt information, and call the “deployProxyByImplementation” function of the factory contract B, passing the address of the implementation contract A and the salt as parameters. This will deploy the proxy contract at address C on the mainnet.

4. The mainnet proxy contract C is invoked to withdraw funds. The project address (EOA) calls the withdraw function of proxy contract C, specifies the recipient of funds, successfully withdraws the frozen ETH from proxy contract C, and then returns it to the relevant user.

2.4. Summary

As can be seen from the above rescue plan, the funds can only be recovered if many conditions are met simultaneously, such as the contract deployer’s relevant nonce on the target chain not being used, the contract trapping the funds having a withdrawal function or being able to deploy a withdrawal function in various ways (the contract can be upgraded or a proxy such as Clones can be used, etc.).

Therefore, everyone must be extremely careful when trading, meticulously verifying each transaction before interacting with the contract. Before engaging with the contract, you can use ZAN’s AI SCAN vulnerability scanning tool to check its security. If your funds are accidentally locked, don’t panic; you can contact ZAN’s contract security audit team to try and help you recover your funds.

This article was written by Cara ( @Cara6289 ) ZAN Team (X 账户 @zan_team ) & AntChain OpenLabs (X account @AntChainOpenLab ).

本文来源于互联网： Web3 Security Series: Can funds mistakenly transferred to other blockchains be recovered?Recommended Articles

#分析# 以太坊# 代币# 工具# web3© 版权声明文章版权归作者所有，未经允许请勿转载。 上一篇 Has Bitcoin's four-year cycle failed? 下一篇 Weekly Editor's Picks (November 15-21) 相关文章 Having faith: 15 reflections on Bitcoin and the crypto market 6086cf14eb90bc67ca4fc62b 37,921 1 This weeks Meme bottom-fishing list: FREDs top holdings increased, ai16z released good news 6086cf14eb90bc67ca4fc62b 37,679 2 Chapter 2 of Story: AI-native infrastructure empowers the $70 trillion IP economy 6086cf14eb90bc67ca4fc62b 26,705 6 A complete review of 15 funded projects in the Monad ecosystemRecommended Articles 6086cf14eb90bc67ca4fc62b 28,809 5 In-depth research report on the privacy coin sector: From the demand for anonymity to the revaluation of value in the er 6086cf14eb90bc67ca4fc62b 16,403 Master the Secrets of Ethereum Passive Income Strategy by 2025 6086cf14eb90bc67ca4fc62b 40,210 2 无评论 您必须登录后才能发表评论！ 立即登录 没有评论... Bee.com 全球最大的 Web3 门户网站 合作伙伴 硬币卡 Binance CoinMarketCap CoinGecko Coinlive 装甲 下载蜜蜂网络APP，开始web3之旅 白皮书 角色 常见问题 © 2021-2026.保留所有权利。. 隐私政策 | 服务条款 下载蜜蜂网络 APP 并开始 web3 之旅 全球最大的 Web3 门户网站 合作伙伴 CoinCarp Binance CoinMarketCap CoinGecko Coinlive Armors 白皮书 角色 常见问题 © 2021-2026.保留所有权利。. 隐私政策 | 服务条款 搜索 搜索InSite链上社会新闻 热门推荐： 空投猎人 数据分析 加密货币名人 陷阱探测器 简体中文 English 繁體中文 日本語 Tiếng Việt العربية 한국어 Bahasa Indonesia हिन्दी اردو Русский 简体中文

智能索引记录