Blockchain mal usado: cuando se mete por marketing, no por necesidad
Introducción
Hay proyectos donde blockchain encaja. Y hay muchos más donde se mete como etiqueta para sonar moderno. El problema no es “blockchain” como tecnología: el problema es blockchain como excusa.
En campo, “blockchain mal usado” tiene un patrón repetido: un sistema que podría ser una base de datos bien gobernada se convierte en un conjunto de piezas más caro, más lento, más difícil de operar y con peores propiedades legales. Y todo para poder decir “usa blockchain”.
Este post te da criterio práctico: cómo decidir rápido, señales rojas, costes ocultos reales, alternativas mejores y cómo reconducir un proyecto sin reescribirlo entero.
Test rápido: ¿te cuadra blockchain o estás comprando humo?
Responde estas preguntas sin autoengaño. Si no puedes responder con claridad, no tienes caso de uso; tienes marketing.
| Pregunta | Respuesta “sí” (señal a favor) | Respuesta “no” (señal de humo) |
|---|---|---|
| ¿Hay múltiples organizaciones que deben escribir/validar? | Hay multi-writer real | Una sola organización decide y las demás “consultan” |
| ¿Existe un conflicto de confianza o falta de árbitro aceptado? | No hay árbitro legítimo o nadie acepta uno | Ya hay un operador natural (empresa/administración) |
| ¿El historial verificable es parte del valor del producto? | El historial es “la prueba” | Solo quieres trazabilidad interna |
| ¿Puedes operar gobernanza, claves, upgrades y monitoreo? | Hay equipo/operación y responsabilidades | “Lo pondrá un proveedor” sin plan ni SLA |
| ¿Aceptas coste/latencia por ese modelo de confianza? | El trade-off es consciente y asumido | Esperas que sea más rápido/barato que una BD |
Si tu caso de uso es “una empresa quiere trazabilidad”, la solución suele ser: BD + auditoría + firma + almacenamiento inmutable (WORM). Es más barato, más rápido y más gobernable.
Qué problema resuelve blockchain (y cuál NO)
Blockchain no compite por eficiencia. Compite por modelo de confianza. Es una herramienta para coordinar una fuente de verdad compartida cuando: hay múltiples partes, conflictos de confianza y necesidad de verificación sin un único árbitro.
Lo que blockchain no te da por defecto:
- privacidad (muchas cadenas son “lo contrario” de privacidad),
- rectificación (la inmutabilidad choca con corregir/borrar),
- rendimiento barato (consenso + replicación cuestan),
- seguridad automática (malas claves, mala operación y mala gobernanza rompen todo).
Señales rojas de “blockchain por postureo”
- No hay gobernanza: nadie te puede explicar membresía, upgrades, disputa y operación.
- La red la opera una sola entidad pero se vende como “descentralizada”.
- Meten datos personales (o datos “rectificables”) en una estructura inmutable.
- El caso de uso real es auditoría interna (y aun así usan cadena).
- Se habla de “transparencia” sin definir quién audita, cómo y con qué evidencia.
- El POC funciona, pero no existe plan de operación (monitorización, claves, incidentes, backups).
Costes ocultos (los que matan proyectos en el año 2)
El POC no muestra el coste real. El coste real aparece cuando el sistema tiene que vivir en producción. Blockchain introduce fricción estructural:
| Coste oculto | Qué te obliga a hacer | Impacto típico |
|---|---|---|
| Gobernanza | Reglas de entrada/salida, upgrades, disputas | Bloqueo político y “parálisis de red” |
| Gestión de claves | Custodia, rotación, recuperación, HSM/KMS | Pérdida = pérdida; robo = desastre |
| Operación | Nodos, monitorización, incidentes, capacidad | OPEX alto y dependencia de perfiles raros |
| Modelo de datos | Minimización on-chain, off-chain inevitable | Arquitectura híbrida más compleja |
| Integración | Indexación, colas, confirmaciones, reintentos | Más puntos de fallo y más latencia |
Alternativas mejores (cuando blockchain no toca)
Muchísimos “casos blockchain” se resuelven con técnicas maduras y más defendibles. Aquí tienes una tabla de sustitución práctica:
| Necesidad real | Solución recomendada | Por qué suele ser mejor |
|---|---|---|
| Trazabilidad interna y auditoría | BD + audit log + control de cambios + WORM | Más simple, más rápido, más gobernable |
| Integridad de documentos | Hash + firma + timestamp + repositorio de evidencias | Prueba de no-alteración sin red distribuida |
| Compartir datos entre partes con reglas claras | API + contratos + auditoría independiente + acuerdos | Si hay árbitro aceptado, blockchain sobra |
| Registro “append-only” | Event sourcing / logs inmutables / transparency log | Inmutabilidad práctica sin consenso multi-nodo |
Casos en los que se utiliza mal y por qué (con ejemplos de campo)
1) “Trazabilidad” dentro de una sola empresa
Si solo una empresa escribe y valida, blockchain no añade confianza. Añade coste y fricción. Lo que necesitas es auditoría bien hecha: quién cambió qué, cuándo, por qué, con evidencia.
2) Certificar documentos “por si acaso”
Si tu objetivo es demostrar integridad, no necesitas una red distribuida. Necesitas un método verificable: hashes, firma y timestamping + políticas de custodia. Blockchain puede ser un lujo caro sin retorno.
3) Datos personales on-chain
Meter datos personales en un sistema inmutable suele ser una mala idea por diseño: rectificación/borrado, minimización, exposición y riesgo reputacional. Si el equipo dice “ya veremos”, eso no es arquitectura: es deuda futura garantizada.
Casos buenos (cuando sí aporta valor)
1) Consorcio real, con multi-writer y fricción de confianza
Varias organizaciones escriben y validan; ninguna puede ser “dueña” de la BD; se necesita auditoría compartida. Aquí sí puede haber valor, especialmente en redes permissioned con gobernanza explícita.
2) Historial verificable como parte del producto
Cuando el historial verificable no es accesorio, sino el núcleo del valor, blockchain puede ser la pieza correcta. Pero incluso ahí, casi siempre es híbrido: lo operativo va fuera y la cadena ancla lo verificable.
Diagrama ligero: patrón híbrido que suele funcionar
Sistema operativo (BD/Storage) → genera evidencia (hash/estado mínimo) → ancla/verifica en cadena
Lecturas y reporting → Indexer/DB (off-chain) ← eventos/confirmaciones de la cadena
Si aun así se usa blockchain: stack mínimo para no hacer una chapuza
Un proyecto serio asume desde el día 1 que blockchain implica arquitectura híbrida y operación:
- Gestión de claves (KMS/HSM/Vault). Sin esto, el proyecto no es defendible.
- Indexer o capa de lectura (porque leer directamente de la cadena no escala para producto).
- BD off-chain para datos operativos y búsquedas.
- Eventing (cola/stream) para procesar confirmaciones y reintentos.
- Observabilidad (latencia, reintentos, confirmaciones, fallos de firma/tx).
- Gobernanza escrita: membresía, upgrades, disputas, auditoría.
Patrones de fracaso (malas prácticas extendidas) y cómo corregirlos
Esta sección está pensada para proyectos reales que ya existen. No es “teoría bonita”: son patrones que vemos repetirse. Te damos algunos tips senscillos en cada caso, que pueden ayudarte si estás pensando en montar algo con blockchain.
Patrón 1: “Blockchain privado” operado por una sola entidad
Por qué es mala práctica: no hay ganancia de confianza; solo coste adicional.
Impacto: la red no aporta nada que no aporte una BD con auditoría; además complica operación y auditoría.
Cómo reconducir (sin big-bang):
- Hoy: define el objetivo real (auditoría, integridad, interoperabilidad) y mide qué aporta la cadena frente a una BD.
- 1 semana: decide: (A) convertir a consorcio real (multi-operador) o (B) migrar a alternativa (BD + audit log + WORM).
- 1 mes: si se migra, conserva solo “anclaje” (hash) como evidencia externa y mueve lo operativo fuera.
- 3 meses: simplifica: elimina dependencia de la cadena si ya no aporta valor medible.
Patrón 2: datos sensibles o personales en cadena
Por qué es mala práctica: inmutabilidad vs rectificación/borrado y riesgo de exposición.
Impacto: riesgo legal, reputacional y operativo; “parches” complejos y costosos.
Cómo reconducir:
- Hoy: stop: no más PII on-chain. Inventario de lo ya escrito.
- 1 semana: patrón híbrido: on-chain solo hashes/referencias; datos cifrados off-chain.
- 1 mes: políticas de minimización y control de acceso; proceso de respuesta a solicitudes (rectificación).
- 3 meses: auditoría de exposición + rediseño de modelo de datos para evitar recurrencia.
Patrón 3: smart contracts como “backend general”
Por qué es mala práctica: cambios caros, riesgo alto, latencia y dificultad de corregir errores.
Impacto: el producto se vuelve lento y frágil; la evolución queda bloqueada por la cadena.
Cómo reconducir: mover lógica operativa al backend y dejar on-chain solo lo mínimo verificable (estado/consentimiento/anchor).
Patrón 4: no existe plan de operación (observabilidad, incidentes, upgrades)
Impacto: el sistema “funciona” hasta el primer incidente. Y luego no hay respuesta, solo improvisación.
Cómo reconducir:
- Hoy: define SLOs (latencia/confirmación/errores) y métricas mínimas.
- 1 semana: alertas, runbook y responsable de operación.
- 1 mes: simulacro (caída de nodo, fallo de firma, congestión) y lecciones aprendidas.
Patrón 5: no hay “exit plan”
Impacto: quedas atrapado: si el modelo fracasa, no puedes salir sin romperlo todo.
Cómo reconducir: define desde ya cómo migrar (dejar anclajes, exportar evidencias, reconstruir ledger en BD).
Checklist de decisión (versión consultoría, sin humo)
- ¿Qué conflicto de confianza resuelve exactamente?
- ¿Quién opera nodos y quién valida? (nombres, responsabilidades, SLAs)
- ¿Qué datos van on-chain y por qué? (y qué queda off-chain)
- ¿Cómo gestionas claves (custodia, rotación, pérdida, auditoría)?
- ¿Cómo lees rápido? (indexación/caché) ¿Cómo manejas confirmaciones y reintentos?
- ¿Qué coste/latencia aceptas? (medible)
- ¿Qué alternativa no-blockchain has descartado y por qué?
- ¿Cuál es el plan de salida si el modelo no funciona?
Conclusión
Blockchain puede ser una herramienta útil, pero solo cuando el problema lo exige. Si se mete por marketing, el resultado típico es un sistema más caro, más lento y más difícil de operar, con peor encaje legal y sin valor diferencial real.
En Gondor defendemos criterio: si aporta valor medible, se diseña y se opera bien. Si no, se elige la alternativa simple que funciona. Lo demás es postureo.