--- title: "Proxy actualizable sin inicializar: riesgo de toma de control del inicializador" description: "Los proxies actualizables inicializan su propio almacenamiento mediante una llamada al inicializador, no mediante el constructor de la implementación. Este artículo explica el front-running, el bloqueo de la implementación y las comprobaciones de despliegue." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Proxy actualizable sin inicializar: riesgo de toma de control del inicializador > Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas. ## Respuesta directa Los contratos actualizables no utilizan un constructor para establecer el estado del agente, sino que dependen del inicializador. Este artículo explica los agentes no inicializados, el bloqueo de implementación y las comprobaciones de implementación. Cuando se implementa la nueva dirección de proxy pero la transacción de inicialización aún no se ha confirmado, cualquiera puede intentar llamar primero al inicializador público y convertirse en propietario. Cuando se implementa el agente, el constructor no ejecutará la lógica de inicialización del contrato en el almacenamiento del agente. Por lo tanto, los sistemas actualizables suelen utilizar un inicializador al que sólo se puede llamar una vez para configurar el propietario, los parámetros del token y los módulos. Si la función no está protegida adecuadamente, o si la implementación y la inicialización se dividen en dos transacciones, un atacante puede llamarla primero. ## Cómo funciona El proceso de seguridad coloca los datos de llamada de implementación e inicialización en la misma transacción atómica y deshabilita la inicialización al implementar la construcción del contrato para evitar que la implementación misma sea asumida. El reinicializador se utiliza para agregar un nuevo estado a la nueva versión y también debe limitar la versión y los permisos de llamada. Solo verificar el propietario del agente sin verificar el estado de inicialización de la implementación aún puede generar riesgos. Las operaciones en cadena se dividen en cuatro capas: la billetera es responsable de la visualización y la firma, RPC es responsable de la lectura y transmisión, el código del contrato determina el cambio de estado y el consenso del bloque determina si la transacción finalmente se confirma. Mostrar "éxito" en cualquier nivel no puede reemplazar la verificación en otros niveles. ## Ejemplo El proyecto implementa al agente primero y planea llamar a inicializar (equipo) a continuación. El atacante monitorea el mempool y primero llama a inicializar (atacante) con una tarifa más alta, se convierte en administrador y luego actualiza a una implementación maliciosa y transfiere fondos. La transacción de inicialización del propio equipo se revierte, pero en este punto se pierde el control. El gas, el deslizamiento y el tiempo de bloqueo en el caso se utilizan para demostrar el método de cálculo. Antes de la operación real, se debe leer el precio, la liquidez, los permisos y el estado del contrato de la cadena y el bloque actuales. La cantidad registra simultáneamente la cantidad de tokens, el valor en dólares y el número entero sin procesar en la cadena. ## Riesgos Las rentabilidades deben calcularse en función del valor real de salida: Valor de salida neto = valor de mercado del activo - shock de precio - tarifa de protocolo - impuesto de transferencia - Gas - descuento por riesgo de espera Establezca tres escenarios de estrés de congestión de la red, excepción de Oracle y actualización del administrador. Supongamos que Gas se expande cinco veces, la profundidad del grupo cae un 50%, la moneda estable se descuenta un 5% y no puede salir durante un día. Si los ingresos de un mes no pueden cubrir la fricción por presión, los ingresos elevados no proporcionan una compensación suficiente. El protocolo único, la cadena única, el puente único y la moneda estable única establecen límites superiores respectivamente. Cualquier puesto que requiera que administradores, oráculos, puentes, interfaces y un único RPC sean normales al mismo tiempo para salir deben reducirse aún más, y las múltiples dependencias relacionadas no deben confundirse con dispersión. ## Errores comunes - Mito 1: El saldo inicial es el hecho en la cadena. La interfaz puede estar almacenada en caché, indexada tarde o conectada a la red incorrecta y debe validarse de forma cruzada con lecturas de contrato. - Mito 2: Aumentar el Gas o el Deslizamiento puede solucionar cualquier falla. El gas sólo afecta a la clasificación y el deslizamiento sólo relaja el precio; Los errores de permiso, Nonce y condiciones del contrato no se repararán automáticamente. - Mito 3: Las pruebas exitosas en pequeñas cantidades significan seguridad permanente. Las actualizaciones de administradores, los parámetros dinámicos y los cambios de liquidez cambiarán los resultados y deben revisarse antes de cada expansión de posición. ## Temas relacionados - [ERC-4626 primer ataque de inflación de depósitos: por qué las acciones de Vault pueden redondearse](/es/crypto/erc4626-inflation-attack/) - [contrato de agencia](/es/crypto/proxy-contract/) - [contrato inteligente](/es/crypto/smart-contract/) - [Contrato actualizable](/es/crypto/upgradeable-contract/) - [Prueba de validez](/es/crypto/validity-proof/) ## Fuentes autorizadas - [API de Proxy e Initializable](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (consultado: 2026-08-20) - [Escritura de contratos actualizables](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (consultado: 2026-08-20) - [Actualización de contratos inteligentes](https://ethereum.org/developers/docs/smart-contracts/upgrading/) - Ethereum.org (consultado: 2026-08-20) Source: https://wiki.fcontext.com/es/crypto/initializer-takeover/index.mdx