Actualización de contratos inteligentes

¿Qué es la actualización de contratos inteligentes?

La actualización de contratos inteligentes es la capacidad de cambiar, sustituir, ampliar o redirigir la lógica de un sistema de contratos inteligentes desplegado después de su primer despliegue.

En el ámbito cripto, la capacidad de actualización se utiliza porque muchos contratos inteligentes gestionan activos reales, y los equipos pueden necesitar corregir errores, mejorar funciones, actualizar integraciones o responder a problemas de seguridad después del lanzamiento.

La documentación oficial de Ethereum sobre la actualización de contratos inteligentes explica que los contratos inteligentes suelen considerarse inmutables, pero los desarrolladores pueden utilizar patrones de actualización cuando se necesitan cambios futuros.

Un contrato inteligente básico desplegado suele conservar el mismo código para siempre, salvo que se haya diseñado con un mecanismo de actualización.

Un sistema de contratos inteligentes actualizable separa las direcciones orientadas al usuario, el estado almacenado y la lógica de negocio para que pueda introducirse nueva lógica sin obligar a los usuarios a migrar manualmente.

El modelo de actualización más habitual utiliza un contrato proxy con el que interactúan los usuarios y un contrato de implementación que contiene la lógica actual.

Cuando cambia la implementación, la dirección del proxy puede mantenerse igual mientras cambia el código que hay detrás.

Esto es útil para los usuarios porque los saldos, permisos e integraciones pueden seguir apuntando a la misma dirección.

Es arriesgado porque las personas o el sistema de gobernanza con autoridad de actualización pueden ser capaces de cambiar el comportamiento del contrato después de que los usuarios depositen fondos.

En términos sencillos, la actualización de contratos inteligentes consiste en diseñar software on-chain de modo que su lógica pueda actualizarse más adelante, preservando el estado importante, la continuidad de las direcciones y el acceso de los usuarios.

Por qué es importante la actualización de contratos inteligentes

La actualización de contratos inteligentes es importante porque el código blockchain desplegado puede controlar tokens, tesorerías, mercados de préstamos, sistemas de staking, bridges, NFT o derechos de gobernanza.

Un error en código inmutable puede bloquear activos, inutilizar funciones para los usuarios o exponer fondos a atacantes.

La capacidad de actualización ofrece a los desarrolladores una forma de aplicar parches a problemas críticos y mejorar un protocolo después de su despliegue.

La guía de OpenZeppelin sobre la actualización de contratos inteligentes explica que los despliegues actualizables pueden modificar el código del contrato mientras preservan la dirección, el estado y el saldo.

Esta preservación es importante porque los usuarios, las wallets, las herramientas de análisis y otros protocolos pueden depender ya de la dirección del contrato original.

Sin capacidad de actualización, un equipo podría tener que desplegar un contrato nuevo y pedir a los usuarios que migren fondos o aprobaciones manualmente.

La migración puede ser lenta, arriesgada, costosa y confusa.

Sin embargo, la capacidad de actualización también cambia el modelo de confianza de un contrato inteligente.

Un contrato que puede actualizarse no es plenamente inmutable del mismo modo que un contrato sin mecanismo de actualización.

Los usuarios siempre deben preguntarse quién puede actualizar el contrato, cómo se aprueban las actualizaciones, con qué rapidez pueden producirse y si los usuarios pueden salir antes de que entre en vigor un cambio importante.

Cómo funciona la actualización de contratos inteligentes

La actualización de contratos inteligentes suele funcionar separando el almacenamiento de la lógica.

El contrato proxy conserva la dirección a la que llaman los usuarios y normalmente almacena el estado principal del sistema.

El contrato de implementación contiene la lógica que define qué hacen las funciones.

Cuando un usuario llama al proxy, este reenvía la llamada al contrato de implementación actual.

En sistemas de estilo Ethereum, este reenvío suele utilizar delegatecall, que ejecuta la lógica de implementación en el contexto de almacenamiento del proxy.

Esto significa que el código de implementación puede leer y escribir en el almacenamiento del proxy como si dicho almacenamiento perteneciera a la implementación.

Cuando el protocolo se actualiza, una cuenta autorizada o un proceso de gobernanza cambia la dirección de implementación almacenada por el proxy.

Después del cambio, las futuras llamadas se dirigen a la nueva lógica de implementación.

El almacenamiento anterior puede permanecer en su lugar, por lo que los saldos de los usuarios y el estado del protocolo pueden continuar si el diseño de almacenamiento es compatible.

Este diseño es potente, pero requiere reglas estrictas sobre el diseño de almacenamiento, la inicialización, la autorización, las auditorías y la gobernanza de actualizaciones.

Contrato proxy

Un contrato proxy es la dirección estable del contrato con la que interactúan los usuarios y otros contratos en muchos sistemas actualizables.

El proxy suele almacenar el estado y reenviar llamadas de funciones a un contrato de implementación.

La documentación de OpenZeppelin sobre el patrón de actualización mediante proxy describe el patrón de proxy de almacenamiento no estructurado como un elemento fundamental para los contratos actualizables.

Un proxy es útil porque los usuarios no necesitan cambiar las direcciones de contrato cada vez que se actualiza la lógica.

Las aplicaciones, wallets, paneles e integraciones DeFi pueden seguir utilizando la misma dirección del proxy.

El patrón proxy también añade complejidad, ya que los usuarios pueden ver una dirección de contrato mientras que la lógica real reside en otra dirección.

Los exploradores de blockchain suelen mostrar información del proxy y direcciones de implementación cuando pueden detectar el patrón.

Los usuarios deberían examinar tanto el proxy como la implementación al revisar contratos actualizables.

Un proxy no es seguro automáticamente, ya que su seguridad depende de los controles de actualización, la compatibilidad de almacenamiento y la calidad del código de implementación.

El proxy es la puerta de entrada, mientras que la implementación es la lógica que hay detrás de esa puerta.

Contrato de implementación

Un contrato de implementación es el contrato que contiene la lógica de negocio utilizada por un proxy.

