¿Qué significa que un contrato se pueda actualizar? ¿Quién tiene los permisos de actualización?
En los proyectos Web3, algunos contratos inteligentes no se pueden modificar directamente una vez desplegados, mientras que otros se pueden actualizar mediante mecanismos específicos.
Cuando muchos usuarios ven «contrato actualizable», lo primero que les preocupa es: si el código puede cambiar, ¿significa que el equipo del proyecto puede modificar mis activos en cualquier momento?
Es una cuestión que merece atención, pero no se debe equiparar sin más un contrato actualizable con uno inseguro.
Lo que realmente hay que determinar no es solo si el contrato se puede actualizar, sino quién tiene permiso para hacerlo, qué se puede cambiar con la actualización y si todo el proceso está sujeto a controles eficaces.
1. ¿Por qué necesitan actualizarse los contratos inteligentes?
Las actualizaciones de contratos inteligentes pueden tener motivos técnicos legítimos.
Por ejemplo, un proyecto puede necesitar corregir vulnerabilidades, optimizar la lógica de negocio, ajustar parámetros del protocolo o añadir nuevas funciones.
En los proyectos que utilizan una arquitectura de contratos proxy, la dirección del contrato con el que interactúan los usuarios puede permanecer igual, mientras que la lógica de ejecución real puede cambiar a un nuevo contrato de implementación.
Esto significa que el hecho de que la dirección que ven los usuarios no haya cambiado no implica necesariamente que la lógica del código subyacente siga siendo la misma.
Ten en cuenta que no todos los contratos se pueden actualizar. Algunos están diseñados para no ser actualizables desde el momento de su implementación, mientras que otros pueden actualizarse mediante un modelo proxy, un mecanismo de migración u otra arquitectura.
Los riesgos y las limitaciones también varían según el mecanismo.
2. ¿Quién controla los permisos de actualización?
Esta es una de las cuestiones más importantes que hay que tener en cuenta al evaluar contratos actualizables.
Entre las formas habituales de controlar las actualizaciones se encuentran:
Control por un único administrador
Una dirección específica ejecuta las operaciones de actualización.
Este método puede ser más eficiente, pero si la clave privada de esa dirección se filtra, es robada o quien la controla actúa de forma maliciosa, pueden surgir riesgos graves.
Control multifirma
Las actualizaciones requieren la aprobación conjunta de varios firmantes designados.
La multifirma puede reducir los riesgos derivados de que una sola clave se vea comprometida, pero la seguridad sigue dependiendo de la independencia de los firmantes, del umbral establecido y de cómo se gestionen las claves.
Control mediante DAO o mecanismos de gobernanza
Las actualizaciones se deciden mediante propuestas, votaciones u otros procesos de gobernanza.
Este método incorpora mecanismos de participación y supervisión, pero aún hay que prestar atención a si el poder de voto está demasiado concentrado, si las reglas para las propuestas son razonables y quién tiene la autoridad final para ejecutar los cambios.
Mecanismo de bloqueo temporal
Algunos proyectos establecen un periodo de espera antes de ejecutar una actualización, para que los usuarios puedan revisar los cambios y decidir qué hacer.
Sin embargo, no todos los proyectos cuentan con un bloqueo temporal, y su existencia tampoco significa que se eliminen todos los riesgos.
Ten en cuenta también que la multifirma, las DAO y los bloqueos temporales pueden combinarse. No basta con ver el nombre de un mecanismo para dar por hecho que los permisos son seguros.
3. ¿Por qué merecen especial atención los contratos proxy?
En una arquitectura habitual de contratos proxy, el sistema puede entenderse como dos partes:
Contrato proxy: la dirección con la que suelen interactuar los usuarios.
Contrato de implementación: el código que contiene la lógica de ejecución real.
El contrato proxy puede reenviar las llamadas al contrato de implementación para que las ejecute, de acuerdo con reglas específicas.
Si quien tiene los permisos de actualización puede reemplazar el contrato de implementación, la lógica de ejecución podría cambiar aunque la dirección del contrato proxy siga siendo la misma.
Por eso, no basta con consultar las direcciones de los contratos que el proyecto ha hecho públicas.
También debes averiguar:
¿Cuál es la dirección del contrato de implementación actual?
¿Quién puede modificar la dirección del contrato de implementación?
¿Las actualizaciones están sujetas a una multifirma, a la gobernanza o a un bloqueo temporal?
¿Se ha realizado alguna actualización recientemente?
¿La nueva versión ha sido auditada o sometida a otras comprobaciones de seguridad?
Por supuesto, un contrato proxy no implica necesariamente un riesgo elevado. Lo importante es entender su estructura de control y los permisos reales.
4. ¿Qué riesgos pueden derivarse de los permisos de actualización?
El primero es el riesgo de abuso de permisos.
Si una entidad puede cambiar por sí sola la lógica de implementación, los usuarios deben evaluar las posibles consecuencias de ese poder.
El segundo es el riesgo de que se comprometa una clave privada.
Aunque el equipo del proyecto no tuviera inicialmente malas intenciones, el robo de la clave que controla los permisos de actualización podría dar lugar a cambios no autorizados.
El tercero es el riesgo asociado a una nueva versión.
Que la versión original haya sido auditada no significa que la nueva haya pasado las mismas comprobaciones. La lógica modificada podría introducir nuevas vulnerabilidades o alterar las hipótesis de seguridad originales.
El cuarto es el riesgo de que fallen los mecanismos de gobernanza.
Aunque el proyecto afirme que lo gestiona una DAO, hay que verificar si los permisos de ejecución están realmente sujetos a la gobernanza o si, en última instancia, siguen bajo el control exclusivo de algún administrador.
Estos riesgos no significan que los contratos actualizables no merezcan usarse, sino que el propio mecanismo de actualización también debe someterse a una evaluación de seguridad.
5. ¿Cómo pueden verificar los usuarios comunes los permisos de actualización?
Puedes seguir estos pasos en orden.
Paso 1: Confirma la dirección del contrato.
Consulta la documentación oficial del proyecto para verificar la red y la dirección correctas del contrato y, después, revisa la información del contrato en el explorador de bloques correspondiente.
No des por sentado que has identificado el contrato correcto basándote únicamente en publicaciones en redes sociales o en los nombres que aparecen en los resultados de búsqueda.
Paso 2: Comprueba si el contrato se puede actualizar.
Revisa el código fuente público, la información de verificación del contrato y los registros relacionados con los contratos proxy para confirmar qué arquitectura utiliza.
Si no puedes confirmarlo, no saques conclusiones basándote únicamente en una etiqueta de la página de la dirección.
Paso 3: Averigua quién controla las actualizaciones.
Según cómo esté implementado el contrato, verifica la dirección del administrador, el rol autorizado para actualizar, el contrato de gestión del proxy o el contrato que ejecuta la gobernanza.
Si no puedes confirmar esta información, considéralo un problema de transparencia aún sin resolver, no algo seguro por defecto.
Paso 4: Revisa los mecanismos de protección.
Confirma si las actualizaciones requieren la aprobación de varios firmantes, si hay un bloqueo temporal y si el proceso de gobernanza es público y verificable.
Comprueba también que estos mecanismos se apliquen realmente a las operaciones de actualización más importantes.
Paso 5: Revisa el historial de actualizaciones.
Comprueba si ha cambiado el contrato de implementación y si la nueva versión incluye una descripción pública de los cambios, los resultados de auditorías y los avisos de seguridad pertinentes.
Los registros en la cadena pueden aportar pruebas importantes, pero por sí solos no demuestran que una actualización sea necesariamente razonable o segura.
6. ¿Qué debes hacer si descubres que un proyecto tiene permisos de actualización?
No concluyas de inmediato que «el proyecto necesariamente tiene un problema».
Debes seguir evaluando:
¿Los permisos de actualización están concentrados en una sola entidad?
¿Las actualizaciones importantes requieren una aprobación adicional?
¿Existe un mecanismo razonable de notificación y espera?
¿El proyecto publica el historial de actualizaciones y los resultados de las comprobaciones de seguridad?
Si una actualización modifica condiciones de riesgo importantes, ¿tienen los usuarios la oportunidad de informarse y volver a evaluar la situación?
Si no es posible verificar los permisos clave, el mecanismo de actualización no es transparente o el proyecto se niega a explicar cambios importantes, conviene extremar la precaución.
Ante operaciones de alto riesgo, no tomes decisiones basándote únicamente en las promesas verbales del equipo del proyecto.
Conclusión
Un contrato actualizable es un diseño técnico, no una conclusión definitiva sobre su seguridad.
La capacidad de actualización puede ayudar a un proyecto a corregir problemas y mantener el protocolo a lo largo del tiempo. Sin embargo, si los permisos están excesivamente concentrados, los mecanismos de protección son insuficientes o el código actualizado no se revisa adecuadamente, también puede introducir riesgos importantes.
No preguntes solo «¿se puede actualizar este contrato?». Pregúntate también «¿quién puede actualizarlo, qué restricciones se aplican a la actualización y cómo se verifica después?».
El verdadero valor del análisis en cadena no consiste en etiquetar algo como seguro o peligroso al ver un término técnico, sino en encontrar pruebas de los permisos que puedan verificarse de forma independiente.
Aviso de seguridad: Este artículo tiene fines educativos sobre seguridad en Web3 y no constituye asesoramiento de inversión. Los mecanismos de permisos varían según la arquitectura de cada contrato. Para evaluarlos, consulta el código del contrato verificado, los registros en cadena y la documentación pública del proyecto.
