* Reenvíe el título original: Explorando el puente canónico de Ethereum de Eclipse y el sistema de prueba

Una visión general de nuestro puente canónico

Eclipse se compone de tres capas:

1. Ejecución: Una bifurcación del cliente de Solana Labs (v1.17) para la ejecución de transacciones SVM
2. Liquidación: Nuestro puente canónico que define la regla de elección de bifurcación de Eclipse existe en Ethereum, donde también se presentarán pruebas de fraude
3. Disponibilidad de datos: Eclipse publica los datos necesarios para producir pruebas de fraude como blobs de datos en Celestia

El siguiente diagrama ilustra cómo interactúan estos módulos:

El resto de este artículo se centrará en el puente Ethereum de Eclipse, como se muestra en el diagrama. Blobstream transmitirá las certificaciones firmadas por el validador de Celestia para certificar a Ethereum que los datos de un lote de tragamonedas de Eclipse se publicaron correctamente. Esto permite que el puente de Eclipse verifique los datos proporcionados para las pruebas de fraude con las raíces de datos firmadas de Celestia. En el resto de esta sección, describiremos los procesos mediante los cuales:

1. Los fondos se depositan a través de nuestro puente,
2. blobs de datos de lotes de bloques de Eclipse se publican en Celestia,
3. se gestionan los retiros a través del puente, y
4. Las pruebas de fraude se generan en el peor de los casos.

Depositar a través del puente nativo de Ethereum de Eclipse

El flujo cuando un usuario deposita en Eclipse a través del puente nativo de Ethereum se resume de la siguiente manera:

1. Un usuario llama al contrato Deposit Bridge de Eclipse en Ethereum
2. Desde el ejecutor SVM de Eclipse [1], el repetidor [2] observa la dirección de depósito y destino del usuario
3. A continuación, el repetidor llama al programa puente SVM, que es responsable de transferir el depósito de un usuario a la dirección de destino correspondiente
4. El repetidor verifica la transacción de depósito a través de un cliente zk-light (a implementar)
5. Finalmente, el bloque que contiene la transacción de transferencia posterior al depósito se finaliza y se publica a través de un complemento Solana Geyser

El siguiente diagrama muestra las interacciones entre Ethereum, Celestia y el ejecutor de SVM durante el flujo de depósito descrito anteriormente:

Publicación de las ranuras de Eclipse en Celestia como blobs de datos

A continuación se resume el flujo para publicar lotes de ranuras de Eclipse en Celestia como blobs de datos:

1. El ejecutor de SVM publica cada ranura de Eclipse en la cola de mensajes a través de Geyser
2. El ejecutor de SVM publica lotes de ranuras de Eclipse en Celestia como blobs de datos
3. El conjunto de validadores de Celestia produce compromisos con los blobs de datos enviados, que se pueden usar para demostrar la inclusión de una transacción en la cadena de Eclipse contra la raíz de datos
4. Las raíces de datos contenidas en cada encabezado de bloque de Celestia se transmiten al contrato puente de Eclipse en Ethereum a través de Blobstream

El siguiente diagrama de Celestia explica cómo se almacena el compromiso de los datos dentro de un bloque de Celestia determinado en el encabezado del bloque:

Retirar y enviar pruebas de fraude al puente Ethereum de Eclipse

Al igual que otras L2 que utilizan pruebas de fraude (Arbitrum, Fuel y muchas otras), los retiros de Eclipse requieren un período de impugnación durante el cual los verificadores pueden presentar pruebas de fraude en el caso de una transición de estado no válida:

1. Con una cadencia regular, el ejecutor de SVM publica un compromiso con una época (un número predeterminado de lotes) de las ranuras de Eclipse en Ethereum, junto con una garantía
2. El contrato puente de Eclipse lleva a cabo algunas comprobaciones básicas para garantizar que los datos publicados estén bien formados (descritos en la sección Diseño a prueba de fraudes)
3. Si el lote enviado supera estas comprobaciones básicas, hay una ventana predefinida durante la cual los verificadores pueden publicar pruebas de fraude en caso de que el compromiso del lote implique una transición de estado no válida
4. Si un verificador publica una prueba de fraude exitosa, gana la garantía del albacea, el lote publicado se rechaza y el estado canónico de Eclipse L2 se revierte al último compromiso de lote válido. Aquí, el gobierno de Eclipse tendría la capacidad de elegir un nuevo albacea
5. Si transcurre el período de impugnación sin que haya una prueba de fraude exitosa, el albacea recupera su garantía junto con una recompensa
6. En consecuencia, el contrato puente de Eclipse ahora completará cualquier transacción de retiro que se incluyó en el lote finalizado