Puede definir funciones para transferencias, depósitos, retiradas, préstamos, votaciones, acuñación, quema, pausas, liquidaciones u otras acciones del protocolo.

Los usuarios normalmente no interactúan directamente con la dirección de implementación en un sistema basado en proxy.

En su lugar, interactúan con el proxy, y el proxy delega la ejecución en la implementación.

Una actualización suele consistir en cambiar el proxy para que apunte a un nuevo contrato de implementación.

La nueva implementación debe ser compatible con el diseño de almacenamiento anterior y con las expectativas de los usuarios.

Una actualización peligrosa de la implementación puede añadir lógica maliciosa, romper la contabilidad, cambiar permisos o bloquear retiradas.

Por este motivo, el código de implementación debe verificarse, auditarse, probarse y revisarse antes de ejecutar la actualización.

Los usuarios no deben asumir que un protocolo permanece igual para siempre solo porque la dirección del proxy no haya cambiado.

En sistemas actualizables, la dirección de implementación es una parte fundamental de la seguridad.

Delegatecall

Delegatecall es un mecanismo de bajo nivel de la EVM que permite a un contrato ejecutar código de otro contrato utilizando el contexto de almacenamiento del llamante.

En la actualización mediante proxy, delegatecall permite al proxy utilizar la lógica de implementación mientras mantiene el estado en la dirección del proxy.

Por eso una nueva implementación puede cambiar el comportamiento sin mover los saldos de los usuarios desde el proxy.

Delegatecall es potente porque separa el código del estado.

Es arriesgado porque la implementación debe asumir que escribe en el almacenamiento del proxy, no en su propio almacenamiento.

Si la implementación utiliza un diseño de almacenamiento distinto del esperado, las variables pueden colisionar o corromper el estado.

Un diseño incorrecto de delegatecall puede provocar la sobrescritura de variables de propiedad, saldos, mappings o valores de configuración.

Los desarrolladores deben evitar escribir lógica proxy personalizada con delegatecall salvo que comprendan plenamente el almacenamiento y la ejecución de la EVM.

Los usuarios no necesitan entender cada opcode, pero deben saber que los proxies actualizables dependen de una indirección técnica.

Delegatecall es uno de los motivos por los que los contratos actualizables necesitan auditorías especializadas.

Diseño de almacenamiento

El diseño de almacenamiento es el orden y la ubicación de las variables en el almacenamiento de un contrato inteligente.

La documentación de Solidity sobre el diseño de almacenamiento explica cómo se organizan las variables de estado en el almacenamiento y por qué las reglas de diseño son importantes para contratos y bibliotecas.

El diseño de almacenamiento es uno de los riesgos más importantes de la capacidad de actualización.

Si una nueva implementación cambia incorrectamente el orden, el tipo o la estructura de las variables existentes, el proxy puede interpretar los datos de almacenamiento antiguos de una manera nueva y defectuosa.

Por ejemplo, un mapping de saldos podría desplazarse, una dirección de propietario podría sobrescribirse o una variable de configuración podría leerse como un tipo distinto.

Esto se denomina riesgo de colisión de almacenamiento o corrupción del almacenamiento.

Los desarrolladores normalmente añaden nuevas variables después de las existentes, en lugar de insertarlas en medio.

También evitan cambiar los tipos de variables o el orden de herencia sin una planificación cuidadosa de la migración.

Las herramientas modernas de actualización pueden comparar los diseños de almacenamiento antes de permitir una actualización.

Los usuarios deben considerar la seguridad del diseño de almacenamiento como una parte esencial de la seguridad de los contratos actualizables.

Slots de almacenamiento de proxy ERC-1967

ERC-1967 es un estándar que define slots de almacenamiento específicos para información del proxy, como la dirección de implementación, la dirección de administrador y la dirección de beacon.

El estándar ERC-1967 define slots de almacenamiento estándar para proxies, de modo que las herramientas y los exploradores puedan identificar la configuración del proxy de forma más fiable.

Estos slots estandarizados reducen la probabilidad de que las variables de gestión del proxy colisionen con las variables de almacenamiento de la aplicación.

ERC-1967 también ayuda a los exploradores de blockchain a mostrar a los usuarios qué implementación utiliza actualmente un proxy.

Muchos sistemas proxy modernos se basan en slots compatibles con ERC-1967.

El estándar no hace que las actualizaciones sean seguras por sí mismo.

Principalmente proporciona un lugar predecible para almacenar los metadatos del proxy.

Los desarrolladores siguen necesitando una autorización correcta, validación del diseño de almacenamiento, revisión de la implementación y una ejecución segura de la actualización.

Los usuarios que revisen contratos actualizables deben comprobar si el proxy sigue estándares conocidos en lugar de un patrón personalizado desconocido.

El almacenamiento proxy estandarizado mejora la transparencia, pero es solo una parte de la seguridad de la actualización de contratos inteligentes.

Patrón Transparent Proxy

El patrón Transparent Proxy separa las llamadas de administrador de las llamadas de los usuarios para reducir la confusión de selectores de función entre las funciones del proxy y las funciones de implementación.

La documentación de OpenZeppelin sobre proxies explica que TransparentUpgradeableProxy incluye una interfaz integrada de administrador y actualización.

En este patrón, los usuarios normales interactúan con las funciones de implementación a través del proxy.

El administrador del proxy realiza las acciones de actualización y no debe llamar accidentalmente a las funciones de implementación a través del proxy del mismo modo que lo hacen los usuarios.

Este diseño ayuda a evitar conflictos en los que una función del proxy y una función de implementación comparten el mismo selector.

Los proxies transparentes se utilizan ampliamente porque proporcionan un modelo de administración claro.

Sin embargo, siguen requiriendo una gestión segura de las claves de administrador.

Si el administrador del proxy está controlado por una sola clave expuesta, todo el protocolo puede estar en riesgo.

Los proxies transparentes pueden ser seguros cuando se combinan con control multifirma, timelocks, auditorías y una gobernanza clara.

El patrón reduce un riesgo técnico, pero no elimina el riesgo de gobernanza.

