Saltar al contenido
Financial Context Wiki

Contrato inteligente actualizable

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.

Actualizado

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

Fuentes

Navegación

Buscar en la wiki...