El método en seis preguntas, la versión corta en tres, lo que no te da y por dónde seguir con lo que existe hoy.
🎯 Objetivo de la lección
Convertir el curso en un método corto: qué preguntar ante un contrato o una aplicación antes de tocarla, en qué orden, y qué hacer con las respuestas. Con la advertencia de lo que este método no te da y por dónde seguir con lo que existe hoy.
🧵 Lo que sostiene todo el curso
Cuatro ideas. Con ellas se reconstruye el resto.
1. Aquí el registro no anota: ejecuta. De ahí sale todo lo demás, empezando por que ejecutar cuesta y por que el coste es un peaje fijo que no depende de cuánto mueves.
2. Un programa puede tener fondos, y no es nadie. Depositas en un texto que se ejecuta. Lo que pase depende de ese texto, y no hay a quién reclamar.
3. Nada del mundo exterior entra solo. Un contrato es ciego: no sabe la hora, no puede mirar fuera y no puede sacar un número al azar. Todo lo que sepa del mundo se lo ha escrito alguien.
4. El código no cambia; el comportamiento sí. La inmutabilidad protege las instrucciones que hay en una dirección, no tus condiciones.
Y por debajo, la pregunta de Blockchain, que aquí ha aparecido en cada lección: ¿a cambio de qué?
🧭 El método, en seis preguntas
En este orden, porque las primeras descartan más rápido. Y todas se responden mirando el contrato y datos públicos, no la web del proyecto: eso ya lo cubría el método de Qué es Web3 y qué no, y este es el complementario.
1. ¿Está el código publicado y verificado? Es decir: ¿lo que se puede leer es lo que se ejecuta? Es un dato que se consulta y se ve enseguida. Si no hay texto, o hay texto sin verificar, ya sabes en qué situación estás y las cinco preguntas siguientes valen menos.
2. ¿La dirección reenvía a otra? Si reenvía, el comportamiento puede cambiar sin que cambie nada de lo que tú conoces.
3. ¿Quién puede cambiarlo, con cuántas firmas y con cuánta demora? Una clave, varias, una votación, ninguna. Y si hay demora, cuánta: es lo único que te da tiempo a irte. Sin respuesta pública, estás en un sistema cuyas reglas cambia alguien a quien no has identificado.
4. ¿De qué dato de fuera depende, y quién lo escribe? Si depende de un precio, de un resultado o de un hecho del mundo, ese es probablemente el punto más débil, y casi nadie lo mira.
5. ¿Qué te está pidiendo firmar exactamente, y con qué tope? Una operación concreta o una autorización que sobrevive a la sesión. Sin tope y a un contrato que puede cambiar, autorizas lo que ese contrato llegue a ser.
6. ¿Cuánto costaría salir, y de qué depende que puedas? Entrar y salir se pagan por separado. Y hay diseños en los que salir depende de que un tercero actúe, de que un plazo termine o de que alguien te compre.
Con seis respuestas concretas tienes una descripción que no depende de adjetivos. Y si alguna no tiene respuesta comprobable, eso ya es la respuesta.
⏱️ La versión de tres preguntas
Cuando no hay tiempo para las seis:
¿Puedo leer lo que se ejecuta?
¿Quién puede cambiarlo, y con cuánto aviso?
¿Qué estoy firmando y con qué tope?
La segunda es la más reveladora, y la tercera la única que depende solo de ti.
⚠️ Lo que este método no te da
Con la misma claridad que en los otros cursos.
No dice si algo va a funcionar, ni si va a seguir existiendo, ni qué le pasará a su valor. Nadie lo sabe. El método describe de qué depende una cosa, no cómo acabará.
No detecta un fallo en el código. Eso exige leer el código con criterio, no está a tu alcance ni al de la mayoría, y ya se dijo en la 2.1: de los cuatro caminos por los que sale el dinero, los dos primeros no los puedes evaluar. Lo que el método hace es dejarte claro cuánto estás confiando en que otros lo hayan hecho.
Y no protege del riesgo que no es técnico. Entender esto a la perfección no impide que alguien se gane tu confianza. Eso está en Seguridad básica en Bitcoin y criptomonedas, y es lo que más fondos se lleva.
El riesgo de aprender a evaluar es creerse a salvo. Entender cómo funciona algo y acertar con ello son cosas distintas.
🗣️ Dos formas de hablar de esto que conviene reconocer
«El código es ley.» Suena a garantía y describe mal lo que hay. Sí es cierto que el contrato hace lo que dice sin interpretar nada. Pero el código puede no ser legible, puede cambiarlo alguien, puede depender de un dato que le escriben, y su resultado puede ser catastrófico sin tener ningún fallo. Quien repite la frase suele omitir las cuatro cosas.
«Todo esto es un casino.» También es cómodo, y falla en lo contrario: hay diferencias reales y comprobables entre un contrato verificado que nadie puede cambiar y uno ilegible con una sola llave detrás. Meterlos en el mismo saco ahorra el trabajo de mirar.
Lo que has visto no encaja en ninguna de las dos, y esa es la idea: hay propiedades concretas, comprobables una por una, y de ellas depende lo que te puede pasar.
🧭 Por dónde seguir
Solo con lo que existe hoy en la plataforma.
Si vas a tocar algo con dinero real, lo primero es Seguridad básica en Bitcoin y criptomonedas, en la ruta de Seguridad. Nada de este curso protege una clave mal guardada, y el cuarto camino de la 2.3 —tu propia firma— se combate ahí tanto como aquí.
Si quieres comprobar por tu cuenta en vez de creerte lo que lees, Nodos Bitcoin - Tu Soberanía Técnica enseña a mantener una copia completa de un registro. Es de otra red y a propósito: la práctica de verificar sin intermediario es la misma, y es la forma de dejar de dar por buena la palabra de un servicio de consulta.
Si algo de las piezas generales se quedó flojo, Blockchain: lo que Bitcoin no es tiene el estado compartido, las otras formas de consenso y las capas y puentes, que aquí se han dado por sabidos.
Y los huecos, dichos sin prometer fechas: los préstamos y mercados que funcionan con contratos, y las organizaciones que se gobiernan con votos, no están hoy en la plataforma. Tampoco la criptografía de debajo ni cómo se programa nada de esto. Cuando estén, se dirá.
📌 En resumen
Cuatro ideas sostienen el curso: el registro ejecuta, un programa puede tener fondos y no es nadie, nada del mundo entra solo y el código no cambia pero el comportamiento sí.
El método son seis preguntas: código verificado, si reenvía, quién puede cambiarlo y con cuánta demora, de qué dato depende, qué firmas y con qué tope y cuánto cuesta salir.
En versión corta: ¿puedo leer lo que se ejecuta?, ¿quién puede cambiarlo y con cuánto aviso? y ¿qué firmo y con qué tope?
Si una pregunta no tiene respuesta comprobable, eso ya es la respuesta.
El método no dice si algo funcionará, no detecta fallos en el código y no protege del riesgo que no es técnico.
Los dos discursos fáciles —«el código es ley» y «todo es un casino»— ahorran el trabajo de mirar. Hay propiedades concretas y comprobables, y de ellas depende lo que te puede pasar.