Patrón de proxy UUPS

UUPS significa Universal Upgradeable Proxy Standard.

El estándar EIP-1822 describe un patrón de proxy universal actualizable en el que la lógica de actualización está vinculada al diseño de la implementación.

La documentación de OpenZeppelin explica que UUPSUpgradeable incluye el mecanismo de actualización en el contrato de implementación, en lugar de utilizar la misma estructura integrada de administrador de proxy que un proxy transparente.

Los proxies UUPS pueden ser más ligeros que los proxies transparentes porque el proxy puede ser más sencillo.

Sin embargo, la implementación debe incluir y proteger correctamente las funciones de actualización.

Una implementación UUPS deficiente puede eliminar accidentalmente la capacidad de actualización, exponer la autoridad de actualización o permitir actualizaciones no autorizadas.

Los desarrolladores también deben protegerse frente a actualizaciones a una implementación que rompa la ruta de actualización.

UUPS puede ser eficiente y flexible cuando se utiliza con bibliotecas maduras y herramientas de validación.

No debe copiarse sin más sin comprender la autorización y las comprobaciones de seguridad de actualización.

Los usuarios deben comprobar quién controla las actualizaciones UUPS y si las actualizaciones anteriores fueron transparentes y auditadas.

Patrón Beacon Proxy

Un patrón Beacon Proxy utiliza un contrato beacon que almacena la dirección de implementación para varios proxies.

En lugar de que cada proxy almacene su propia dirección de implementación, cada proxy lee la implementación desde el beacon.

Esto permite actualizar conjuntamente muchas instancias de proxy actualizando un único beacon.

Los proxies beacon son útiles para sistemas que despliegan muchos contratos similares, como vaults, pools, cuentas o instancias de contratos específicas de usuarios.

Pueden reducir la complejidad operativa cuando muchas instancias necesitan la misma actualización.

También pueden aumentar el radio de impacto, ya que una actualización defectuosa del beacon puede afectar a muchos proxies a la vez.

La documentación de OpenZeppelin sobre proxies incluye BeaconProxy y UpgradeableBeacon como componentes relacionados con proxies.

La autoridad del beacon debe protegerse cuidadosamente porque puede controlar la lógica de muchos contratos.

Los usuarios deben comprobar si el contrato que utilizan depende de un beacon y quién puede actualizarlo.

Un beacon resulta práctico para los desarrolladores, pero concentra el poder de actualización en un punto de control compartido.

Patrón Diamond Proxy

El patrón Diamond Proxy permite a un contrato similar a un proxy enrutar llamadas de funciones a múltiples contratos de implementación denominados facets.

El estándar Diamond EIP-2535 define un sistema modular de contratos inteligentes en el que las funciones pueden añadirse, sustituirse o eliminarse mediante facets.

Los diamonds resultan útiles para sistemas grandes que superarían los límites de tamaño de los contratos o que necesitan actualizaciones modulares.

Un diamond puede organizar lógica compleja en muchos facets separados, manteniendo una dirección principal.

Esta flexibilidad puede ser potente para grandes sistemas DeFi, juegos, sistemas de cuentas o marcos de protocolos.

También aumenta la complejidad, ya que usuarios y auditores deben comprender el enrutamiento de facets, las tablas de selectores, los patrones de almacenamiento y la autoridad de actualización.

Una actualización de diamond puede sustituir solo una parte del sistema, lo que hace importante el seguimiento de cambios.

El diseño del almacenamiento es especialmente importante porque múltiples facets pueden compartir el mismo almacenamiento.

Los desarrolladores deben utilizar patrones claros de diamond storage o almacenamiento con espacios de nombres cuando corresponda.

Los usuarios deben considerar los contratos diamond como sistemas actualizables avanzados que requieren una revisión cuidadosa.

Almacenamiento con espacios de nombres

El almacenamiento con espacios de nombres es un método para organizar el almacenamiento de contratos de forma que diferentes módulos utilicen ubicaciones de almacenamiento definidas y reduzcan el riesgo de colisiones.

El estándar ERC-7201 sobre el diseño de almacenamiento con espacios de nombres define una convención para documentar ubicaciones de almacenamiento de este tipo en el código fuente de Solidity.

El almacenamiento con espacios de nombres es útil en contratos actualizables y modulares porque reduce la dependencia de un único orden sencillo de variables a través de una larga cadena de herencia.

Puede hacer que las actualizaciones sean más seguras cuando los contratos se crean a partir de varios módulos.

También puede ayudar a las herramientas a validar los cambios de almacenamiento con mayor claridad cuando existe compatibilidad del compilador y del framework.

La guía de OpenZeppelin para escribir contratos actualizables señala que se requiere Solidity 0.8.20 o una versión superior para que sus plugins de actualización validen los diseños de almacenamiento con espacios de nombres utilizando la información necesaria del compilador.

El almacenamiento con espacios de nombres no elimina la necesidad de auditorías.

Ayuda a estructurar el estado para que los cambios futuros sean más fáciles de gestionar.

Los desarrolladores deben utilizar el almacenamiento con espacios de nombres de forma coherente si eligen esa arquitectura.

Los usuarios se benefician indirectamente porque un diseño de almacenamiento más seguro reduce la probabilidad de corrupción de estado relacionada con actualizaciones.

Inicializadores

Los inicializadores son funciones especiales de configuración utilizadas por los contratos actualizables en lugar de constructores.

En un contrato normal, un constructor se ejecuta cuando el contrato se despliega.

En un sistema proxy, los usuarios interactúan con el proxy y los constructores de implementación no inicializan el almacenamiento del proxy de la manera habitual.

Por este motivo, las implementaciones actualizables suelen utilizar funciones inicializadoras para establecer propietarios, nombres de tokens, permisos, valores de configuración y otros estados iniciales.

Un inicializador solo debe ejecutarse una vez, salvo que se utilice un reinicializador diseñado cuidadosamente para una actualización posterior.

Si un inicializador queda abierto, un atacante podría inicializar el contrato y obtener el control de roles importantes.

