--- title: "Contrato inteligente actualizable" description: "Un contrato inteligente actualizable conserva la dirección y el estado de un proxy mientras actores autorizados cambian o redirigen su implementación. Esa flexibilidad añade riesgos de almacenamiento, inicialización, gobernanza y supervisión." 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. # Contrato inteligente actualizable > Solo con fines educativos; no constituye asesoramiento de inversión ni de seguridad. La capacidad de actualización puede permitir que actores privilegiados cambien el comportamiento del contrato y puede ocasionar pérdidas. ## Respuesta directa Un contrato inteligente actualizable es un sistema desplegado cuya lógica efectiva puede cambiar sin trasladar a los usuarios a una nueva dirección principal ni descartar el estado allí guardado. En redes compatibles con Ethereum, el diseño habitual es un proxy que conserva el estado y reenvía llamadas mediante `delegatecall` a un contrato de implementación. Una actualización autorizada cambia la implementación, mientras la dirección, el almacenamiento y el saldo del proxy permanecen. No se reescribe bytecode inmutable: se añade una capa de indirección. Así pueden corregirse fallos y añadirse funciones, pero también se crea una vía privilegiada capaz de modificar retiros, comisiones, permisos o contabilidad. Hay que evaluar el código actual y las reglas que decidirán el código futuro. No todos los proxies son actualizables ni todos los sistemas mutables usan proxies. Algunos proyectos despliegan contratos nuevos y migran el estado; otros desactivan la actualización de forma permanente. La arquitectura y autoridad reales en cadena importan más que una etiqueta de la interfaz. ## Cómo funciona El usuario llama al proxy, que lee una dirección de implementación y ejecuta ese código en el contexto de almacenamiento del proxy mediante `delegatecall`. El código procede de la implementación, pero las lecturas y escrituras afectan al proxy y se conservan el remitente y el valor originales. ERC-1967 normaliza slots de implementación, beacon y administrador para facilitar su inspección. Los proxies transparentes administran la actualización en el proxy y separan llamadas administrativas y de usuario. Los UUPS sitúan la lógica de actualización en la implementación y usan la compatibilidad de ERC-1822, por lo que su autorización es crítica. Los proxies beacon obtienen la implementación de un beacon; una sola actualización puede cambiar muchos proxies. La compatibilidad de estado es la restricción principal. Reordenar, eliminar o cambiar el tipo de variables, o alterar la herencia, puede corromper datos. Diseños solo aditivos, huecos reservados o almacenamiento con espacios de nombres ERC-7201 ayudan, pero no sustituyen la validación entre versiones. Los constructores inicializan la implementación, no el almacenamiento del proxy. Por eso suele llamarse una vez a un inicializador como `initialize`. La implementación debe bloquear la inicialización directa y las migraciones posteriores deben usar reinicializadores limitados. Un inicializador público o repetible puede entregar roles al atacante. Un proceso defendible es: 1. Fijar código fuente, compilador, dependencias, layouts, direcciones y bytecode esperado de ambas implementaciones. 2. Revisar cambios, compatibilidad, inicialización o migración, autorización, dependencias y supuestos de reversión; probar la transacción completa en un fork. 3. Publicar propuesta y dirección, y aplicar el multisig, la gobernanza y el timelock declarados sin vías ocultas. 4. Ejecutar y verificar slot de implementación o beacon, eventos, bytecode, estado inicializado, roles e invariantes en un bloque registrado. 5. Vigilar cambios de slots, roles y parámetros, y preparar incidentes sin asumir que revertir siempre será seguro. ## Ejemplo Un protocolo de préstamos necesita una nueva función de reembolso. Su proxy delega en la implementación A. El equipo despliega B, comprueba que solo añade almacenamiento y prepara la migración. La gobernanza publica el bytecode y pone la actualización tras un timelock de 48 horas. Después, la misma dirección delega en B y los saldos siguen en el proxy. Los usuarios deben comprobar que el slot pasó de A a B, que la migración ocurrió una sola vez y que roles y saldos son correctos. Si un guardián puede omitir el timelock o un firmante puede sustituir B por código arbitrario, ese poder forma parte del modelo de confianza aunque la propuesta ordinaria siguiera el proceso anunciado. ## Riesgos - **Sustitución privilegiada:** un administrador, multisig, gobernador o clave comprometida puede instalar lógica maliciosa o defectuosa. - **Corrupción del almacenamiento:** un layout incompatible puede reinterpretar saldos, propietarios, mappings o cuentas. - **Fallo de inicialización:** un inicializador omitido, repetido o expuesto puede inutilizar el sistema o transferir el control. - **Fallo propio del patrón:** transparent, UUPS, beacon y proxies personalizados fallan de modos distintos; el nombre no demuestra corrección. - **Gobernanza aparente:** un timelock o voto puede tener bypass de emergencia, demora corta, poder concentrado o firmantes débiles. - **Migración o reversión insegura:** el estado puede cambiar de forma irreversible; restaurar código antiguo no restaura necesariamente su significado. - **Brecha de verificación:** verificar el código de la implementación no prueba que el proxy apunte a ella ni que administrador y estado sean los previstos. - **Riesgo de supervisión e integración:** exploradores, interfaces, auditores e integraciones pueden seguir una versión obsoleta u omitir un cambio global del beacon. ## Errores comunes - **«El contrato de esta dirección es inmutable».** El bytecode del proxy puede serlo mientras su conducta cambia mediante el slot de implementación o beacon. - **«Un multisig descentraliza las actualizaciones».** Solo reduce la dependencia de una clave si firmantes, umbral, operación y reemplazo son sólidos. - **«Un timelock impide actualizaciones maliciosas».** Da tiempo para observar y salir; no vuelve seguro el código ni ayuda a quien no puede salir. - **«Superar la comprobación de almacenamiento prueba la seguridad».** Solo cubre el layout, no lógica, autorización, oráculos, migración o economía. - **«Renunciar a actualizar siempre elimina el control».** Hay que comprobar en cadena administrador, beacon, gobernador, autorización UUPS y rutas alternativas. ## Temas relacionados - [Contrato inteligente](/es/crypto/smart-contract/) - [Cómo leer una auditoría de contratos](/es/crypto/contract-audit/) - [Cartera multifirma](/es/crypto/multisig-wallet/) - [Bloqueo temporal](/es/crypto/timelock/) ## Fuentes - [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultado: 2026-08-22) - [ERC-1822: Universal Upgradeable Proxy Standard (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (consultado: 2026-08-22) - [ERC-7201: Namespaced Storage Layout](https://eips.ethereum.org/EIPS/eip-7201) - Ethereum Improvement Proposals (consultado: 2026-08-22) - [Proxy Upgrade Pattern](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin Docs (consultado: 2026-08-22) - [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Docs (consultado: 2026-08-22) - [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Docs (consultado: 2026-08-22) - [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) - Solidity Documentation (consultado: 2026-08-22) Source: https://wiki.fcontext.com/es/crypto/upgradeable-contract/index.mdx