Disponibilidad de datos

"No confíe, verifique" es un principio común en Ethereum. La idea es que su nodo pueda verificar de manera independiente que la información que recibe es correcta ejecutando todas las transacciones en los bloques que recibe de sus pares para asegurarse de que los cambios propuestos coincidan exactamente con los calculados de manera independiente por el nodo. Esto significa que los nodos no tienen que confiar en que los remitentes del bloque sean honestos. Esto no es posible si falta información.

La disponibilidad de datos se refiere a la confianza que un usuario puede tener en que los datos necesarios para verificar un bloque están realmente disponibles para todos los participantes de la red. Para los nodos completos en la capa 1 de Ethereum, esto es relativamente simple; el nodo completo descarga una copia de todos los datos en cada bloque; los datos tienen que estar disponibles para que la descarga sea posible. Un bloque con datos faltantes sería descartado en lugar de ser agregado a la cadena de bloques. Esto es la «disponibilidad de datos en cadena» y es una característica de las cadenas de bloques monolíticas. Los nodos completos no pueden ser engañados para aceptar transacciones inválidas porque descargan y ejecutan cada transacción por sí mismos. Sin embargo, en el caso de las cadenas de bloques modulares, los rollups de capa 2 y los clientes ligeros, el panorama de la disponibilidad de datos es más complejo, lo cual requiere de procedimientos de verificación más sofisticados.

Requisitos previos

Debería tener una buena comprensión de los fundamentos de la cadena de bloques, especialmente de los mecanismos de consenso. Esta página también asume que el lector está familiarizado con los bloques, las transacciones, los nodos, las soluciones de escalabilidad y otros temas relevantes.

El problema de la disponibilidad de los datos

El problema de la disponibilidad de datos es la necesidad de demostrar a toda la red que la forma resumida de algunos datos de transacción que se están agregando a la cadena de bloques realmente representa un conjunto de transacciones válidas, pero hacerlo sin requerir que todos los nodos descarguen todos los datos. Todos los datos de transacción son necesarios para verificar de manera independiente los bloques, pero requerir que todos los nodos descarguen todos los datos de transacción es un obstáculo para el escalamiento. Las soluciones al problema de disponibilidad de datos buscan proporcionar garantías suficientes de que todos los datos de transacción estuvieron disponibles para que los participantes de la red que no descargan y almacenan los datos los pudieran verificar.

Los nodos ligeros y los rollups de la capa 2 son ejemplos importantes de participantes de la red que requieren fuertes garantías de disponibilidad de datos, pero no pueden descargar y procesar los datos de las transacciones por sí mismos. Evitar la descarga de datos de transacción es lo que hace que los nodos ligeros sean ligeros y permite que las rollups sean soluciones efectivas de escalamiento.

La disponibilidad de los datos también es una preocupación fundamental para los futuros clientes de Ethereum «sin estado» que no necesitan descargar ni almacenar datos de estado para verificar los bloques. Los clientes sin estado todavía necesitan tener la certeza de que los datos están disponibles en alguna parte y de que se han procesado correctamente.

Soluciones de disponibilidad de los datos

Muestreo de disponibilidad de datos (DAS)

El muestreo de disponibilidad de datos (DAS) es una forma en la que la red verifica que los datos están disponibles sin ejercer demasiada presión sobre ningún nodo individual. Cada nodo (incluidos los nodos que no realizan staking) descarga un pequeño subconjunto seleccionado al azar de los datos totales. La descarga exitosa de las muestras confirma con alto grado de confianza que todos los datos están disponibles. Esto se basa en la codificación de borrado de datos, que expande un conjunto de datos dado con información redundante (la forma en que se hace esto es ajustando una función conocida como polinomio sobre los datos y evaluando ese polinomio en puntos adicionales). Esto permite que los datos originales se recuperen a partir de los datos redundantes cuando sea necesario. Una consecuencia de esta creación de datos es que, si alguno de los datos originales no está disponible, ¡faltará la mitad de los datos ampliados! La cantidad de muestras de datos que descarga cada nodo puede ajustarse de modo que sea extremadamente probable que falte al menos uno de los fragmentos de datos muestreados por cada cliente si menos de la mitad de los datos está realmente disponible.

