1. El punto de partida es la coordinación
Una organización puede tener sus procesos digitalizados y seguir conciliando información con bancos, proveedores o clientes. Cuando cada participante conserva su versión de una operación, aparecen tareas de comparación, verificación y resolución de diferencias. Blockchain puede aportar un registro verificable y reglas compartidas; su utilidad depende de que esas propiedades resuelvan una fricción concreta.
Antes de elegir una red, identificá quién crea la información, quién necesita comprobarla y qué desacuerdos son costosos. Si una sola organización controla el proceso, o todos aceptan a un administrador con mecanismos de auditoría, una base de datos puede ser suficiente. La comparación debe incluir integración, operación, gobernanza, recuperación y salida del sistema.
2. Cómo cambia el modelo de negocio
En bancos y medios de pago, analizá las funciones: registro, transferencia, conciliación, custodia y liquidación. Automatizar una de ellas puede reducir trabajo manual, pero también desplazar ingresos y responsabilidades. Una fintech puede coordinar servicios sobre una infraestructura abierta y mantener intermediación en identidad, experiencia de usuario o custodia. Una Big Tech puede aportar distribución e infraestructura y concentrar el acceso del usuario aunque el registro subyacente sea distribuido.
La pregunta económica es doble: ¿quién obtiene el beneficio y quién asume el costo? Una red compartida puede ahorrar conciliación al comprador mientras exige al proveedor cargar datos y operar nuevos sistemas. Sin incentivos para participar y estándares de información, el proyecto puede fallar aunque el software funcione.
3. Evolución y diversidad de redes
El sistema propuesto por Bitcoin articula firmas, validación de gastos y prueba de trabajo para transferencias entre pares. Ethereum incorpora un entorno general de ejecución de contratos. Las DLT empresariales permiten explorar acuerdos entre organizaciones identificadas. Esta evolución amplía las opciones: no implica que toda empresa necesite una criptomoneda ni que una plataforma reemplace universalmente a otra.
Compará las cinco plataformas del programa usando acceso, datos, ejecución y responsabilidades. Evitá rankings de transacciones por segundo sin especificar versiones, configuración y carga. La arquitectura elegida debe sostener los requisitos del caso.
4. De un acuerdo a una regla ejecutable
Para diseñar un smart contract, separá estado, acciones, permisos y precondiciones. En un escrow, el estado describe si hay fondos y si se habilitó su liberación. El programa verifica condiciones y procesa una llamada; no comprende por sí mismo el significado comercial de una entrega ni decide cómo resolver una ambigüedad.
Preguntá quién invoca cada acción, quién puede actualizar reglas y qué ocurre ante inactividad, error o disputa. Si una condición depende del mundo externo, es necesario especificar el origen del dato. La automatización puede ejecutar de manera consistente una decisión basada en información incorrecta.
5. Aplicación sectorial y límites
En logística, distinguir trazabilidad documental de existencia y condición física del bien. En salud, identificar qué información sensible debe quedar fuera del registro compartido. En PropTech, separar representación digital de los derechos sobre un inmueble. En InsurTech, distinguir la regla de pago del daño individual, de la calidad del indicador y de la capacidad de financiar la obligación.
La ventaja potencial es contar con evidencia compartida y reglas consistentes. Las desventajas posibles incluyen complejidad, exposición de información, dependencia de fuentes y custodios, costos de integración y desacuerdos de gobernanza. No se eliminan por usar un contrato inteligente.
6. Cómo evaluar una propuesta
- Describir el problema y la alternativa actual con una métrica observable.
- Identificar actores, incentivos y conflictos de interés.
- Explicar qué garantías debe aportar la arquitectura.
- Definir datos, permisos, reglas de ejecución y manejo de excepciones.
- Comparar costos y riesgos contra una solución más simple.
- Proponer un piloto con criterios de aceptación y una vía de salida.
Como hipótesis de piloto, podría medirse el tiempo de conciliación antes y después, manteniendo comparable el volumen de operaciones. La reducción debe verificarse con datos; no se infiere automáticamente de descentralizar el registro.
Recorrido sugerido
| Día | Actividad | Evidencia de aprendizaje |
|---|---|---|
| 1 | Leer la guía y comparar redes. | Mapa de actores y fricción del caso. |
| 2 | Explorar arquitectura y seguro con oráculos. | Dos escenarios y explicación del cambio de resultado. |
| 3 | Resolver un caso y practicar el cuestionario. | Recomendación argumentada y reflexión sobre errores. |
La duración es orientativa y sigue los tres días indicados en la guía de la unidad. El cuestionario es formativo: sus resultados locales no sustituyen la evaluación institucional.
Bibliografía y fuentes
Bibliografía de la Unidad 1 del programa: Bashir (2018), Mastering Blockchain, 2.ª edición; Beltrán, Nespral y Fernández Hergueta (2021), Blockchain: el modelo descentralizado hacia la economía digital; Drescher (2017), Blockchain Basics; Edmunds (2022), DeFi. El nuevo paradigma de las finanzas modernas; Lewis (2018), The Basics of Bitcoins and Blockchains.
Fuentes primarias de arquitectura consultadas para esta ampliación el 9 de septiembre de 2026. Los ejemplos sectoriales y las simulaciones son casos didácticos hipotéticos, no afirmaciones sobre implementaciones comerciales.