sequencer example l2

Ejemplo de documentación acumulada

Este repositorio contiene un resumen de ejemplo que se integra con Espresso Sequencer. El paquete acumulativo de ejemplo representa un almacén de cuentas clave/valor simple que recibe transacciones ordenadas de Espresso, las ejecuta en la máquina virtual acumulada y publica pruebas de estado simuladas en un contrato inteligente L1 (Ethereum). El paquete acumulativo contiene una API simple para enviar transacciones y consultar saldos de cuentas.

Introducción

Espresso se basa en HotShot, una red que logra consenso sobre lotes de transacciones acumuladas. En un nivel alto, un rollup es una solución de escalamiento L1 que realiza cálculos costosos fuera de la cadena. En el caso de zkRollups, un proveedor envía periódicamente puntos de control del estado acumulativo junto con pruebas por lotes de la validez de la transacción a la L1. El ejemplo ilustrado aquí es un zkRollup simulado. Para obtener más información sobre los paquetes acumulativos de Espresso, lea nuestros documentos.

Ejecutando el ejemplo

Requisitos previos

Asegúrese de que docker esté instalado en su sistema.

Para distribuciones de Linux, siga las instrucciones oficiales de su distribución de Linux o consulte las instrucciones oficiales de Docker.

Ejecución del resumen de ejemplo en el secuenciador Espresso

Primero necesitamos iniciar una red local de Espresso Sequencer.

 git clone https://github.com/EspressoSystems/espresso-sequencer
cd espresso-sequencer
docker compose pull
docker compose up -d --wait

Una vez que haya terminado, implemente el paquete acumulativo de ejemplo, se puede ejecutar de forma nativa.

Para ejecutarlo de forma nativa, se requiere una cadena de herramientas de óxido. Proporcionamos un shell nix para instalar todas las dependencias. Nix se puede instalar a través del instalador nix. Una vez instalado ejecute lo siguiente desde la raíz del proyecto:

 nix develop
just dev-demo

Interactuando con la demostración

Después de ejecutar just dev-demo , podrá ver new state event después de unos minutos.

1. Alice firma una transacción transfiriendo tokens acumulados a Bob. Alice envía esta transacción al paquete acumulativo a través del punto final submit de la API del paquete acumulativo. Si a Alice le preocupa la censura, puede enviar su transacción directamente al secuenciador.
2. El servidor API acumulativo reenvía la transacción al secuenciador. La transacción se etiqueta con el ID de espacio de nombres único del paquete acumulativo para que el paquete pueda identificar sus propias transacciones en el paso 4.
3. La red secuenciadora procesa la transacción y finalmente la incluye en un bloque. Un nodo secuenciador envía el nuevo estado al contrato Light Client en L1, que verifica que se haya alcanzado un consenso sobre el nuevo estado.
4. El servicio ejecutor recibe una notificación del nuevo estado mediante una suscripción a un servicio de consulta proporcionado por un nodo secuenciador.
5. El ejecutor también escucha los encabezados del nuevo bloque que fue secuenciado en la red hotshot. Luego recupera la prueba del espacio de nombres, el vid común y el hash del bloque.
6. Luego, el ejecutor procesa las transacciones, realizando los siguientes pasos:
   • El ejecutor aplica transacciones al estado de VM. Antes de la aplicación, se valida cada transacción y se descartan las transacciones inválidas (un resumen real eventualmente incluiría pruebas de invalidez de la transacción). En nuestro caso, el bloque contiene una única transacción de Alice a Bob. Dado que la transacción contiene una firma válida y Alice tiene saldo suficiente, la transacción se aplica correctamente y los saldos se actualizan.
   • Después de la aplicación de la transacción, el ejecutor actualiza el estado de la VM con el compromiso del nuevo bloque y el compromiso del estado anterior.
   • El ejecutor calcula un nuevo compromiso de estado y genera una prueba simulada de que el estado se actualizó correctamente con respecto al compromiso del bloque HotShot.
7. El ejecutor publica la prueba en el contrato acumulativo.
8. El contrato acumulativo verifica la prueba consultando el último compromiso de bloque certificado del contrato de secuenciador. Nota: En nuestra implementación actual, no estamos haciendo mucha verificación en el contrato. Para fines de producción, el contrato acumulativo deberá realizar verificaciones adicionales con el estado del cliente ligero.
9. Bob consulta su saldo mediante la API acumulada y ve que ha recibido algunos tokens nuevos. Si se tratara de un resumen real, un Bob potencialmente desconfiado podría verificar su saldo con el compromiso de estado del contrato acumulativo (el ejemplo actualmente no incluye esta característica).

Arquitectura acumulada

Estado de resumen

El estado del paquete acumulativo de ejemplo consta de:

• Cuentas : una asignación de direcciones ECDSA (estilo EVM) a saldos de un token ficticio.
• Block Hash : Hash del bloque de consenso más reciente.
• Compromiso de estado anterior : un compromiso criptográfico con el estado del paquete acumulativo antes del paso de ejecución más reciente.
• VM : información sobre la máquina virtual acumulada. En este momento, esta es una identificación simple.

Ejecutor

El ejecutor es un servicio responsable de suscribirse al nuevo estado publicado en el contrato del cliente ligero L1, aplicar transacciones al estado acumulativo y presentar pruebas simuladas al contrato acumulativo. Los paquetes acumulativos a menudo separan las funciones de ejecutor y probador en dos servicios distintos, pero este ejemplo los combina en aras de la simplicidad.

API acumulativa

La API acumulativa es una API REST que incluye un punto final submit y query .

Contrato acumulativo

El contrato acumulativo almacena el compromiso de estado acumulativo más reciente. El contrato actualiza el compromiso estatal cuando recibe del ejecutor una prueba válida de transición estatal.

Café exprés

En este ejemplo, utilizamos algunos componentes de Espresso como se describe a continuación. Puede encontrar más información en los documentos.

Cliente ligero

El cliente ligero es un contrato inteligente que verifica la integridad del estado acumulativo. El código del contrato se puede encontrar aquí.

Red de café expreso

Ejecutamos una red de espresso utilizando las imágenes acoplables del secuenciador de espresso. La red utiliza hotshot para lograr un consenso sobre el estado del resumen. La arquitectura se puede encontrar aquí.

Hotshot

Espresso Network utiliza HotShot para lograr un consenso sobre el estado del resumen.