Contrato actualizable

¿Qué es un contrato actualizable?

Un contrato actualizable es un diseño de contrato inteligente que permite a una aplicación blockchain modificar o ampliar su lógica después del despliegue, manteniendo la misma dirección visible para el usuario, el estado almacenado y el saldo.

En criptomonedas, los contratos actualizables se utilizan principalmente en protocolos DeFi, sistemas de tokens, contratos de staking, bridges, mercados de préstamos, cuentas inteligentes, sistemas de gobernanza y otras aplicaciones on-chain que pueden necesitar correcciones o nuevas funciones con el tiempo.

Los contratos inteligentes tradicionales suelen describirse como inmutables porque su código desplegado no puede editarse directamente una vez que está on-chain.

Los contratos actualizables resuelven esta limitación separando la dirección del contrato y los datos almacenados de la lógica de negocio que ejecuta las acciones de los usuarios.

La forma más habitual de crear un contrato actualizable es el patrón proxy, en el que los usuarios interactúan con un contrato proxy y este reenvía las llamadas a un contrato de implementación independiente.

El proxy mantiene la misma dirección pública, mientras que el contrato de implementación puede sustituirse por una versión más reciente cuando se realiza una actualización autorizada.

Esto significa que los usuarios no necesitan trasladarse a una nueva dirección de contrato cada vez que un protocolo corrige un error, añade una función o mejora su lógica interna.

Para los usuarios de criptomonedas, el principal beneficio es la continuidad, ya que los saldos de tokens, los registros de staking, el poder de voto y las posiciones en el protocolo pueden permanecer en el mismo almacenamiento del contrato.

Para los desarrolladores, el principal beneficio es la flexibilidad, ya que pueden mejorar un protocolo sin obligar a una migración completa de fondos y datos de los usuarios.

Para inversores y traders, la principal preocupación es el riesgo de gobernanza, ya que el poder de actualización puede cambiar el comportamiento de un protocolo después de que los usuarios hayan depositado activos.

Cómo funcionan los contratos actualizables

Un contrato actualizable suele tener al menos dos elementos principales: el contrato proxy y el contrato de implementación.

El contrato proxy es la dirección con la que suelen interactuar los usuarios, las wallets, los exploradores de blockchain y otros contratos inteligentes.

El contrato de implementación contiene la lógica real, como las reglas de transferencia, los cálculos de staking, las funciones de préstamo, la distribución de recompensas o las comprobaciones de control de acceso.

Cuando un usuario envía una transacción al proxy, este utiliza un mecanismo de bajo nivel denominado

para ejecutar código del contrato de implementación.

Con

, la lógica de implementación se ejecuta como si formara parte del proxy, pero el almacenamiento, la dirección y el saldo permanecen vinculados al proxy.

Por ello, el proxy puede conservar los datos de los usuarios mientras cambia la dirección de implementación durante una actualización.

La actualización propiamente dicha suele producirse cuando un administrador autorizado, una wallet multisig, un contrato de gobernanza o un timelock cambia el puntero de implementación del proxy por un nuevo contrato de implementación.

La nueva implementación debe diseñarse cuidadosamente para funcionar con la estructura de almacenamiento existente del proxy.

Si la estructura de almacenamiento se rompe, el contrato actualizado puede interpretar incorrectamente los saldos, los registros de propiedad, los permisos u otros datos críticos.

Esta es una de las principales razones por las que los contratos actualizables requieren una ingeniería, pruebas y auditorías más estrictas que los contratos simples no actualizables.

Por qué los contratos actualizables son importantes en cripto

Los contratos actualizables son importantes porque las aplicaciones cripto suelen proteger activos reales y no pueden depender de los métodos tradicionales de actualización de software.

En las aplicaciones web normales, los desarrolladores pueden aplicar parches al código backend, volver a desplegar servicios o cambiar bases de datos sin pedir a los usuarios que trasladen sus activos.

En las blockchains públicas, el código de contrato desplegado suele ser permanente, por lo que un error grave puede requerir una migración difícil si el contrato no es actualizable.

Un diseño actualizable puede reducir este problema al permitir actualizaciones controladas de la lógica del protocolo.

Esto resulta útil cuando un proyecto necesita corregir vulnerabilidades, admitir nuevos estándares de tokens, añadir controles de riesgo, mejorar la eficiencia de gas o responder a cambios en el ecosistema blockchain.

Sin embargo, la capacidad de actualización también modifica el modelo de confianza de una aplicación cripto.

