Análisis de la Disponibilidad de la Blockchain Basado en el Block Lag
Este análisis se centra en examinar el retraso del bloque 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 en un entorno Jupyter Notebook. Los hallazgos y percepciones resultantes se documentan en un proyecto de GitHub. Al explorar las estadísticas de retraso del bloque, podemos obtener una mejor comprensión del rendimiento y eficiencia de estas redes blockchain.
¿Por qué son importantes los retrasos de bloque?
El objetivo de este análisis es medir cuán bien las redes blockchain de diferentes tipos, cumplen con las expectativas del cliente en términos de disponibilidad y velocidad. Esto no se define solo por las estadísticas promedio, como el tiempo promedio de bloque y las transacciones por segundo. La distribución de estos parámetros también es importante, especialmente los casos extremos de retrasos inesperadamente largos en los tiempos de bloque.
Cuando la red blockchain no agrega el nuevo bloque durante mucho tiempo, todas las aplicaciones que están en esa red se paralizan efectivamente. Es equivalente a que el programa se bloquee en tu computadora. Los clientes de la Blockchain, como las billeteras o DApps, no pueden ejecutar transacciones, realizar transferencias o llamadas a contratos inteligentes.
Un intervalo de tiempo muy largo entre los bloques es equivalente a la interrupción del servicio de la red blockchain. Aquí intentamos medir con qué frecuencia ocurre esto y cuán grave es en diferentes blockchains.
Aquí, consideramos la interrupción cuando el próximo bloque no aparece en el intervalo de tiempo 10x del período promedio de bloqueo. Por ejemplo, si el período promedio en Ethereum es de 14 segundos, consideramos 140 segundos como interrupción. Esto se calcula con relación a los valores promedio, porque las expectativas de los clientes (humanos y aplicaciones) se adaptan a los tiempos promedio de bloqueo, siendo muy diferentes en las redes blockchain.
Estadísticas agregadas en tiempo de bloque
Aquí están las estadísticas agregadas de las 4 redes blockchain en consideración:
Ethereum puede dividirse en dos períodos: antes del fork de la Prueba de Participación (Proof of Stake, POS) y después de ella, ya que las estadísticas muestran diferencias notables. La tabla, indica claramente que el tiempo máximo puede sobreponerse, enormemente, a las figuras promedias, alguna veces incluso extendiéndose a hora o incluso días. Ahora, examinaremos cada cadena individualmente y luego, volveremos para analizar los números del SLA en su conjunto.
Ethereum antes del POS
La distribución del tiempo de bloque en Ethereum antes de POS (escala de frecuencia logarítmica):
El histograma en escala logarítmica parece muy suave y tiene una pendiente casi lineal para un intervalo de 10 a 120 segundos por bloque.
Puede ser modelado aproximadamente como de decaimiento exponencial:
Freq ~ A * exp ( -t * B )
La prueba de trabajo (POW) requiere adivinar el rompecabezas criptográfico, que es una adivinanza aleatoria, que debería seguir la distribución Binomial. Aquí vemos la huella de esa distribución con t >> average(t), la media es de aproximadamente 14 segundos.
Esto significa que cualquier proyecto consensuado de POW asume las interrupciones, cuando el tiempo de bloqueo, debido a razones probabilísticas, excede algún valor predefinido.
En este diagrama, los 140 segundos (media de 14 segundos x factor 10) están en el medio, mostrando muchos bloques, que tardaron más tiempo en minar.
También hay varios bloques con un retraso superior a 300 seg
ethereum[(ethereum['lag']>300) & (ethereum['block']<15537393)]
nos da los bloques con tiempos de bloque extremos:
Buenas noticias, ¡todos ellos están bien en el pasado!
La distribución del tiempo de bloque en Ethereum después de POS (escala de frecuencia logarítmica):
Aquí vemos un histograma muy discreto, con tiempos de bloque de 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):
Bitcoin y Ethereum emplean Proof of Work (PoW) para la minería de bloques, los cuales contribuyen a sus tendencias similares hacia valores más grandes. Notablemente, hay un rango negativo notable de tiempos de bloque. Esto se debe al uso del tiempo de minería del bloque como una marca de tiempo, en lugar del tiempo real en que el bloque se agregó a la blockchain. En la práctica, los tiempos de minería pueden establecerse mucho antes de la inclusión del bloque en la cadena, ocasionando una cantidad considerable de bloques con retrasos 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ápido que los retrasos positivos. Entre los bloques, hay 151 ocurrencias donde la minería tardó más de 2 horas, con algunas tardando más de 10 horas.
Observa que todo esto está bien al comienzo de la red... ¡buenos tiempos!
Binance Smart Chain
La distribución del tiempo de bloque en Binance Smart Chain (escala de frecuencia logarítmica):
La distribución de BSC cae muy 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):
Solana es famosa por sus tiempos de bloque muy rápidos... ¡y largas interrupciones! Estos son bloques que tardaron más de 10 minutos:
Y como puedes ver, a veces están cerca de un día entero, (!) cuando la red efectivamente se detuvo.
Números de Disponibilidad Agregados
Los números agregados de las distribuciones, se recogen en la siguiente tabla:
Binance Smart Chain y Ethereum, particularmente después de la introducción de Proof of Stake (PoS), son altamente favorecidos por su disponibilidad excepcional, acercándose a casi el 100%. Este nivel de disponibilidad garantiza un alto grado de previsibilidad en el rendimiento de la aplicación.
Por otro lado, Solana, aunque es una de las redes más rápidas, muestra una disponibilidad ligeramente inferior al 97%. Este nivel de disponibilidad se considera inadecuado, incluso para sistemas centralizados no redundantes, como un sitio web de servidor único.
Conjuntos de datos
Los datos para el retraso entre bloques en segundos versus el número de bloques se consultan a partir de conjuntos de datos Bitquery para 4 blockchains.
Están públicamente disponibles S3:
Jupyter Notebook
El Jupyter Notebook está en este proyecto de github. Para ejecutar el código, necesitarás hacer la instalación estándar de los laboratorios Jupyter y descargar los conjuntos de datos en la carpeta de datos dentro del proyecto.
Después de eso, ejecuta
% jupyter-lab
y carga el notebook BlockhainTimes.ipynb.
Nota: La traducción se basó en el artículo en portugués.
El artículo original en inglés ha sido actualizado y modificado, es la versión más actual.Este artículo es una traducción realizada por @bananlabs. Puedes encontrar los artículos en estos enlaces:
inglés
portugués
Discussion (0)