Claves de administración e inmutabilidad

Curiosidad

1. ¿Qué es una autoridad de emisión y qué le permite hacer a su titular?
2. ¿Por qué un proxy actualizable puede ser tanto una característica de seguridad como una puerta trasera?
3. Si eliminar las claves de administrador elimina los ataques pero también impide las correcciones, ¿quién decide qué riesgo acepta una comunidad?

Explorar

Parte IClaves de administrador: la raíz del robo en los contratos

1. Muchos rug pulls tienen su origen en un poder retenido. Una autoridad de emisión permite a su titular imprimir tokens ilimitados y venderlos en el mercado a voluntad. Una autoridad de congelamiento o una lista negra impide que determinados holders muevan su saldo. Un impuesto configurable por el propietario puede elevar la comisión de venta al cien por cien, dejando la liquidez atrapada. Cada uno de estos poderes es una clave en manos de alguien, y cada uno puede volverse contra las mismas personas a las que debía servir.
2. Los proxies actualizables separan el almacenamiento de la lógica: el estado reside en una dirección, mientras que el código se ejecuta desde otra que un administrador puede cambiar en cualquier momento. Esto permite aplicar parches cuando se encuentran errores, pero también significa que las reglas de un token pueden cambiar retroactivamente para todos sus holders. En exploits de DeFi, las actualizaciones de proxies se han usado de forma abusiva para redirigir fondos o alterar el comportamiento del protocolo después del despliegue. El token Squid Game (noviembre de 2021) muestra adónde conduce el control retenido: su contrato permitía comprar a cualquiera, pero impedía vender a los holders comunes, y cuando sus creadores retiraron sus ganancias, el precio cayó casi a cero en cuestión de minutos.
3. El compromiso es estructural. Si se elimina la clave de emisión, nadie podrá imprimir tokens adicionales; si se elimina la vía de retiro de la liquidez del pool, nadie podrá sacar las reservas. El costo es que ningún desarrollador, auditor o miembro de la comunidad podrá corregir un error, responder a una emergencia o ajustar parámetros cuando cambien las condiciones. En un mercado sin permisos, todo poder de administración es al mismo tiempo una superficie de ataque y una herramienta de mantenimiento. A qué lado sirve depende de si quien posee la clave actúa de buena fe y la mantiene segura.
4. Las defensas a nivel de billetera no pueden sustituir al diseño a nivel de contrato. Un usuario puede revocar las autorizaciones de tokens, evitar firmar transacciones desconocidas y verificar las direcciones de los contratos antes de interactuar, pero estas prácticas no sirven de nada contra una autoridad de emisión que se esté utilizando activamente o contra una actualización de proxy que cambie las reglas en medio de la transacción. En los tokens SPL, la autoridad de emisión siempre se establece al crear el token y permanece así hasta que se establezca en “None”; la autoridad de congelamiento es opcional y, si no se indica, nunca puede añadirse. De cualquier manera, una autoridad activa sigue funcionando independientemente de la precaución del usuario.
5. La documentación de proxies de OpenZeppelin explicita la arquitectura: un contrato de implementación contiene la lógica, mientras que un proxy conserva el estado y le reenvía cada llamada mediante delegatecall. Actualizar significa apuntar el proxy a una nueva dirección de implementación. Así es como los equipos publican correcciones, pero también significa que cualquier titular de la autoridad de actualización puede reemplazar todo el conjunto de reglas en una sola transacción. La distinción entre un parche y un robo es puramente de comportamiento, no técnica.
6. Inspeccionar el contrato de un token revela qué claves están activas. En una cadena EVM, revisa si el contrato tiene un rol de propietario y si está detrás de un proxy actualizable; en Solana, revisa las autoridades de emisión y de congelamiento y cualquier extensión de Token-2022, como un delegado permanente, un transfer hook o una comisión de transferencia. Cada poder ausente o revocado elimina su clase de ataque. El riesgo restante recae en las personas: el phishing, la suplantación de identidad y la manipulación social operan completamente fuera del código.

Parte IIInmutabilidad y ausencia de claves de administración

7. Muchos contratos inteligentes pueden modificarse después de su lanzamiento. En Solana, los programas son actualizables por defecto a través de una clave de “autoridad de actualización”; en cadenas EVM como Ethereum, los contratos son inmutables a menos que se construyan con patrones de proxy que redirijan la ejecución a un contrato de implementación reemplazable. Este diseño permite corregir errores y añadir nuevas funcionalidades, pero también significa que el código con el que interactúan los usuarios hoy puede no ser el mismo que leyeron ayer.
8. El riesgo de la mutabilidad es la confianza concentrada. Si un desarrollador posee una clave administrativa, puede, en teoría, alterar la oferta de tokens, congelar cuentas de usuarios o vaciar los pools de liquidez en cualquier momento. Esto crea un “modo dios” que contradice el espíritu descentralizado de las cadenas de bloques. Cuando The DAO fue hackeado en junio de 2016, la comunidad de Ethereum debatió si realizar un hard fork para revertir el robo, una medida que dividió la cadena en Ethereum y Ethereum Classic. Ese evento puso de manifiesto cómo incluso los cambios a nivel de red conllevan profundos riesgos de gobernanza.
9. La inmutabilidad elimina este riesgo por completo. Al revocar todas las autoridades administrativas —como las de acuñación, congelamiento y actualización de programas en Solana— o al desplegar sin proxies ni roles de propietario en cadenas EVM, el contrato se convierte en una bóveda sellada. Nadie puede cambiar las reglas después del despliegue. El código en producción puede cotejarse una sola vez con el código auditado, y seguirá siendo el mismo. Esto elimina la amenaza de abuso por parte de personas internas, pero también fija para siempre cualquier posible error.
10. El costo de la inmutabilidad es la permanencia. Si existe un error crítico, no hay parche; solo una migración a un nuevo contrato o un fork de la red puede solucionarlo. Esto eleva lo que está en juego en la verificación previa al lanzamiento. Los equipos deben invertir mucho en verificación formal, fuzzing exhaustivo y auditorías de múltiples partes antes del despliegue. La carga se traslada del mantenimiento posterior al lanzamiento al rigor previo al lanzamiento. Un solo caso límite pasado por alto se convierte en una característica permanente del sistema.
11. Bitcoin sirve como punto de referencia para la ‘neutralidad creíble’. Sus reglas solo cambian mediante un amplio consenso entre miles de nodos independientes, y no por parte de una sola entidad. No existe ninguna clave administrativa que pueda alterar la recompensa por bloque o la validez de las transacciones. Esa rigidez es en gran medida la razón por la cual muchos consideran a Bitcoin como un sistema con neutralidad creíble: ninguna parte individual puede reescribir sus reglas.
12. Para los diseñadores de tokens, elegir la inmutabilidad es una señal de compromiso con la transparencia. Los usuarios pueden verificar que el código desplegado no puede cambiar. Sin embargo, esta elección requiere aceptar que los errores son irreversibles. La disyuntiva es clara: obtener una previsibilidad que los usuarios pueden verificar, o conservar la flexibilidad a costa de introducir un único punto de fallo y posibles abusos.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• Solana Program Library, SPL Token documentation
• OpenZeppelin, 'Proxy Upgrade Pattern' documentation
• Contemporary reporting on the Squid Game token collapse (November 2021)
• Chainalysis, Crypto Crime Report (2024)
• Solana documentation: deploying programs (upgrade authority)
• V. Buterin, 'Credible Neutrality as a Guiding Principle' (2020)