Si una dirección puede actualizar un contrato al instante, los usuarios deben confiar en que esa dirección no instalará lógica maliciosa o negligente.

Si las actualizaciones están controladas por una gobernanza descentralizada, los usuarios deben confiar en el proceso de gobernanza, las reglas de votación, el timelock y la participación de los votantes.

Un contrato actualizable bien diseñado debe equilibrar la flexibilidad con límites sólidos sobre quién puede actualizarlo, cuándo pueden realizarse actualizaciones y cómo pueden supervisar los usuarios los cambios.

Patrón proxy

El patrón proxy es la arquitectura más utilizada para los contratos actualizables.

En este patrón, el contrato proxy almacena el estado y reenvía las llamadas de funciones al contrato de implementación.

El contrato de implementación contiene la lógica de negocio, pero los usuarios habituales no deben utilizarlo directamente.

Cuando el protocolo se actualiza, se despliega un nuevo contrato de implementación y el proxy se actualiza para apuntar a esa nueva implementación.

La dirección visible para el usuario no cambia, por lo que las wallets, integraciones y otros contratos pueden seguir llamando a la dirección del proxy.

Este diseño se explica detalladamente en la documentación de Ethereum sobre actualización de contratos inteligentes.

El patrón proxy es potente porque evita la migración manual del estado, que puede ser costosa, arriesgada y confusa para los usuarios.

También es peligroso cuando los desarrolladores no comprenden el funcionamiento del almacenamiento del proxy, los selectores de función, las funciones inicializadoras y los permisos de administrador.

Un proxy no es automáticamente seguro solo por ser actualizable.

La seguridad del diseño depende de la calidad de la implementación, los permisos de actualización, las pruebas, la gobernanza y la supervisión.

Contrato de implementación

El contrato de implementación a veces se denomina contrato de lógica porque contiene el código que define el funcionamiento de la aplicación.

Por ejemplo, en un contrato de token, la implementación puede definir las reglas de transferencia, aprobaciones, límites de acuñación, lógica de quema y permisos basados en roles.

En un contrato de staking, la implementación puede definir reglas de depósito, reglas de retirada, fórmulas de recompensa, lógica de penalización y controles de emergencia.

En un contrato de préstamo, la implementación puede definir reglas de garantía, cálculos de intereses, lógica de liquidación y parámetros de riesgo.

Cuando un proxy delega una llamada a la implementación, el código de implementación utiliza el almacenamiento del proxy.

Esto significa que la implementación debe escribirse como si sus variables fueran a almacenarse dentro del contrato proxy.

Normalmente, los desarrolladores deben impedir que los usuarios inicialicen o utilicen indebidamente el contrato de implementación directamente.

También deben asegurarse de que cualquier nueva implementación sea compatible con la estructura de almacenamiento de la versión anterior.

Una nueva implementación que modifique incorrectamente el almacenamiento puede causar daños permanentes a los datos on-chain.

Estructura de almacenamiento

La estructura de almacenamiento es uno de los conceptos más importantes para la seguridad de los contratos actualizables.

En Solidity, las variables de estado se colocan en slots de almacenamiento conforme a reglas específicas, incluido el orden de las variables y el orden de herencia.

Cuando se actualiza un contrato, la nueva implementación debe interpretar el almacenamiento existente del proxy de la misma forma que la implementación anterior.

Los desarrolladores suelen añadir nuevas variables únicamente después de las variables existentes, en lugar de eliminar variables, reordenarlas o modificar sus tipos.

Si un contrato almacenaba originalmente el saldo de un usuario en un slot, la nueva versión no debe tratar accidentalmente ese mismo slot como una dirección de administrador o una variable de recompensa.

Las colisiones de almacenamiento pueden provocar saldos incorrectos, pérdida de permisos, contabilidad errónea o comportamiento explotable del contrato.

La documentación de Solidity sobre estructura de almacenamiento explica cómo organiza Solidity las variables de estado en el almacenamiento persistente.

Las bibliotecas modernas de contratos actualizables también incluyen herramientas y comprobaciones que ayudan a los desarrolladores a detectar cambios de almacenamiento inseguros antes del despliegue.

Incluso con herramientas, la estructura de almacenamiento debe revisarse cuidadosamente en cada actualización.

Slots de almacenamiento de proxy ERC-1967

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

El objetivo de ERC-1967 es reducir las colisiones de almacenamiento entre el proxy y el contrato de implementación.

También ayuda a los exploradores de blockchain y las herramientas de desarrollo a identificar la implementación que hay detrás de un proxy.

