Consultando las pruebas de Blobstream

Requisitos previos

  • Acceso a una Celestia nodo completo de consenso Punto final de RPC (o nodo completo). El nodo no necesita ser un nodo de validación para que se consulten las pruebas. Un nodo completo es suficiente.

Descripción general de las consultas de prueba

Para probar la inclusión de transacciones, blobs o acciones de PayForBlobs (PFB), comprometidas en un bloque de Celestia, utilizamos el RPC del nodo de consenso de Celestia para buscar pruebas que puedan verificarse en un contrato de liquidación nominal a través de Blobstream. De hecho, cuando una transacción PFB se incluye en un bloque, se separa en una transacción PFB (sin el blob) y el blob de datos real que lleva. Estos dos se dividen en acciones, que son las construcciones de bajo nivel de un bloque Celestia, y se guardan en el bloque Celestia correspondiente. Obtenga más información sobre las acciones en el especificaciones de acciones.

Los dos diagramas a continuación resumen cómo se compromete una sola acción, que puede contener una transacción PFB, o una parte de los datos de despliegue que se publicaron utilizando un PFB, en Blobstream.

La parte se destaca en verde. R0, R1 etc., representan las respectivas raíces de fila y columna, los gradientes azul y rosa son datos codificados de borrado. Se pueden encontrar más detalles sobre el diseño cuadrado en el diseño del cuadrado de datos y estructuras de datos parte de las especificaciones.

La plaza Celestia

Plaza

El esquema de compromiso

Diagrama de compromiso de Blobstream

Entonces, para demostrar la inclusión de una acción en un bloque de Celestia, usamos Blobstream como fuente de verdad. Actualmente, utilizaremos la implementación de Blobstream X de Blobstream, se puede encontrar más información sobre Blobstream X en la visión general. En pocas palabras, Blobstream X atestigua los datos publicados en Celestia en el contrato de Blobstream X mediante la verificación de una prueba zk de los encabezados de un lote de bloques de Celestia. Luego, mantiene referencia de ese lote de bloques utilizando el compromiso merkleizado de sus (dataRoot, height) resultando en a data root tuple root. Compruebe el diagrama anterior que muestra:

  • 0: esas son las acciones, que cuando están unificadas, contienen el PFB o el blob de datos de rollup.

  • 1: las raíces de fila y columna son las raíces del árbol merkle del espacio de nombres sobre las acciones. Más información sobre el NMT en el especificaciones NMT. Estos se comprometen con las filas y columnas que contienen las acciones anteriores.

  • 2: las raíces de datos: que son el compromiso binario del árbol de merkle sobre las raíces de fila y columna. Esto significa que si puede probar que una acción es parte de una fila, use una prueba de merkle de espacio de nombres. Luego pruebe que esta fila está comprometida con la raíz de datos. Entonces puede estar seguro de que esa acción se publicó en el bloque correspondiente.

  • 3: para agrupar varios bloques en el mismo compromiso, creamos un compromiso sobre el (dataRoot, height) tupla para un lote de bloques, lo que da como resultado una raíz de tupla de raíz de datos. Es este compromiso el que se almacena en el contrato inteligente de Blobstream X.

Entonces, si podemos demostrar que una acción es parte de una fila, entonces esa fila está comprometida por una raíz de datos. Luego, demuestre que esa raíz de datos junto con su altura está comprometida con la raíz de tupla de raíz de datos, que se guarda en el contrato de Blobstream X, podemos estar seguros de que esa participación se comprometió en el bloque Celestia correspondiente.

En este documento, proporcionaremos detalles sobre cómo consultar las pruebas anteriores y cómo adaptarlas para enviarlas a un contrato de rollup para su verificación.

Demostración práctica

Esta parte proporcionará los detalles de la generación de pruebas y la forma de hacer que los resultados de las consultas de pruebas estén listos para ser consumidos por el contrato de implementación objetivo.

NOTA

Para los fragmentos de cliente de go, asegúrese de tener los siguientes reemplazos en su go.mod:

ir

Además, asegúrese de actualizar las versiones para que coincidan con las últimas github.com/celestiaorg/cosmos-sdk y github.com/celestiaorg/celestia-core versiones.

1. Prueba de inclusión de raíz de datos

