Respuestas>Más información sobre escalabilidad y rendimiento>Rendimiento de la cadena de bloques frente a latencia
Rendimiento de la cadena de bloques frente a latencia
// Tags
rendimiento de la cadena de bloquesTPS de la cadena de bloques
En resumen: el rendimiento y la latencia son dos medidas diferentes del rendimiento de una cadena de bloques que a menudo se confunden. El rendimiento es la capacidad: el número de transacciones que la red puede procesar por segundo (TPS). La latencia es la velocidad: el tiempo que tarda una transacción concreta en confirmarse y completarse. Una analogía con una autopista ayuda a aclarar la distinción. El rendimiento es el número de coches que la autopista puede transportar por hora. La latencia es el tiempo que tarda un coche en recorrer el trayecto desde la entrada hasta la salida. Una autopista puede tener un alto rendimiento (muchos coches) pero una alta latencia (velocidad lenta debido a la congestión), o un bajo rendimiento (pocos coches) pero una baja latencia (cada coche se desplaza rápido). Las mejores cadenas de bloques optimizan ambos aspectos, pero las compensaciones son reales.
La explicación sencilla
Cuando la gente pregunta «¿qué cadena de bloques es la más rápida?», normalmente se refiere a la latencia: ¿con qué rapidez se confirma mi transacción? Sin embargo, los materiales de marketing de la mayoría de los proyectos de cadena de bloques hacen hincapié en el rendimiento: cuántas transacciones por segundo puede gestionar la red. Se trata de métricas relacionadas, pero distintas, y confundirlas conduce a decisiones arquitectónicas erróneas y a expectativas de rendimiento poco realistas.
El rendimiento, medido en transacciones por segundo (TPS), indica la cantidad total de trabajo que puede realizar la red. Ethereum aproximadamente entre 15 y 30 TPS. Solana , en la práctica, entre cientos y miles de TPS. Bitcoin entre 5 y 7 TPS. Estas cifras representan la capacidad total de la red, es decir, el número total de transacciones de todos los usuarios que pueden incluirse en los bloques por segundo.
La latencia, medida en segundos o minutos, indica cuánto tiempo tarda una transacción concreta desde su envío hasta su finalización. En Ethereum, una transacción suele incluirse en un bloque en un plazo de entre 12 y 24 segundos, pero no se considera definitiva hasta pasados aproximadamente 12-13 minutos (dos épocas de finalidad). En Bitcoin, una transacción suele aparecer en un bloque en un plazo de entre 10 y 60 minutos y se considera liquidada de forma fiable tras seis confirmaciones (aproximadamente 60 minutos). En Solana, una transacción suele confirmarse en un plazo de entre 400 milisegundos y unos pocos segundos.
Una cadena de bloques puede tener un alto rendimiento pero una alta latencia (procesar muchas transacciones por segundo, pero cada una tarda mucho tiempo en completarse), o un bajo rendimiento pero una baja latencia (procesar pocas transacciones por segundo, pero cada una se completa rápidamente). Lo ideal es un alto rendimiento y una baja latencia, pero lograr ambas cosas a la vez sin sacrificar la descentralización ni la seguridad es el principal reto técnico del diseño de las cadenas de bloques.
Por qué esta distinción es importante para los desarrolladores
La distinción entre rendimiento y latencia tiene implicaciones prácticas directas para el diseño de aplicaciones. Si tu aplicación es un sistema de pagos, la latencia es la principal preocupación. A los usuarios que esperan en una caja les importa la rapidez con la que se confirma su pago individual, no cuántos otros pagos está procesando la red al mismo tiempo. Una cadena de bloques con 100 TPS y una finalidad de 2 segundos ofrece una mejor experiencia de pago que una con 10 000 TPS y una finalidad de 60 segundos.
Si tu aplicación es una plataforma de gran volumen de datos (como un agregador de DEX, un backend de videojuegos o un servicio de análisis), el rendimiento es más importante. Necesitas que la red pueda gestionar un gran número de operaciones simultáneas sin que el sistema se sature y se reduzca el rendimiento para todos los usuarios. Una cadena de bloques con 10 000 TPS y una finalización de 10 segundos puede ser preferible a otra con 100 TPS y una finalización de 1 segundo si tu aplicación genera miles de transacciones por segundo.
Para los proveedores de infraestructura y los operadores de nodos, esta distinción influye en la forma en que diseñan sus sistemas. Las cadenas de alto rendimiento generan más datos por segundo, lo que exige a los nodos un mayor ancho de banda, almacenamiento y potencia de procesamiento. Las cadenas de alta latencia con finalidad probabilística requieren una gestión más sofisticada de las reorganizaciones en los flujos de datos. Comprender el perfil de rendimiento y latencia de cada cadena que admites determina tus requisitos de hardware, el diseño de tus flujos de datos y tu modelo de costes.
Qué factores influyen en el rendimiento
El rendimiento viene determinado principalmente por tres parámetros del protocolo: el tamaño del bloque (o límite de gas), el tiempo de bloque y la complejidad de la transacción.
El tamaño del bloque define la cantidad máxima de datos o de cálculo que puede caber en un solo bloque. El límite de gas Ethereum limita el cálculo total por bloque. El límite de peso Bitcoin limita la cantidad total de datos por bloque. Los bloques más grandes pueden incluir más transacciones, lo que aumenta el rendimiento, pero también tardan más en propagarse por la red (lo que aumenta el riesgo de bifurcaciones) y requieren más recursos de los nodos (lo que podría reducir la descentralización).
El tiempo de bloque es la frecuencia con la que se generan nuevos bloques. Ethereum bloques cada 12 segundos. Bitcoin 10 minutos. Solana 400 milisegundos. Los tiempos de bloque más cortos aumentan el rendimiento, ya que la red procesa los bloques con mayor frecuencia, pero también incrementan la sobrecarga de comunicación entre los nodos y pueden plantear problemas de estabilidad.
La complejidad de las transacciones varía según la cadena y el tipo de transacción. Una simple transferencia de ETH consume 21 000 de gas, mientras que una interacción compleja de DeFi puede consumir 500 000 de gas o más. Las cadenas que gestionan transacciones más sencillas (o que optimizan la ejecución mediante el paralelismo, como Monad Solana, Sui y Monad ) pueden alcanzar un mayor TPS para un tamaño de bloque y un tiempo de bloque determinados.
La sobrecarga del mecanismo de consenso también afecta al rendimiento. Los sistemas de prueba de trabajo, como Bitcoin importantes recursos a la minería, lo que limita la rapidez con la que se pueden producir bloques de forma segura. Los sistemas de prueba de participación reducen esta sobrecarga, pero siguen requiriendo rondas de comunicación entre los validadores. El consenso de tipo BFT (utilizado por cadenas como Cosmos, Aptos y Sui) puede lograr una finalización más rápida, pero suele requerir un conjunto más reducido de validadores, lo que tiene implicaciones para la descentralización.
Qué factores influyen en la latencia
La latencia de una transacción concreta tiene varios componentes: el tiempo de espera en el mempool (el tiempo que la transacción permanece en la cola antes de ser seleccionada para un bloque), el tiempo de producción de bloques (la frecuencia con la que se crean nuevos bloques), el tiempo de propagación (el tiempo que tarda el nuevo bloque en llegar a todos los nodos) y el tiempo de finalidad (el número de bloques o épocas adicionales que deben transcurrir antes de que la transacción se considere irreversible).
En condiciones normales, el tiempo de espera en el mempool es mínimo, ya que la capacidad de los bloques supera la demanda. Durante los periodos de congestión, el tiempo de espera en el mempool es el principal factor que determina la latencia, ya que las transacciones compiten por un espacio limitado en los bloques. Las transacciones con comisiones más altas se seleccionan más rápidamente; las transacciones con comisiones más bajas pueden tener que esperar varios ciclos de producción de bloques.
El modelo de finalidad es el principal factor que diferencia la latencia entre las distintas cadenas. Las cadenas con finalidad instantánea (determinista), como las que utilizan un consenso basado en Tendermint, confirman las transacciones en una sola ronda de consenso sin posibilidad de reversión. Las cadenas con finalidad probabilística, como Bitcoin Ethereum, requieren múltiples confirmaciones antes de que una transacción se considere liquidada. La diferencia es enorme: una transacción en una cadena de Tendermint se considera definitiva en cuestión de segundos, mientras que una Bitcoin no se considera definitiva de forma fiable hasta pasada una hora.
Las redes de capa 2 añaden complejidad al panorama de la latencia. Una transacción en Arbitrum Base rápidamente en la capa 2 (en fracciones de segundo o segundos), pero los datos subyacentes no se liquidan en Ethereum hasta que el rollup publique su prueba o lote, lo que puede tardar entre minutos y horas. Dependiendo de los requisitos de seguridad de la aplicación, la latencia relevante podría ser el tiempo de confirmación de la capa 2 (rápido) o el tiempo de liquidación de la capa 1 (lento).
¿Cuál es la diferencia entre el rendimiento y la latencia?
Es fácil confundir el rendimiento y la latencia, ya que ambos describen la velocidad, pero responden a preguntas diferentes. El rendimiento se refiere al volumen: cuántas transacciones puede procesar toda la red por segundo. La latencia se refiere a una transacción concreta: cuánto tiempo tarda en completarse desde que se envía hasta que se finaliza. Ambos pueden variar de forma independiente, por lo que los equipos de infraestructura suelen hacer un seguimiento de ellos por separado, junto con la latencia de RPC. La tabla siguiente muestra las diferencias.
Aspecto
Rendimiento
Latencia
Qué mide
Capacidad total de la red
Velocidad de una sola transacción
Unidad
Transacciones por segundo (TPS)
Segundos o minutos
Analogía con la autopista
Número de coches por hora que circulan por la carretera
Tiempo necesario para que un coche cruce
Lo más importante para
Plataformas de datos de gran volumen
Pagos y aplicaciones interactivas
Mejorado por
Bloques más grandes, tiempos de bloque más cortos, ejecución en paralelo
Mayor rapidez en la finalización de las transacciones y menor congestión
Riesgo clave
Recursos de los nodos y presión por la descentralización
Largas esperas para recibir la confirmación
¿En qué se diferencian el rendimiento y la latencia entre las distintas cadenas de bloques?
Las distintas cadenas se sitúan en puntos muy diferentes en el mapa de rendimiento y latencia, debido en gran medida a sus diseños de consenso y modelos de finalidad. La tabla siguiente ofrece cifras aproximadas de varias redes de uso generalizado. Considéralas como una guía orientativa, ya que las cifras reales varían en función de las condiciones de la red y las actualizaciones del protocolo.
Blockchain
Rendimiento (TPS)
Tiempo de bloque
Plazo para la resolución definitiva
Bitcoin
De 5 a 7
Unos 10 minutos
Unos 60 minutos
Ethereum
De 15 a 30
Unos 12 segundos
Entre 12 y 13 minutos aproximadamente
Solana
Miles
Unos 400 ms
Segundos
Arbitrum
Miles
Unos 250 ms
Segundos en L2, más tiempo para estabilizarse en L1
BNB Smart Chain
De decenas a cientos
Unos 3 segundos
Entre 2 y 3 segundos
¿Puede una cadena de bloques tener un alto rendimiento y una baja latencia al mismo tiempo?
En principio sí, pero intentar conseguir ambas cosas a la vez suele tener un coste, que en la mayoría de los casos es la descentralización. Los bloques más grandes y los tiempos de bloqueo más cortos aumentan el rendimiento, pero también exigen más a cada nodo, lo que puede reducir el número de participantes capaces de seguir el ritmo. Esta tensión es el núcleo de la disyuntiva entre descentralización y rendimiento. Una forma habitual de conseguir tanto velocidad como capacidad es trasladar la ejecución desde la capa base a una cadena de bloques de Capa 2, que confirma rápidamente las transacciones sin dejar de liquidarlas en una Capa 1 segura.
¿Cómo afecta la congestión de la red al rendimiento y a la latencia?
La congestión se produce cuando estas dos métricas entran en conflicto. Cuando la demanda supera el espacio disponible en los bloques, las transacciones se acumulan en el mempool, las comisiones aumentan y la latencia se dispara, aunque la cadena siga procesando near máximo rendimiento. En otras palabras, la red está ocupada, pero es lenta para cada usuario individual. Comprender qué provoca la congestión de la cadena de bloques y las razones generales por las que estas se ralentizan te ayuda a diseñar aplicaciones que se degraden de forma controlada en lugar de bloquearse cuando el tráfico se dispara.
Preguntas frecuentes
¿Un TPS más alto es siempre mejor?
No necesariamente. Un TPS elevado solo resulta útil si tu aplicación genera realmente un gran volumen de transacciones. En el caso de una aplicación de pagos o un producto interactivo, la baja latencia y la rapidez en la finalización suelen ser más importantes que la capacidad bruta. La métrica adecuada que hay que optimizar depende de tu carga de trabajo, no de qué cifra parezca más impresionante en el ámbito del marketing.
¿Significa una baja latencia que una transacción es definitiva?
No. Una confirmación rápida no es lo mismo que la finalidad. Una transacción puede aparecer rápidamente en un bloque y, aun así, seguir siendo reversible hasta que la cadena alcance su umbral de finalidad. En las cadenas con finalidad probabilística hay que esperar a recibir varias confirmaciones, mientras que las cadenas determinísticas alcanzan la finalidad en una sola ronda de consenso. Consulta «finalidad de la cadena de bloques» para conocer la distinción completa.
¿En qué se diferencia la latencia de RPC de la latencia de la cadena de bloques?
La latencia de la cadena de bloques se refiere al tiempo que tarda la red en confirmar una transacción, mientras que la limitación de velocidad y el tiempo de respuesta del proveedor añaden un retraso adicional, a nivel de infraestructura, a cada solicitud que realiza tu aplicación. Una cadena rápida puede seguir pareciendo lenta si tu capa RPC está sobrecargada, por lo que ambas capas son importantes.
¿Los rollups de capa 2 mejoran el rendimiento o la latencia?
Ambas cosas, con una salvedad. Un rollup aumenta el rendimiento efectivo y ofrece confirmaciones rápidas en la capa 2, pero la liquidación completa de vuelta a la capa 1 puede tardar más tiempo. Que la latencia relevante sea la rápida de la capa 2 o la más lenta de la capa 1 depende del nivel de seguridad que requiera tu aplicación.
¿Qué cadena de bloques tiene el mejor rendimiento y la menor latencia?
No hay un único ganador; depende de lo que estés desarrollando. Solana otras cadenas de alto rendimiento destacan por su TPS bruto y por las confirmaciones en menos de un segundo, mientras que las cadenas con finalidad determinista son las que liquidan las transacciones más rápido, y Bitcoin tanto por la máxima seguridad como por la descentralización. Adapta el perfil de la cadena a las necesidades de tu aplicación, en lugar de perseguir una única cifra destacada.
Cómo Quicknode a los desarrolladores a gestionar ambas cosas
La infraestructura Quicknode está optimizada tanto para cargas de trabajo que requieren un gran rendimiento como para aquellas sensibles a la latencia. La API Core ofrece acceso RPC de baja latencia a través de una red de nodos distribuida a nivel mundial en más de 80 cadenas, con tiempos de respuesta 2,5 veces más rápidos que los de la competencia. Esto reduce directamente la latencia derivada de la infraestructura en cada llamada RPC que realiza tu aplicación. Para las cadenas en las que la latencia es especialmente crítica (como los slots de 400 ms Solana), Quicknode Yellowstone gRPC, que utiliza Protocol Buffers binarios en lugar de JSON para una serialización más rápida y una menor sobrecarga.
Para cargas de trabajo que requieren un alto rendimiento, Quicknode Streams gestiona la ingesta de grandes volúmenes de datos independientemente de las TPS de la cadena subyacente. Tanto si estás indexando Ethereum 15 TPS como Solana miles de TPS, Streams los datos completos de los bloques a tu destino con entrega garantizada y procesamiento por lotes configurable para un rendimiento óptimo. Clústeres dedicados proporcionan una infraestructura aislada para aplicaciones que necesitan un rendimiento predecible en condiciones de red variables, lo que garantiza que los picos de rendimiento provocados por la congestión no afecten a la fiabilidad de tu canalización de datos.
