¿Cómo pueden estar seguros los pares en una red de blockchain de que todos los datos de un bloque recién propuesto están disponibles? ¿Y por qué es importante?

En esta publicación, profundizamos en los detalles del problema de disponibilidad de datos y cómo puede afectar la escalabilidad en Ethereum.

¿Cuál es el problema de disponibilidad de datos?

El problema de Disponibilidad de Datos (DA): ¿Cómo pueden estar seguros los pares en una red blockchain de que todos los datos de un bloque recién propuesto están realmente disponibles? Si los datos no están disponibles, el bloque podría contener transacciones maliciosas que están siendo ocultadas por el productor de bloque. Incluso si el bloque contiene transacciones no maliciosas, ocultarlas podría comprometer la seguridad del sistema.

Para proporcionar un ejemplo, supongamos que Alice es un operador de un ZK-Rollup (ZKR). Ella presenta una Prueba ZK en Ethereum que es verificada. Si no presenta todos los datos de transacción en Ethereum, aunque su prueba demuestre que todas las transiciones de estado realizadas en el rollup son válidas, los usuarios del rollup podrían estar en la oscuridad sobre sus saldos de cuenta actuales. La prueba presentada no arroja luz sobre los estados actuales debido a la naturaleza de Cero Conocimiento de la misma.

Existe un ejemplo análogo en el Optimistic Rollup (OPR)configuración, donde Alice presenta una afirmación en Ethereum, pero ninguno de los participantes del OPR puede desafiarla porque los datos transaccionales no están disponibles y, por lo tanto, no pueden recalcular o desafiar la afirmación.

Para contrarrestar los escenarios anteriores, tanto los diseños OPR como ZKR obligan a los operadores a presentar todos los detalles transaccionales sobre Ethereumcomo 'calldata'. Si bien esto les permite evadir el problema de DA a corto plazo, a medida que el número de transacciones aumenta dentro de los rollups, la cantidad de datos que deben enviarse también aumentaría, limitando la cantidad de escalabilidad que estos rollups pueden ofrecer.

Para empeorar las cosas, la falta de disponibilidad de datos no es una falla atribuible de forma única. Esto significa que los participantes no pueden demostrar a otros pares que falta un fragmento de datos en particular. Esto se debe a que Bob puede difundir que el bloque enviado por Alice tiene datos faltantes, pero cuando Charlie consulta a Alice, ella puede proporcionarle los datos a él.

¿Cómo afecta esto a una cadena de bloques hoy?

Para responder a esta pregunta, primero revisemos la estructura de bloque general de una cadena de bloques similar a Ethereum y los tipos de clientes que existen en cualquier red de cadena de bloques.

Un bloque se puede dividir en dos partes principales:

• Encabezado de bloque: Un pequeño encabezado de bloque contiene el resumen y metadatos relacionados con las transacciones incluidas en el bloque.
• Cuerpo de bloque: Esto contiene todos los datos transaccionales y constituye la mayor parte del tamaño del bloque.

En los protocolos de blockchain convencionales, todos los nodos se consideran nodos completos que sincronizan todo el bloque y verifican todas las transiciones de estado. Necesitan gastar una cantidad considerable de recursos para verificar la validez de las transacciones y almacenar los bloques. Por otro lado, estos nodos no pueden ser obligados a aceptar ninguna transacción inválida.

Puede haber otra clase de nodos que no tienen (o no quieren gastar) recursos para verificar cada transacción. En cambio, están principalmente interesados en conocer el estado actual del blockchain y si algunas transacciones, que les son relevantes, están incluidas en la cadena o no. Idealmente, estos clientes ligeros también deberían estar protegidos de seguir una cadena que contiene transacciones inválidas. Esto es posible usando lo que se llama pruebas de fraude. Estos son mensajes sucintos que muestran que un bloque en particular incluye una transacción que es inválida. Cualquier nodo completo puede producir una prueba de fraude, y el cliente ligero no tiene que confiar en que un nodo completo en particular sea honesto. Solo tienen que asegurarse de que están bien conectados a una red de chismes que garantiza que si hay una prueba de fraude disponible para un encabezado de bloque, la recibirán.