Para demostrar que la raíz de datos está comprometida con el contrato inteligente Blobstream X, tendremos que proporcionar una prueba Merkle de la tupla raíz de datos a una raíz de tupla raíz de datos. Esto se puede crear usando el data_root_inclusion_proof consulta.

Esto punto final permite consultar una raíz de datos a prueba de raíz de tupla de raíz de datos. Se necesita un bloque height, un bloque de inicio y un bloque final, luego genera la prueba binaria Merkle del DataRootTuple, correspondiente a eso height, a la DataRootTupleRoot que está comprometido en el contrato de Blobstream X.

El punto final se puede consultar utilizando el cliente golang:

ir

Ejemplo completo de prueba de que un bloque Celestia fue comprometido por el contrato Blobstream X

ir

2. Prueba de inclusión de transacciones

Para demostrar que una transacción de rollup es parte de la raíz de datos, tendremos que proporcionar dos pruebas: (1) una prueba Merkle de espacio de nombres de la transacción a una raíz de fila. Esto podría hacerse probando las acciones que contienen la transacción en la raíz de la fila utilizando una prueba Merkle de espacio de nombres. (2) Y, una prueba Merkle binaria de la raíz de fila a la raíz de datos.

Estas pruebas se pueden generar utilizando el ProveShares consulta.

Esto punto final permite consultar una prueba de acciones a raíces de fila, luego una raíz de fila a pruebas de raíz de datos. Se necesita un bloque height, un índice de acción inicial y un índice de acción final que definen un rango de acciones. Luego, se generan dos pruebas:

  • Una prueba NMT de las acciones a las raíces de las filas

  • Una prueba binaria de Merkle de la raíz de fila a la raíz de datos

NOTA

Si el rango de acciones abarca varias filas, entonces la prueba puede contener múltiples pruebas NMT y binarias.

El punto final se puede consultar utilizando el cliente golang:

ir

Convertir las pruebas para ser utilizables en el DAVerifier biblioteca

Contratos inteligentes que utilizan el DAVerifier la biblioteca toma el siguiente formato de prueba:

solidez

Para construir el SharesProof, necesitaremos la prueba que consultamos anteriormente, y es la siguiente:

data

Estas son las acciones en bruto que se presentaron a Celestia en el bytes formato. Si tomamos el ejemplo blob que se presentó en el RollupInclusionProofs.t.sol, podemos convertirlo en bytes usando el abi.encode(...) como hecho para esta variable. Esto se puede obtener del resultado anterior de la prueba de inclusión de transacciones consulta en el campo data.

shareProofs

Esta es la prueba de acciones a las raíces de las filas. Estos pueden contener múltiples pruebas si las acciones que contienen el blob se extienden a través de varias filas. Para construirlos, utilizaremos el resultado de la prueba de inclusión de transacciones sección.

Mientras que el NamespaceMerkleMultiproof ser:

solidez

Entonces, podemos construir el NamespaceMerkleMultiproof con el siguiente mapeo:

  • beginKey en la estructura de Solidez == start en la respuesta de la consulta

  • endKey en la estructura de Solidez == end en la respuesta de la consulta

  • sideNodes en la estructura de Solidez == nodes en la respuesta de la consulta

  • El NamespaceNode, que es el tipo de sideNodes, se define de la siguiente manera:

solidez

Entonces, construimos un NamespaceNode tomando los valores de la nodes campo en la respuesta de consulta, los convertimos de base64 a hex, luego usamos el siguiente mapeo:

  • min== los primeros 29 bytes en el valor decodificado

  • max== los segundos 29 bytes en el valor decodificado

  • digest== los 32 bytes restantes en el valor decodificado

El min y max son Namespace tipo que es:

solidez

Entonces, para construirlos, separamos los 29 bytes en el valor decodificado para:

  • primer byte: version

  • 28 Bytes restantes: id

Un ejemplo de hacer esto se puede encontrar en el RollupInclusiónProofs.t.sol prueba.

Un ayudante golang que se puede utilizar para hacer esta conversión es el siguiente:

ir

con proofs ser sharesProof.ShareProofs.

namespace

Cuál es el espacio de nombres utilizado por el rollup al enviar datos a Celestia. Como se ha descrito anteriormente, se puede construir de la siguiente manera:

solidez

A través de tomar el namespace valor de la prove_shares respuesta de consulta, decodificándola de base64 a hex, luego:

  • primer byte: version

  • 28 Bytes restantes: id

