---
title: "Trilema de la cadena de bloques"
description: "El trilema de blockchain es una heurística para comparar escalabilidad, descentralización y seguridad bajo cargas de trabajo y modelos de amenazas explícitos. No es un teorema o una regla que los sistemas literalmente elijan sólo dos."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Trilema de la cadena de bloques
> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
## Respuesta directa
El trilema de blockchain es una heurística de diseño: aumentar la escalabilidad, la descentralización o la seguridad bajo un modelo de confianza y recursos fijos puede presionar las otras dimensiones. No es un teorema de imposibilidad matemática, una puntuación aditiva o una regla según la cual cada red debe seleccionar exactamente dos propiedades.
Cada eje necesita definiciones operativas. La escalabilidad incluye rendimiento sostenible, latencia, tarifas y crecimiento de datos o estado bajo la carga establecida. La descentralización incluye validación independiente, entrada y salida sin permiso y concentración entre participación o poder hash, operadores, clientes, proveedores de nube, geografía y gobernanza. La seguridad incluye seguridad, vivacidad, finalidad, resistencia a la censura, disponibilidad de datos y recuperación bajo un modelo de adversario explícito.
La fragmentación, los resúmenes, las pruebas de validez, los clientes ligeros y el muestreo de disponibilidad de datos pueden mejorar la frontera factible al cambiar quién ejecuta, descarga, almacena, prueba o verifica los datos. No eliminan las compensaciones: mueven los costos de los recursos e introducen suposiciones específicas de cada capa sobre secuenciadores, probadores, desafiantes, puentes, claves de actualización y disponibilidad de datos.
## Cómo funciona
1. Fije la cadena, la red, la versión del protocolo, la capa y el reclamo arquitectónico exacto. Identifique los componentes de consenso, ejecución, disponibilidad de datos, liquidación y gobernanza en lugar de calificar solo una marca.
2. Definir escalabilidad, descentralización y seguridad con proxies mensurables, una carga de trabajo y una ventana de observación. No agregue TPS, recuento de nodos y costo de ataque en una puntuación adimensional.
3. Mapear quién propone, construye, ordena, valida, almacena datos, prueba, desafía, actualiza, pausa y habilita la salida. Registro de permisos, custodia y límites de control de emergencia.
4. Medir la descentralización entre entidades de participación o poder hash, nodos de validación independientes, software de cliente, alojamiento, geografía y gobernanza. Incluya barreras de hardware, ancho de banda, almacenamiento, tiempo de sincronización y capital.
5. Medir la seguridad como protección, vivacidad, finalidad, resistencia a la censura, disponibilidad y recuperación de datos bajo umbrales contradictorios establecidos, supuestos de correlación e incentivos económicos.
6. Mida la escalabilidad utilizando el rendimiento sostenido y de cola, la latencia de inclusión y finalidad, las tarifas bajo carga, los bytes, el crecimiento del estado, los costos de sincronización y verificación, además del comportamiento durante la congestión o falla de los componentes.
7. Compare arquitecturas en la misma carga de trabajo y modelo de amenaza, versione la evidencia y enfatice las fallas. Indique qué supuesto de costo o confianza se movió entre capas en lugar de afirmar que el trilema se resolvió.
## Ejemplo
- Una cadena hipotética completamente replicada que lleva `2 MiB / 12 seconds` tiene `7,200 blocks/day` y una entrada sin procesar de `2 * 7,200 = 14,400 MiB/day = 14.0625 GiB/day`. Elevar la carga útil a `8 MiB` da `57,600 MiB/day = 56.25 GiB/day`, exactamente `4x` antes de la sobrecarga del protocolo, los índices, el estado y la replicación. La capacidad aumenta, pero esta aritmética no es un requisito completo del nodo.
- Supongamos que los operadores de estaca controlan `34%, 22%, 18%, 16%, 10%`. Bajo un umbral de bloqueo de vida establecido `>= 1/3`, solo el primer operador califica. Bajo un umbral de control establecido `>= 2/3`, el prefijo más pequeño son los tres primeros: `34 + 22 + 18 = 74%`; los dos primeros totalizan solo `56%`. Los vínculos de entidades reales y los umbrales de protocolo aún requieren verificación.
- Si `10,000 transactions * 200 bytes = 2,000,000 bytes`, pero un resumen publica un `400,000-byte batch`, el promedio es `400,000 / 10,000 = 40 bytes/transaction` o `5x` compresión de datos. Esto por sí solo no dice nada sobre el riesgo del secuenciador, la prueba, el puente, la disponibilidad de datos o la clave de actualización.
- En un modelo de muestreo ilustrativo con `4,096 shares`, un adversario retiene `25% = 1,024 shares`. Si se toman `30 independent uniform samples with replacement`, la probabilidad de perder todas las acciones retenidas es `(3,072 / 4,096)^30 = 0.75^30 = 0.0001785821 = 0.01785821%`; la detección modelada es `99.98214179%`. La independencia, la uniformidad y el modelo de retención son suposiciones, no una garantía de producción.
## Riesgos
- Tratar la heurística del trilema como un teorema universal demostrado.
- Dejar indefinida la escalabilidad, la descentralización o la seguridad.
- Agregar proxies diferentes en una partitura opaca o adimensional.
- La selección selectiva anunciaba un TPS máximo en lugar de un rendimiento sostenible.
- Informar promedios mientras se oculta la latencia de cola y el comportamiento de carga de fallas.
- Utilizar únicamente las tarifas como medida de escalabilidad sin carga de trabajo ni subvenciones.
- Tratar los recuentos de nodos, validadores o direcciones sin procesar como entidades independientes.
- Ignorar la participación delegada, el poder de hash y el control común del operador.
- Ignorar la concentración de clientes, nube, geografía y gobernanza.
- Excluyendo barreras de hardware, ancho de banda, almacenamiento, sincronización y capital.
- Llamar seguro a un sistema sin un adversario ni un umbral establecidos.
- Combinar seguridad, vivacidad, finalidad, resistencia a la censura y recuperación.
- Ignorar la disponibilidad de datos, la recuperación histórica y el crecimiento estatal.
- Exagerar las garantías y suposiciones del cliente ligero, de prueba o de muestreo.
- Comparar el rendimiento de L1 y L2 como si sus garantías fueran idénticas.
- Suponiendo que un paquete acumulativo hereda todas las propiedades de seguridad de la capa base.
- Ignorar las claves de secuenciador, probador, retador, puente, administrador y actualización.
- Comparar diferentes versiones de protocolos, cargas de trabajo o ventanas de observación.
- Inferir la demanda simbólica o el valor de la inversión a partir de la calidad de la arquitectura.
- Declarar una solución permanente después de una optimización elimina un cuello de botella.
## Errores comunes
- **Cada cadena de bloques debe elegir exactamente dos de tres propiedades.** El trilema es una heurística comparativa; Los sistemas ocupan fronteras cambiantes de compensación bajo diferentes supuestos.
- **Más validadores o nodos significan automáticamente más descentralización y seguridad.** Los pesos de las entidades, el software, el alojamiento, la geografía, la gobernanza y la verificación independiente son importantes.
- **Un número alto de TPS demuestra una descentralización escalable.** La carga de trabajo, el hardware, el crecimiento de los datos, la latencia de cola, las tarifas y el comportamiento ante fallos determinan si la capacidad es sostenible.
- **L2, la modularidad o la fragmentación eliminan el trilema.** Estos diseños redistribuyen la ejecución, los datos, las pruebas y la confianza; Cada garantía debe ser rastreada de principio a fin.
- **Las tres dimensiones son puntuaciones escalares fijas o predicen el valor del token.** Las mediciones son multidimensionales y versionadas, mientras que la economía de los tokens es una cuestión separada.
## Temas relacionados
- [Cadena de bloques](/es/crypto/blockchain/)
- [Capa 2](/es/crypto/layer2/)
- [Blockchain modular](/es/crypto/modular-blockchain/)
## Fuentes autorizadas
- [Por qué la fragmentación es genial: desmitificando las propiedades técnicas](https://vitalik.eth.limo/general/2021/04/07/sharding.html) - Vitalik Buterin (consultado: 2026-08-18)
- [Escalado](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (consultado: 2026-08-18)
- [Disponibilidad de datos](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultado: 2026-08-18)
- [Gira tu propio nodo Ethereum](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consultado: 2026-08-18)
- [Diversidad de clientes](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (consultado: 2026-08-18)
- [Ataque y defensa de prueba de participación de Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (consultado: 2026-08-18)
- [Bitcoin: un sistema de efectivo electrónico entre pares](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consultado: 2026-08-18)
- [Descripción general de la tecnología Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (consultado: 2026-08-18)
Source: https://wiki.fcontext.com/es/crypto/blockchain-trilemma/index.mdx