Sin embargo, hay un problema con este sistema: ¿qué pasa si un productor de bloques no revela todos los datos detrás de un bloque? En este caso, los nodos completos obviamente rechazarán el bloque, ya que en su opinión, ni siquiera es un bloque si no viene con el cuerpo del bloque. Sin embargo, los clientes ligeros pueden recibir la cadena de encabezados y no tienen forma de darse cuenta de que faltan los datos. Al mismo tiempo, los nodos completos no pueden producir pruebas de fraude, porque les faltarían los datos necesarios para crear pruebas de fraude.

Para contrarrestar esto, necesitamos un mecanismo para que los clientes ligeros verifiquen la disponibilidad de datos. Esto garantizaría que un productor de bloques que oculta datos no pueda salirse con la suya convenciendo a un cliente ligero de lo contrario. También obligaría al productor de bloques a revelar partes de los datos, lo que haría que toda la red tuviera acceso al bloque completo de manera colaborativa.

Profundicemos un poco más en el problema con la ayuda de un ejemplo. Supongamos que la productora de bloques Alice construye un bloque B con transacciones tx1, tx2, …, txn. Supongamos que tx1 es una transacción maliciosa. Si tx1 se transmite, cualquier nodo completo puede verificar que es maliciosa y enviar esto a un cliente ligero como una prueba de fraude que inmediatamente sabría que el bloque es inaceptable. Sin embargo, si Alice quiere ocultar tx1, revela la cabecera y todos los datos transaccionales excepto tx1. Los nodos completos no pueden verificar la corrección de tx1.

Uno podría pensar que una solución simple es que todos los clientes ligeros simplemente muestreen las transacciones al azar, y si encuentran que sus muestras están disponibles, pueden estar seguros de que el bloque está disponible. Deje que los nodos ligeros consulten una transacción cualquiera, de manera uniforme al azar. La probabilidad de que el cliente ligero consulte tx1 es 1/n. Por lo tanto, con una probabilidad abrumadora, Alice logra engañar a los clientes ligeros para que acepten una transacción maliciosa. En otras palabras, la mayoría de los clientes ligeros serán engañados. Debido a la naturaleza no atribuible, los nodos completos no pueden probar de ninguna manera que tx1 no está disponible. Desafortunadamente, aumentar el número de muestras no mejora mucho esta situación.

Entonces, ¿qué hacemos al respecto?

La solución a este problema radica en introducir redundancia en un bloque. Existe un amplio conjunto de literatura sobre teoría de codificación en general, y codificación de borrado en particular, que puede ayudarnos con este problema.

En pocas palabras, la codificación de borrado nos permite extender cualquier n fragmentos de datos en 2n fragmentos de datos de tal manera que cualquier n de los 2n son suficientes para reconstruir la pieza original de datos (los parámetros son ajustables, pero aquí lo consideramos por simplicidad).

Si obligamos al productor de bloques a codificar por borrado las transacciones tx1, tx2, …, txn, entonces, para ocultar una sola transacción, necesitaría ocultar n+1 fragmentos de datos, ya que n son suficientes para construir el conjunto completo de transacciones. En este caso, un número constante de consultas da al cliente ligero una confianza muy alta de que los datos subyacentes están disponibles de hecho.

¡Vaya, ¿así que esto es todo?

No. Aunque este sencillo truco hace que el trabajo de ocultar sea más difícil, todavía es posible que el productor de bloques simplemente realice intencionalmente el código de borrado de manera incorrecta. Sin embargo, un nodo completo puede verificar si este código de borrado se realizó correctamente y, si no, puede demostrar esto a un cliente ligero. Este es otro tipo de prueba de fraude, al igual que en el caso de transacciones maliciosas anteriores. Curiosamente, debe haber un único vecino honesto de un nodo completo de un cliente ligero para que esté seguro de que, si el bloque es malicioso, recibirá una prueba de fraude. Esto asegura que el cliente ligero tenga acceso a una cadena sin transacciones maliciosas con una probabilidad muy alta.

Pero hay un truco. Si se hace de manera ingenua, el tamaño de algunas pruebas de fraude puede ser del mismo orden que el tamaño del bloque en sí. La suposición de recursos que teníamos sobre el cliente ligero nos prohíbe usar un diseño así. Ha habido mejoras al respecto mediante el uso de técnicas de codificación de borrado multidimensional que reducen el tamaño de las pruebas de fraude a costa del tamaño del compromiso. Por razones de brevedad, no cubrimos esto, pero este papeltiene un análisis detallado de ello.

