WEB3DEV Español

Cover image for Análisis de Disponibilidad de Blockchain Basado en el Retraso de Bloques
Paulo Gio
Paulo Gio

Posted on

Análisis de Disponibilidad de Blockchain Basado en el Retraso de Bloques

https://bitquery.io/_next/image?url=%2Fblog%2Fblockchain%2Fanalysis-of-blockchain-availabilitybased-on-block-lag%2Fcover.png&w=3840&q=75

Este análisis se centra en examinar el retraso de bloques en la cadena de cuatro redes blockchain: Bitcoin, Ethereum, Solana y Binance Smart Chain. El objetivo es calcular varias estadísticas relacionadas con el tiempo de bloque.

Para llevar a cabo este análisis, se obtuvieron y procesaron conjuntos de datos utilizando herramientas Pandas dentro de un entorno de Jupyter Notebook. Los hallazgos e ideas resultantes están documentados en un proyecto de GitHub. Al explorar las estadísticas de retraso de bloques, podemos obtener una mejor comprensión del rendimiento y eficiencia de estas redes blockchain.

¿Por Qué Importan los Retrasos de Bloques?

El objetivo de este análisis es medir cuán bien las redes blockchain de diferentes tipos cumplen las expectativas del cliente en cuanto a disponibilidad y velocidad. Esto no se define únicamente por las estadísticas medias, como el tiempo promedio de bloque y las transacciones por segundo. La distribución de estos parámetros también es importante, y especialmente los casos extremos de retrasos inesperadamente largos en los tiempos de bloque.

Cuando la red blockchain no añade un nuevo bloque durante mucho tiempo, todas las aplicaciones que dependen de esa red se paralizan efectivamente. Es equivalente a que un programa se cuelgue en tu ordenador. Los clientes de blockchain, como las billeteras o DApps, no pueden ejecutar transacciones, hacer transferencias o llamadas a contratos inteligentes.

Un tiempo de retraso demasiado largo entre los bloques equivale a una interrupción del servicio de la red blockchain. Aquí intentamos medir con qué frecuencia ocurre esto y cuán grave es en diferentes blockchains.

Consideramos una interrupción cuando el siguiente bloque no aparece en un intervalo de tiempo 10 veces mayor que el período promedio de bloque. Por ejemplo, si el período promedio en Ethereum es de 14 segundos, consideramos 140 segundos como una interrupción. Esto se calcula en relación con los valores promedio, porque las expectativas de los clientes (tanto humanos como aplicaciones) se adaptan a los tiempos promedio de bloque, que son muy diferentes entre las redes blockchain.

Estadísticas Agregadas sobre Tiempos de Bloque

Aquí están las estadísticas agregadas de las 4 redes blockchain en consideración:

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/Screenshot-2023-05-17-174356.png

Ethereum se puede dividir en dos períodos: antes de la bifurcación de Prueba de participación (POS) y después de ella, ya que las estadísticas muestran diferencias notables. La tabla indica claramente que el tiempo máximo puede superar ampliamente las cifras promedio, a veces incluso extendiéndose a horas o días. Ahora examinaremos cada cadena individualmente y luego volveremos a analizar las cifras de SLA en su conjunto.

Ethereum Antes de POS

La distribución del tiempo de bloque en Ethereum antes de POS (escala de frecuencia logarítmica):

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/alekseyblog-768x367.png

El histograma en escala logarítmica se ve muy suave y tiene una pendiente casi lineal para un rango de 10.12 segundos por bloque. Puede ser aproximadamente modelado como un decaimiento exponencial:

Freq ~ A * exp ( -t * B )

La prueba de trabajo requiere adivinar un rompecabezas criptográfico, que es una suposición aleatoria, que debe seguir la distribución binomial. Aquí vemos el rastro de esta distribución con t >> average(t), la media es aproximadamente de 14 segundos.

Esto significa que cualquier consenso de POW asume, por diseño, las interrupciones, cuando el tiempo de bloque debido a razones probabilísticas excede algún valor predefinido.

En este diagrama, los 140 segundos (14 segundos en promedio x factor 10) están en el medio, mostrando muchos bloques que tardaron más en minar.