Si una nueva implementación necesita nuevas variables de estado, puede requerirse un reinicializador para configurarlas de forma segura.

Los desarrolladores deben proteger los inicializadores y desactivar la inicialización en contratos de implementación independientes cuando corresponda.

Los usuarios deben actuar con cautela cuando un contrato actualizable tiene un historial de inicialización poco claro.

Los errores de inicialización son una fuente importante de vulnerabilidades en contratos actualizables.

Autoridad de actualización

La autoridad de actualización es la cuenta, el contrato, la wallet multifirma, el timelock, la DAO o el sistema de gobernanza que puede aprobar actualizaciones.

La autoridad de actualización es una de las hipótesis de confianza más importantes de un contrato actualizable.

Si una única clave privada controla las actualizaciones, esa clave puede ser capaz de sustituir la lógica del protocolo.

Si una wallet multifirma controla las actualizaciones, los usuarios deben confiar en el grupo de firmantes y en su seguridad operativa.

Si una DAO controla las actualizaciones, los usuarios deben comprender el poder de voto, el quórum, el retraso de propuestas, el retraso de ejecución y los riesgos de ataques a la gobernanza.

Si un timelock controla las actualizaciones, los usuarios pueden tener tiempo para revisar y salir antes de que entren en vigor los cambios.

Un proceso seguro de actualización suele combinar ejecución multifirma, retraso mediante timelock, divulgación pública de propuestas, revisión de auditorías y monitorización.

La autoridad de actualización debe ser visible y estar documentada.

Los usuarios no deben considerar los contratos actualizables como trustless si un grupo pequeño puede cambiarlos de forma instantánea.

En sistemas actualizables, el diseño de gobernanza es diseño de seguridad.

Timelocks

Un timelock retrasa la ejecución después de que se proponga o apruebe una actualización.

Este retraso da tiempo a usuarios, auditores, investigadores y sistemas de monitorización para revisar el próximo cambio.

Un timelock puede reducir el riesgo de actualizaciones sorpresa que alteren inmediatamente el comportamiento del contrato.

También puede dar a los usuarios tiempo para retirar fondos si no están de acuerdo con una actualización.

Sin embargo, los timelocks no son perfectos porque las correcciones de emergencia pueden requerir rapidez durante ataques activos.

Algunos sistemas utilizan rutas de emergencia más cortas y rutas normales de gobernanza más largas.

Las rutas de emergencia pueden proteger a los usuarios frente a exploits, pero también pueden crear riesgo de centralización.

Un buen protocolo explica claramente sus reglas de timelock.

Los usuarios deben comprobar si las actualizaciones se retrasan, son inmediatas o están controladas por poderes de emergencia.

Un timelock es valioso porque transforma la autoridad de actualización de poder instantáneo en poder visible y diferido.

Actualizaciones controladas por gobernanza

Las actualizaciones controladas por gobernanza utilizan votación mediante tokens, voto delegado, aprobación por consejo, propuestas de DAO o sistemas similares para aprobar cambios de implementación.

Esto puede hacer que las actualizaciones sean más descentralizadas que una sola clave de administrador.

También puede hacer que las actualizaciones sean más lentas y complejas.

La seguridad de la gobernanza depende de la distribución de votantes, las reglas de quórum, los umbrales de propuestas, el retraso de votación, el retraso de ejecución, la delegación y la resistencia a la compra de votos o a ataques de gobernanza con flash loans.

Un voto de gobernanza no significa automáticamente que un cambio sea técnicamente seguro.

Los votantes pueden aprobar código que no comprenden por completo.

Una propuesta maliciosa puede ocultar lógica peligrosa dentro de un paquete de actualización grande.

Los protocolos deben publicar diferencias claras de actualización, auditorías, resultados de simulaciones y explicaciones en lenguaje sencillo antes de las votaciones.

Los usuarios deben revisar los procesos de actualización de gobernanza antes de depositar activos en un protocolo.

La gobernanza puede distribuir el poder, pero no elimina la necesidad de una revisión técnica de seguridad.

Contratos inmutables frente a contratos actualizables

Un contrato inteligente inmutable no puede cambiarse después del despliegue salvo que se haya diseñado con controles externos o rutas de migración.

Un contrato inteligente actualizable puede cambiar su lógica mediante un mecanismo de actualización definido.

Los contratos inmutables pueden ser más fáciles de analizar porque el código desplegado permanece fijo.

También pueden ser peligrosos si se descubre un error grave y no existe una corrección segura.

Los contratos actualizables pueden corregir errores y añadir funciones.

También pueden introducir riesgo de confianza porque la lógica futura puede diferir del código que los usuarios revisaron originalmente.

Ningún modelo es siempre mejor.

Un contrato de token sencillo puede preferir la inmutabilidad si las reglas nunca deben cambiar.

Un protocolo DeFi complejo puede necesitar capacidad de actualización para parches de seguridad y condiciones de mercado cambiantes.

El diseño adecuado depende del riesgo, la complejidad, la madurez de la gobernanza y las expectativas de los usuarios.

Migración frente a actualización

La migración consiste en desplegar un contrato nuevo y trasladar usuarios, activos o integraciones del contrato antiguo al nuevo.

La capacidad de actualización consiste en cambiar la lógica detrás de una dirección o sistema existente mientras se preserva el estado o la continuidad orientada al usuario.

La migración puede ser más fácil de entender porque el contrato antiguo permanece sin cambios y el contrato nuevo es independiente.

La migración puede resultar complicada porque los usuarios podrían tener que aprobar transferencias, mover posiciones, reclamar nuevos tokens o actualizar integraciones.

La capacidad de actualización puede ofrecer una experiencia de usuario más fluida porque la misma dirección sigue activa.

La capacidad de actualización también puede ocultar grandes cambios detrás de la misma dirección.

Algunos protocolos utilizan ambos enfoques en función de la gravedad del cambio.

Una pequeña corrección de errores puede utilizar una actualización, mientras que un rediseño importante puede utilizar una migración.

