Resumen Técnico: Integración Segura de AltDA para Ethereum L2s

Planteamiento del Problema

Los sistemas de Disponibilidad de Datos Alternativos (AltDA) permiten que los rollups de Capa 2 (L2) de Ethereum escalen mediante la publicación de datos masivos en redes externas (por ejemplo, Celestia, EigenDA, Avail) mientras se postean únicamente referencias compactas en Ethereum. Si bien esto alivia los cuellos de botella de rendimiento de la disponibilidad de datos (DA) nativa de Ethereum, introduce una brecha de seguridad crítica en el límite de la integración.

Los marcos de trabajo existentes en el ecosistema identifican riesgos de alto nivel, como los supuestos de confianza respecto al proveedor de DA o la existencia de un verificador de DA. Sin embargo, no proporcionan una especificación completa de cómo una L2 debe integrarse con AltDA. Esta falta de una especificación rigurosa de extremo a extremo crea "brechas de conocimiento" donde:

1. Los Verificadores de DA pueden autenticar una declaración sobre datos externos sin probar que el estado de la L2 se deriva de esos datos específicos.
2. Los Compromisos (Commitments) pueden ser válidos en su creación pero inseguros para consumir posteriormente si el sistema de DA elimina (pruning) los datos o si el intervalo de tiempo para la recuperación expira.
3. Existe Ambigüedad donde un compromiso válido se vincula a un blob que se decodifica en múltiples payloads de rollup o en uno no canónico.

Estas brechas pueden conducir a modos de falla graves, incluyendo paradas de la L2, derivaciones inconsistentes entre nodos honestos, aserciones de estado inválidas y ataques de puente (bridge attacks) donde se retiran fondos basados en transiciones de estado no verificadas o conflictivas.

Metodología

El documento propone un marco de validación canónica que modela el límite de integración de AltDA como un pipeline de traducción tipado, determinista y total. Los autores definen el flujo como:
$$\text{InboxBytes} \rightarrow \text{AltDACommitment} \rightarrow \text{Blob} \rightarrow \text{RollupPayload}$$

La metodología central consiste en definir una Función de Validación Total ($F$) que mapea cualquier cadena de bytes arbitraria desde el inbox de L1 a exactamente uno de tres resultados:

1. RollupPayload(p): Un payload único y válido para la lógica de ejecución de la L2.
2. Drop (Descarte): Una entrada inválida que debe ser rechazada de forma determinante.
3. Stall (Parada temporal): Una condición temporal (por ejemplo, indisponibilidad de datos) que detiene el procesamiento pero no causa un fallo de consenso, sujeta a políticas de reintento/timeout.

El marco identifica seis obligaciones semánticas que deben aplicarse a lo largo de este pipeline:

• Parsing Canónico: Manejo de bytes arbitrarios del inbox sin errores de implementación (crashes).
• Verificación de DA: Validación de que el compromiso es auténtico bajo el sistema de DA externo.
• Recencia: Asegurar que el compromiso es lo suficientemente reciente como para que las partes honestas aún puedan recuperar los datos dentro de la ventana de liquidación.
• Vinculación Compromiso-a-Blob (Commitment-to-Blob Binding): Probar que el blob recuperado corresponde de manera única al compromiso.
• Unicidad del Payload: Asegurar que el blob se decodifica en exactamente un payload de rollup canónico.
• Manejo Determinista de Fallos: Asegurar que todas las entradas inválidas resulten en un Drop o Stall definido, en lugar de un comportamiento indefinido.

Los autores analizan tres patrones de integración para determinar dónde se pueden aplicar estas obligaciones:

1. Prueba de Falla Interactiva (Interactive Fault Proof): Aplicar la validación de DA dentro del proceso de resolución de disputas.
2. Prueba de Validez (Validity Proof): Incluir la relación de DA (verificación, vinculación, recencia) dentro de la declaración de la prueba sucinta.
3. Verificación Eager del Inbox (Eager Inbox Verification): Validar los compromisos a nivel del contrato de inbox de L1 antes de que entren en el pipeline de derivación.

Contribuciones Claves

