¿A dónde fueron los contratos inteligentes inmutables?

Cuando DeFi empezaba a ganar impulso, uno de sus puntos de venta más fuertes era la inmutabilidad. Sus defensores contrastaban los contratos inteligentes con servicios centralizados como intercambios o casinos.

La narrativa era simple y convincente.

• Los intercambios centralizados, los casinos, los procesadores de pagos y servicios similares requieren confianza en sus propietarios. El dueño puede congelar tu cuenta, cambiar comisiones, huir con tu criptomoneda o entregarla al gobierno ante la primera petición.
• DeFi, en contraste, se suponía que requería confianza solo en la fiabilidad del código del contrato inteligente. Un contrato inteligente se presentaba como una máquina expendedora encerrada en el hormigón de la blockchain. Sus reglas eran conocidas de antemano, y nadie —ni el desarrollador, ni la policía, ni un tribunal— podría cambiarlas después del lanzamiento.

Han pasado unos años. Hoy, esta narrativa está efectivamente muerta, aunque rara vez se reconoce abiertamente. La gran mayoría de los modernos protocolos DeFi (Aave, Compound, Uniswap V3, Sky Protocol, varios puentes y soluciones L2) son, desde un punto de vista técnico, actualizables. Sus administradores poseen llaves que convierten un contrato inteligente en algo más parecido a un servidor web regular, donde el backend puede actualizarse en cualquier momento.

¿Cómo ocurrió esta revolución silenciosa? ¿Cómo exactamente aprendieron los desarrolladores a eludir la inmutabilidad de la blockchain? ¿Y queda todavía algo verdaderamente inmutable en lo que seguimos llamando “finanzas descentralizadas”?

Anatomía del control: cómo funcionan los contratos proxy

Muchos lectores pueden objetar en este punto: “Un momento. La ideología DeFi surgió dentro de Ethereum. Y después del controvertido episodio de The DAO, nadie se atrevería a reescribir nada en esa blockchain nunca más. Así que el código de cualquier contrato inteligente debe permanecer inmutable después del despliegue.”

Eso es cierto. No solo Ethereum, sino cualquier blockchain es una base de datos de solo añadir. Nadie puede borrar un contrato una vez que ha sido escrito en la cadena.

Sin embargo, los desarrolladores encontraron una elegante solución alternativa que eventualmente se convirtió en estándar de la industria: el Patrón Proxy.

Imagina que una aplicación no consiste en un único contrato, sino en dos.

• El Proxy es la interfaz externa. Tiene una dirección fija en la cadena con la que los usuarios interactúan, y es allí donde se almacenan todos los tokens y registros de saldo. Pero este contrato es deliberadamente superficial: no contiene la lógica financiera central.
• La Implementación es el mecanismo interno. Aquí es donde viven las fórmulas: cómo se calcula el interés, cómo se intercambian tokens, quién puede retirar cuánto. Pero este contrato no guarda criptomoneda en sí.

Cuando depositas o retiras tokens, interactúas con el Proxy. El Proxy usa una instrucción de bajo nivel llamada delegatecall para leer el contrato de Implementación y ejecutar su código en el contexto del propio almacenamiento del Proxy.

Dentro del contrato Proxy, hay una variable (a menudo expuesta vía una función interna _implementation) que almacena la dirección de la Implementación actual. También existe una función especial, accesible solo al administrador: upgradeTo(newAddress).

En cualquier momento, el administrador del Proxy puede:

• desplegar un nuevo contrato de Implementación en la blockchain (por ejemplo, con una nueva funcionalidad o una corrección de errores);
• llamar a upgradeTo en el Proxy y señalar la nueva dirección de Implementación.

Después de eso, el Proxy empieza a usar inmediatamente la nueva lógica.

Desde la perspectiva del usuario, nada ha cambiado. La dirección del contrato es la misma y su criptomoneda sigue almacenada allí. En realidad, sin embargo, las reglas del sistema pueden haber cambiado por completo.

Si el administrador despliega una Implementación maliciosa (por ejemplo, una que permita al admin retirar todos los fondos), el Proxy obedientemente entregará toda la criptomoneda, porque ejecuta ciegamente cualquier código que se le indique usar.

¿Por qué aceptamos esto?

El cambio de la inmutabilidad a la actualizabilidad no nació de la malicia: surgió por necesidad.

Primero, recordemos la historia de The DAO. Una vulnerabilidad en su contrato inteligente permitió a un hacker drenar una enorme cantidad de fondos. Para revertir esto, los operadores de nodos de Ethereum hicieron un movimiento que para los puristas de las criptomonedas fue una herejía: reescribieron la historia de la blockchain para deshacer la transacción del hacker. Todo el episodio dejó una cosa clara: el código inmutable significa errores inmutables. Si un contrato tiene un fallo, no puede parchearse. Eso deja solo dos opciones: control centralizado sobre toda la red (como ocurrió con Ethereum en ese momento), o control centralizado sobre contratos individuales. Con el tiempo, la industria se decantó por lo que parecía el mal menor: permitir control centralizado a nivel de contrato mientras se preserva la apariencia de descentralización a nivel del ecosistema.

