El ciclo de vida de una transacción celestia-app
Los usuarios solicitan la aplicación celestia para poner los datos a disposición mediante el envío PayForBlobs transacciones. Cada transacción consiste en la identidad del remitente, los datos que se pondrán a disposición, también conocidos como el mensaje, el tamaño de los datos, el espacio de nombres y una firma. Cada productor de bloques se agrupa en múltiples lotes PayForBlobs transacciones en un bloque.
Sin embargo, antes de proponer el bloque, el productor lo pasa a la máquina estatal a través de ABCI++, donde cada uno PayForBlobs la transacción se divide en un mensaje con espacio de nombres (denotado por Msg en la siguiente figura), es decir, los datos junto con el ID de espacio de nombres y una transacción ejecutable (denotado por e-Tx en la siguiente figura) que no contiene los datos, sino solo un compromiso que se puede utilizar en un momento posterior para demostrar que los datos se pusieron a disposición.
Por lo tanto, los datos de bloque consisten en datos particionados en espacios de nombres y transacciones ejecutables. Tenga en cuenta que solo estas transacciones son ejecutadas por la máquina del estado de Celestia una vez que se compromete el bloque.
A continuación, el productor de bloques añade al encabezado de bloque un compromiso de los datos de bloque. Como descrito en la página "Capa de disponibilidad de datos de Celestia", el compromiso es la raíz Merkle de la 4kraíces Merkle intermedias (es decir, una para cada fila y columna de la matriz extendida). Para calcular este compromiso, el productor de bloques realiza las siguientes operaciones:
Divide las transacciones ejecutables y los datos con espacio de nombres en acciones. Cada acción consiste en algunos bytes prefijados por un espacio de nombres. Con este fin, las transacciones ejecutables están asociadas con un espacio de nombres reservado.
Organiza estas acciones en una matriz cuadrada (hilera). Tenga en cuenta que las acciones están acolchadas a la siguiente potencia de dos. El resultado cuadrado de tamaño k×kse conoce como los datos originales.
Extiende los datos originales a un 2k×2kmatriz cuadrada que usa el esquema de codificación Reed-Solomon de 2 dimensiones descrito anteriormente. Las acciones extendidas (es decir, que contienen datos de borrado) están asociadas con otro espacio de nombres reservado.
Calcula un compromiso para cada fila y columna de la matriz extendida utilizando los NMT descritos anteriormente.
Por lo tanto, el compromiso de los datos de bloque es la raíz de un árbol Merkle con las hojas de las raíces de un bosque de subárboles Merkle Namespaced, uno para cada fila y columna de la matriz extendida.
Comprobación de la disponibilidad de datos
Para mejorar la conectividad, el celestia-node aumenta la celestia-app con una red libp2p separada, i.e., el llamado Red DA, que sirve a las solicitudes de DAS.
Los nodos de luz se conectan a un nodo celestia en la red DA, escuchan encabezados de bloque extendidos (es decir, los encabezados de bloque junto con los metadatos DA relevantes, como el 4kraíces intermedias de Merkle), y realizar DAS en los encabezados recibidos (es decir, solicitar datos aleatorios compartidos).
Tenga en cuenta que aunque se recomienda, realizar DAS es opcional: los nodos de luz podrían confiar en que los datos correspondientes a los compromisos en los encabezados de bloque fueron puestos a disposición por la capa Celestia DA. Además, los nodos de luz también pueden enviar transacciones a la celestia-app, es decir., PayForBlobs transacciones.
Mientras realiza DAS para un encabezado de bloque, cada nodo de luz consulta a Celestia Nodes para una serie de datos compartidos aleatorios de la matriz extendida y las pruebas Merkle correspondientes. Si todas las consultas tienen éxito, entonces el nodo de luz acepta el encabezado del bloque como válido (desde una perspectiva DA).
Si al menos una de las consultas falla (es decir, no se recibe el recurso compartido de datos o la prueba de Merkle no es válida), luego, el nodo de luz rechaza el encabezado del bloque e intenta nuevamente más tarde. El nuevo juicio es necesario para tratar con falsos negativos, es decir, encabezados de bloque rechazados aunque los datos de bloque están disponibles. Esto puede suceder debido a la congestión de la red, por ejemplo.
Alternativamente, los nodos de luz pueden aceptar una cabecera de bloque aunque los datos no estén disponibles, es decir, a falso positivo. Esto es posible ya que la propiedad de solidez (es decir, si un nodo de luz honesto acepta un bloque como disponible, es posible, entonces, al menos un nodo completo honesto eventualmente tendrá todos los datos del bloque) está garantizado probabilísticamente (para obtener más detalles, eche un vistazo al papel original).
Ajustando los parámetros de Celestia (por ejemplo., el número de datos compartidos muestreados por cada nodo de luz) la probabilidad de falsos positivos puede reducirse lo suficiente como para que los productores de bloques no tengan incentivos para retener los datos de bloque.
Last updated