Los usuarios deben comprender si un protocolo puede cambiar in situ o requiere una migración manual.

El riesgo de migración y el riesgo de actualización son diferentes, pero ambos requieren una comunicación cuidadosa.

Verificación del código fuente

La verificación del código fuente ayuda a los usuarios a comparar el código fuente publicado con el bytecode desplegado.

La documentación de Ethereum sobre verificación de contratos inteligentes explica que la verificación compara el código fuente de un contrato inteligente y el bytecode compilado.

En los contratos actualizables, los usuarios deben verificar tanto el proxy como la implementación actual cuando sea posible.

Un proxy verificado por sí solo puede no mostrar toda la lógica de negocio.

Una implementación verificada ayuda a los usuarios a leer la lógica actual, pero aun así deben comprobar la autoridad de actualización.

Cuando un protocolo se actualiza, la nueva implementación también debe verificarse.

Los usuarios no deben asumir que un contrato sigue siendo seguro porque una implementación anterior fue auditada.

Una actualización puede añadir nuevas funciones, cambiar permisos, alterar la contabilidad o introducir nuevos errores.

La verificación es una medida de transparencia, no una garantía completa de seguridad.

Los sistemas actualizables necesitan verificación continua después de cada actualización.

Huecos de almacenamiento

Los huecos de almacenamiento son slots de almacenamiento reservados y sin utilizar que se añaden a contratos actualizables para que las versiones futuras puedan agregar variables sin desplazar inesperadamente el almacenamiento de contratos secundarios.

Este patrón es habitual en contratos actualizables con mucha herencia.

Un hueco de almacenamiento puede aparecer como un array no utilizado de tamaño fijo reservado para variables futuras.

Cuando una actualización futura añade variables de estado, los desarrolladores pueden reducir el tamaño del hueco según corresponda.

Los huecos de almacenamiento son útiles, pero requieren disciplina.

Utilizar incorrectamente el hueco puede seguir causando problemas de diseño de almacenamiento.

El almacenamiento con espacios de nombres es un enfoque más reciente que puede reducir la dependencia de grandes huecos de almacenamiento en algunas arquitecturas.

Los desarrolladores deben seguir las directrices de su framework de actualización y de las herramientas del compilador.

Los auditores deben revisar los huecos de almacenamiento y los cambios de diseño durante cada actualización.

Los usuarios no necesitan gestionar los huecos de almacenamiento, pero se benefician cuando los desarrolladores los utilizan correctamente.

Pruebas de actualización

Las pruebas de actualización comprueban si una nueva implementación funciona correctamente con el estado existente del proxy.

Las pruebas unitarias normales no son suficientes porque pueden desplegar un contrato nuevo con almacenamiento limpio.

Las pruebas de actualización deben simular la versión anterior, rellenar un estado realista, ejecutar la actualización y luego probar la nueva versión frente al estado existente.

Las pruebas deben comprobar saldos, permisos, contabilidad, aprobaciones de tokens, asignaciones de roles, ajustes de oráculos, lógica de pausas y posiciones de usuarios.

También deben comprobar que los usuarios no autorizados no puedan actualizar el contrato.

Las pruebas con forks pueden ayudar a simular actualizaciones frente al estado real de una red cuando corresponda.

Las herramientas de validación del diseño de almacenamiento pueden detectar muchos cambios inseguros antes del despliegue.

La cobertura de pruebas debe incluir tanto rutas correctas como rutas de fallo.

Cada actualización debe tratarse como un nuevo despliegue con riesgo adicional de migración.

Un protocolo que se actualiza sin pruebas rigurosas expone a los usuarios a un peligro evitable.

Auditorías de actualización

Una auditoría de actualización revisa la nueva implementación, los cambios de almacenamiento, la lógica del inicializador o reinicializador, los controles de acceso y la ruta de ejecución de la gobernanza.

Una auditoría de actualización debe comparar la versión anterior con la nueva.

El objetivo no es solo inspeccionar el código nuevo, sino también entender cómo afecta el código nuevo al estado y los usuarios existentes.

Los auditores deben revisar el diseño de almacenamiento, las llamadas externas, los permisos, la autorización de actualización, los controles de emergencia, los eventos y la compatibilidad con integraciones.

También deben revisar si la actualización crea cambios incompatibles en la ABI para aplicaciones que llaman al contrato.

Una auditoría no garantiza la seguridad, pero reduce el riesgo.

Los protocolos grandes deben publicar informes o resúmenes de auditoría cuando las actualizaciones afecten a fondos de usuarios.

Las actualizaciones pequeñas también pueden ser peligrosas si afectan a la contabilidad, los permisos, las retiradas o la lógica de oráculos.

Los usuarios deben comprobar si una actualización importante de implementación fue auditada antes de confiar en ella.

Las auditorías de actualización son una defensa esencial contra regresiones ocultas.

Compatibilidad ABI

La compatibilidad ABI significa que las aplicaciones externas pueden seguir llamando al contrato como se espera después de una actualización.

La ABI define los nombres de funciones, entradas, salidas, eventos y errores utilizados por wallets y aplicaciones.

Una actualización puede romper la compatibilidad si elimina funciones, cambia los tipos de retorno, modifica el comportamiento de los eventos o altera supuestos de los que dependen los integradores.

Los cambios incompatibles en la ABI pueden provocar fallos en aplicaciones front-end, bots, sistemas contables o integraciones DeFi.

Incluso si el almacenamiento es seguro, la experiencia de usuario puede romperse si la interfaz cambia sin coordinación.

Los desarrolladores deben documentar claramente los cambios de ABI antes de las actualizaciones.

Los integradores deben monitorizar las actualizaciones de implementación en los protocolos de los que dependen.

Los usuarios pueden ver transacciones fallidas si una aplicación no se actualiza para una nueva implementación.

La compatibilidad ABI forma parte de la seguridad de actualización porque los contratos inteligentes existen dentro de un ecosistema más amplio.

Una actualización técnicamente válida puede seguir perjudicando a usuarios reales si las interfaces cambian de forma descuidada.