Sin un slot de almacenamiento estándar, sería más difícil para las wallets, los exploradores, los auditores y las herramientas de supervisión entender qué contrato de lógica utiliza un proxy.

ERC-1967 es especialmente importante porque el propio proxy necesita almacenar datos relacionados con las actualizaciones, mientras que la implementación también espera utilizar el almacenamiento del proxy.

La especificación oficial ERC-1967 define estas convenciones de slots de almacenamiento para proxy.

Para los usuarios de criptomonedas, ERC-1967 puede facilitar la inspección de los contratos actualizables, ya que muchas herramientas pueden mostrar la dirección de implementación actual.

Para los desarrolladores, ERC-1967 proporciona una forma más segura y estándar de almacenar metadatos del proxy.

Almacenamiento con espacios de nombres ERC-7201

ERC-7201 es un estándar más reciente para la estructura de almacenamiento con espacios de nombres en contratos inteligentes.

El almacenamiento con espacios de nombres agrupa variables de estado relacionadas bajo un espacio de nombres específico para reducir conflictos de estructura de almacenamiento, especialmente en sistemas actualizables complejos.

Esto resulta útil cuando los contratos utilizan herencia, módulos, plugins o varios componentes actualizables.

OpenZeppelin Contracts 5.x utiliza patrones de contratos actualizables que incluyen espacios de nombres de almacenamiento de estilo ERC-7201 en las variantes actualizables.

La especificación oficial ERC-7201 describe una convención para documentar ubicaciones de almacenamiento con espacios de nombres en el código fuente de Solidity.

Para los desarrolladores, el almacenamiento con espacios de nombres puede facilitar el razonamiento sobre las actualizaciones, ya que cada componente del contrato puede conservar su propia área de almacenamiento.

Para los usuarios, el almacenamiento con espacios de nombres es en gran medida invisible, pero puede mejorar la seguridad si se implementa correctamente.

No elimina la necesidad de auditorías, pruebas y una revisión cuidadosa de las actualizaciones.

Inicializadores en lugar de constructores

Los contratos actualizables suelen utilizar funciones inicializadoras en lugar de constructores.

Un constructor normal se ejecuta únicamente cuando se despliega un contrato, pero en un diseño proxy, el proxy utiliza el código de la implementación sin ejecutar el constructor de la implementación para el estado del proxy.

Por ello, los contratos actualizables suelen trasladar la lógica de configuración a una función como

.

El inicializador establece valores como el nombre del token, el símbolo del token, la dirección del propietario, los roles de administrador, los parámetros de comisión o la configuración inicial.

El inicializador debe estar protegido para que solo pueda ejecutarse una vez en cada proxy.

Si un inicializador puede invocarse más de una vez, un atacante puede restablecer la propiedad, cambiar permisos o tomar el control del contrato.

La guía de OpenZeppelin para escribir contratos actualizables explica por qué los constructores se sustituyen por funciones inicializadoras en los contratos actualizables basados en proxies.

Los buenos contratos actualizables también utilizan cuidadosamente funciones reinicializadoras cuando una nueva versión añade nuevos requisitos de configuración.

Todos los inicializadores y reinicializadores deben revisarse como parte del proceso de actualización.

Proxy transparente

Un proxy transparente es un diseño de proxy que separa las llamadas de administrador de las llamadas de usuario.

En este modelo, el administrador puede realizar acciones relacionadas con las actualizaciones, mientras que los usuarios habituales se reenvían al contrato de implementación.

El patrón de proxy transparente ayuda a evitar un problema por el cual un administrador activa accidentalmente funciones de implementación a través del proxy.

También reduce el riesgo de conflictos entre los selectores de funciones de administrador del proxy y las funciones de implementación.

Este patrón es habitual en sistemas de producción porque proporciona una estructura de administración clara para las actualizaciones.

Como contrapartida, puede implicar componentes adicionales de despliegue y gestión, como un contrato de administrador de proxy.

Para los usuarios, el punto importante es identificar quién controla el administrador del proxy y si las actualizaciones están retrasadas, gobernadas o supervisadas externamente.

Proxy UUPS

UUPS significa Universal Upgradeable Proxy Standard.

En un diseño UUPS, la lógica de actualización suele ubicarse en el contrato de implementación, en lugar de gestionarse por completo desde el propio proxy.

Esto puede hacer que el proxy sea más pequeño y más barato de desplegar, pero también significa que la implementación debe incluir y proteger correctamente la función de actualización.