También hay varios bloques con un retraso superior a 300 segundos.

ethereum[(ethereum['lag']>300) & (ethereum['block']<15537393)]

nos da los bloques con tiempos extremos:

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/Screenshot-2023-05-17-182700.png

¡La buena noticia es que todos ellos están bien en el pasado!

Ethereum Después de POS

La distribución del tiempo de bloque en Ethereum después de POS (escala de frecuencia logarítmica):

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/alekseyblog5-768x366.png

Aquí vemos un histograma muy discreto, con tiempos de bloque que son múltiplos de 6 y 12 segundos. El tiempo máximo es 96 = 12 * 8, el mínimo es 6 segundos.

Bitcoin

La distribución del tiempo de bloque en Bitcoin (escala de frecuencia logarítmica):

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/alekseyblog2-768x367.png.

Bitcoin y Ethereum emplean Prueba de Trabajo (PoW) para la minería de bloques, lo que contribuye a sus tendencias similares hacia valores más grandes. Notablemente, hay un rango negativo significativo en los tiempos de bloque. Esto surge al utilizar el tiempo de minería de bloques como una marca de tiempo, en lugar del tiempo real cuando el bloque fue añadido a la cadena de bloques. En la práctica, los tiempos de minería pueden establecerse mucho antes de la inclusión del bloque en la cadena, lo que resulta en un considerable número de bloques con retrasos de tiempo negativos.

Sin embargo, estos retrasos negativos no deberían afectar significativamente la medición de los retrasos de bloque en el rango positivo. Esto se debe a que su distribución disminuye mucho más rápidamente que la de los retrasos positivos. Entre los bloques, hay 151 instancias donde la minería tomó más de 2 horas, con algunos tomando más de 10 horas.

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/Screenshot-2023-05-17-183632.png

¡Ten en cuenta que todos estos están al principio de la red... buenos tiempos!

Binance Smart Chain

La distribución del tiempo de bloque en Binance Smart Chain (escala de frecuencia logarítmica):

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/alekseyblog3-768x367.png

La distribución de BSC cae bastante rápido, y no hay tiempos de bloque extremadamente largos aquí.

Solana

La distribución del tiempo de bloque en Solana (escala de frecuencia logarítmica):

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/alekseyblog4-1-768x367.png

Solana es famosa por los tiempos de bloque muy rápidos... ¡y las largas interrupciones! Estos son bloques que tardaron más de 10 minutos:

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/Screenshot-2023-05-17-185132-267x300.png

Y como puedes ver, a veces están cerca de todo un día (!) cuando la red efectivamente se detuvo.

Figuras Agregadas de Disponibilidad

Las cifras agregadas de las distribuciones se recopilan en la siguiente tabla:

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/Screenshot-2023-05-17-191059-768x173.png

https://bitquery.io/blog/blockchain/analysis-of-blockchain-availabilitybased-on-block-lag/Screenshot-2023-05-17-191112-768x275.png

Binance Smart Chain y Ethereum, en particular después de la introducción de PoS, son altamente preferidos por su excepcional disponibilidad, acercándose casi al 100%. Este nivel de disponibilidad asegura un alto grado de previsibilidad en el rendimiento de las aplicaciones.

Por otro lado, Solana, siendo una de las redes más rápidas, muestra una disponibilidad ligeramente menor del 97%. Este nivel de disponibilidad se considera inadecuado, incluso para sistemas centralizados no redundantes, como un sitio web con un único servidor.

Conjuntos de Datos

Los datos de los retrasos entre bloques en segundos frente al número de bloques se obtienen de los conjuntos de datos de Bitquery para 4 blockchains.

Están disponibles en S3 público:

Binance Smart Chain

Rede Principal da Ethereum

Bitcoin

Rede Principal da Solana

Jupyter Notebook

El notebook Jupyter se encuentra en el proyecto de github. Para ejecutar el código, necesitará una instalación estándar de Jupyter labs y descargar los conjuntos de datos en la carpeta de datos dentro del proyecto.

Después de eso, ejecute % jupyter-lab y carga el notebook BlockhainTimes.ipynb.

Artículo original publicado por Aleksey Studnev. Traducción de Paulinho Giovannini.

Discussion (0)