El DAS se utilizará para garantizar que los operadores de rollup pongan a disposición sus datos de transacción una vez que se haya implementado la fragmentación completa de Danksharding. Los nodos de Ethereum van a tomar muestras aleatorias de los datos de transacción proporcionados en blobs utilizando el esquema de redundancia explicado anteriormente para asegurarse de que existan todos los datos. La misma técnica también podría emplearse para estar seguros de que los productores de bloques estén poniendo a disposición todos sus datos, garantizando así la seguridad de los clientes ligeros. Del mismo modo, en el marco de la separación de proponentes-constructores, solo el constructor del bloque estaría obligado a procesar un bloque entero; los demás validadores lo verificarían mediante el muestreo de disponibilidad de datos.

Comités de disponibilidad de datos

Los Comités de Disponibilidad de Datos (DAC) son entidades de confianza que proporcionan o certifican la disponibilidad de datos. Los DAC se pueden utilizar en lugar de, o en combinación conopens in a new tab DAS. Las garantías de seguridad que vienen con los comités dependen de la configuración específica. Ethereum utiliza subconjuntos de validadores seleccionados al azar para dar fe de la disponibilidad de datos para nodos ligeros, por ejemplo.

Algunos validiums también utilizan DAC. El DAC es un conjunto de nodos confiables que almacenan copias de datos sin conexión. El DAC está obligado a poner los datos a disposición en caso de disputa. Los miembros del DAC también publican atestaciones en cadena para demostrar que los datos mencionados están realmente disponibles. Algunos validiums reemplazan los DAC con un sistema de validadores de prueba de participación (PoS). Aquí cualquiera puede convertirse en un validador y almacenar los datos fuera de la cadena. Sin embargo, deben proporcionar una "garantía o fianza", que se deposita en un contrato inteligente. En caso de comportamiento malicioso, como que el validador retenga los datos, la garantía puede acuchillarse (cortarse). Los comités de disponibilidad de datos basados en la prueba de participación son considerablemente más seguros que los DAC regulares porque incentivan directamente el comportamiento honesto.

Disponibilidad de los datos y nodos ligeros

Los nodos ligeros necesitan validar la corrección de las cabeceras de bloque que reciben sin descargar los datos del bloque. El precio de ser tan ligeros es la incapacidad de verificar de forma independiente los encabezados de los bloques mediante la reejecución de transacciones de manera local, como lo hacen los nodos completos.

Los nodos ligeros de Ethereum confían en conjuntos aleatorios de 512 validadores que han sido asignados a un comité de sincronización. El comité de sincronización funciona como un DAC, el cual señala a los clientes ligeros que los datos en el encabezado son correctos mediante una firma criptográfica. El comité de sincronización se renueva diariamente. Cada cabecera de bloque alerta a los nodos ligeros sobre qué validadores se espera que firmen el siguiente bloque, de modo que no se les pueda engañar para que confíen en un grupo malicioso que finja ser el verdadero comité de sincronización.

Sin embargo, ¿qué pasaría si un atacante lograra de alguna manera pasar una cabecera de bloque maliciosa a los clientes ligeros y los convenciera de que fue firmada por un comité de sincronización honesto? En ese escenario, el atacante podría incluir transacciones no válidas y el cliente ligero las aceptaría ciegamente, ya que no verifican independientemente todos los cambios de estado resumidos en el encabezado del bloque. Para protegerse de esto, el cliente ligero puede utilizar pruebas de fraude.

La forma en que estas pruebas de fraude funcionan es que un nodo completo, al detectar que una transición de estado inválida se difunde por la red, podría generar rápidamente un pequeño conjunto de datos para demostrar que una transición de estado propuesta es imposible que surja de un conjunto dado de transacciones y transmitir esos datos a sus pares. Los nodos ligeros podrían recoger dichas pruebas de fraude y utilizarlas para descartar encabezados de bloques incorrectos, asegurándose de que permanezcan en la misma cadena honesta que los nodos completos.

Esto depende de nodos completos que tengan acceso a los datos completos de las transacciones. Un atacante que propague el encabezado incorrecto de un bloque y sumado a eso no ponga a disposición los datos de transacciones podría evitar que los nodos completos generen pruebas de fraude. Los nodos completos podrían emitir una advertencia sobre un bloque incorrecto, pero no podrían respaldar su advertencia con pruebas, ya que los datos no estaban disponibles para generarlas.

La solución a este problema de disponibilidad de datos es el muestreo de disponibilidad de datos (DAS). Los nodos ligeros descargan fragmentos muy pequeños y aleatorios de los datos de estado completo y utilizan estas muestras para verificar que el conjunto de datos completo esté disponible. La probabilidad real de asumir incorrectamente la disponibilidad total de los datos tras descargar N fragmentos aleatorios puede calcularse (para 100 fragmentos la probabilidad es de 10^-30opens in a new tab, es decir, increíblemente improbable).