Si la lógica de autorización de actualización es incorrecta, el contrato puede quedar expuesto a actualizaciones no autorizadas.

Si la función de actualización se elimina o se rompe en una implementación futura, el proxy puede volverse difícil o imposible de actualizar de nuevo.

Los proxies UUPS son populares, pero requieren un control de acceso y pruebas cuidadosos.

Los usuarios deben comprobar si un contrato UUPS dispone de una autoridad de actualización clara, un timelock y un historial público de actualizaciones.

Proxy beacon

Un proxy beacon es un diseño en el que varios contratos proxy obtienen su dirección de implementación de un contrato beacon compartido.

Esto permite actualizar a la vez muchas instancias de proxy modificando la dirección de implementación almacenada en el beacon.

Los proxies beacon pueden resultar útiles cuando un protocolo despliega muchos contratos similares, como bóvedas, pools, cuentas o posiciones tokenizadas.

La principal ventaja es la eficiencia operativa, ya que una actualización del beacon puede actualizar numerosos proxies.

El principal riesgo es la concentración, porque una actualización defectuosa del beacon puede afectar a muchos contratos al mismo tiempo.

La propiedad del beacon y los permisos de actualización deben protegerse mediante una gobernanza y supervisión sólidas.

Patrón diamond

El patrón diamond es una arquitectura de actualización en la que un proxy puede dirigir distintas llamadas de función a diferentes contratos de implementación, denominados habitualmente facets.

Esto permite dividir un gran sistema de contratos inteligentes en módulos más pequeños.

Un diseño diamond puede actualizar una parte del sistema sin sustituir todas las funciones a la vez.

Puede ser útil para protocolos cripto complejos que necesitan muchas funciones bajo una sola dirección.

La contrapartida es la complejidad, ya que los desarrolladores deben gestionar con mucho cuidado los selectores de función, el almacenamiento de facets, el control de acceso y las reglas de actualización.

Los sistemas de estilo diamond pueden ser potentes, pero pueden resultar más difíciles de inspeccionar para los usuarios medios que las estructuras proxy más sencillas.

Ventajas de los contratos actualizables

La primera ventaja de los contratos actualizables es la corrección de errores.

Si se descubre un problema grave, los desarrolladores pueden ser capaces de aplicar un parche a la lógica sin obligar a los usuarios a migrar manualmente sus fondos.

La segunda ventaja es la ampliación de funciones.

Un protocolo puede añadir nuevos tipos de garantía, nuevas reglas de recompensa, nuevos módulos o nuevos controles de seguridad manteniendo la misma dirección de contrato.

La tercera ventaja es la estabilidad de las integraciones.

Las wallets, plataformas de análisis, agregadores y otros contratos inteligentes pueden seguir apuntando a la misma dirección proxy después de una actualización.

La cuarta ventaja es la experiencia de usuario.

Es posible que los usuarios no necesiten aprobar, retirar, volver a depositar o mover posiciones manualmente durante cada actualización del protocolo.

La quinta ventaja es la respuesta ante emergencias.

Un proceso de actualización bien gobernado puede ayudar a un protocolo a responder a riesgos activos con mayor rapidez que un proceso de migración completo.

Riesgos de los contratos actualizables

El mayor riesgo de un contrato actualizable es el abuso administrativo.

Si la autoridad de actualización está controlada por una clave privada débil, un equipo negligente o un proceso de gobernanza comprometido, el contrato puede modificarse de forma perjudicial.

Una actualización maliciosa podría vaciar fondos, bloquear retiradas, modificar comisiones, alterar saldos o eliminar protecciones para los usuarios.

Otro riesgo importante es la corrupción del almacenamiento.

Una actualización de implementación mal diseñada puede romper la relación entre los datos antiguos y la nueva lógica.

Un tercer riesgo es la complejidad oculta.

Los usuarios pueden pensar que interactúan con un único contrato, pero el comportamiento real depende de la dirección de implementación actual y de los permisos de actualización.

Un cuarto riesgo es una supervisión deficiente.

Si los usuarios y las integraciones no siguen las actualizaciones, pueden pasar por alto cambios importantes en el comportamiento del protocolo.

Un quinto riesgo es la captura de la gobernanza.

Si el poder de voto está concentrado, un grupo reducido puede aprobar actualizaciones que le beneficien a costa de otros usuarios.

Cómo pueden evaluar los usuarios un contrato actualizable

Los usuarios deben comprobar primero si el contrato es un proxy y qué implementación utiliza actualmente.

Muchos exploradores de blockchain muestran información de proxy cuando el contrato sigue estándares comunes de proxy como ERC-1967.

