Español
Oct 19, 2026

El trilema de la blockchain explicado: ¿tiene solución?

El trilema de la blockchain: una cadena solo logra con facilidad dos de tres propiedades (descentralización, seguridad, escalabilidad). Rollups, sharding y Sui.

El trilema de la blockchain explicado: ¿tiene solución?

El trilema de la blockchain, también llamado trilema de la escalabilidad, es la idea de que una blockchain solo puede lograr con facilidad dos de tres propiedades a la vez: descentralización, seguridad y escalabilidad. Si se aumenta el rendimiento pidiendo a los nodos que trabajen más, menos personas pueden ejecutar un nodo; si se reparte la carga entre muchas cadenas pequeñas, cada una resulta más fácil de atacar. El concepto lo popularizó Vitalik Buterin, cofundador de Ethereum, y la mayoría de los diseños de blockchain modernos pueden leerse como un intento de escapar de él.

Esta guía explica de dónde viene el trilema, qué significa realmente cada propiedad, cómo los rollups, el sharding y la ejecución paralela intentan conseguir las tres y por qué algunos investigadores lo consideran más una regla empírica que una ley.

¿Qué es el trilema de la blockchain?

La formulación más clara procede del ensayo de Buterin de abril de 2021 «Why sharding is great». En él describe tres propiedades que una blockchain intenta tener y afirma que las técnicas «sencillas» solo consiguen dos:

  • Escalabilidad: la cadena «puede procesar más transacciones de las que un solo nodo normal (piense en un portátil de consumo) puede verificar».
  • Descentralización: la cadena «puede funcionar sin ninguna dependencia de confianza respecto de un pequeño grupo de grandes actores centralizados».
  • Seguridad: la cadena «puede resistir que un gran porcentaje de los nodos participantes intente atacarla».

La idea es anterior a ese ensayo. La Sharding FAQ de Ethereum, un documento de investigación temprano, ya se preguntaba si «hay algún tipo de trilema de la escalabilidad en juego», y definía la descentralización como un sistema en el que cada participante solo necesita los recursos de «un portátil normal o un VPS pequeño».

Fíjese en lo que hacen estas definiciones. La escalabilidad se mide frente a lo que puede gestionar un nodo corriente, no como una cifra bruta de transacciones por segundo. Una cadena que procesa 100.000 transacciones por segundo pero necesita hardware de centro de datos para verificarlas no ha resuelto el trilema: ha elegido la escalabilidad por encima de la descentralización.

Los tres compromisos clásicos

El ensayo de Buterin clasifica los diseños ingenuos en tres grupos, cada uno de los cuales elige dos vértices:

DiseñoObtieneRenuncia aPor qué
Blockchains tradicionales (Bitcoin, Ethereum antes del sharding)Descentralización, seguridadEscalabilidadCada participante ejecuta un nodo completo que verifica todas las transacciones, de modo que el rendimiento queda limitado por un ordenador corriente.
Cadenas de alto TPS con pocos validadoresEscalabilidad, seguridadDescentralizaciónUn número reducido de nodos, a menudo de 10 a 100 según la descripción de Buterin, mantiene el consenso entre ellos con hardware potente.
Ecosistemas multicadenaEscalabilidad, descentralizaciónSeguridadLa carga se reparte entre muchas cadenas independientes, pero a un atacante le basta con hacerse con una de ellas, que puede ser una parte ínfima del total.

La tensión de fondo es el coste de los recursos. Si cada nodo debe comprobarlo todo, el nodo más lento que se quiera incluir fija el límite de velocidad. Si se eleva ese límite, se reduce el conjunto de personas que pueden participar. Si se divide el trabajo entre grupos, cada grupo es más pequeño y más barato de corromper. Nuestra guía proof of stake vs proof of work explica cómo se determina, de entrada, el coste de atacar una cadena.

Rollups: escalar la ejecución fuera de la cadena

La respuesta principal de Ethereum han sido los rollups de layer 2. Un rollup ejecuta las transacciones en una red aparte y después publica los datos en Ethereum junto con una prueba de validez (ZK rollups) o con una afirmación que cualquiera puede impugnar mediante una prueba de fraude (optimistic rollups). La capa base sigue siendo lo bastante pequeña para que la verifiquen nodos corrientes, mientras la ejecución ocurre en otro lugar.