Riesgo de la clave de administrador

El riesgo de la clave de administrador es el riesgo de que la clave o cuenta que controla las actualizaciones sea robada, utilizada indebidamente, perdida o controlada por una parte no fiable.

Si un atacante obtiene autoridad de actualización, puede desplegar lógica maliciosa que vacíe fondos o cambie saldos.

Si se pierde una clave de administrador, el equipo podría no poder corregir errores futuros.

Si una persona controla la clave de administrador, los usuarios deben confiar en que esa persona no actuará de forma maliciosa o negligente.

Las wallets multifirma pueden reducir el riesgo de una sola clave al exigir varias aprobaciones.

Los timelocks pueden reducir el riesgo de actualizaciones sorpresa al añadir un retraso.

La gobernanza de una DAO puede distribuir el poder de actualización, pero introduce riesgos de ataques a la gobernanza.

Los protocolos deben revelar quién controla las actualizaciones y cómo se protegen las claves.

Los usuarios deben considerar el control de administrador oculto o poco claro como una señal de advertencia importante.

En contratos actualizables, la seguridad del administrador suele ser tan importante como la seguridad del código.

Actualizaciones de emergencia

Las actualizaciones de emergencia son actualizaciones rápidas que se utilizan para corregir vulnerabilidades críticas o detener ataques activos.

Pueden proteger los fondos de los usuarios cuando esperar a un ciclo completo de gobernanza sería demasiado lento.

Las actualizaciones de emergencia también pueden crear riesgo de centralización porque pueden omitir las revisiones, votaciones o retrasos de timelock habituales.

Un protocolo debe definir los poderes de emergencia antes de que ocurra una emergencia.

Los controles de emergencia deben ser limitados, estar documentados y monitorizados, y regirse por procesos fiables.

Después de una actualización de emergencia, el equipo debe publicar información clara sobre qué cambió y por qué.

Los usuarios deben comprender si un protocolo dispone de derechos de actualización de emergencia.

Un protocolo sin ruta de emergencia puede responder más lentamente a los exploits.

Un protocolo con poder de emergencia ilimitado puede requerir demasiada confianza.

El mejor diseño equilibra una protección rápida con transparencia y rendición de cuentas.

Tokens actualizables

Los tokens actualizables son contratos de tokens cuya lógica puede cambiar después del despliegue.

Esto puede permitir correcciones de errores, cambios de cumplimiento, nuevos modelos de comisiones, cambios de bridge o actualizaciones de funciones.

También puede permitir cambios peligrosos, como nuevos derechos de acuñación, restricciones de transferencia, listas negras o comisiones inesperadas.

Los usuarios deben comprobar si un contrato de token es actualizable antes de asumir que sus reglas son fijas.

Un token con autoridad de actualización puede cambiar su comportamiento aunque su nombre, símbolo y dirección sigan siendo los mismos.

Los titulares del token deben revisar los roles de administrador, la autoridad de acuñación, los controles de pausa, las funciones de lista negra y la gobernanza de actualización.

El código fuente verificado debe comprobarse después de actualizaciones importantes.

Los proveedores de liquidez deben ser especialmente cautos porque los cambios en las reglas del token pueden afectar a los pools de trading.

Un token actualizable puede ser legítimo, pero tiene un modelo de confianza distinto al de un token inmutable.

La capacidad de actualización del token debe divulgarse claramente a los usuarios.

Protocolos DeFi actualizables

Los protocolos DeFi actualizables pueden cambiar la lógica de préstamos, swaps, staking, liquidaciones, estrategias de vault, tipos de interés o reglas de colateral.

Esta flexibilidad puede ser útil porque los mercados DeFi cambian rápidamente y los errores pueden ser graves.

También puede crear riesgo porque las reglas del protocolo pueden cambiar después de que los usuarios depositen fondos.

Una actualización podría alterar la lógica de retirada, los cálculos de comisiones, los parámetros de riesgo, las fuentes de oráculos o el comportamiento de liquidación.

Los usuarios deben comprobar si las actualizaciones del protocolo DeFi están controladas por un equipo, una wallet multifirma, un timelock o un proceso de gobernanza.

También deben comprobar si los contratos críticos son inmutables o actualizables.

Un protocolo puede tener algunos contratos inmutables y otros actualizables.

El riesgo de actualización en DeFi es especialmente importante porque los contratos suelen mantener liquidez agrupada.

Una mala actualización puede afectar a muchos usuarios a la vez.

DeFi actualizable requiere monitorización continua, no confianza puntual.

Actualización y oráculos

Los oráculos proporcionan datos externos, como precios de activos, a los contratos inteligentes.

Un protocolo actualizable puede ser capaz de cambiar la lógica de los oráculos o las direcciones de los oráculos.

La documentación de Ethereum sobre oráculos explica que los oráculos son necesarios porque los contratos inteligentes no pueden acceder directamente a datos off-chain por sí mismos.

La capacidad de actualización de los oráculos puede ser útil cuando un feed anterior deja de ser fiable o se dispone de una fuente mejor.

Puede ser peligrosa si un administrador puede cambiar a un oráculo manipulado o malicioso.

En sistemas de préstamos y derivados, una mala actualización de oráculo puede provocar liquidaciones injustas o liquidaciones incorrectas.

Los usuarios deben comprobar quién puede cambiar las fuentes de oráculos y si dichos cambios están sujetos a timelock.

Los desarrolladores deben utilizar una gobernanza y monitorización sólidas de los oráculos.

Los cambios de oráculos deben tratarse como actualizaciones de alto riesgo.

Las fuentes de datos forman parte de la lógica de los contratos inteligentes incluso cuando se encuentran fuera del código principal del contrato.

Actualización y bridges

Los bridges suelen utilizar contratos actualizables porque la lógica del bridge debe responder a nuevas cadenas, formatos de mensajes, conjuntos de validadores, controles de riesgo y parches de seguridad.

La capacidad de actualización de un bridge puede mejorar su adaptabilidad.

También puede crear un importante riesgo de confianza porque los bridges pueden controlar grandes cantidades de activos bloqueados o acuñados.