Los usuarios también deben comprobar quién tiene permiso para actualizar el contrato.

Una actualización controlada por una única cuenta de propiedad externa suele ser más arriesgada que una actualización controlada por una multisig, un timelock o un proceso de gobernanza transparente.

Los usuarios deben revisar si el proyecto anuncia las actualizaciones antes de que se produzcan.

También deben comprobar si el contrato ha sido auditado, si los informes de auditoría cubren la lógica de actualización y si las actualizaciones anteriores se ejecutaron de forma segura.

En el caso de depósitos grandes, los usuarios deben prestar atención a la duración del timelock, los poderes de pausa de emergencia, los cambios de roles administrativos y el historial de eventos de actualización.

Un contrato puede estar técnicamente bien escrito y seguir siendo arriesgado si su autoridad de actualización está demasiado centralizada o se supervisa mal.

Mejores prácticas para desarrolladores

Los desarrolladores deben utilizar frameworks de actualización bien revisados en lugar de escribir lógica de proxy desde cero, salvo que tengan una amplia experiencia en seguridad.

Deben proteger las funciones de actualización con un control de acceso sólido, como propiedad multisig, permisos basados en roles, timelocks o gobernanza on-chain.

Deben escribir pruebas automatizadas tanto para el despliegue original como para cada ruta de actualización.

Deben comparar las estructuras de almacenamiento antes y después de las actualizaciones para detectar cambios inseguros.

Deben utilizar protección de inicializadores y evitar funciones de configuración sin protección.

Deben evitar patrones peligrosos de bajo nivel salvo que sean necesarios y se hayan revisado por completo.

Deben publicar el código fuente de implementación y facilitar la inspección de las relaciones de proxy.

Deben emitir eventos claros cuando se produzcan actualizaciones para que los sistemas de supervisión puedan detectar los cambios.

Deben documentar qué ha cambiado, por qué ha cambiado y qué riesgos se han considerado.

Deben planificar la respuesta ante emergencias sin otorgar poder ilimitado a un único actor.

Contrato actualizable frente a contrato inmutable

Un contrato inmutable no puede modificar su código desplegado después del despliegue.

Esto ofrece a los usuarios una gran previsibilidad porque las reglas están fijadas, salvo que el contrato ya incluya parámetros configurables.

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

Esto ofrece flexibilidad a los desarrolladores, pero exige que los usuarios confíen en el proceso de actualización.

Los contratos inmutables suelen preferirse para activos simples, protocolos mínimos o sistemas en los que las reglas fijas son más importantes que la flexibilidad futura.

Los contratos actualizables suelen preferirse para protocolos complejos que pueden necesitar parches, controles de riesgo, integraciones y mantenimiento a largo plazo.

Ninguno de los dos diseños es siempre mejor.

La elección adecuada depende del valor protegido, la complejidad de la aplicación, las necesidades de actualización previstas y la solidez de la gobernanza.

Por qué la capacidad de actualización afecta al riesgo del token y del protocolo

Los contratos actualizables pueden afectar directamente a los titulares de tokens porque la lógica del contrato puede definir la acuñación, la quema, las restricciones de transferencia, las comisiones o los derechos de gobernanza.

Si una actualización modifica las reglas del token, puede afectar a la confianza del mercado y a la utilidad del token.

Los contratos de staking actualizables pueden afectar a las tasas de recompensa, los periodos de bloqueo, las penalizaciones y el comportamiento de las retiradas.

Los contratos de préstamo actualizables pueden afectar a los ratios de garantía, los umbrales de liquidación, los tipos de interés y los controles de riesgo de mercado.

Los bridges actualizables pueden afectar a la custodia de activos, la verificación de mensajes y la lógica de retirada.

Por ello, los traders e inversores a largo plazo deben considerar los permisos de actualización como parte del análisis fundamental del protocolo.

Un token puede parecer descentralizado a nivel de mercado y seguir dependiendo de un contrato que un pequeño grupo puede actualizar.

Comprender la capacidad de actualización ayuda a los usuarios a evaluar si las reglas de un protocolo están realmente fijadas o siguen sujetas a cambios.

Malentendidos habituales

Un malentendido habitual es pensar que un contrato actualizable implica que el código del contrato original se edita on-chain.

En la mayoría de los diseños proxy, el código proxy original no se edita, sino que el proxy pasa a apuntar a un contrato de implementación diferente.

Otro malentendido es que la capacidad de actualización siempre es negativa.

