Serie de seguridad en Web3: ¿Se pueden recuperar los fondos enviados por error a otra cadena?

En el mundo de las criptomonedas, un clic equivocado puede desencadenar un “desastre digital”. Uno de los peores sueños es enviar activos a la cadena de bloques equivocada. Por ejemplo, querer enviar ETH a una dirección en la red de prueba Sepolia en Ethereum, pero accidentalmente enviarlo a una dirección en la red principal de Ethereum. En estos casos, ¿es posible recuperar los fondos enviados por error desde la red principal de Ethereum? La posibilidad de recuperar los activos depende en gran medida del tipo de dirección de destino. Este artículo analizará diferentes escenarios.

1. Escenario uno: la dirección de recepción es EOA

EOA (Cuenta Externamente Controlada) es la dirección de una wallet común controlada directamente por una clave privada o frase semilla.

Requisitos previos para recuperar los activos:

• Has enviado los activos a una dirección EOA.
• Posees la clave privada o frase semilla de esa dirección EOA de destino. (Generalmente, es otra wallet tuya o la de un amigo dispuesto a colaborar).
• La cadena de destino es compatible con EVM.

Método para recuperar los activos:

El poseedor de la clave privada de la dirección EOA receptora puede retirar los fondos directamente en esa cadena.

2. Escenario dos: la dirección de recepción es un contrato inteligente

Este es uno de los escenarios más desesperantes. Dado que las direcciones de contratos inteligentes no están controladas por claves privadas, nadie puede poseer la clave privada de un contrato inteligente y, por tanto, no puede controlarlo como un EOA. Además, si ese contrato no tiene funciones predefinidas para manejar “transferencias erróneas de activos”, los fondos enviados por error pueden quedar bloqueados permanentemente dentro del contrato, sin posibilidad de ser recuperados.

Sin embargo, en ciertos casos, todavía hay esperanza. A continuación, construiremos un escenario donde ETH está bloqueado en la red principal de Ethereum, y explicaremos cómo recuperarlo.

2.1. Introducción del escenario

Este escenario se resume así: el usuario quería interactuar con un contrato en la red de prueba Sepolia para transferir ETH y acuñar tokens, pero por error conectó su wallet a la red principal de Ethereum, enviando ETH a un contrato en la red principal, lo que provocó que los fondos quedaran bloqueados allí. La construcción del escenario es la siguiente:

1. En la red de prueba Sepolia, el equipo (EOA) despliega un contrato de implementación, suponiendo que dicho contrato permite a los usuarios depositar ETH para acuñar tokens (por ejemplo, mediante una función mintTokens). La dirección de despliegue es A. Es importante notar que en A no existe una función que permita extraer ETH directamente.

2. En la misma red de prueba Sepolia, el equipo despliega un contrato factory, cuya función es desplegar contratos proxy mediante clones (Clones) que apunten a un contrato de implementación, usando una función como deployProxyByImplementation. La dirección de despliegue es B. Se realiza una llamada a deployProxyByImplementation, pasando la dirección del contrato A como _implementation, y creando así un contrato proxy C que apunta a A.

3. El usuario intenta en la red de prueba Sepolia transferir ETH a la dirección del proxy C para acuñar tokens, pero por error conecta su wallet a la red principal y envía ETH directamente a la dirección C en la mainnet. En ese momento, la dirección C en la mainnet no tiene ningún contrato desplegado ni clave privada, por lo que los fondos quedan bloqueados en esa dirección en la mainnet.

2.2. Puntos clave

Antes de describir la solución de rescate, es necesario entender algunos conceptos básicos.

2.2.1. create y create2

create y create2 son los métodos comunes en Solidity para desplegar contratos.

• create despliega un contrato cuya dirección depende de la dirección del creador y del nonce de ese creador, sin importar el contenido del contrato.
• create2, en cambio, calcula la dirección del contrato en función de:
  • 0xff
  • La dirección del creador
  • Un valor salt (confusión)
  • El bytecode de creación del contrato (init_code).

2.2.2. Clones (contratos proxy mínimos)

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

Los clones, también conocidos como contratos proxy mínimos, consisten en desplegar un contrato proxy con un coste muy bajo que apunta a un contrato implementado. Los clones pueden desplegarse usando create o create2, por ejemplo, mediante la función cloneDeterministic, que utiliza create2.

El bytecode de los clones es muy simple, por ejemplo: 0x363d3d373d3d3d363d73<dirección del contrato implementado>5af43d82803e903d91602b57fd5bf3, donde la dirección del contrato implementado está codificada directamente. Todas las llamadas al proxy se delegan mediante delegatecall al contrato implementado.

El método cloneDeterministic usa create2, por lo que la dirección del proxy depende de: la dirección del creador, el valor salt, y la dirección del contrato implementado, pero no del código del contrato implementado.

![])https://img-cdn.gateio.im/webp-social/moments-628ce0ce97dbf40349dc8b7a0c07eab3.webp(

)# 2.3. Solución de rescate

Ahora veremos cómo recuperar ETH en la dirección C en la mainnet. La estrategia principal es desplegar un contrato en la mainnet en la misma dirección C, que tome control y permita extraer los ETH bloqueados.

Los pasos son:

![]###https://img-cdn.gateio.im/webp-social/moments-22428dd6bb1fbd62d2205538c0cc6c92.webp(

1. Desplegar en la mainnet el mismo contrato factory que en Sepolia, en la misma dirección B. La razón es que la dirección del proxy desplegado con cloneDeterministic depende de la dirección del factory y del salt. Para ello, en la mainnet, se debe usar el nonce correcto: primero determinar el nonce del despliegue en Sepolia, y luego en la mainnet, desplegar en la misma posición para que la dirección sea la misma.

2. Desplegar en la mainnet la misma implementación del contrato A. Como la dirección del proxy depende del salt y del contrato de implementación, basta desplegar en la misma dirección A en la mainnet un contrato que tenga funciones de extracción de ETH. La dirección en la mainnet será igual que en Sepolia si se despliega con el mismo nonce.

3. Desplegar en la mainnet el mismo proxy C. Usar los mismos parámetros de salt y de implementación para que la dirección del proxy sea la misma en mainnet que en Sepolia.

4. Desde la wallet del equipo, llamar a la función withdraw del proxy C para extraer los ETH bloqueados y devolverlos a los usuarios.

)# 2.4. Resumen

El rescate solo es posible si se cumplen varias condiciones: que el creador del contrato en la cadena de destino no haya usado el nonce, que el contrato bloqueador tenga funciones de retiro, o que el despliegue sea compatible con métodos para extraer fondos (como contratos upgradeables o proxies).

Por ello, en futuras transacciones, hay que tener mucho cuidado, verificar cada paso y, antes de interactuar con un contrato, usar herramientas como AI SCAN de ZAN para comprobar la seguridad del mismo. En caso de que los fondos queden bloqueados, no hay que desesperar y se puede contactar con el equipo de auditoría de ZAN para intentar rescatar los fondos.

Este artículo ha sido escrito por ZANTeam (@zan_team) y AntChain OpenLabs (@AntChainOpenLab), con Cara (@Cara6289).