Latencia y throughput en blockchain

A medida que evoluciona Ethereum, la eficiencia de su comunicación entre pares (P2P) sigue siendo un factor crítico en su rendimiento y escalabilidad. La hipótesis de que mejorar la distribución geográfica de los nodos de Ethereum podría mejorar la latencia, en particular aumentando la presencia de nodos en América Latina, África y Asia del Sur, podría ser correcta. Esta diversificación podría reducir potencialmente la centralización de nodos predominantemente en EE. UU. y Europa, lo que podría llevar a interacciones de red más democráticas y eficientes. Medir efectivamente la eficiencia de los sistemas blockchain es un tema de vital importancia pero a menudo subestimado en su discusión. La complejidad de estos sistemas radica en su capacidad para manejar la latencia y el rendimiento de manera óptima.

En este artículo, exploraremos cómo entender estos conceptos y la metodología detrás de la medición de la latencia y el rendimiento en entornos blockchain.

Latencia

Para comenzar, vayamos a la definición del concepto:

“En redes informáticas de datos, la latencia de red es la suma de retardos temporales dentro de una red. Un retardo es producido por la demora en la propagación y transmisión de paquetes dentro de la red.”

Es decir que si queremos enviar datos de una computadora a otra, habra un retraso en el envio de la misma, donde siempre va a haber cierta latencia, aun cuando se hable de latencia cero. En el caso de que hablemos de latencia cero es que esta es imperceptible (3 ms aproximadamente).

Latencia en Blockchains

La latencia en una blockchain se representa mediante el tiempo que transcurre desde que se inicia una transacción hasta que se confirma su validez.

Esto es importantísimo para los usuarios, ya que si la latencia de una blockchain es mala, las transacciones tardan mucho tiempo en confirmarse lo que a la hora de estar interactuando con diferentes aplicaciones o realizando transferencias significa tener un tiempo de demora.

En sistemas clásicos de tolerancia a fallos bizantinos (BFT) como PBFT, Tendermint, Tusk & Narwhal, una transacción se finaliza una vez que se confirma. Sin embargo, en consensos de la cadena más larga como el Consenso Nakamoto, Solana/Ethereum PoS, una transacción puede incluirse en un bloque y luego reorganizarse. Esto significa que debemos esperar hasta que una transacción tenga una profundidad de "k-bloques", lo que resulta en una latencia significativamente mayor que una sola confirmación.

Rendimiento

El rendimiento de datos, también conocido como throughput, representa la carga total que el sistema puede manejar por unidad de tiempo, midiendo qué tan rápido puede moverse la información de un punto a otro, es decir, el volumen de información neto que fluye a través de un sistema.

Por ejemplo: el throughput en el contexto de las redes de comunicación, es la proporción de mensajes enviados que se entregan con éxito. Suele medirse en bits por segundo (bit/s o bps) y paquetes de datos por segundo (pps) o paquetes de datos por intervalo de tiempo.

Además, el throughput de un sistema de comunicación se ve afectado por el medio físico analógico (como su proveedor de datos), la potencia informática disponible de los componentes del sistema (su PC) y las acciones de los usuarios finales.

Rendimiento en Blockchain

El rendimiento en el contexto de Blockchain se expresa en transacciones por segundo (TPS), es decir, cuántas transacciones puede procesar la blockchain en un segundo. Este datos se suele observar en el explorador de bloques de la red (blockchain) que estemos utilizando.

Veamos algunos ejemplos en distintas blockchains:

Ethereum:

https://etherscan.io/
https://etherscan.io/

Polygon:

https://polygonscan.com/
https://polygonscan.com/

Optimism:

https://optimistic.etherscan.io/
https://optimistic.etherscan.io/

Sin embargo, es importante entender que el rendimiento de una blockchain está sujeto a ciertas limitaciones y fundamentos que también son comunes en sistemas integrados, informáticos y distribuidos.

El rendimiento también refleja cómo la red maneja la carga total de operaciones por unidad de tiempo. Esto incluye factores como el mecanismo de consenso utilizado (como prueba de participación o prueba de trabajo), el límite de tamaño/tasa de bloque y otros protocolos intensivos en recursos que aseguran la red.

Las redes que utilizan un mecanismo de consenso de prueba de participación (PoS) pueden ser mucho más rápidas que las que usan prueba de trabajo (PoW), ya que no requieren el mismo nivel de poder de procesamiento de los nodos. Idealmente, la tasa de procesamiento de transacciones de una red blockchain debería ser proporcional al número de nodos en la red, pero en la práctica esto puede verse afectado por la congestión de la red y la escalabilidad vertical en lugar de la escalabilidad horizontal o lineal.

Relacion Latencia/Rendimiento

Uno de los desafíos en la medición de metricas en blockchain es la relación entre la latencia y el rendimiento. En situaciones de baja congestion, la latencia tiende a ser constante, mientras que el rendimiento puede variar simplemente ajustando la carga. Por otro lado, en momentos de alta congestion, el rendimiento se mantiene constante, pero la latencia puede fluctuar significativamente al aumentar la carga.

La metodología de medición es otro aspecto crucial a considerar que es fundamental para identificar posibles cuellos de botella y garantizar un funcionamiento óptimo bajo diversas condiciones. Existen diferentes enfoques para diseñar experimentos o pruebas, como sistemas de bucle abierto o cerrado, y la elección adecuada depende del escenario particular que se esté evaluando. Además, la distribución de interarribos en las cargas de trabajo sintéticas juega un papel importante en la precisión de las mediciones.

Al comparar distintas blockchains, es esencial establecer un Objetivo de Nivel de Servicio (SLO) para garantizar comparaciones justas. También es importante tener en cuenta el punto de saturación del sistema, ya que operar más allá de este punto puede llevar a un aumento significativo de la latencia y a una violación del SLO.

Medición de congestion en la red

Para medir la latencia en situaciones de alta carga, se pueden emplear técnicas como el muestreo de transacciones. Esta metodología permite obtener mediciones precisas sin afectar la distribución de la carga y preveer la congestion de la red, donde nos referimos a que el numero de transacciones supera a la capacidad de la red, provocando retrasos en el procesamiento, es decir, mayor latencia.

Ejemplos de estos casos son:

  • Cuando se hace viral un NFT y se producen demasiados minteos del token

  • Cuando un juego se populariza y hay muchos jugadores realizando transacciones para poder jugarlo

  • O hasta con el lanzamiento de nuevos casos de uso como los tokens BRC-20 en la blockchain de Bitcoin que provoco un gran aumento de transacciones, provocando congestion en la red

Igualmente, los usuarios pueden pagar gas (fee de la transaccion) mas alto para que se le de prioridad a esta, lo que termina afectando economicamente para mal a los usuarios de la red congestinada. En la siguiente imagen podemos observar un mapa de calor del precio del gas en la red de Ethereum mainnet de los ultimos dias, indicando que gas se pago en promedio en cada hora de cada dia:

Fuente: https://etherscan.io/gastracker#heatmap_gasprice
Fuente: https://etherscan.io/gastracker#heatmap_gasprice

De esta forma tambien podemos ver que horas la latencia es buena y podemos realizar transacciones, si queremos observar el precio del gas en una ventana de tiempo mas grande podemos verlo en este grafico:

Fuente: https://etherscan.io/chart/gasprice
Fuente: https://etherscan.io/chart/gasprice

Por estas razones, las blockchains siempre estan buscando formas de optimizar sus transacciones, mejorar su escalabilidad y reducir la congestion, si esto se suena interesante podes pasar por las redes de Layer 2 en español.

Subscribe to SEED Latam
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.