Ni inteligente ni contrato: qué garantiza, quién puede cambiarlo y qué autorizas exactamente al firmar.
🎯 Objetivo de la lección
Entender qué es un contrato inteligente sin la palabra «inteligente», qué garantiza y qué no, y —lo más práctico de todo el curso— qué estás autorizando exactamente cuando una aplicación te pide que firmes.
🤖 No es inteligente y no es un contrato
El nombre es de 1994 y ha envejecido mal. Conviene deshacerlo por partes, porque cada mitad induce a un error distinto.
No es inteligente. No interpreta, no juzga, no entiende el contexto ni tiene criterio. Es un programa con instrucciones fijas que hace lo mismo cada vez. Si las instrucciones tienen un fallo, lo ejecuta con toda fidelidad.
No es un contrato. Un contrato es un acuerdo entre partes que un tribunal puede interpretar cuando hay discrepancia. Esto no admite interpretación ni tiene a quién acudir.
Lo que sí es, dicho llanamente: un programa publicado en el registro compartido, que cualquiera puede leer y llamar, y que se ejecuta igual para todos.
Un ejemplo basta para ver la forma: un programa que dice «quien deposite X recibe Y», con las cantidades y las condiciones escritas. Cuando alguien deposita X, el programa entrega Y. No porque sea justo, sino porque es lo que pone.
🧱 Qué garantiza de verdad
Tres cosas, y conviene saber cuáles son exactamente porque se confunden con otras que suenan parecidas.
Que hace lo que pone. Todos los participantes ejecutan el mismo código y comprueban el resultado. No se puede alterar para un caso concreto.
Que está publicado. Cualquiera puede leerlo antes de usarlo. No hace falta fiarse de lo que diga su web.
Que no depende de que nadie quiera cumplirlo. No hay una parte que pueda negarse, retrasarse o desaparecer.
Y ahora lo que no garantiza, que es igual de importante:
Que lo que pone sea lo que te conviene. Un contrato puede estar escrito para perjudicarte y funcionar perfectamente.
Que no tenga fallos. Se han perdido cantidades enormes por errores de programación en contratos que se ejecutaron exactamente como estaban escritos.
Que nadie pueda cambiarlo. Muchos conservan una llave de administración. Lo vemos ahora.
Que lo de fuera sea verdad. Un contrato que reacciona a un precio depende de quién le dice ese precio. Esa pieza externa suele ser el punto débil.
🗝️ La llave que casi nadie mira
Esta es la condición número dos de la lección 1.2, en concreto.
Un contrato puede publicarse con una función que permite a una dirección concreta pausarlo, actualizarlo, cambiar sus parámetros o retirar lo depositado. Se hace por motivos razonables: corregir fallos, reaccionar a un ataque, adaptarse a un cambio legal.
Pero su existencia cambia lo que estás usando. Si alguien puede cambiar las reglas, hay un tercero de confianza, igual que antes, solo que ahora no aparece en ninguna pantalla y no ha firmado nada contigo.
No es necesariamente malo: un contrato sin posibilidad de corrección es un contrato que no se puede arreglar cuando se descubre un fallo. Es un intercambio, como todo lo demás en este curso. Lo que no es aceptable es no saberlo.
La pregunta correcta no es «¿es inmutable?», sino «¿quién puede cambiarlo, y qué hace falta para que lo cambie?»
🪟 Qué es una aplicación de estas
Lo que llamamos una aplicación descentralizada suele ser dos cosas pegadas:
Uno o varios contratos en el registro compartido, que es donde está la lógica y lo depositado.
Una web normal que te enseña botones y traduce lo que pulsas a llamadas a esos contratos.
Esa web es una web corriente, alojada donde se aloja todo, con un dominio que alguien paga. Es la cuarta condición de la lección 1.2, y aquí se ve por qué importa tanto: la parte que decide qué firmas es precisamente la parte centralizada.
De ahí sale el ataque más rentable del sector, que no toca el contrato en absoluto: alterar la web —o construir una copia idéntica— para que el botón de siempre proponga una firma distinta. El contrato es honesto; lo que cambió fue lo que te pidieron firmar.
✍️ Qué estás autorizando
La parte práctica. Cuando una aplicación te pide firmar, casi siempre es una de estas tres:
1. Un mensaje. Firmar un texto para demostrar que controlas la clave. No mueve nada, no cuesta nada. Inofensivo salvo casos rebuscados.
2. Una operación concreta. Enviar una cantidad determinada, ahora. Lo que ves es lo que pasa, una vez.
3. Una autorización. Das a un contrato permiso para mover cierto tipo de unidades de tu dirección, cuando él decida, sin volver a preguntarte.
La tercera es la que hay que mirar con atención, y es la más frecuente porque muchas aplicaciones la necesitan para funcionar. Dos detalles que la hacen peligrosa:
Suele pedirse sin límite de cantidad. Es más cómodo: se firma una vez y ya no molesta. También significa que el permiso alcanza a todo lo que tengas de eso, ahora y en el futuro.
No caduca. Sigue vigente meses después, cuando ya no recuerdas haberla dado y quizá el contrato haya cambiado de manos.
Por eso conviene revisar y retirar los permisos concedidos de vez en cuando, que es la revisión anual de la que habla Seguridad básica, lección 2.3.
🔍 Lo que se puede hacer antes de firmar
Sin ser programador, tres cosas al alcance de cualquiera:
Leer qué tipo de firma es. Las carteras lo indican, aunque no siempre con claridad. Distinguir «mensaje» de «autorización» ya evita la mayoría de los disgustos.
Mirar si la cantidad es ilimitada, y si la cartera permite ponerle un tope, ponérselo.
Llegar a la web escribiendo tú la dirección, nunca desde un enlace que te llega. Contra la copia idéntica no hay otra defensa.
Y una regla que resume el módulo: si no entiendes qué te están pidiendo firmar, la respuesta no es firmar con cuidado. Es no firmar.
📌 En resumen
Ni inteligente ni contrato: un programa publicado que se ejecuta igual para todos, sin interpretar nada y sin tribunal al que acudir.
Garantiza que hace lo que pone, que está publicado y que no depende de la voluntad de nadie. No garantiza que te convenga, ni que no tenga fallos, ni que nadie pueda cambiarlo.
La pregunta correcta no es «¿es inmutable?» sino «¿quién puede cambiarlo y qué hace falta para que lo haga?»
Una aplicación es contratos más una web corriente. La parte que decide qué firmas es la parte centralizada, y de ahí sale el ataque más rentable.
Tres firmas distintas: mensaje, operación concreta y autorización. La tercera suele ser sin límite y no caduca.
Si no entiendes qué te piden firmar, no firmes.
➡️ Qué viene después
Queda la última pieza, y la que más ruido tiene alrededor: los tokens y los NFTs. Qué representan exactamente, qué derechos dan y cuáles no, y por qué «único» no significa «valioso».