Un ejemplo se puede encontrar en el RollupInclusiónProofs.t.sol prueba.

Un método para convertir a espacio de nombres, siempre que el tamaño del espacio de nombres sea 29, es el siguiente:

ir

con namespace ser sharesProof.NamespaceID.

rowRoots

Cuáles son las raíces de las filas donde se localizan las acciones que contienen los datos de Rollup.

En golang, la prueba se puede convertir de la siguiente manera:

ir

con roots ser sharesProof.RowProof.RowRoots.

rowProofs

Estas son las pruebas de las filas a la raíz de datos. Son de tipo BinaryMerkleProof:

solidez

Para construirlos, tomamos la respuesta de la prove_shares consulta y realiza el siguiente mapeo:

  • key en la estructura de Solidez == index en la respuesta de la consulta

  • numLeaves en la estructura de Solidez == total en la respuesta de la consulta

  • sideNodes en la estructura de Solidez == aunts en la respuesta de la consulta

El tipo de la sideNodes es a bytes32.

Un ejemplo se puede encontrar en el RollupInclusiónProofs.t.sol prueba.

Un ayudante golang para convertir las pruebas de fila es el siguiente:

ir

con proofs ser sharesProof.RowProof.Proofs.

attestationProof

Esta es la prueba de la raíz de datos a la raíz de tupla de raíz de datos, que se compromete en el contrato de Blobstream X:

solidez

  • tupleRootNonce: el nonce en el que Blobstream X se comprometió con el lote que contiene el bloque que contiene los datos.

  • tuple: el DataRootTuple del bloque:

solidez

que comprende a dataRoot, es decir, el bloque que contiene la raíz de datos de datos de Rollup, y el height que es el height de ese bloque.

  • proof: el BinaryMerkleProof de la tupla raíz de datos a la raíz de tupla raíz de datos. Construirlo es similar a construir las raíces de fila a prueba de raíz de datos en el rowProof sección.

Un ejemplo se puede encontrar en el RollupInclusiónProofs.t.sol prueba.

Un ayudante golang para crear una prueba de certificación:

ir

con el nonce siendo la certificación nonce, que se puede recuperar usando BlobstreamX eventos contractuales. Consulte a continuación un ejemplo. Y height siendo la altura del bloque Celestia que contiene los datos de despliegue, junto con el blockDataRoot siendo la raíz de datos de la altura del bloque. Finalmente, dataRootInclusionProof es la prueba de inclusión de raíz de datos de bloque Celestia a la raíz de tupla de raíz de datos que se consultó al comienzo de esta página.

Si el dataRoot o el tupleRootNonce se desconoce durante la verificación:

  • dataRoot: se puede consultar usando el /block?height=15 consulta (15 en este punto final de ejemplo), y tomando el data_hash campo de la respuesta.

  • tupleRootNonce: se puede volver a intentar consultando el BlobstreamXDataCommitmentStored eventos del contrato de BlobstreamX y buscando el nonce que acredite los datos correspondientes. Un ejemplo:

ir

Escuchar nuevos compromisos de datos

Para escuchar nuevo BlobstreamXDataCommitmentStored eventos, secuenciadores pueden usar el WatchDataCommitmentStored como sigue:

ir

Luego, se pueden crear nuevas pruebas como se documentó anteriormente utilizando los nuevos compromisos de datos contenidos en los eventos recibidos.

Ejemplo de rollup que utiliza el DAVerifier

Un ejemplo de rollup que utiliza el DAVerifier puede ser tan simple como:

solidez

Luego, puede enviar la prueba de fraude usando golang de la siguiente manera:

ir

Para el paso (2), verifique el documentación de pruebas de inclusión de rollup para más información.

Conclusión

Después de crear todas las pruebas y verificarlas:

  1. Verifique la prueba de inclusión de la transacción a la raíz de datos de Celestia

  2. Demuestre que la tupla raíz de datos está comprometida con el contrato inteligente Blobstream X

Podemos estar seguros de que los datos se publicaron en Celestia, y luego las implementaciones pueden continuar con su mecanismo normal de prueba de fraude.

NOTA

Las construcciones de prueba anteriores se implementan en Solidity y pueden requerir diferentes enfoques en otros lenguajes de programación.

Last updated