Una actualización maliciosa de un bridge podría cambiar las reglas de retirada, acuñar activos envueltos de forma indebida o redirigir fondos.

Los usuarios deben comprobar la autoridad de actualización del bridge, la gobernanza de validadores, los timelocks, las auditorías y los controles de emergencia.

Los bridges ya son complejos porque dependen de varias redes e hipótesis de verificación.

La capacidad de actualización añade otra capa de riesgo.

Un contrato bridge con una gobernanza de actualización sólida puede ser más seguro que uno controlado por una única clave.

Sin embargo, ningún proceso de actualización elimina todos los riesgos de los bridges.

Los usuarios de bridges deben comprender tanto las hipótesis técnicas como las de gobernanza antes de transferir activos.

Actualización y confianza de los usuarios

La capacidad de actualización crea una disyuntiva de confianza.

Los usuarios obtienen el beneficio de correcciones de errores y mejoras de funciones.

Los usuarios aceptan el riesgo de que la lógica futura pueda cambiar de maneras que no les gusten.

Un proceso de actualización transparente puede mejorar la confianza al mostrar qué cambiará antes de que cambie.

Un proceso de actualización oculto o instantáneo puede reducir la confianza porque los usuarios no pueden evaluar los cambios a tiempo.

Los protocolos deben explicar los derechos de actualización en lenguaje sencillo.

Deben publicar direcciones de implementación, direcciones de administrador, detalles del timelock, informes de auditoría y propuestas de gobernanza.

Los usuarios no deben limitarse a preguntar si un contrato está auditado.

Deben preguntar si el código auditado puede sustituirse mañana.

En contratos inteligentes actualizables, la confianza depende tanto del código actual como del control sobre cambios futuros.

Cómo comprobar si un contrato es actualizable

Empieza comprobando la página del contrato en un explorador de blockchain para ver si está etiquetado como proxy.

Después, comprueba la dirección de implementación si el explorador muestra una.

Revisa si el proxy sigue un patrón conocido como ERC-1967, Transparent Proxy, UUPS, Beacon Proxy o Diamond.

Comprueba si el código fuente de implementación está verificado.

Comprueba quién controla las actualizaciones mediante direcciones de administrador, roles de propietario, wallets multifirma, timelocks o contratos de gobernanza.

Revisa los eventos recientes en busca de cambios de implementación o transacciones de actualización.

Lee la documentación del protocolo para comprender la política de actualización.

Consulta los informes de auditoría para ver si la capacidad de actualización estaba incluida en el alcance.

Monitoriza las propuestas de gobernanza si el protocolo utiliza actualizaciones controladas por una DAO.

Una dirección de contrato por sí sola no es suficiente porque los sistemas actualizables requieren revisar conjuntamente el proxy, la implementación y la estructura de autoridad.

Errores comunes en la actualización de contratos inteligentes

Un error común es cambiar el orden de las variables de almacenamiento durante una actualización.

Otro error es olvidar proteger las funciones inicializadoras.

Un tercer error es utilizar una única clave privada como único administrador de actualizaciones.

Un cuarto error es actualizar sin un timelock o aviso público.

Un quinto error es desplegar una nueva implementación sin verificar el código fuente.

Un sexto error es asumir que una auditoría anterior sigue cubriendo una nueva implementación.

Un séptimo error es cambiar la ABI de forma que se rompan las integraciones.

Un octavo error es no probar las actualizaciones con un estado existente similar al de producción.

Un noveno error es utilizar lógica proxy personalizada sin una revisión exhaustiva.

Un décimo error es decir a los usuarios que un sistema está descentralizado mientras un pequeño grupo de administradores puede sustituir instantáneamente la lógica.

Ventajas de la actualización de contratos inteligentes

La primera ventaja es la capacidad de corregir errores después del despliegue.

La segunda ventaja es la capacidad de añadir funciones sin obligar a los usuarios a migrar manualmente.

La tercera ventaja es la continuidad de direcciones para usuarios, wallets e integraciones.

La cuarta ventaja es una mayor capacidad de respuesta durante emergencias.

La quinta ventaja es una mejor mantenibilidad a largo plazo para protocolos complejos.

La sexta ventaja es una iteración de producto más fluida en mercados cripto que evolucionan rápidamente.

La séptima ventaja es la capacidad de actualizar integraciones de oráculos, parámetros de riesgo o dependencias externas.

La octava ventaja es una menor fricción de migración cuando evoluciona el diseño del protocolo.

Estas ventajas explican por qué muchas aplicaciones cripto sofisticadas eligen arquitecturas actualizables.

Las ventajas son mayores cuando la autoridad de actualización es transparente, segura, diferida, auditada y gobernada de manera responsable.

Riesgos y limitaciones de la actualización de contratos inteligentes

El primer riesgo es una autoridad de actualización maliciosa o comprometida.

El segundo riesgo es la corrupción del almacenamiento durante un cambio inseguro de implementación.

El tercer riesgo es el uso indebido de inicializadores o reinicializadores.

El cuarto riesgo es la centralización oculta mediante claves de administrador.

El quinto riesgo son las integraciones rotas debido a cambios de ABI o comportamiento.

El sexto riesgo es la confusión de los usuarios porque la dirección visible puede seguir siendo la misma mientras cambia la lógica.

El séptimo riesgo es el abuso de actualizaciones de emergencia.

El octavo riesgo es una falsa confianza derivada de una auditoría que solo cubría una implementación antigua.

El noveno riesgo es la captura de la gobernanza o votaciones apresuradas.

El décimo riesgo es la complejidad que dificulta que usuarios y auditores comprendan el sistema.

Buenas prácticas para desarrolladores

Utiliza bibliotecas de actualización maduras y bien revisadas en lugar de código proxy personalizado cuando sea posible.

Elige un patrón de actualización claro como Transparent Proxy, UUPS, Beacon Proxy o Diamond solo después de comprender sus ventajas e inconvenientes.

Valida el diseño de almacenamiento antes de cada actualización.