En términos del trilema, los rollups intentan conservar la descentralización y la seguridad de Ethereum añadiendo escala. El ensayo de Buterin de diciembre de 2021 «Endgame» detallaba el compromiso: «La producción de bloques está centralizada, la validación de bloques no requiere confianza y está muy descentralizada, y se sigue impidiendo la censura». Un operador potente puede producir bloques, siempre que cualquiera pueda comprobarlos a bajo coste.

La práctica va por detrás de la teoría. A 17 de octubre de 2026, L2BEAT clasificaba 57 de los 67 proyectos de layer 2 evaluados en el Stage 0, lo que significa que los operadores aún podían saltarse las reglas. El 3 de febrero de 2026, Buterin escribió que «la visión original de las L2 y de su papel en Ethereum ya no tiene sentido, y necesitamos un nuevo camino», citando el lento avance en descentralización y una capa base que ahora escala con comisiones bajas (The Defiant). Nuestra guía de layer 2 trata los rollups en detalle.

Sharding: dividir el trabajo en la layer 1

El sharding ataca el trilema de frente. En lugar de que cada nodo procese todas las transacciones, los validadores se dividen en grupos (shards) que gestionan cada uno una parte de la carga, mientras una capa de coordinación mantiene a los shards de acuerdo. Para evitar que un atacante se concentre en un solo shard, los validadores se asignan de forma aleatoria y se redistribuyen. El ensayo de Buterin de 2021 sostiene que esta combinación es «una técnica que te da las tres»: cada nodo realiza una fracción del trabajo, no se necesitan supernodos y un atacante tiene que vencer al sistema entero, no a una pequeña parte.

El propio Ethereum se alejó del sharding de la ejecución. Ahora fragmenta los datos: los blobs de la actualización Dencun (13 de marzo de 2024) y PeerDAS de la actualización Fusaka (3 de diciembre de 2025) permiten a los nodos confirmar que los datos de los rollups están disponibles mediante muestreo en lugar de descargarlos por completo (Ethereum Foundation).

MultiversX aplica sharding de la ejecución en su cadena principal. Su adaptive state sharding combina sharding de red, de transacciones y de estado, con una metachain que decide en cada epoch qué nodos cambian de shard; la selección usa aleatoriedad para que no pueda predecirse de antemano. Con su consenso Secure Proof of Stake, cada validador debe hacer staking de al menos 2.500 EGLD (documentación de MultiversX). La configuración de la red en vivo a 17 de octubre de 2026 mostraba 3 shards de ejecución, 400 nodos por shard y una ronda de 600 ms (gateway de MultiversX).

El precio es la complejidad. Una transacción que afecta a cuentas de dos shards se ejecuta en dos pasos y de forma asíncrona, lo que dificulta componer algunas interacciones DeFi. Nuestra guía del sharding y la explicación de EGLD y MultiversX profundizan en ello.

DAG y ejecución paralela: el enfoque de Sui

Una tercera vía mantiene una sola cadena pero aprovecha todos los núcleos de cada validador. Sui ordena las transacciones con Mysticeti, un protocolo de consenso en el que los validadores proponen bloques en paralelo y los bloques se referencian entre sí formando un grafo acíclico dirigido (DAG). La documentación de Sui indica que Mysticeti confirma en unos 0,5 segundos de media, con un rendimiento sostenido de 200.000 transacciones por segundo en benchmarks, aunque advierte de que son cifras de pruebas controladas y no métricas de producción.

El modelo de datos de Sui también ayuda. Cada transacción declara los objetos que utiliza y, según la documentación sobre el ciclo de vida de las transacciones, las transacciones que no entran en conflicto en sus entradas se ejecutan de forma totalmente paralela. Dos personas que operan en dos pools distintos no tienen que esperarse.

En términos del trilema, esto impulsa la escalabilidad haciendo más eficiente a cada validador en lugar de dividir la red. El compromiso está en el listón de hardware. La guía de validadores de Sui recomienda al menos 24 núcleos físicos, 128 GB de memoria, 4 TB de almacenamiento NVMe y una conexión de 1 Gbps, muy por encima de un portátil de consumo. Nuestras guías sobre Sui y Mysticeti explican el diseño.

