No sabe la hora, no puede mirar fuera y no puede sacar un número al azar. Quién acaba metiendo el mundo exterior dentro, y cómo falla.
🎯 Objetivo de la lección
Entender el límite que no es de precio: hay cosas que un programa de estos no puede hacer por diseño. No sabe qué hora es, no puede mirar fuera y no puede sacar un número al azar. De ahí sale la pieza que explica la mayoría de los fallos caros del ecosistema: alguien tiene que meter el mundo exterior dentro.
🧮 Una máquina muy limitada, a propósito
Los programas no se ejecutan en el ordenador de nadie en particular. Se ejecutan en una máquina virtual: un procesador imaginario, definido en el protocolo, que todos los que mantienen una copia reproducen exactamente igual.
«Exactamente igual» es la clave, y viene directamente de lo que ya sabes de Blockchain: si todos ejecutan lo mismo y comparan el resultado, el resultado tiene que ser el mismo para todos, siempre. Da igual el ordenador, el país, el momento en que lo ejecute o el sistema operativo.
A eso se le llama que la ejecución sea determinista: las mismas entradas dan la misma salida, sin excepciones. Y esa exigencia, que parece inocente, prohíbe un montón de cosas que cualquier programa normal hace sin pensar.
🚫 Cuatro cosas que no puede hacer
1. No puede consultar nada de fuera. No puede pedir una página web, ni llamar a un servicio, ni leer un archivo. Si pudiera, dos copias que preguntaran en momentos distintos obtendrían respuestas distintas y dejarían de coincidir.
2. No sabe qué hora es. Lo único parecido a un reloj es la hora que declara el bloque en el que se ejecuta, que la pone quien construye el bloque y tiene margen. Sirve para «después del día tal», no para nada fino.
3. No puede sacar un número al azar. El azar de verdad es lo contrario del determinismo. Todo lo que parezca aleatorio sale de datos del propio registro, y quien construye el bloque tiene influencia sobre esos datos. Es un problema real: cualquier reparto que dependa de un azar mal construido es manipulable por quien ordena las operaciones.
4. No puede actuar solo. Ya lo viste en la 1.1: no vigila y no se despierta. Alguien de fuera tiene que llamarlo y pagar.
Y todo esto no es una carencia que se vaya a arreglar. Es el precio de que cualquiera pueda comprobar el resultado sin fiarse de quien lo produjo. La pregunta de siempre: a cambio de eso, el programa se queda ciego y quieto.
🌐 Entonces, ¿cómo sabe un contrato cuánto vale algo?
No lo sabe. Alguien se lo escribe.
Esa es la respuesta completa, y conviene que quede desnuda, porque el nombre técnico —oráculo— suena a mecanismo y no lo es. Un oráculo es una parte que anota dentro del registro un dato de fuera. Nada más. El contrato lee esa anotación y la da por buena, porque no tiene forma de comprobarla.
Con eso se sostienen la mayoría de las cosas que hacen estas redes: cualquier programa que dependa de un precio, de un resultado, de una temperatura o de si algo ocurrió, depende de quien escribe ese dato.
Y de ahí la consecuencia incómoda: se puede tener un contrato perfectamente escrito, verificado y revisado, que se comporte de forma catastrófica sin que su código tenga ningún fallo, porque el dato del que dependía era falso. El programa hizo exactamente lo que decía.
💣 Las tres formas de que el dato falle
Ordenadas de la más obvia a la que más dinero se ha llevado.
1. Quien lo escribe miente o le fuerzan a mentir. Si una sola parte escribe el dato, esa parte puede vaciar todo lo que dependa de él. Es la versión directa, y por eso casi nadie la deja así.
2. El dato es correcto pero viejo. Escribir cuesta, así que los datos no se actualizan continuamente: se actualizan cuando cambian lo suficiente o cuando pasa cierto tiempo. En un momento de movimiento brusco, el contrato opera con una realidad de hace un rato. Nadie ha mentido y el resultado es igual de malo.
3. El dato es cierto, y el problema es lo que mide. Esta es la fina. Si el dato refleja el precio de un mercado pequeño, alguien con suficiente dinero puede mover ese mercado a propósito durante unos segundos, hacer que el contrato valore algo mal y aprovecharlo. El oráculo hizo su trabajo con honradez: informó de un precio que era real. Manipular la realidad es más barato que manipular el informe.
La tercera es la que hay que entender, porque desmonta la idea tranquilizadora de «el dato viene de varias fuentes independientes». Varias fuentes independientes que miran el mismo mercado delgado coinciden todas en el precio manipulado.
🎲 El caso del azar, en una frase
Merece su apartado porque se repite en repartos, sorteos y adjudicaciones. Si el número «al azar» sale de algo del registro —la huella de un bloque, la hora, el saldo de una cuenta—, quien construye el bloque puede elegir entre varios resultados posibles, o simplemente no incluir la operación si no le conviene.
No hace falta un ataque sofisticado: basta con estar en la posición de ordenar las operaciones. Es la misma ventaja que ya conoces de Blockchain: quien decide el orden tiene ventaja, aquí aplicada a un sorteo.
🧭 Qué preguntar cuando algo depende de un dato de fuera
Cinco preguntas. Ninguna exige leer código.
¿Quién puede escribir este dato? Una parte, varias, o cualquiera que aporte algo a cambio.
¿De dónde sale, y qué profundidad tiene lo que mide? Un dato sacado de un sitio donde mueve poco dinero es manipulable, por muchas fuentes que lo confirmen.
¿Cada cuánto se actualiza, y qué pasa si deja de llegar? Lo segundo importa más: hay contratos que se paran y contratos que siguen con el último valor que tenían.
¿El contrato distingue un dato fresco de uno viejo? Si no comprueba la antigüedad, un dato caducado le vale igual.
¿Qué pasa si el dato es absurdo? Un buen diseño se detiene ante un valor imposible. Uno malo lo ejecuta.
Y si alguna no tiene respuesta pública, eso ya es la respuesta. La regla es la misma de Blockchain, y aquí se aplica igual.
📌 En resumen
Los programas corren en una máquina virtual que todos reproducen igual, así que la ejecución tiene que ser determinista: mismas entradas, misma salida, siempre.
Por eso un contrato no puede consultar nada de fuera, no sabe qué hora es, no puede sacar un número al azar y no puede actuar solo.
No es una carencia por resolver: es el precio de que cualquiera pueda comprobar el resultado.
Un oráculo no es un mecanismo: es alguien que escribe un dato de fuera dentro del registro, y el contrato lo da por bueno porque no puede comprobarlo.
Un contrato sin ningún fallo puede comportarse de forma catastrófica si el dato del que dependía era falso.
El dato falla de tres formas: alguien miente, es correcto pero viejo o es cierto y mide algo manipulable. La tercera desmonta el consuelo de «viene de varias fuentes».
Si el azar sale del propio registro, quien construye el bloque influye en el resultado.
➡️ Qué viene después
Con esto cierra el módulo: ya sabes qué añadió esta red, qué cuesta y qué no puede hacer. El módulo 2 va a lo que de verdad decide si algo sale mal, y empieza por lo más elemental y lo que menos gente comprueba: que el código que lees no es necesariamente el que se ejecuta.