Investigador de Input Output expone las necesidades de disponibilidad de datos de Cardano

El investigador de Input Output Giorgos Panagiotakos ha presentado un documento que describe la necesidad de una capacidad dedicada de disponibilidad de datos en la capa base de Cardano.

El enunciado de problema de Disponibilidad de Datos en Capa 1 propuesto examina cómo los proyectos podrían publicar información que otros puedan recuperar y verificar sin necesariamente convertirla en parte del historial permanente de transacciones del libro mayor. Se basa en los requisitos debatidos en un taller técnico de IO Research el 3 de septiembre.

Por qué los proyectos de Cardano necesitan acceso a los datos publicados

Algunas aplicaciones de blockchain necesitan que la información permanezca disponible solo el tiempo suficiente para que los participantes verifiquen una acción o respondan a un problema. Otras necesitan que los registros sean accesibles mucho después de haber sido creados.

Para ciertos protocolos de Capa 2, los participantes pueden necesitar información de estado publicada para reconstruir sus posiciones y retirar fondos si el protocolo se detiene o un operador se desconecta. Los rollups optimistas necesitan que los datos de las transacciones permanezcan accesibles el tiempo suficiente para que un participante construya una prueba de fraude al impugnar un estado declarado.

El documento también enumera grandes pruebas de conocimiento cero, papeletas de gobernanza, registros de auditoría y aplicaciones que agrupan muchas operaciones pequeñas en lotes. Sus requisitos de retención difieren: alguna información puede ser necesaria durante horas, otros datos durante días y los registros usados para auditorías posteriores potencialmente durante años.

Panagiotakos describe varias opciones existentes. Los proyectos pueden publicar datos directamente en el libro mayor de Cardano, apoyarse en un sistema externo como Celestia o usar un operador de confianza. Según el documento, publicar grandes volúmenes en el libro mayor puede ser demasiado costoso para algunas aplicaciones, mientras que un servicio externo introduce suposiciones separadas de seguridad y disponibilidad.

El CPS también aborda IPFS, que identifica el contenido usando información derivada de los propios datos. Ese enfoque permite a un receptor comprobar el contenido recuperado, pero no garantiza que otro participante siga almacenándolo y sirviéndolo.

Qué necesitaría una capa de disponibilidad de datos de Cardano

El enunciado de problema establece cinco objetivos para una solución potencial. Sus garantías de disponibilidad deberían apoyarse en las suposiciones de seguridad existentes de Cardano en lugar de en un operador de almacenamiento confiable independiente o en un conjunto de validadores externos separado.

La información publicada también debería poder recuperarse durante un periodo definido. Una solución propuesta tendría que especificar cuándo se acepta la publicación, cuándo comienza y termina la retención y las suposiciones bajo las cuales los participantes pueden obtener los datos.

El tercer objetivo es la integridad de los datos: cualquiera que recupere la información debería poder verificar su corrección. El cuarto es la compatibilidad con pruebas de pertenencia y no pertenencia, que permitirían a los contratos inteligentes de Plutus comprobar si determinados datos pertenecen a un conjunto publicado.

El objetivo final abarca el costo y el rendimiento. El CPS pide un costo por byte sustancialmente menor que el de publicar datos equivalentes directamente en la capa base, mayor rendimiento y una latencia de publicación comparable a la de Capa 1. Solicita que las futuras propuestas indiquen cifras con las que se puedan medir esos requisitos.

El documento ilustra la variedad de necesidades a través de proyectos individuales. Enumera un periodo de retención de una hora a cinco días para Gummiworm, mientras que Midgard, un rollup optimista, se describe como requiriendo almacenamiento durante siete días y compatibilidad con pruebas de pertenencia y no pertenencia.

Para las aplicaciones de gobernanza, el CPS señala rondas de votación anteriores de Project Catalyst al discutir una capacidad potencial de 100,000 a un millón de votos. También señala que algunas pruebas de conocimiento cero poscuánticas pueden superar los 100 kilobytes, lo que incrementa la cantidad de datos que las aplicaciones pueden necesitar publicar.

El almacenamiento archivístico permanente y la confidencialidad quedan fuera del alcance propuesto. Para los registros de gobernanza que deben permanecer disponibles para auditorías años después, el documento identifica como necesario un mecanismo de archivo por separado.

[NEWSBREAK]

Costos, cronograma y cuestiones técnicas abiertas

Panagiotakos no ha seleccionado una arquitectura ni ha anunciado una actualización de red completada. El CPS pregunta qué sistema de pruebas podría soportar el rendimiento requerido y cómo lo referenciarían los scripts de Plutus.

También deja abierto quién debería pagar por la retención de datos: el publicador, la parte que los recupera o el protocolo. Cualquier modelo de precios tendría que contemplar tanto publicaciones pequeñas ocasionales como aplicaciones que generen tráfico sostenido de alto volumen.

Para los operadores de stake pool, el documento pregunta cómo afectaría una solución a los requisitos de hardware y a los costos operativos, y qué incentivos fomentarían la participación. También pide una primera fase lo suficientemente simple como para ofrecer una capacidad útil para al menos una de las aplicaciones identificadas.

El enunciado de problema incluye una restricción de tiempo. Según el documento, una solución que esté a más de aproximadamente ocho meses podría llegar demasiado tarde para algunos proyectos que planean lanzarse dentro del año. Una alternativa posterior necesitaría una mejora significativa del rendimiento o otra ventaja clara para sustituir la infraestructura que un proyecto ya hubiera integrado.

La seguridad poscuántica se enumera como deseable en lugar de obligatoria. El CPS propuesto permanece abierto en el repositorio de Cardano Improvement Proposals y aún no se le ha asignado un número.