Por qué el muestreo de disponibilidad de datos es importante para el escalamiento de Blockchain

Autor: Bessie Liu, Blockworks Compilador: Shan Ouba, Jinse Finance

A medida que Ethereum continúa escalando, la disponibilidad de datos en cadena se ha convertido en un tema cada vez más común.

Hoy en día, los desarrolladores de Ethereum están trabajando en dónde y cómo se deben almacenar los datos en la red blockchain para resolver el llamado trilema blockchain, el equilibrio entre seguridad, escalabilidad y descentralización. En las criptomonedas, la disponibilidad de datos se refiere al concepto de que todos los participantes de la red pueden acceder y recuperar datos almacenados en la red. En la primera capa de Ethereum, los nodos de la red descargan todos los datos de cada bloque, lo que dificulta la ejecución de transacciones no válidas.

Si bien esto garantiza la seguridad, el proceso puede ser relativamente ineficiente: requerir que los nodos de la red verifiquen y almacenen todos los datos en un bloque reduce en gran medida el rendimiento y dificulta la escalabilidad de la cadena de bloques. La solución de escalado de Capa 2 de Ethereum tiene como objetivo resolver este problema.

Una solución popular hoy en día es Optimistic Rollup, como Arbitrum y Optimism. Los resúmenes optimistas son de naturaleza "optimista" porque suponen que las transacciones son válidas a menos que se demuestre lo contrario.

Anurag Arjun, cofundador de la cadena de bloques modular Avail, dijo a Blockworks que la mayoría de los Rollups actuales tienen un solo clasificador, lo que significa que existe el riesgo de centralización.

Actualmente, esto no es un problema importante, ya que las soluciones acumuladas tienen que colocar datos de transacciones sin procesar en ethereum utilizando algo llamado calldata; como señaló Arjun, esta es la forma más barata de almacenamiento en ethereum en la actualidad.

Neel Somani, fundador de la solución de escalado blockchain Eclipse, dijo que una vez que los datos de las llamadas se envían a la red principal de ethereum, cualquiera puede cuestionar su precisión durante un período de tiempo determinado.

Si nadie cuestiona la validez del paquete acumulativo, se aceptará en Ethereum una vez que se acabe el tiempo.

El problema, señaló Somani, es que si alguien no tiene los datos, ¿cómo puede demostrar que la operación se ejecutó de forma incorrecta?

"Si no te digo lo que ejecuté, no puedes probar que estaba mal, así que necesitas saber exactamente lo que ejecuté para solucionar este problema", dijo Somani. "Por lo tanto, todas las cadenas de bloques deben demostrar la disponibilidad de datos de alguna manera o forma".

Muestreo de disponibilidad de datos

Dado que todas las cadenas de bloques deben demostrar la disponibilidad de datos, puede resultar ineficiente descargar bloques completos en la red, lo que a su vez plantea la cuestión de la disponibilidad inicial de datos. "Entonces, como alguien que no quiere descargar el bloque completo, todavía quiero estar seguro de que la información sobre ese bloque no ha sido retenida", dijo Somani. La solución es utilizar el muestreo de disponibilidad de datos para tener confianza en que el bloque existe.

Somani explicó que el muestreo de disponibilidad de datos implica muestrear una porción aleatoria de un bloque para obtener una confianza arbitrariamente alta de que el bloque existe. Esta técnica utiliza un polinomio (una expresión matemática que contiene variables, coeficientes y exponentes) para modelar la relación entre variables en un bloque.

Un error común sobre la disponibilidad de datos de muestreo es que si se muestrean la mitad de los bloques, sólo se puede obtener un 50% de confianza en que la información de ese bloque es precisa, dijo Somani. Este no es el caso, explicó, porque al igual que con el muestreo de disponibilidad de datos, los usuarios deben asegurarse de tener suficientes puntos para recuperar el polinomio original. Actualmente, proyectos como Celestia y Avail están creando soluciones de muestreo de disponibilidad de datos.

"Creemos sinceramente que cada capa base se convertirá en una capa de disponibilidad de datos", dijo Arjun a Blockworks. "La dirección principal a la que nos enfrentamos es querer escalar la disponibilidad de datos en la capa base y ejecutarlos y agregarlos en la segunda capa".