¿Qué es el problema de disponibilidad de datos?

Cuando un usuario envía una transacción en una rollup, el mensaje va directamente a un secuenciador, que generalmente es una computadora realmente rápida que combina estas transacciones en un lote a través de un proceso fuera de la cadena.

Después de comprimir esto en un tamaño más pequeño, el lote se envía a una capa de liquidación como Ethereum.

Debido a la gran demanda de espacio en bloque en estas redes, esta es una solución mucho más económica que publicar las transacciones individuales directamente en la capa de liquidación. Actualmente, la mayoría de los paquetes acumulativos emplean un único secuenciador (es decir, una entidad que realiza la secuenciación), aunque se están explorando los secuenciadores compartidos.

Esto es generalmente seguro porque los usuarios pueden garantizar que la ejecución de una transacción fue válida a través de pruebas de validez o pruebas de fraude que se pueden comprobar en la capa de liquidación. Sin embargo, lo que los paquetes acumulativos no pueden garantizar es si el secuenciador es honesto acerca de qué transacciones se enviaron y si envía o no a todos los mismos datos.

Esencia del problema de disponibilidad de datos

La capa de liquidación, o cualquier nodo completo que esté observando la red, tiene la tarea de verificar el trabajo realizado por el rollup y necesita los datos de la transacción para hacerlo.

De forma predeterminada, los rollups no pueden probar de manera fácil y económica que el secuenciador procesó todas las transacciones entrantes en un bloque, o que todas las transacciones que se agregaron al bloque son de dominio público.

Como tal, el secuenciador puede censurar los datos de transacción enviados por el usuario o, peor aún, evitar que estén disponibles para ser verificados por la capa de liquidación.

Aunque técnicamente este tipo de censura también podría ocurrir en las blockchains regulares, es prácticamente imposible debido a la gran cantidad de validadores en las redes de proof of stake y al hecho de que solo uno de ellos debe ser honesto.

Pero lo que es más importante, los datos no son necesarios para la validación por parte de una capa de liquidación porque las transacciones ya se liquidaron a través del proceso de consenso.

¿Cómo soluciona Celestia este problema?

Celestia es una blockchain Layer 1 creada con Cosmos SDK y brinda disponibilidad de datos como un servicio para rollups. Lo más común es que la red de Celestia reciba todas las transacciones entrantes del usuario desde el secuenciador, aunque también podría ser el primer receptor antes de que vayan al rollup para ejecutarse, según la configuración del mismo. Usemos un ejemplo para explicar esto desde la perspectiva de una transacción. Asumiremos una red imaginaria llamada Roll Protocol que se creó como un rollup optimista basado en Cosmos SDK.

Ejemplos

  • Supongamos que está utilizando Keplr para enviar tokens de $ROLL a su amigo en el protocolo Roll. Una vez enviada, la transacción de envío viaja primero al secuenciador del protocolo Roll.
  • El secuenciador, una computadora que opera como un proceso fuera de la cadena que ejecuta el Protocolo Roll, ahora analiza todas las transacciones y las compara con el estado actual del Protocolo Roll, para ver si son realmente válidas. En el caso de su mensaje de envío, verificaría si contenía una dirección de destinatario válida y si tenía suficientes tokens de $ROLL para enviar a su amigo, entre otras cosas.
  • Las transacciones que son válidas luego se recopilan en un bloque y el secuenciador las ejecuta, lo que significa que se realizan cambios en su almacenamiento. Los saldos de tu wallet y tu amigo se actualizan para reflejar los tokens que se intercambian.
  • Luego, el secuenciador comparte este bloque con transacciones con Celestia y lo coloca en el espacio de nombres “Roll Protocol”, que en realidad es solo una etiqueta para mantener los datos fácilmente separados. Los validadores en la red de Celestia luego acuerdan el contenido del bloque, se finaliza en la red y se distribuye a todos los nodos.
  • Al mismo tiempo, el secuenciador convierte todas las transacciones exitosas que formaban parte del bloque en un lote y las envía a una capa de liquidación, que a menudo es solo un smart contract en una cadena Layer 1 como Ethereum. La capa de liquidación es la blockchain donde se envían las pruebas de fraude en caso de que alguien identifique que una transacción específica no fue válida (por ejemplo, en realidad no tenía los fondos para enviarle algunos tokens a su amigo). Pero, ¿quiénes son estas personas que hacen este trabajo?

Full nodes

Otros full nodes que son operados por dApps independientes, como DEX, también ejecutarán las transacciones al mismo tiempo que lo hace el secuenciador. Esto les permite mantenerse al día con el estado más reciente y brindarle actualizaciones sobre su saldo, por ejemplo. Más importante aún, pueden verificar de antemano si alguna de las transacciones no fue válida. En caso de que lo sea, la prueba de fraude se envía a la capa de liquidación.

  • Tal vez recuerdes que las rollups optimistas tienen una ventana de tiempo antes de que se liquiden las transacciones. Tener estos full nodes verificando la validez por adelantado ayuda a los usuarios a considerar la transacción como “final” antes de que se cierre la ventana optimista, siempre que confíe en la entidad que opera el full node. Llamamos a este sistema confianza minimizada, en el sentido de que solo necesita confiar en que la red contenga al menos un nodo de muchos nodos que sea honesto para omitir la ventana de tiempo optimista.
  • Para probar si el secuenciador no se estaba comportando mal, los full nodes, así como la capa de liquidación, necesitarán acceso a algunos de los datos que se publicaron en Celestia, porque el secuenciador podría haber ejecutado transacciones no válidas. Afortunadamente, la red de Celestia publicó un bloque que contenía todas las transacciones entrantes de Roll Protocol que se incluyeron en este lote anteriormente, por lo que estamos seguros de que tenemos lo que necesitamos para demostrar la honestidad del secuenciador cuando sea necesario.

Transacciones

Es importante tener en cuenta que a Celestia no le importa el contenido de cada transacción. De hecho, ni siquiera puede entender estas transacciones, porque no hay un entorno de ejecución en Celestia que hable el mismo idioma. Al separar estas preocupaciones a través de esta pila modular, el secuenciador puede enfocarse en ser realmente rápido en la ejecución de transacciones, la capa de liquidación puede enfocarse en ser segura y proporcionar funcionalidad de puente, mientras que la capa de consenso y disponibilidad de datos puede enfocarse en ser descentralizada. Esto mejora en gran medida la escalabilidad y la optimización al garantizar que cada subcomponente responsable del funcionamiento de la red esté altamente especializado.

Aunque nuestro ejemplo utiliza un paquete acumulativo basado en Cosmos SDK, los paquetes acumulativos compatibles con EVM no están excluidos. Celestia también podría funcionar como una capa de disponibilidad de datos para el ecosistema EVM, posiblemente mucho más barato que alternativas como EIP-4844 en Ethereum, también conocido como Danksharding.

Aprende más sobre