Colaborador: cuando las cadenas de bloques comienzan a escalar, a menudo se encuentran con el problema de disponibilidad de datos; desglosamos exactamente lo que hay aquí.

[wps_section size=”full-boxed” height=”auto” background_color=”#1e73be” background_size=”cover” background_repeat=”no-repeat” background_mode=”fixed” align_content_vertical=”center” align=”left” content_width=”100%” content_color=”#fff” padding=”12″ margin=”15″] [wps_lists icon=”arrow-right” icon_color=”#fff”]

• Cómo funcionan los nodos Blockchain
• ¿Dónde es relevante el problema de disponibilidad de datos?
• Aumento del tamaño de los bloques
• Fragmentación
• Rollups
• Ir más lejos
• ¿Qué soluciones están disponibles para el problema de disponibilidad de datos?
• Descarga de todos los datos
• Pruebas de disponibilidad de datos
• Conclusión

[/wps_lists][/wps_section]

La “disponibilidad de datos” y el “problema de disponibilidad de datos” son términos que se utilizan para referirse a un problema específico que se enfrenta en varias estrategias de escala de blockchain. Este problema pregunta: ¿cómo pueden los nodos estar seguros de que cuando se produce un nuevo bloque, todos los datos de ese bloque se publicaron realmente en la red? El dilema es que si un productor de bloques no libera todos los datos en un bloque, nadie podría detectar si hay una transacción maliciosa oculta dentro de ese bloque.

En este artículo, profundizaremos en el problema de la disponibilidad de datos, por qué es importante y qué soluciones existen para él.

‍Cómo funcionan los nodos Blockchain

En una cadena de bloques, cada bloque consta de dos piezas:

• Un encabezado de bloque. Estos son los metadatos del bloque, que constan de información básica sobre el bloque, incluida la raíz de transacciones de Merkle.
• Los datos de la transacción. Esto constituye la mayor parte del bloque y consta de las transacciones reales.

También hay generalmente dos tipos de nodos en una red blockchain:

‍

• Nodos completos (también conocidos como nodos de validación completa). Estos son nodos que descargan y verifican que todas las transacciones en la cadena de bloques sean válidas. Esto requiere una gran cantidad de recursos y cientos de gigabytes de espacio en disco, pero estos son los nodos más seguros, ya que no se los puede engañar para que acepten bloques que tienen transacciones no válidas.
• Clientes ligeros. Si su computadora no tiene los recursos para ejecutar un nodo completo, entonces puede ejecutar un cliente ligero. Un cliente ligero no descarga ni valida ninguna transacción. En cambio, solo descargan el encabezado del bloque y asumen que el bloque solo contiene transacciones válidas, por lo que los clientes ligeros son menos seguros que los nodos completos.

Afortunadamente, existe una manera de permitir que los clientes ligeros verifiquen indirectamente que todas las transacciones en bloques son válidas. En lugar de verificar las transacciones ellos mismos, pueden confiar en nodos completos para enviarles una prueba de fraude si un bloque contiene una transacción no válida. Esta es una pequeña prueba de que una transacción específica en un bloque no es válida. No cubriremos cómo funciona esta prueba en este artículo, pero este documento lo explica con más detalle.

Solo hay un problema: para que un nodo completo genere una prueba de fraude para un bloque, necesitan conocer los datos de la transacción para ese bloque. Si un productor de bloques solo publica el encabezado del bloque pero no los datos de la transacción, los nodos completos no podrán verificar si las transacciones son válidas y generar pruebas de fraude si no lo son. Es un requisito que los productores de bloques deben publicar todos los datos de sus bloques, pero necesitamos una forma de hacer cumplir esto.

Para resolver este problema, debe haber algún tipo de forma para que los clientes ligeros verifiquen que los datos de la transacción de un bloque se publicaron realmente en la red, de modo que los nodos completos puedan verificarlo. Sin embargo, queremos evitar que los clientes livianos descarguen todo el bloque para verificar que se haya publicado, porque eso anula el punto de un cliente liviano.

¿Cómo resolvemos esto? Primero, analicemos en qué otros aspectos es relevante el problema de disponibilidad de datos y luego analizaremos las soluciones.

¿Dónde es relevante el problema de disponibilidad de datos?

En la primera sección, presentamos el problema de disponibilidad de datos. Analicemos para qué soluciones de escalabilidad es importante.

Aumento del tamaño de los bloques

En cadenas de bloques como Bitcoin, la mayoría de las computadoras portátiles estándar tienen la capacidad de ejecutar un nodo completo y verificar toda la cadena, porque hay un límite de tamaño de bloque artificial para mantener la cadena de bloques pequeña.

Pero, ¿y si quisiéramos aumentar el límite de tamaño de bloque? Menos personas se permitirán ejecutar nodos completos y verificar de forma independiente la cadena, y más personas ejecutarán clientes ligeros que son menos seguros. Esto es malo para la descentralización, porque sería más fácil para los productores de bloques cambiar las reglas del protocolo e insertar transacciones no válidas que los clientes ligeros aceptarán como válidas. Por lo tanto, agregar soporte a prueba de fraude para clientes livianos se vuelve muy importante, pero como se discutió, los clientes livianos necesitan una forma de verificar que todos los datos en bloques se hayan publicado para que esto funcione.

‍Fragmentación

Una forma de aumentar el rendimiento de una cadena de bloques es dividir la cadena de bloques en varias cadenas llamadas fragmentos. Estos fragmentos tienen sus propios productores de bloques y pueden comunicarse entre sí para transferir tokens entre fragmentos. El objetivo de la fragmentación es dividir a los productores de bloques en la red para que, en lugar de que cada productor de bloques procese cada transacción, dividan su poder de procesamiento en diferentes fragmentos que solo procesen algunas transacciones.

Por lo general, un nodo completo en una cadena de bloques fragmentada ejecutará un nodo completo para solo uno o unos pocos fragmentos, y ejecutará un cliente ligero para todos los demás fragmentos. Después de todo, cualquiera que ejecute un nodo completo para cada fragmento anula el propósito de fragmentar, que es dividir los recursos de la red en diferentes nodos.

Sin embargo, este método tiene sus problemas. ¿Qué pasa si los productores de bloques en un fragmento se vuelven maliciosos y comienzan a aceptar transacciones no válidas? Es más probable que esto suceda en un sistema fragmentado que en un sistema no fragmentado, ya que un sistema fragmentado es más fácil de atacar ya que solo tiene unos pocos productores de bloques en cada fragmento. Recuerde que los productores de bloques se dividen en diferentes fragmentos.

Para resolver el problema de detectar si algún fragmento aceptó una transacción no válida, debe poder garantizar que todos los datos en ese fragmento se publicaron y estuvieron disponibles, de modo que cualquier transacción no válida pueda probarse con una prueba de fraude.

Rollups

Los rollups optimistas son una nueva estrategia de escalado que se basa en cadenas laterales llamadas rollups, que pueden considerarse como fragmentos. Estas cadenas laterales tienen sus propios productores de bloques dedicados, que pueden transferir activos hacia y desde otras cadenas.

Pero, ¿qué pasa si los productores de bloques se portan mal y hacen bloques que incluyen transacciones no válidas y roban todo el dinero de los usuarios en la cadena lateral? Para solucionar este problema, se pueden utilizar pruebas de fraude para detectarlo. Pero una vez más, los usuarios de la cadena lateral necesitan alguna forma de asegurarse de que los datos de todos los bloques de la cadena lateral se hayan publicado realmente, para asegurarse de que se puedan detectar las transacciones no válidas. Los paquetes acumulativos en Ethereum se ocupan de esto simplemente publicando todos los bloques acumulados en la cadena Ethereum y confiando en él para la disponibilidad de datos, por lo tanto, utilizando Ethereum como una capa de disponibilidad de datos para descargar datos.

Los rollups de conocimiento cero (ZK) son similares a los rollup optimistas, pero en lugar de utilizar pruebas de fraude para detectar bloques no válidos, utilizan una prueba criptográfica llamada prueba de validez para demostrar que un bloque es vald. Las pruebas de validez en sí mismas no requieren disponibilidad de datos. Sin embargo, los resúmenes de ZK en su conjunto aún requieren disponibilidad de datos, porque si un productor de bloques hace un bloque válido y lo prueba con una prueba de validez pero no libera los datos del bloque, los usuarios no sabrán cuál es el estado de la cadena de bloques. es y cuáles son sus saldos, por lo que no podrá interactuar con la cadena.

Ir más lejos

Los paquetes acumulativos son un diseño que utiliza una cadena de bloques solo como una capa de disponibilidad de datos para volcar transacciones, pero todo el procesamiento y el cálculo de las transacciones reales ocurren en el paquete acumulativo. Esto conduce a una idea interesante: una cadena de bloques en realidad no necesita hacer ningún cálculo, pero como mínimo necesita ordenar las transacciones en bloques y garantizar la disponibilidad de datos de las transacciones.

Esta es la filosofía de diseño de LazyLedger, que es una cadena de bloques “perezosa” que solo hace las dos cosas principales que una cadena de bloques debe hacer: ordenar transacciones y ponerlas a disposición, de manera escalable. Esto lo hace útil como un componente “conectable” mínimo para sistemas como los acumulados.

‍¿Qué soluciones están disponibles para el problema de disponibilidad de datos?

Descarga de todos los datos

La forma más obvia, como se discutió, de resolver el problema de disponibilidad de datos es simplemente requerir que todos (incluidos los clientes ligeros) descarguen todos los datos. Claramente, esto no se escala bien. Esto es lo que hacen actualmente la mayoría de las cadenas de bloques, como Bitcoin y Ethereum.

Pruebas de disponibilidad de datos

Las pruebas de disponibilidad de datos son una nueva tecnología que permite a los clientes verificar con muy alta probabilidad que se hayan publicado todos los datos de un bloque, descargando solo una parte muy pequeña de ese bloque.

Utiliza una primitiva matemática llamada códigos de borrado, que se utilizan en todas partes en la tecnología de la información, desde CD-ROM hasta comunicaciones por satélite y códigos QR. La codificación de borrado le permite tomar un bloque, digamos 1 MB grande, y “explotarlo” a 2 MB de tamaño, donde el 1 MB extra es un dato especial llamado código de borrado. Si faltan bytes del bloque, puedes recuperar esos bytes fácilmente gracias al código. Puede recuperar todo el bloque incluso si falta hasta 1 MB del bloque. Es la misma tecnología que le permite a su computadora leer todos los datos en un CD-ROM incluso si está rayado.

Esto significa que para que el 100% de un bloque esté disponible, el productor de bloques solo debe publicar el 50% en la red. Si un productor de bloques malicioso quiere retener incluso el 1% del bloque, debe retener el 50% del bloque, porque ese 1% se puede recuperar del 50%.

Armados con este conocimiento, los clientes pueden hacer algo inteligente para asegurarse de que ninguna parte del bloque haya sido retenida. Pueden intentar descargar algunos fragmentos aleatorios del bloque, y si no logran descargar alguno de esos fragmentos (es decir, el fragmento está en el 50% de los fragmentos que un productor de bloques malicioso no publicó), rechazarán el bloque como no disponible. Después de intentar descargar un fragmento aleatorio, existe un 50% de posibilidades de que detecten que el bloque no está disponible. Después de dos fragmentos, hay un 75% de probabilidad, después de tres fragmentos, hay un 87,5% de probabilidad y así sucesivamente hasta que después de siete fragmentos, hay un 99% de probabilidad. Esto es muy conveniente, porque significa que los clientes pueden verificar con alta probabilidad que se publicó todo el bloque, descargando solo una pequeña parte.

Los detalles completos de las pruebas de disponibilidad de datos son un poco más complicados y se basan en otras suposiciones, como requerir un número mínimo de clientes ligeros en la red para que haya suficientes clientes ligeros realizando solicitudes de muestra para que puedan recuperar colectivamente todo el bloque. Puede consultar el documento de prueba de disponibilidad de datos original si desea obtener más información.

‍Conclusión

En este artículo, presentamos el problema de disponibilidad de datos, mostramos por qué es importante para la escalabilidad de blockchain y describimos una solución.