En segundo lugar, muchos proyectos DeFi son efectivamente startups. Necesitan evolucionar: añadir nuevas estrategias, soportar nuevos tokens, corregir casos borde. Sin contratos proxy, cada actualización obligaría a los usuarios a retirar fondos de un contrato antiguo y depositarlos en uno nuevo. Eso es torpe, caro y malo para la adopción.

En tercer lugar, los reguladores entraron en escena. DeFi depende en gran medida de las stablecoins, y los reguladores insisten en que estas deben incluir funciones como listas negras de direcciones y lógica actualizable para cumplir con las normas financieras. Incluso MakerDAO —emisor de DAI, antaño el ejemplo por excelencia de stablecoins descentralizadas— tuvo que ceder ante la presión. Cuando se rebrandó bajo Sky Protocol, añadió funciones controladas por administradores a su nueva stablecoin, USDS.

¿Y los usuarios? Votaron con sus carteras. Las altas rentabilidades (APY) y las interfaces atractivas importan más para la mayoría de la gente que ideales abstractos como la descentralización.

La ilusión de la descentralización: ¿quién tiene el “botón rojo”?

Muchos proyectos afirman ser descentralizados simplemente porque su llave de admin no está controlada por una única persona. ¿Pero eso realmente cambia algo?

Cuando la llave de actualización la sostiene un solo desarrollador, ese es claramente el escenario más riesgoso. Si esa persona es hackeada o presionada (física o legalmente), los fondos de los usuarios podrían desaparecer en un instante. Y aun así esta configuración sigue siendo común, especialmente en contratos de monedas meme, que a menudo se tratan como poco serios.

A veces la llave se divide en varias partes: digamos cinco personas (a menudo fundadores e inversores tempranos) sostienen una cada una, y se requieren tres firmas para realizar cambios. Pero esto sigue siendo centralizado. La colusión es posible. También lo es la intervención estatal.

Una opción algo más segura es el mecanismo Timelock. Aquí, un admin puede programar una actualización, pero solo entra en vigor después de 24 - 48 horas. Esto da a los usuarios tiempo para revisar el nuevo código y retirar sus fondos si el cambio es malicioso. Pero en realidad, nadie supervisa los contratos inteligentes 24/7. Y en emergencias (como un exploit activo), 24 - 48 horas es tiempo más que suficiente para que un atacante lo drene todo.

El mal menor es la gobernanza basada en DAO. En protocolos como Compound y Uniswap, la autoridad de actualización se maneja mediante contratos inteligentes ligados a votaciones de los poseedores de tokens. Los cambios solo ocurren si se emiten suficientes votos a favor. En teoría, esto es un paso hacia la verdadera descentralización. Pero en la práctica, grandes fondos de capital riesgo (como a16z o Polychain) poseen tantos tokens de gobernanza que pueden impulsar casi cualquier decisión. Además, la participación de votantes suele ser mínima, lo que facilita el control del proceso.

Islas de inmutabilidad: ¿quiénes siguen inalterables?

¿Todavía existen servicios DeFi donde “el código es la ley”? Sí, pero ahora ocupan un nicho muy estrecho en el ecosistema. Estos son ejemplos raros de contratos inteligentes verdaderamente inmutables.

Uniswap V1 / V2
Los pools de liquidez en estas versiones son completamente inmutables. Ni desarrolladores, ni inversores, ni siquiera gobiernos pueden retirar fondos, alterar fórmulas o cambiar las reglas. Los contratos inteligentes están escritos en piedra: sin llave de admin, sin ruta de actualización.

Liquity USD (LUSD)
El contrato LUSD no tiene llaves de admin ni función de actualización. Los parámetros del sistema fueron codificados matemáticamente al lanzamiento y nunca podrán cambiarse. Eso lo convierte en una de las stablecoins más resilientes en DeFi. No es muy usada —quizás porque la gente supone que carece de liquidez—. Pero eso es una concepción errónea:

• A nivel de protocolo, cada LUSD siempre puede redimirse por el ETH que lo respalda.
• En rabbit.io, LUSD puede intercambiarse por cualquier cripto sin límites ni restricciones.

Tornado Cash V1 / V2
Las primeras versiones de los contratos de Tornado Cash inicialmente tenían llaves de admin —necesarias para parchear errores en el entorno en vivo. Pero una vez que el protocolo demostró ser estable, se renunció al control: la llave de admin se entregó a la dirección 0x00...0000, haciendo los contratos totalmente inmutables.

Esta decisión puso de manifiesto una verdad fundamental sobre la inmutabilidad: protege contra ataques de gobernanza.