¿Es real el trilema? Las principales críticas

El trilema es una abreviatura útil, pero no es un teorema demostrado. Objeciones habituales:

  • Los términos son difusos. «Descentralizado» y «seguro» no tienen una medida única y aceptada. Una cadena puede contar sus validadores, sus nodos completos, la distribución de su stake o la diversidad de sus clientes, y cada criterio da una respuesta distinta.
  • Es una instantánea de la tecnología actual. La formulación original describe lo que logran las técnicas «sencillas». Las pruebas de validez, el muestreo de disponibilidad de datos y mejores protocolos de consenso han desplazado cada uno la frontera, y por eso el propio Buterin sostiene que el sharding y los rollups pueden conseguir las tres.
  • El hardware no deja de mejorar. Lo que se considera un «nodo normal» crece cada año, de modo que un nivel de rendimiento que antes exigía centralización puede funcionar más adelante en equipos de consumo.
  • También importan otros compromisos. La latencia, la componibilidad, el coste y la complejidad no aparecen en el triángulo y, sin embargo, deciden qué diseño se adapta a cada uso. El sharding, por ejemplo, escala bien pero hace asíncronas las llamadas entre shards.
  • El marketing abusa de él. Muchos proyectos afirman haber «resuelto el trilema». En la práctica, compruebe qué supone una cadena sobre el hardware de los validadores, cuántas partes independientes ejecutan nodos y qué tendría que controlar un atacante.

Un resumen justo: nada es gratis, pero el precio de cada vértice ha bajado. Los diseños se diferencian sobre todo en las suposiciones que están dispuestos a hacer.

Dónde encaja JewelSwap

JewelSwap se basa en layer 1 que recorren caminos distintos frente al trilema: el liquid staking de JWLEGLD en MultiversX, con sharding, JWLSUI en Sui y JWLXRD en Radix. El diseño de cada cadena determina las comisiones, la velocidad y aquello en lo que usted debe confiar.

Preguntas frecuentes

¿Qué es el trilema de la blockchain en pocas palabras?

Es la idea de que una blockchain solo puede tener con facilidad dos de tres propiedades: descentralización, seguridad y escalabilidad. Mejorar una, como el rendimiento, suele costar otra, como el número de personas que pueden permitirse ejecutar un nodo.

¿Quién ideó el trilema de la blockchain?

Lo popularizó Vitalik Buterin, cofundador de Ethereum. Aparece en la primera Sharding FAQ de Ethereum y en su ensayo de abril de 2021 «Why sharding is great», que define las tres propiedades.

¿Es el trilema de la escalabilidad lo mismo que el trilema de la blockchain?

Sí. Ambos nombres describen el mismo compromiso entre descentralización, seguridad y escalabilidad. El propio Buterin lo llama trilema de la escalabilidad.

¿Alguien ha resuelto el trilema de la blockchain?

Ninguna cadena lo ha demostrado sin lugar a dudas. Los rollups, el sharding y la ejecución paralela amplían los límites, pero cada uno se apoya en suposiciones sobre los operadores, el hardware o la complejidad entre shards. Trate «trilema resuelto» como un reclamo de marketing y revise los detalles.

¿Qué relación tienen las layer 2 con el trilema?

Los rollups sacan la ejecución de la capa base para que Ethereum siga siendo fácil de verificar, con el objetivo de añadir escala sin renunciar a la descentralización ni a la seguridad. En la práctica, la mayoría seguían clasificados en el Stage 0 por L2BEAT en octubre de 2026, lo que significa que los operadores podían saltarse las reglas.

Siga leyendo

Este artículo es educativo y no constituye asesoramiento financiero. Las cifras corresponden al 17 de octubre de 2026 y proceden de L2BEAT, la Ethereum Foundation y la documentación de MultiversX y Sui, y cambian con el tiempo; las fuentes están enlazadas a lo largo del texto.

About the author.

Co-Founder at JewelSwap & Chief Strategy Officer at iDenfy. Viktor brings his successful track record of superb development & project management.