Quién puede cambiar las reglas después

🎯 Objetivo de la lección

Responder de una vez la pregunta que arrastras desde Qué es Web3 y qué no: ¿quién puede cambiar un contrato y qué hace falta para que lo haga? Cómo se cambia algo que se supone inmutable, qué poderes existen además de cambiar el código, y cómo se responde la pregunta sin saber programar.

🪤 La trampa: el código no cambia, el comportamiento sí

Las dos frases que se repiten son ciertas y engañan juntas:

«El código de un contrato no se puede modificar.» Cierto. Las instrucciones que hay en una dirección son las que son para siempre.

«Este proyecto ha actualizado su contrato.» También cierto, y pasa todos los días.

No hay contradicción, porque se cambia sin modificar nada. El truco es viejo y sencillo: la dirección con la que tú tratas no contiene la lógica. Contiene una nota que dice «lo que hay que ejecutar está en esa otra dirección» y reenvía las llamadas allí.

Esa nota se puede reescribir. Se publica un contrato nuevo en otra dirección y se cambia la nota para que apunte a él. La dirección que tú conoces no ha cambiado, tu saldo sigue ahí, y sin embargo las reglas que lo gobiernan son otras desde hace un bloque.

Es la pieza que hay que entender de esta lección: la inmutabilidad protege el código, no protege tus condiciones.

🔑 Quién aprieta el interruptor

Ese cambio no lo puede hacer cualquiera. Lo hace quien tenga el permiso, y ahí hay una escala real, de menos a más garantía para ti:

1. Una sola clave. Una persona, o quien le haya robado la clave, cambia las reglas en el tiempo que tarda una operación. Es la situación más común en proyectos recientes y la que menos se anuncia.

2. Varias claves, y hacen falta unas cuantas. Tres de cinco, cuatro de siete. Mejor, con dos advertencias: hay que saber si las claves son de personas distintas o del mismo equipo —porque cinco claves en un cajón son una clave— y si la lista está publicada.

3. Varias claves y además una demora. El cambio se anuncia y no puede aplicarse hasta que pasa un plazo. Esto es lo que de verdad te protege, y no porque impida el cambio: porque te da tiempo a irte. Es la diferencia entre enterarte antes y enterarte después.

4. Una votación. Puede ser mejor o mucho peor que las anteriores, y depende de quién tenga los votos. Si unos pocos concentran la mayoría, es el punto 1 con un trámite. Se mira en el reparto, no en el reglamento.

5. Ningún mecanismo. No se puede cambiar. Nadie, nunca.

⚖️ Y aquí no hay una respuesta buena

Lo cómodo sería decir que el punto 5 es el ideal. No lo es, y esta es la parte honesta de la lección.

Un contrato que no se puede cambiar tampoco se puede arreglar. Si tiene un fallo, el fallo es permanente, y lo único que se puede hacer es avisar a la gente de que salga. Cosa que ha pasado.

Así que los dos extremos tienen precio:

• Poder cambiarlo se paga en que existe alguien con la llave, y su decisión, su error o su coacción son tu riesgo.

• No poder cambiarlo se paga en que un fallo no tiene arreglo y una circunstancia nueva no se puede acomodar.

La pregunta de siempre, otra vez: ¿a cambio de qué? Y la conclusión práctica no es «busca contratos inmutables», sino saber en qué punto de la escala estás y que sea el que crees.

Con una afirmación que sí conviene dejar clara: un contrato que alguien puede cambiar a su gusto y sin demora es un servicio gestionado por ese alguien, con pasos de más. Puede estar perfectamente bien usarlo. Lo que no está bien es creer que no dependes de nadie.

🎚️ Los otros poderes, que se cuentan menos

Cambiar la lógica es el poder grande, pero hay otros que no requieren cambiar nada y bastan para arruinarte el día. Conviene conocerlos por nombre porque aparecen en los contratos continuamente:

• Pausar. Detener el contrato. Nadie puede operar, ni sacar. A veces es una protección sensata ante un ataque; a veces es una puerta cerrada con tu dinero dentro.

• Cambiar un parámetro. Una comisión, un límite, un plazo, un umbral. Sin tocar el código: el código ya preveía que ese número fuera modificable.

• Añadir o quitar direcciones de una lista. Permitir o impedir que ciertas cuentas operen. En la lección 3.2 verás la versión más fuerte de esto.

• Retirar fondos por una vía de emergencia. Una función pensada para rescatar en caso de desastre, que es exactamente la misma función que se necesita para vaciarlo.

Un contrato puede ser inmutable y tener las cuatro. «Inmutable» no significa «sin dueño».

🧭 Cómo se responde la pregunta, en la práctica

Cuatro comprobaciones. Ninguna exige leer código, y las cuatro son datos públicos:

1. ¿La dirección reenvía a otra? Es decir, ¿el comportamiento puede cambiar? Es un hecho consultable, y es el primero.

2. ¿Quién tiene el permiso y está publicado quién es? Una clave, varias, un voto. Y si son varias: ¿de gente distinta?

3. ¿Hay demora, y cuánta? Sin demora, la garantía es la buena voluntad del que tiene la llave.

4. ¿Hay registro de los cambios anteriores? Un historial de cambios silenciosos dice más que cualquier documento.

Y la regla que ya conoces: si alguna no tiene respuesta pública, eso ya es la respuesta. No es una sospecha, es una descripción: estás en un sistema cuyas reglas puede cambiar alguien que no has identificado.

📌 En resumen

• El código no se modifica; el comportamiento sí. Se publica lógica nueva en otra dirección y se reescribe la nota que dice dónde está.

• Así que la inmutabilidad protege el código, no tus condiciones.

• La escala, de menos a más garantía: una clave, varias claves, varias claves con demora, una votación —que vale lo que valga el reparto de votos— y ningún mecanismo.

• La demora es lo que de verdad protege, y no porque impida el cambio: porque te da tiempo a irte.

• No poder cambiar nada también tiene precio: un fallo es permanente. Los dos extremos cuestan algo.

• Un contrato que alguien cambia a su gusto y sin demora es un servicio gestionado por ese alguien, con pasos de más.

• Hay poderes que no cambian el código y bastan: pausar, cambiar un parámetro, listas de direcciones y la vía de emergencia. «Inmutable» no significa «sin dueño».

• Cuatro comprobaciones públicas: si reenvía, quién tiene el permiso, si hay demora y si hay historial.

➡️ Qué viene después

Ya tienes las dos primeras piezas de por qué algo sale mal: el código puede no ser el que crees, y las reglas puede cambiarlas alguien. La lección siguiente cierra el módulo juntándolas con las otras dos y poniéndoles orden: las cuatro formas por las que el dinero sale de un contrato, y cuál de ellas depende solo de ti.