Diseño a prueba de fraude

En esta sección final, detallaremos el diseño del sistema a prueba de fraude de Eclipse, inspirado en Anatoly Yakovenko y John Adler. Por lo general, para cualquier prueba de fraude, un verificador debe:

1. Identificar una transacción que contiene una transición de estado no válida
2. Proporcione las entradas a dicha transacción con la transición de estado no válida
3. Demostrar que volver a ejecutar dicha transacción con las entradas dadas da como resultado una salida que no es igual a lo que se comprometió en la cadena

En el caso de Eclipse, (1) Celestia merkliza blobs de lotes de bloques que publica el ejecutor de SVM de Eclipse, lo que permite pruebas de inclusión de transacciones a través de testigos de Merkle. Para (2), a diferencia de las L2 basadas en EVM, que publican una raíz de Merkle en el árbol de estado global, por razones de rendimiento, Eclipse no actualiza un árbol de estado global transacción por transacción, pero explicaremos cómo aseguramos la corrección de las entradas con más detalle a continuación. Finalmente, en el caso de (3), el verificador de Eclipse genera una prueba zk de la(s) salida(s) para una transacción determinada, a diferencia del enfoque de juego de verificación interactiva común en las L2 basadas en EVM.

Todas las transacciones de Eclipse se pueden representar como si se tomara una lista de cuentas de entrada, se ejecutara una transacción y se produjera una lista de cuentas de salida resultantes:

La observación crítica para nuestro diseño a prueba de fraude es que para la ejecución de transacciones, siempre se da el caso de que cualquier S_InputAccount debe haber sido el S_OutputAccount de alguna transacción anterior. Esto nos permite hacer referencia a la última transacción de la cadena que produjo una cuenta de entrada determinada en lugar de proporcionar un testigo de Merkle a un árbol de estado global. Como resultado de nuestro diseño, introducimos tipos adicionales de acusaciones de fraude, como una referencia a que la transacción anterior no es válida o que la cuenta de entrada ya está siendo "gastada" por alguna transacción posterior. Describimos este proceso con más detalle a continuación:

Entradas de transacción registradas en Celestia

1. Datos de transacción (contabilizados por el secuenciador)
2. Datos de transacción (registrados por el ejecutor de SVM) que contienen lo siguiente:
   1. Recuento de transacciones [3]
   2. Ubicación del espacio de nombres Celestia de los datos de la transacción
   3. Hash de cuenta [4] para cada entrada, con el recuento de transacciones que da como resultado cada
   4. Lista de sysvars utilizados y valor de cada uno, con el recuento de transacciones que da como resultado cada uno (si corresponde) [5]
   5. Salida de la transacción, si la transacción se realizó correctamente; de lo contrario, un indicador de que la transacción falló (ya sea porque no se pudo analizar o porque no se pudo ejecutar)

Compromisos por lotes publicados en The Ethereum Bridge

Además, los lotes de datos de transacciones publicados en Celestia tienen sus compromisos transmitidos al contrato de Ethereum. Los compromisos consisten en:

1. La ubicación del espacio de nombres Celestia de los datos de transacción de la última transacción incluida en el lote
2. La ubicación del espacio de nombres Celestia de los datos de ejecución [6] de todas las transacciones incluidas
3. Una lista de depósitos, retiros y anulaciones, cada uno de los cuales viene con el recuento de transacciones de la transacción de Eclipse asociada

Criterios para un lote no válido

Como se explicó anteriormente, hay varias formas en que se puede encontrar que un lote es incorrecto:

1. Una de las ubicaciones del espacio de nombres Celestia vinculadas tiene un formato incorrecto o no apunta a datos del tipo requerido
2. Hay una transacción en Celestia sin datos de ejecución asociados, lo que puede deberse a dos razones:
   1. La transacción, que se suponía que era la más reciente del lote, no tiene datos de ejecución asociados.
      1. En tal caso, un verificador verifica que este sea el caso y el contrato puente de Ethereum verifica que la última entrada en la lista de datos de ejecución no se corresponda con los datos correctos de la transacción
   2. Faltan los datos de ejecución de una transacción diferente
      1. Un verificador publica la ubicación del espacio de nombres Celestia de los datos de transacción de la transacción infractora y las transacciones anteriores y posteriores en el orden en que se ejecutó correctamente. A continuación, el contrato puente comprueba que se ha omitido esta transacción