El problema con las soluciones basadas en pruebas de fraude es que los clientes ligeros nunca están completamente seguros sobre ningún bloque para el cual aún no han recibido una prueba de fraude. Además, confían continuamente en que sus pares nodos completos sean honestos. Los nodos honestos también necesitan ser incentivados para seguir auditando continuamente los bloques.

Nos enfocamos aquí en sistemas que garanticen que, si la codificación de bloque es inválida, los nodos completos puedan detectarlo y proporcionar pruebas a los clientes ligeros que los convenzan de la mala conducta. Sin embargo, en la siguiente sección, veremos codificaciones de bloque que garanticen que solo las codificaciones válidas puedan ser comprometidas en la cadena. Esto elimina la necesidad de pruebas de fraude que demuestren errores de codificación. Estas soluciones basadas en pruebas de validez permiten a las aplicaciones utilizar el sistema sin tener que esperar estas pruebas de fraude de los nodos completos.

Entonces, ¿cómo funcionan estas soluciones?

Recientemente, los compromisos polinomiales han despertado un interés renovado en el espacio de la cadena de bloques. Estos compromisos polinomiales, especialmente el compromisos KZG/Kate de tamaño constante a polinomios, se puede utilizar para diseñar un esquema DA ordenado sin necesidad de pruebas de fraude. En resumen, los compromisos KZG nos permiten comprometernos con un polinomio usando un solo elemento de grupo de curva elíptica. Además, el esquema nos permite demostrar que en algún punto i el polinomio φ se evalúa en φ(i) usando un testigo de tamaño constante. El esquema de compromiso es computacionalmente vinculante y también es homomórfico, lo que nos permite evitar de forma ordenada las pruebas de fraude.

Forzamos al productor de bloques a tomar los datos transaccionales originales y organizarlos en una matriz 2D de tamaño n x m. Utiliza interpolación polinómica para extender cada columna de tamaño n en columnas de tamaño 2n. Cada fila de esta matriz extendida genera un compromiso polinómico y envía estos compromisos como parte del encabezado del bloque. A continuación se muestra una representación esquemática del bloque.

Los clientes ligeros consultan cualquier celda de esta matriz extendida para obtener el testigo que les permite verificarlo inmediatamente contra el encabezado del bloque. Las pruebas de membresía de tamaño constante hacen que el muestreo sea extremadamente eficiente. La naturaleza homomórfica del compromiso se asegura de que la prueba verifique solo si el bloque está construido correctamente y la interpolación polinómica asegura que un número constante de muestras exitosas significa que los datos están disponibles con una probabilidad muy alta.

Una representación esquemática del bloque

Los detalles más finos del esquema junto con más optimizaciones y estimaciones de costos están más allá del alcance de este artículo. Sin embargo, nos gustaría señalar que aunque discutimos un esquema 2D aquí, garantías similares pueden ser proporcionadas con un esquema 1D también, que tiene un tamaño de encabezado más pequeño a costa de menos paralelismo y eficiencia de muestreo del cliente ligero. Nos adentraremos más en esto en artículos de seguimiento.

¿Cuáles son las otras alternativas y qué sigue?

El código de borrado de dimensión superior y los compromisos KZG no son las únicas formas de abordar el problema de DA. Hay otras formas que omitimos aquí como Árboles de Merkle codificados, Árbol de Entrelazamiento Codificado, FRI, y enfoques basados en STARK, pero cada uno tiene sus méritos y deméritos.

En Avail, hemos estado trabajando en una solución de Disponibilidad de Datos utilizando compromisos KZG. En publicaciones posteriores, cubriremos los detalles de implementación, cómo puedes usarlo hoy y cómo pretendemos transformar el espacio del problema de DA. Para obtener más información sobre Avail, síguenos en Twitter y únete a nuestro servidor de Discord.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [Equipo de Disponibilidad]. Todos los derechos de autor pertenecen al autor original [Equipo de Avail]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con el [Gate Learn] equipo y lo resolverán rápidamente.

2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.

3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.