Toma Tornado Cash V3 como ejemplo aleccionador. Esta versión introdujo mejoras: tamaños de depósito flexibles (no solo 0.1, 1, 10 o 100 ETH) y un sistema de transferencias privadas basado en L2 vía Gnosis Chain. Para permitir actualizaciones y parches de seguridad para un protocolo tan complejo, la gobernanza se entregó a una DAO —específicamente, a los poseedores del token TORN.

En 2023, un atacante propuso una actualización de gobernanza aparentemente inofensiva. Oculto en el código había una puerta trasera. Una vez aprobada, le dio al atacante control total sobre la DAO. Secuestraron la lógica del contrato y robaron una porción de los tokens de gobernanza.

Un ataque así habría sido físicamente imposible en las versiones inmutables. No había rutas de actualización. No había votos. No había botones rojos.

Más allá de Ethereum: cómo otros ecosistemas manejan las actualizaciones de contratos

Los contratos proxy se han convertido en el estándar de facto en las blockchains compatibles con EVM. ¿Pero qué pasa con los ecosistemas no EVM?

Solana
En muchos casos, la inmutabilidad es incluso más débil que en Ethereum. Por defecto, los contratos inteligentes de Solana pueden ser actualizados usando una Upgrade Authority. Los desarrolladores pueden renunciar a este poder para hacer un programa inmutable, pero en la cultura acelerada e innovadora de Solana, hacerlo es raro. Una situación similar existe en Near Protocol, donde la actualizabilidad también es la norma.

Polkadot y Cosmos
Estos ecosistemas siguen un enfoque distinto: las actualizaciones ocurren no a través de funciones de admin dentro de contratos, sino vía gobernanza a nivel de validadores. Cuando depositas fondos en un contrato inteligente en estas redes, no estás confiando en un admin de contrato: estás confiando en que los validadores de toda la cadena actúen honestamente.

Cardano
Cardano soporta varios tipos de contratos inteligentes, pero el principal son los scripts Plutus, que se construyen sobre un estricto modelo de inmutabilidad.

• Un script Plutus está ligado a un UTXO específico y su código está hasheado en la propia dirección.
• Una vez desplegado, el código no puede cambiarse —punto.
• Si los desarrolladores necesitan arreglar un bug o cambiar la lógica de negocio, deben desplegar un nuevo script con un hash diferente y migrar los fondos manualmente.
• Debido a esta arquitectura, los patrones proxy son imposibles.

Técnicamente, Cardano también soporta contratos con lógica off-chain, que podrían usarse para construir sistemas actualizables con control de admin. Pero en la práctica, tales diseños son raros —a diferencia de las cadenas EVM.

Ecosistema Bitcoin
Sí, Bitcoin también tiene protocolos de contratos inteligentes.

• RGB
  Aquí, tanto el contrato inteligente como el estado del token se almacenan localmente en los dispositivos de los usuarios en lugar de on-chain. No existe un contrato centralizado que pueda ser actualizado por un admin. Si un emisor de tokens publica nuevas reglas, los usuarios deben aceptar la actualización —como actualizar una app en tu dispositivo. No hay forma de forzar cambios a todos los usuarios simultáneamente.
• Stacks
  Todos los contratos inteligentes en Stacks se vuelven inmutables una vez desplegados. Las actualizaciones solo pueden introducirse mediante una arquitectura modular: la nueva funcionalidad se añade mediante contratos separados que interactúan con el contrato original, pero no pueden anular o alterar las reglas existentes. En otras palabras, cualquier actualización es una adición, no una modificación. La lógica original permanece intacta y exigible, y ninguna parte del contrato desplegado puede cambiarse retroactivamente.
• Elastos y Rootstock
  Estas son sidechains compatibles con EVM, lo que significa que siguen los mismos patrones de actualización que Ethereum. Los desarrolladores pueden implementar contratos proxy y retener control de admin, tal como en cualquier cadena EVM.

Así, incluso en la comunidad de Bitcoin —que tradicionalmente ha valorado la inmutabilidad sobre la flexibilidad— ahora existen protocolos de contratos inteligentes que permiten a los operadores del servicio modificar las reglas después de aceptar los fondos de los usuarios.

Conclusión

Parece que el término “aplicación descentralizada” es a menudo poco más que un truco de marketing. Eso no es necesariamente malo: la capacidad de actualizar contratos inteligentes ha salvado miles de millones de dólares cuando se han descubierto vulnerabilidades. Pero los usuarios deben entender los riesgos:

• En un servicio tradicional centralizado, puedes perder tu cripto simplemente porque no posees las llaves de tu wallet.
• En el DeFi moderno, puedes perder tu cripto simplemente porque el admin puede cambiar la cerradura (las reglas del contrato inteligente).

La verdadera inmutabilidad sigue siendo dominio de protocolos conservadores como Tornado Cash Classic, Liquity, y soluciones nativas en Cardano o sobre Bitcoin, que sacrifican flexibilidad en aras de la seguridad. Todo lo demás, en última instancia, se reduce a la confianza —en equipos que se esconden detrás de la brillante etiqueta de una “DAO”.