3. Hay una transacción cuyos datos de ejecución son incorrectos, lo que podría deberse a lo siguiente:
   1. El recuento de transacciones asociado a un hash de cuenta o sysvar no produce la salida reclamada.
      1. En este caso, un verificador publica la ubicación del espacio de nombres Celestia de los datos de ejecución de la transacción dada con el recuento correspondiente, y el contrato puente verifica que el valor dado sea incorrecto.
   2. El recuento de transacciones asociado a un hash de cuenta o sysvar está desactualizado
      1. Un verificador publica la ubicación del espacio de nombres Celestia de los datos de ejecución de una transacción más reciente, modificando el valor en cuestión, y el contrato puente comprueba que se trata de una transacción más reciente.
   3. El resultado de la transacción es incorrecto o la transacción utiliza una entrada que no aparece en la lista:
      1. En este caso, se necesita una prueba zk de la ejecución correcta de la transacción o una prueba zk de que la transacción utiliza una entrada que no está en la lista. Esto se puede obtener de dos maneras:
         1. Un verificador publica la prueba, o
         2. Un verificador publica el índice de la transacción que se afirma que es fraudulenta, y el contrato del puente de Eclipse lo utiliza para solicitar una prueba de zk de Bonsai de RISC Zero
   4. Hubo un depósito de Ethereum hace más de N lotes, pero no hay un depósito correspondiente en la lista de transacciones (incluido en el compromiso de lote registrado en el contrato puente) para los N lotes anteriores. Alternativamente, hay un depósito en la lista de transacciones sin ninguna transacción de depósito de Ethereum relacionada, o la transacción existe pero ya se ha incluido en otro lote de Eclipse
      1. En todos estos casos, el contrato puente puede determinar que esto ha sucedido y considerar que dicho lote no es válido
   5. Hay un depósito o retiro ejecutado sin la entrada correspondiente en la lista de transacciones
      1. En tal caso, un verificador publica la ubicación del espacio de nombres Celestia de los datos de ejecución dados y el contrato puente verifica este hecho para juzgar que la transacción no es válida
   6. Hay un depósito o retiro en la lista de transacciones cuya transacción de Eclipse asociada no está realizando la acción esperada o cuyo recuento de transacciones no está dentro de su rango de recuento de transacciones esperado. En tal caso, ocurriría una de las siguientes situaciones:
      1. El puente determinaría automáticamente que este es el caso y rechazaría el lote correspondiente
      2. Un verificador se da cuenta de la transición de estado no válida y publica una prueba de la transacción infractora, que luego se verifica mediante el contrato puente

Si se determina que algún lote de compromiso es incorrecto, el contrato de puente de Eclipse revertirá el puente al del último compromiso de lote demostrablemente correcto. Tenga en cuenta que las transacciones nunca se eliminan de la cadena, incluso en caso de fraude, por lo que solo es necesario volver a calcular el compromiso.

Pensamientos de despedida

Este artículo tenía como objetivo brindar una guía de alto nivel sobre el puente de confianza minimizada de Eclipse en Ethereum y explicar algunos detalles sobre nuestro diseño a prueba de fraude. Dada la naturaleza modular de nuestra L2 y la incipiente de nuestra pila tecnológica, continuaremos publicando artículos y documentación sobre varios aspectos de Eclipse en las próximas semanas.

Para participar en Eclipse Testnet, siga nuestras instrucciones aquí. Puede ponerse en contacto con nosotros en Twitter o Discord con consultas específicas sobre nuestra red de pruebas, puente o preguntas técnicas.

Notas

[1]: El nodo que calcula los resultados de las transacciones de SVM y aplica la salida final al nuevo estado de Eclipse

[2]: Un operador que pasa eventos on-chain entre Ethereum y Eclipse

[3]: Tenga en cuenta que el ejecutor, no el secuenciador, publica esto. Si se incluyera en los datos publicados por el secuenciador, agregaría la complicación de que el secuenciador podría omitir un recuento, lo que haría imposible que el ejecutor hiciera su trabajo correctamente. Esto podría compensarse con el diseño a prueba de fraude, pero añadiría complejidad adicional. Una segunda ventaja de que solo el ejecutor publique el recuento es que facilita permitir que las anulaciones de transacciones se registren en Celestia, si se desea.

[4]: Las cuentas SVM se pueden representar con un hash único. La única forma en que se modifica este hash es a través de una transacción.

[5]: Para hacer esto sin una cantidad excesiva de hashing, ejecutaremos un seguimiento en cada programa ejecutado para ver a qué partes de cada sysvar utilizado se accede realmente. Esto es posible, pero requerirá modificar el intérprete BPF de Solana.

[6]: Esto incluye los datos de las transacciones intentadas que no se ejecutaron.

Renuncia:

1. Este artículo es una reimpresión de [[mirror], Todos los derechos de autor pertenecen al autor original [Eclipse]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.