1. Modelo de Validación Tipado: El documento introduce un modelo formal que separa los bytes del inbox de L1, los compromisos de AltDA, los blobs externos y los payloads de rollup, aclarando que la validez en un dominio no implica validez en otro.
2. Obligaciones Semánticas: Define explícitamente las seis obligaciones centrales requeridas para una integración segura, yendo más allá de las clasificaciones de riesgo de alto nivel hacia requisitos semánticos concretos.
3. Taxonomía de Ataques: Los autores derivan vectores de ataque concretos resultantes de la ausencia de obligaciones, incluyendo:
   • Liquidación sub-restringida (Under-constrained settlement): Donde se acepta una transición de estado sin estar vinculada a los datos autenticados.
   • Paradas de derivación (Derivation halts): Donde las entradas inválidas causan que los nodos honestos fallen o diverjan.
   • Fallos de seguridad en puentes (Bridge safety failures): Donde se aceptan reclamos de estado conflictivos debido a una vinculación de datos ambigua.
4. Evaluación de Arquitecturas Representativas: El marco se aplica a integraciones del mundo real, incluyendo Celestia-Blobstream (OP y Arbitrum), EigenDA (OP y Arbitrum) y Avail-ZKsync. El análisis revela qué obligaciones son aplicadas por componentes específicos (por ejemplo, puentes de DA, contratos de inbox, sistemas de pruebas) e identifica áreas donde las especificaciones actualmente "no están identificadas" o requieren mayor auditoría.

Resultados

La evaluación de las integraciones existentes demuestra que la presencia de un verificador de DA o un puente es insuficiente para la seguridad.

• Integraciones de Celestia: Aunque Blobstream proporciona autenticación, el análisis encontró que algunos diseños (por ejemplo, Hana/OP) carecían de la aplicación explícita de extremo a extremo de la relación de vinculación entre el compromiso autenticado y los datos consumidos por la derivación. Las reglas de recencia tampoco fueron identificadas explícitamente en los materiales examinados.
• Integraciones de EigenDA: Estos diseños (por ejemplo, Hokulea/OP y Arbitrum) mostraron una mayor alineación con el marco. La integración de Arbitrum utiliza "verificación eager" en el inbox, mientras que la integración de OP depende de las pruebas de validez para imponer el predicado de DA. Los autores no encontraron verificaciones faltantes en los patrones examinados, aunque señalan que esto no es una prueba de seguridad completa.
• Avail-ZKsync: Al igual que EigenDA, esta utiliza verificación eager en el inbox. Sin embargo, al igual que en el caso de Celestia, no se identificó una condición de recencia explícita vinculada a la ventana de liquidación en las especificaciones públicas.

Los resultados confirman que la integración segura de AltDA no está determinada únicamente por el proveedor de DA, sino que es una propiedad de todo el stack de integración de la L2.

Significado y Reivindicaciones

El documento sostiene que la integración segura de AltDA es una propiedad de extremo a extremo del inbox, la derivación, la prueba y la ruta de liquidación, en lugar de ser una propiedad del proveedor de DA o de una única llamada de verificación.

Los autores argumentan que la industria se ha centrado demasiado en el "verificador de DA" (que responde si un hecho sobre un sistema externo es cierto) y ha descuidado la "relación de integración" (que responde si cada entrada adversaria en el límite de la L2 conduce a un resultado determinante y aplicado en la liquidación).

La importancia de este trabajo radica en el cambio del paradigma de seguridad:

• Mueve el enfoque de los "supuestos de confianza" hacia las "obligaciones de validación".
• Proporciona una especificación rigurosa para auditores y desarrolladores para asegurar que la capa de liquidación de la L2 imponga la relación completa entre las entradas de L1 y los estados aceptados de la L2.
• Destaca que, sin la aplicación de estas semánticas de validación total, las L2 enfrentan riesgos de liquidación sub-restringida y ataques de puente, independientemente de la fuerza criptográfica del sistema de DA subyacente.

El documento concluye que, a medida que las L2 respaldadas por AltDA aseguran un valor creciente, el límite de integración debe especificarse y auditarse con el mismo rigor que los propios sistemas de ejecución y liquidación de los rollups.