! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
A medida que los usuarios comienzan a integrar Avail en sus diseños de cadenas, a menudo surge la pregunta: "¿Cuántas transacciones puede procesar Avail?" En esta publicación, compararemos el rendimiento de Ethereum y Avail en función de la arquitectura actual de las dos cadenas.
Este es el primero de una serie sobre la escalabilidad de Avail que analizará el rendimiento actual de Avail y su capacidad para escalar a corto y largo plazo.
Avail vs Ethereum
Los bloques de Ethereum pueden contener hasta 1.875 MB de datos y tienen un tiempo de bloque de unos 13 segundos. Sin embargo, los bloques de Ethereum no suelen estar llenos. Casi todos los bloques no alcanzarán el límite superior de datos porque alcanzan el límite de gas, porque tanto la ejecución como la liquidación consumen gas. Como resultado, la cantidad de datos almacenados en cada bloque es variable.
La necesidad de combinar la ejecución, la liquidación y la disponibilidad de datos en el mismo bloque es un problema central con una única arquitectura de cadena de bloques. Los rollups L2 iniciaron el movimiento de las cadenas de bloques modulares, permitiendo que las operaciones de ejecución se manejen en una sola cadena, y los bloques de la cadena están dedicados a la ejecución. Avail va un paso más allá al adoptar un diseño modular que también desacopla la disponibilidad de datos, lo que permite que los bloques de una cadena se dediquen a la disponibilidad de datos.
! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Actualmente, el tiempo de bloqueo de Avail es de 20 segundos y cada bloque puede contener alrededor de 2 MB de datos. Suponiendo un tamaño medio de transacción de 250 bytes, cada bloque de Avail puede contener unas 8.400 transacciones en la actualidad (420 transacciones por segundo).
Además, Avail siempre puede llenar bloques hasta el límite de almacenamiento y aumentar el tamaño según sea necesario. Tenemos una serie de palancas que se pueden ajustar rápidamente para aumentar el número de transacciones por bloque a más de 500.000 (25.000 transacciones por segundo) cuando sea necesario.
¿Podemos aumentar el rendimiento?
Para aumentar el rendimiento (especialmente las transacciones por segundo), los arquitectos de la cadena deben aumentar el tamaño del bloque o disminuir el tiempo de bloqueo.
Para agregarse a la cadena, cada bloque debe generar compromisos, construir pruebas, propagarlas y hacer que todos los demás nodos verifiquen esas pruebas. Estos pasos siempre llevan tiempo, lo que establece un límite superior natural en el tiempo que tardan los bloques en generarse y confirmarse.
Por lo tanto, no podemos simplemente reducir el tiempo de bloqueo a, digamos, un segundo. Esto simplemente no tiene tiempo suficiente para generar compromisos, generar pruebas y propagar esas partes a todos los participantes a través de la red. En un tiempo de bloque teórico de un segundo, incluso si cada participante de la red ejecuta la máquina más potente capaz de producir compromisos y pruebas en un instante, el cuello de botella radica en la propagación de datos. Debido a las limitaciones de velocidad de Internet, la red no puede notificar a todos los nodos completos de bloques lo suficientemente rápido. Por lo tanto, tenemos que asegurarnos de que el tiempo de bloqueo sea lo suficientemente alto como para permitir que los datos se distribuyan a la red después de que se alcance el consenso.
Por el contrario, también es posible aumentar el rendimiento aumentando el tamaño del bloque, es decir, aumentando la cantidad de datos que podemos contener en cada bloque.
Arquitectura actual: Añadir un bloque a la cadena
Primero, veamos los pasos necesarios para agregar un bloque a la cadena. Hay tres pasos principales necesarios para agregar cada bloque a la cadena. Esto incluye el tiempo que se tarda en generar un bloque, propagarlo y validarlo.
! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Generación de bloques
Este paso incluye el tiempo que se tarda en recopilar y ordenar las transacciones de Avail, crear compromisos y escalar (codificación de borrado) la matriz de datos.
La generación de bloques mide el tiempo que se tarda en generar un bloque, ya que esto siempre llevará al menos algún tiempo. Por lo tanto, debemos tener en cuenta no solo el tiempo en el mejor de los casos, sino también la situación media y el tiempo en el peor de los casos en diferentes máquinas.
La máquina más débil que puede participar en la generación de nuevos bloques es la que alcanza el límite de rendimiento en promedio. Todas las máquinas más lentas eventualmente se quedarán atrás porque no pueden alcanzar a las máquinas más rápidas.
2. Retardo de propagación
El retardo de propagación es una medida del tiempo que se tarda en propagar un bloque de un productor a un validador y a una red peer-to-peer.
Actualmente, el tamaño del bloque de Avail es de 2 MB. Dentro del límite de tiempo de bloque actual de 20 segundos, se puede propagar dicho tamaño de bloque. Los tamaños de bloque más grandes hacen que la propagación sea más complicada.
Por ejemplo, si aumentamos Avail para admitir un bloque de 128 MB, es posible que el cálculo pueda escalarse (unos 7 segundos). Sin embargo, el cuello de botella se convierte en el tiempo que se tarda en enviar y descargar estos bloques en la red.
Enviar un bloque de 128 MB al mundo a través de una red peer-to-peer en 5 segundos puede ser el límite de lo que se puede lograr actualmente.
El límite de 128 MB no tiene nada que ver con la disponibilidad de datos o nuestro escenario de compromiso, sino más bien con las limitaciones del ancho de banda de comunicación.
Esta necesidad de tener en cuenta la latencia de propagación nos da el límite de tamaño de bloque teórico actual de Avail.
3. Validación de bloques
Una vez propagado, los validadores participantes no solo confían en los bloques que les proporciona el proponente del bloque, sino que deben verificar que el bloque producido realmente contiene los datos reclamados por el productor.
Hay una cierta tensión entre estos tres pasos. Podemos hacer que todos los validadores sean máquinas potentes y estrechamente conectadas por una excelente red en el mismo centro de datos, lo que reducirá el tiempo de producción y validación, y nos permitirá propagar muchos más datos. Sin embargo, debido a que también queremos tener una red descentralizada y diversa con diferentes tipos de participantes, este no es un enfoque ideal.
En cambio, el aumento en el rendimiento se logrará al comprender los pasos necesarios para agregar bloques a la cadena de disponibilidad y qué pasos se pueden optimizar.
! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Actualmente, los validadores que utilizan Avail toman todo el bloque y copian todos los compromisos generados por el proponente para validar el bloque. Esto significa que los productores de bloques y todos los validadores deben realizar cada uno de los pasos del gráfico anterior.
En una sola cadena de bloques, la práctica predeterminada para cada validador es reconstruir todo el bloque. Sin embargo, en una cadena como Avail, donde las transacciones no se ejecutan, esta reconstrucción no es necesaria. Por lo tanto, una forma de optimizar Avail es permitiendo que los validadores logren sus propias garantías de disponibilidad de datos a través del muestreo, en lugar de reconstruir bloques. Esto requiere menos recursos para los validadores que exigirles que repliquen todos los compromisos. Más sobre esto en un artículo futuro.
¿Cómo funciona el muestreo exploratorio de disponibilidad de datos?
En Avail, los clientes ligeros utilizan tres herramientas principales para confirmar la disponibilidad de los datos: muestras, compromisos y pruebas.
Actualmente, los clientes ligeros realizan operaciones de muestra que solicitan el valor de una celda en particular y su prueba de validez asociada de la red Avail. Cuantas más muestras tomen, más seguros estarán de que todos los datos están disponibles.
Los contratos son generados por los proponentes de bloques y resumen una fila completa de datos en un bloque Avail. (Sugerencia: este es el paso que optimizaremos más adelante en esta serie). ）
Cada celda de la red genera una prueba. Los clientes ligeros utilizan atestaciones y prometen verificar que los valores de las celdas que se les proporcionan son correctos.
Con estas herramientas, el cliente ligero realiza tres pasos.
Decisión: La confianza de disponibilidad requerida determina el número de muestras para la ejecución del cliente ligero. No necesitan muchas muestras (8-30 muestras) para lograr una garantía de disponibilidad superior al 99,95%.
Descarga: A continuación, el cliente ligero solicita estas muestras y sus pruebas asociadas y las descarga de la red (nodo completo u otro cliente ligero).
Validación: Miran la promesa en el encabezado del bloque (que siempre es accesible para los clientes ligeros) y verifican la prueba de cada celda contra la promesa.
Solo con esto, los clientes ligeros pueden confirmar la disponibilidad de todos los datos en un bloque sin tener que descargar la mayor parte del contenido del bloque. Otras medidas tomadas por los clientes ligeros también contribuyen a la seguridad de Avail, pero no se enumeran aquí. Por ejemplo, los clientes ligeros pueden compartir muestras y pruebas que descargan con otros clientes ligeros en caso de que lo necesiten. ¡Pero ese es el procedimiento para que los clientes ligeros confirmen la disponibilidad de datos!
En la segunda parte de esta serie, exploraremos formas de aumentar el rendimiento de Avail a corto plazo. Explicaremos por qué creemos que Avail puede satisfacer las necesidades de cualquier red en el próximo año y cómo podemos mejorar la red para enfrentar los desafíos de los próximos años.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Escalabilidad de DA: estado actual de Avail
! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
A medida que los usuarios comienzan a integrar Avail en sus diseños de cadenas, a menudo surge la pregunta: "¿Cuántas transacciones puede procesar Avail?" En esta publicación, compararemos el rendimiento de Ethereum y Avail en función de la arquitectura actual de las dos cadenas.
Este es el primero de una serie sobre la escalabilidad de Avail que analizará el rendimiento actual de Avail y su capacidad para escalar a corto y largo plazo.
Avail vs Ethereum
Los bloques de Ethereum pueden contener hasta 1.875 MB de datos y tienen un tiempo de bloque de unos 13 segundos. Sin embargo, los bloques de Ethereum no suelen estar llenos. Casi todos los bloques no alcanzarán el límite superior de datos porque alcanzan el límite de gas, porque tanto la ejecución como la liquidación consumen gas. Como resultado, la cantidad de datos almacenados en cada bloque es variable.
La necesidad de combinar la ejecución, la liquidación y la disponibilidad de datos en el mismo bloque es un problema central con una única arquitectura de cadena de bloques. Los rollups L2 iniciaron el movimiento de las cadenas de bloques modulares, permitiendo que las operaciones de ejecución se manejen en una sola cadena, y los bloques de la cadena están dedicados a la ejecución. Avail va un paso más allá al adoptar un diseño modular que también desacopla la disponibilidad de datos, lo que permite que los bloques de una cadena se dediquen a la disponibilidad de datos.
! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Actualmente, el tiempo de bloqueo de Avail es de 20 segundos y cada bloque puede contener alrededor de 2 MB de datos. Suponiendo un tamaño medio de transacción de 250 bytes, cada bloque de Avail puede contener unas 8.400 transacciones en la actualidad (420 transacciones por segundo).
Además, Avail siempre puede llenar bloques hasta el límite de almacenamiento y aumentar el tamaño según sea necesario. Tenemos una serie de palancas que se pueden ajustar rápidamente para aumentar el número de transacciones por bloque a más de 500.000 (25.000 transacciones por segundo) cuando sea necesario.
¿Podemos aumentar el rendimiento?
Para aumentar el rendimiento (especialmente las transacciones por segundo), los arquitectos de la cadena deben aumentar el tamaño del bloque o disminuir el tiempo de bloqueo.
Para agregarse a la cadena, cada bloque debe generar compromisos, construir pruebas, propagarlas y hacer que todos los demás nodos verifiquen esas pruebas. Estos pasos siempre llevan tiempo, lo que establece un límite superior natural en el tiempo que tardan los bloques en generarse y confirmarse.
Por lo tanto, no podemos simplemente reducir el tiempo de bloqueo a, digamos, un segundo. Esto simplemente no tiene tiempo suficiente para generar compromisos, generar pruebas y propagar esas partes a todos los participantes a través de la red. En un tiempo de bloque teórico de un segundo, incluso si cada participante de la red ejecuta la máquina más potente capaz de producir compromisos y pruebas en un instante, el cuello de botella radica en la propagación de datos. Debido a las limitaciones de velocidad de Internet, la red no puede notificar a todos los nodos completos de bloques lo suficientemente rápido. Por lo tanto, tenemos que asegurarnos de que el tiempo de bloqueo sea lo suficientemente alto como para permitir que los datos se distribuyan a la red después de que se alcance el consenso.
Por el contrario, también es posible aumentar el rendimiento aumentando el tamaño del bloque, es decir, aumentando la cantidad de datos que podemos contener en cada bloque.
Arquitectura actual: Añadir un bloque a la cadena
Primero, veamos los pasos necesarios para agregar un bloque a la cadena. Hay tres pasos principales necesarios para agregar cada bloque a la cadena. Esto incluye el tiempo que se tarda en generar un bloque, propagarlo y validarlo.
! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Generación de bloques
Este paso incluye el tiempo que se tarda en recopilar y ordenar las transacciones de Avail, crear compromisos y escalar (codificación de borrado) la matriz de datos.
La generación de bloques mide el tiempo que se tarda en generar un bloque, ya que esto siempre llevará al menos algún tiempo. Por lo tanto, debemos tener en cuenta no solo el tiempo en el mejor de los casos, sino también la situación media y el tiempo en el peor de los casos en diferentes máquinas.
La máquina más débil que puede participar en la generación de nuevos bloques es la que alcanza el límite de rendimiento en promedio. Todas las máquinas más lentas eventualmente se quedarán atrás porque no pueden alcanzar a las máquinas más rápidas.
2. Retardo de propagación
El retardo de propagación es una medida del tiempo que se tarda en propagar un bloque de un productor a un validador y a una red peer-to-peer.
Actualmente, el tamaño del bloque de Avail es de 2 MB. Dentro del límite de tiempo de bloque actual de 20 segundos, se puede propagar dicho tamaño de bloque. Los tamaños de bloque más grandes hacen que la propagación sea más complicada.
Por ejemplo, si aumentamos Avail para admitir un bloque de 128 MB, es posible que el cálculo pueda escalarse (unos 7 segundos). Sin embargo, el cuello de botella se convierte en el tiempo que se tarda en enviar y descargar estos bloques en la red.
Enviar un bloque de 128 MB al mundo a través de una red peer-to-peer en 5 segundos puede ser el límite de lo que se puede lograr actualmente.
El límite de 128 MB no tiene nada que ver con la disponibilidad de datos o nuestro escenario de compromiso, sino más bien con las limitaciones del ancho de banda de comunicación.
Esta necesidad de tener en cuenta la latencia de propagación nos da el límite de tamaño de bloque teórico actual de Avail.
3. Validación de bloques
Una vez propagado, los validadores participantes no solo confían en los bloques que les proporciona el proponente del bloque, sino que deben verificar que el bloque producido realmente contiene los datos reclamados por el productor.
Hay una cierta tensión entre estos tres pasos. Podemos hacer que todos los validadores sean máquinas potentes y estrechamente conectadas por una excelente red en el mismo centro de datos, lo que reducirá el tiempo de producción y validación, y nos permitirá propagar muchos más datos. Sin embargo, debido a que también queremos tener una red descentralizada y diversa con diferentes tipos de participantes, este no es un enfoque ideal.
En cambio, el aumento en el rendimiento se logrará al comprender los pasos necesarios para agregar bloques a la cadena de disponibilidad y qué pasos se pueden optimizar.
! [Escalabilidad de DA: estado actual de Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Actualmente, los validadores que utilizan Avail toman todo el bloque y copian todos los compromisos generados por el proponente para validar el bloque. Esto significa que los productores de bloques y todos los validadores deben realizar cada uno de los pasos del gráfico anterior.
En una sola cadena de bloques, la práctica predeterminada para cada validador es reconstruir todo el bloque. Sin embargo, en una cadena como Avail, donde las transacciones no se ejecutan, esta reconstrucción no es necesaria. Por lo tanto, una forma de optimizar Avail es permitiendo que los validadores logren sus propias garantías de disponibilidad de datos a través del muestreo, en lugar de reconstruir bloques. Esto requiere menos recursos para los validadores que exigirles que repliquen todos los compromisos. Más sobre esto en un artículo futuro.
¿Cómo funciona el muestreo exploratorio de disponibilidad de datos?
En Avail, los clientes ligeros utilizan tres herramientas principales para confirmar la disponibilidad de los datos: muestras, compromisos y pruebas.
Con estas herramientas, el cliente ligero realiza tres pasos.
Solo con esto, los clientes ligeros pueden confirmar la disponibilidad de todos los datos en un bloque sin tener que descargar la mayor parte del contenido del bloque. Otras medidas tomadas por los clientes ligeros también contribuyen a la seguridad de Avail, pero no se enumeran aquí. Por ejemplo, los clientes ligeros pueden compartir muestras y pruebas que descargan con otros clientes ligeros en caso de que lo necesiten. ¡Pero ese es el procedimiento para que los clientes ligeros confirmen la disponibilidad de datos!
En la segunda parte de esta serie, exploraremos formas de aumentar el rendimiento de Avail a corto plazo. Explicaremos por qué creemos que Avail puede satisfacer las necesidades de cualquier red en el próximo año y cómo podemos mejorar la red para enfrentar los desafíos de los próximos años.