Protege cuidadosamente los inicializadores y reinicializadores.

Utiliza control multifirma, timelocks y procesos de gobernanza para una autoridad de actualización significativa.

Publica direcciones de implementación, transacciones de actualización y explicaciones de actualizaciones en lenguaje sencillo.

Verifica el código fuente de cada nueva implementación.

Ejecuta pruebas de actualización frente a estados similares a producción y entornos con fork cuando corresponda.

Audita las actualizaciones importantes antes de ejecutarlas.

Monitoriza los eventos de actualización y prepara planes de reversión o respuesta a incidentes cuando la arquitectura lo permita.

Buenas prácticas para usuarios

Comprueba si un contrato es actualizable antes de depositar fondos.

Revisa quién controla la autoridad de actualización.

Prefiere protocolos que utilicen timelocks, controles multifirma, auditorías y gobernanza pública para las actualizaciones.

Comprueba si el código fuente de la implementación actual está verificado.

No asumas que una auditoría anterior cubre una nueva implementación.

Monitoriza los anuncios de actualizaciones importantes del protocolo si utilizas mucho el protocolo.

Comprende si las actualizaciones de emergencia pueden omitir los retrasos habituales.

Revisa los roles de administrador, los controles de pausa, los controles de oráculos y los permisos de acuñación de tokens.

Considera retirar fondos antes de actualizaciones controvertidas o poco claras cuando sea posible.

Considera la capacidad de actualización como una hipótesis de confianza, no como un detalle técnico menor.

Preguntas frecuentes

¿Qué significa la actualización de contratos inteligentes?

La actualización de contratos inteligentes significa que un sistema de contratos inteligentes desplegado puede cambiar su lógica después del despliegue mediante un mecanismo de actualización diseñado para ello.

¿Por qué se actualizan los contratos inteligentes?

Los contratos inteligentes se actualizan para corregir errores, añadir funciones, mejorar la seguridad, actualizar integraciones, ajustar controles de riesgo o responder a necesidades cambiantes del protocolo.

¿Son menos seguros los contratos inteligentes actualizables?

Los contratos inteligentes actualizables no son automáticamente menos seguros, pero añaden riesgos relacionados con el control de administrador, el diseño de almacenamiento, la gobernanza y los cambios futuros de implementación.

¿Qué es un contrato proxy?

Un contrato proxy es una dirección estable que reenvía llamadas a un contrato de implementación mientras normalmente preserva el estado del sistema.

¿Qué es un contrato de implementación?

Un contrato de implementación contiene la lógica que un proxy ejecuta mediante delegación.

¿Cuál es el mayor riesgo de las actualizaciones de contratos inteligentes?

El mayor riesgo es que una autoridad de actualización autorizada o comprometida pueda sustituir una lógica segura por una lógica defectuosa o maliciosa.

¿Qué es el riesgo de diseño de almacenamiento?

El riesgo de diseño de almacenamiento es la posibilidad de que una nueva implementación lea o escriba incorrectamente el almacenamiento existente del proxy y corrompa un estado importante.

¿Qué es un timelock en la capacidad de actualización?

Un timelock retrasa la ejecución de una actualización para que los usuarios y revisores tengan tiempo de inspeccionar los cambios propuestos antes de que entren en vigor.

¿El código fuente verificado significa que un contrato actualizable es seguro?

No, el código fuente verificado mejora la transparencia, pero los usuarios deben seguir revisando la autoridad de actualización, las auditorías, la seguridad del almacenamiento, la gobernanza y el riesgo de cambios futuros.

¿Cómo puedo saber si un contrato es actualizable?

Puedes comprobar las etiquetas de proxy del explorador de blockchain, las direcciones de implementación, los slots ERC-1967, los eventos de actualización, los roles de administrador, la documentación de gobernanza y los informes de auditoría.

Conclusión

La actualización de contratos inteligentes es el enfoque de diseño que permite a las aplicaciones blockchain cambiar la lógica de sus contratos después del despliegue, preservando direcciones y estados importantes.

Se utiliza ampliamente porque las aplicaciones cripto suelen necesitar correcciones de errores, mejoras de funciones, parches de seguridad y actualizaciones de integraciones después del lanzamiento.

Los diseños de actualización más comunes utilizan proxies, contratos de implementación, delegatecall, slots de almacenamiento estandarizados y una autoridad de actualización controlada.

La capacidad de actualización puede hacer que los protocolos sean más mantenibles y resilientes, pero también cambia el modelo de confianza porque el código futuro puede diferir del código que los usuarios revisaron originalmente.

La seguridad de un sistema actualizable depende de la disciplina en el diseño de almacenamiento, la protección de inicializadores, la verificación del código fuente, las pruebas, las auditorías, la seguridad de las claves de administrador, los timelocks y una gobernanza transparente.

Los usuarios nunca deben considerar un contrato actualizable como plenamente inmutable, salvo que la autoridad de actualización se haya eliminado o se haya hecho imposible por diseño.

Los desarrolladores nunca deben considerar la capacidad de actualización como un simple atajo, ya que el patrón añade importantes responsabilidades de ingeniería y gobernanza.

Para principiantes, la actualización de contratos inteligentes se entiende mejor como una forma de actualizar software blockchain después del despliegue.

Para usuarios avanzados, es un modelo de seguridad completo que implica arquitectura proxy, compatibilidad de almacenamiento, control de acceso, ejecución de gobernanza, monitorización y derechos de salida de los usuarios.

En el contexto del glosario cripto, la actualización de contratos inteligentes significa la capacidad de un sistema de contratos inteligentes desplegado para cambiar su lógica mediante un mecanismo controlado mientras mantiene intactos el estado on-chain importante y las direcciones orientadas al usuario.

La idea clave es que la actualización de contratos inteligentes puede proteger a los usuarios frente a errores permanentes y respaldar la evolución del protocolo, pero debe gestionarse con transparencia, controles sólidos, pruebas cuidadosas y divulgación clara, ya que el poder de actualización también puede convertirse en una importante fuente de riesgo.