La capacidad de actualización puede ser útil cuando es transparente, limitada, auditada y gobernada de forma responsable.

Un tercer malentendido es que las auditorías eliminan el riesgo de actualización.

Una auditoría puede revisar el código actual y el proceso de actualización, pero las implementaciones futuras pueden introducir nuevos riesgos.

Un cuarto malentendido es que los usuarios solo necesitan comprobar la dirección del contrato del token.

En los sistemas actualizables, los usuarios también deben comprobar los contratos de implementación, los roles de administrador y los eventos de actualización.

Un quinto malentendido es que la descentralización impide automáticamente las actualizaciones perjudiciales.

La gobernanza puede seguir fallando si el poder de voto está concentrado, la participación es baja o las propuestas son difíciles de revisar.

Preguntas frecuentes

¿Qué es un contrato actualizable en cripto?

Un contrato actualizable es un diseño de contrato inteligente que permite a un protocolo modificar su lógica después del despliegue manteniendo la misma dirección y los datos almacenados.

¿Por qué los proyectos cripto utilizan contratos actualizables?

Los proyectos cripto utilizan contratos actualizables para corregir errores, añadir funciones, mejorar los controles de seguridad, reducir los costes de migración y mantener las integraciones con el tiempo.

¿Son seguros los contratos actualizables?

Los contratos actualizables pueden ser seguros cuando utilizan un control de acceso sólido, una gestión cuidadosa del almacenamiento, auditorías, supervisión y una gobernanza transparente.

¿Cuál es el principal riesgo de un contrato actualizable?

El principal riesgo es que un actualizador autorizado pueda instalar una lógica perjudicial o defectuosa que modifique el comportamiento del protocolo o ponga en riesgo los fondos de los usuarios.

¿Qué es un contrato proxy?

Un contrato proxy es el contrato visible para el usuario que almacena datos y reenvía llamadas a un contrato de implementación que contiene la lógica actual.

¿Qué es un contrato de implementación?

Un contrato de implementación es el contrato de lógica que define el comportamiento de las funciones cuando el proxy le delega llamadas.

¿Por qué los contratos actualizables utilizan inicializadores?

Los contratos actualizables utilizan inicializadores porque la lógica del constructor no inicializa el almacenamiento del proxy de la misma manera que un despliegue normal de contrato.

¿Qué es una colisión de almacenamiento?

Una colisión de almacenamiento se produce cuando la nueva lógica del contrato lee o escribe slots de almacenamiento de una forma que entra en conflicto con la estructura anterior.

¿Qué es ERC-1967?

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

¿Qué es ERC-7201?

ERC-7201 es un estándar para la estructura de almacenamiento con espacios de nombres, que ayuda a organizar las variables de estado y reducir conflictos de almacenamiento en contratos actualizables complejos.

¿Puede un contrato actualizable volverse inmutable más adelante?

Sí, algunos proyectos pueden renunciar o deshabilitar la autoridad de actualización, pero los usuarios deben verificarlo on-chain en lugar de basarse solo en anuncios.

¿Cómo pueden comprobar los usuarios si un contrato es actualizable?

Los usuarios pueden inspeccionar el contrato en un explorador de blockchain, buscar información de proxy, revisar las direcciones de implementación y comprobar los permisos de administrador o gobernanza.

Conclusión

Un contrato actualizable es un potente diseño de contrato inteligente que proporciona a los protocolos cripto la capacidad de mejorar su lógica conservando la dirección, el estado y el saldo.

El diseño más habitual utiliza un contrato proxy que almacena datos y delega la ejecución en un contrato de implementación sustituible.

Este modelo puede facilitar las correcciones de errores, las actualizaciones de funciones y el mantenimiento del protocolo a largo plazo.

También puede introducir riesgos graves si los permisos de actualización están centralizados, las estructuras de almacenamiento se gestionan incorrectamente o la gobernanza es débil.

Estándares y prácticas importantes como los slots de almacenamiento de proxy ERC-1967, el almacenamiento con espacios de nombres ERC-7201, las funciones inicializadoras, las auditorías, los timelocks y los controles de administrador transparentes pueden reducir estos riesgos.

Para los usuarios de criptomonedas, la capacidad de actualización siempre debe formar parte del análisis de riesgos porque determina si las reglas de un protocolo están fijadas o aún pueden cambiar.

Para los desarrolladores, los contratos actualizables deben tratarse como infraestructura crítica para la seguridad que requiere diseño, pruebas, supervisión y gobernanza cuidadosos desde el primer despliegue.