Qué es blockchain y para qué sirve realmente
Introducción
Blockchain no es una base de datos “mejor”. Es un modelo de confianza. Se usa cuando varias partes necesitan compartir una fuente de verdad y no hay confianza plena (o no hay un árbitro central aceptado por todas).
Si no existe ese problema, blockchain suele ser sobrecoste: más piezas, más latencia, más operación y más riesgo.
Mini decisión en 60 segundos
Si respondes “no” a las dos primeras, normalmente no necesitas blockchain:
- ¿Hay múltiples organizaciones que deben escribir/validar el mismo registro?
- ¿Hay conflicto real de confianza o falta de árbitro aceptado?
- ¿El historial verificable es parte del valor del producto (no un adorno)?
- ¿Aceptas coste y latencia a cambio de ese modelo de confianza?
- ¿Puedes operar claves, nodos, upgrades, incidentes y auditoría?
Qué es blockchain y cómo se estructura
Una blockchain es un registro distribuido donde las operaciones se agrupan en bloques. Cada bloque incluye (entre otras cosas) una referencia criptográfica al bloque anterior, formando una cadena. Esa estructura hace que el historial sea tamper-evident: si alteras el pasado, se nota porque rompes el encadenamiento.
Los 4 componentes que importan
- Transacciones: operaciones (transferencias, cambios de estado, invocaciones a contratos…).
- Bloques: paquetes de transacciones + metadatos + referencia al bloque previo.
- Nodos: máquinas que guardan el historial y verifican reglas del protocolo.
- Consenso: mecanismo para que la red acuerde “qué bloque entra” y en qué orden.
Qué significa “distribuido” (sin confusión)
“Distribuido” no significa “más rápido” ni “más barato”. Significa que el historial lo mantienen varios nodos, y que la aceptación de cambios no depende de un único servidor. A cambio, pagas coordinación y operación.
Blockchain vs base de datos: comparación honesta
| Pregunta | Base de datos tradicional | Blockchain |
|---|---|---|
| ¿Quién controla la escritura? | Un operador | Consenso / consorcio |
| ¿Rectificación/borrado? | Posible (con permisos) | Difícil: se anexa (append-only). Borrar es problemático |
| Coste y rendimiento | Mejor y más barato | Peor y más caro (normalmente) |
| Valor principal | Eficiencia | Verificación y coordinación multi-parte |
Smart contracts: qué son (y lo que la gente imagina que son)
Un smart contract es código que se ejecuta bajo reglas de la cadena y puede cambiar estado en el ledger. No es un “microservicio mágico”. Tiene límites duros:
- Actualizar es complejo (no es “deploy tradicional”).
- Los errores cuestan (y a veces son irreversibles).
- Depende del modelo de ejecución (coste por operación, límites de tamaño, latencia).
- El mundo real es off-chain: si necesitas datos externos, entran oráculos o mecanismos equivalentes.
Regla de oro
Cuanta más lógica metes on-chain, más caro y frágil se vuelve. En sistemas serios: on-chain mínimo, y lo operativo fuera.
Tipos de blockchain: pública vs permissioned
No es un detalle: cambia el modelo de amenaza, la operación y la gobernanza.
| Tipo | Quién participa | Cuándo encaja | Riesgo típico |
|---|---|---|---|
| Pública (permissionless) | Cualquiera | Necesitas neutralidad y apertura | Coste/latencia/operación; exposición pública |
| Consorcio (permissioned) | Entidades identificadas | B2B, auditoría compartida, gobernanza definida | Política: si no hay gobernanza real, fracasa |
Plataformas representativas (familias útiles)
Públicas
- Bitcoin: transferencia de valor y robustez del historial.
- Ethereum: smart contracts y ecosistema (EVM).
Enterprise / consorcio
- Hyperledger Fabric: redes permissioned con identidad, políticas y chaincode.
- Besu: cliente Ethereum en Java para redes públicas y privadas.
- Quorum/GoQuorum: Ethereum permissioned con privacidad de transacciones/contratos.
- Corda: enfoque a acuerdos/flows entre partes identificadas (muy usado en B2B).
Lenguajes de contratos (depende del ecosistema)
- EVM (Ethereum y compatibles): Solidity y Vyper.
- Hyperledger Fabric: chaincode típicamente en Go, Node.js o Java.
- Corda: smart contracts en Kotlin o Java.
Cómo se integra blockchain en una arquitectura real (lo que separa POC de sistema)
Si un proyecto “solo” tiene smart contracts y una web, no tiene arquitectura: tiene demo. Un sistema real suele ser híbrido:
- Off-chain: BD, búsqueda, reporting, permisos, procesos.
- On-chain: evidencia verificable (hashes/referencias), estado mínimo y reglas críticas.
Diagrama ligero (modelo mental)
Backends / Procesos → (evidencia mínima) → Cadena
Lecturas rápidas → Indexer + BD off-chain ← eventos/confirmaciones
Claves → KMS/HSM/Vault (firma + auditoría)
Stack típico (conceptual, OSS-first)
- RPC / nodo: acceso al cliente de la red (propio o proveedor con SLA).
- Servicio de firma: firmas desde KMS/HSM/Vault (no llaves en el repo ni en variables).
- Indexer: para query eficiente (p.ej. The Graph o indexer propio).
- BD off-chain: Postgres/Redis para producto real.
- Eventing: cola/stream para reintentos, idempotencia, confirmaciones.
- Observabilidad: métricas de confirmación, errores de envío, backlog.
Buenas prácticas (las que evitan el desastre)
- Minimiza on-chain: hashes y referencias; datos operativos fuera.
- No metas PII on-chain salvo estrategia legal/operativa muy clara.
- Confirma antes de dar por “final”: en redes públicas, define confirmaciones mínimas.
- Key management serio: custodia, rotación y auditoría.
- Idempotencia: los reintentos existen; diseña para que repetir no duplique.
- Plan de salida: si el modelo fracasa, ¿cómo migras o reduces dependencia?
Malas prácticas extendidas (y su impacto real)
| Mala práctica | Impacto | Corrección mínima |
|---|---|---|
| Una sola entidad opera/decide la “red” | No aporta confianza; solo coste | Convertir en consorcio real o migrar a auditoría/BD |
| Claves privadas gestionadas “como se pueda” | Robo/pérdida = incidente grave | KMS/HSM/Vault + políticas + auditoría |
| Datos personales on-chain | Choque legal/operativo y riesgo reputacional | On-chain hashes; off-chain cifrado y controlable |
| Leer de cadena como si fuera BD | Latencia y UX mala | Indexer + cache + BD off-chain |
| Sin gobernanza ni operación | POC eterno; falla en prod | Roles, runbooks, pruebas, métricas |
Checklist de decisión (versión consultoría)
- ¿Qué conflicto de confianza multi-parte resuelve exactamente?
- ¿Quién valida y quién opera? (roles, responsabilidades, SLAs)
- ¿Qué va on-chain y por qué? (minimización explícita)
- ¿Cómo gestionas claves (custodia, rotación, pérdida, auditoría)?
- ¿Cómo lees rápido (indexer/off-chain) y manejas confirmaciones?
- ¿Qué alternativa no-blockchain has descartado y por qué?
- ¿Cuál es el plan de salida si el modelo no funciona?
Conclusión
Blockchain es útil cuando el problema es confianza multi-parte. Fuera de ahí, es muy fácil convertirlo en un sistema más caro, más lento y más difícil de operar.
En Gondor lo medimos así: si aporta valor verificable y operable, se diseña con rigor. Si no, se elige la alternativa simple y defendible.