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

El esquema de compromiso

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
DAVerifier bibliotecaContratos 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
dataEstas 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
shareProofsEsta 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:
beginKeyen la estructura de Solidez ==starten la respuesta de la consultaendKeyen la estructura de Solidez ==enden la respuesta de la consultasideNodesen la estructura de Solidez ==nodesen la respuesta de la consultaEl
NamespaceNode, que es el tipo desideNodes, 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 decodificadomax== los segundos 29 bytes en el valor decodificadodigest== 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:
version28 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
namespaceCuá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:
version28 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
rowRootsCuá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
rowProofsEstas 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:
keyen la estructura de Solidez ==indexen la respuesta de la consultanumLeavesen la estructura de Solidez ==totalen la respuesta de la consultasideNodesen la estructura de Solidez ==auntsen 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
attestationProofEsta 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: elDataRootTupledel 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: elBinaryMerkleProofde 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=15consulta (15en este punto final de ejemplo), y tomando eldata_hashcampo de la respuesta.tupleRootNonce: se puede volver a intentar consultando elBlobstreamXDataCommitmentStoredeventos 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:
Verifique la prueba de inclusión de la transacción a la raíz de datos de Celestia
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