Incluso en este escenario, ataques que retengan solo unos pocos bytes podrían pasar desapercibidos fácilmente para aquellos clientes que realizan solicitudes de datos aleatorios. La solución se alcanza mediante la codificación de borrado, que reconstruye pequeñas partes de datos faltantes para luego utilizarlas para verificar las modificaciones de estado propuestas. Posteriormente se puede construir una prueba de fraude utilizando los datos reconstruidos, evitando que los nodos ligeros acepten encabezados incorrectos.

Nota: Todavía no se ha implementado el DAS ni las pruebas de fraude para los clientes ligeros de Ethereum de prueba de participación, pero están en la hoja de ruta, muy probablemente en forma de pruebas basadas en ZK-SNARK. Actualmente los clientes ligeros usan una forma de DAC: verifican las identidades del comité de sincronización y luego confían en los encabezados de bloque firmados que reciben.

Disponibilidad de datos y rollups de capa 2

Las soluciones de escalado de capa 2, como los , reducen los costes de las transacciones y aumentan el rendimiento de Ethereum al procesar las transacciones fuera de la cadena. Las transacciones de los rollups se comprimen y son publicadas en lotes en Ethereum. Los lotes representan miles de transacciones individuales fuera de cadena en una única transacción en Ethereum. Esto reduce la congestión en la capa base y disminuye las tarifas para los usuarios.

Sin embargo, solo es posible confiar en las transacciones de «resumen» publicadas en Ethereum, si el cambio de estado propuesto puede ser verificado y confirmado de manera independiente como el resultado de aplicar todas las transacciones individuales fuera de cadena. Si los operadores de los rollup no ponen a disposición los datos de transacción para esta verificación, podrían estar enviando datos incorrectos a Ethereum.

Los rollups optimistas publican datos de transacciones comprimidos en Ethereum y esperan un cierto tiempo (normalmente 7 días) para permitir que verificadores independientes comprueben los datos. Si alguno identifica un problema, puede generar una prueba de fraude y utilizarla para impugnar al rollup. La consecuencia sería una reversión en la cadena y la omisión del bloque inválido. Esto solo es posible si los datos están disponibles. Actualmente, hay dos formas en las que los rollups optimistas publican datos de las transacciones en L1. Algunos rollups hacen que los datos estén permanentemente disponibles como CALLDATA, que vive permanentemente en la cadena. Con la implementación de EIP-4844, algunos rollups publican en cambio sus datos de transacción en un almacenamiento de blobs más barato. Esto no sería un almacenamiento permanente. Los verificadores independientes tienen que consultar los blobs y plantear sus desafíos dentro de ~18 días antes de que los datos se eliminen de la capa 1 de Ethereum. La disponibilidad de datos solamente va a estar garantizada por el protocolo de Ethereum durante ese corto período de tiempo. Luego de ese lapso, la responsabilidad va a recaer en otras entidades del ecosistema de Ethereum. Cualquier nodo puede verificar la disponibilidad de los datos utilizando el DAS, es decir, descargando pequeñas muestras aleatorias de los datos del blob.

Los rollups de conocimiento cero (ZK) no necesitan publicar los datos de las transacciones, ya que las garantizan la corrección de las transiciones de estado. Sin embargo, la disponibilidad de datos sigue siendo un problema porque no podemos garantizar la funcionalidad del rollup de ZK (o interactuar con él) sin acceso a sus datos de estado. Por ejemplo, los usuarios no pueden conocer sus saldos si un operador retiene detalles sobre el estado del rollup. Además, no pueden realizar actualizaciones de estado utilizando la información contenida en un bloque recién agregado.

Disponibilidad de datos frente a recuperabilidad de datos

La disponibilidad de datos es diferente de la capacidad de recuperación de datos. La disponibilidad de datos es la garantía de que los nodos completos han podido acceder y verificar el conjunto completo de transacciones asociadas con un bloque específico. No es necesario que los datos sean accesibles para siempre.

La recuperabilidad de los datos es la capacidad de los nodos para recuperar información histórica de la cadena de bloques. Estos datos históricos no son necesarios para verificar nuevos bloques, solo son necesarios para sincronizar nodos completos del bloque inicial o para servir solicitudes históricas específicas.

El protocolo principal de Ethereum se ocupa principalmente de la disponibilidad de datos, no de su capacidad de recuperación. La recuperabilidad de los datos puede ser proporcionada por una pequeña población de nodos de archivo gestionados por terceros, o puede ser distribuida a través de la red utilizando un almacenamiento de archivos descentralizado como la Portal Networkopens in a new tab.