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.
El rendimiento, medido en transacciones por segundo (TPS), indica la cantidad total de trabajo que puede realizar la red. Ethereum procesa aproximadamente entre 15 y 30 TPS. Solana procesa, en la práctica, entre cientos y miles de TPS. Bitcoin procesa 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 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 finalización de 2 segundos ofrece una mejor experiencia de pago que otra con 10 000 TPS y una finalización 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 sea capaz de gestionar un gran número de operaciones simultáneas sin que el sistema se sature y se vea afectado 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 un manejo más sofisticado 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.
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.
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 hacen Solana, Sui y Monad ) pueden alcanzar un mayor TPS para un tamaño de bloque y un tiempo de bloque determinados.
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 y Ethereum, requieren múltiples confirmaciones antes de que una transacción se considere liquidada. La diferencia es enorme: una transacción en una cadena Tendermint se considera definitiva en cuestión de segundos, mientras que una transacción 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 o Base se confirma rápidamente en la capa 2 (desde menos de un segundo hasta varios segundos), pero los datos subyacentes no se liquidan en la capa 1 de 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 la diferencia.
¿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 se finalizan en una sola ronda de consenso. Consulta «finalidad de la cadena de bloques» para conocer la distinción completa.
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 en 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.
Para cargas de trabajo que requieren un alto rendimiento, Quicknode Streams gestiona la ingesta de grandes volúmenes de datos independientemente del TPS de la cadena subyacente. Tanto si estás indexando Ethereum a 15 TPS como Solana a miles de TPS, Streams entrega datos en bloques completos a tu destino con entrega garantizada y procesamiento por lotes configurable para un rendimiento óptimo. Los 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 canal de datos.