sequencer example l2

Exemplo de documentação cumulativa

Este repositório contém um exemplo de rollup que se integra ao Espresso Sequencer. O rollup de exemplo representa um armazenamento simples de conta de chave/valor que recebe transações ordenadas do Espresso, executa-as na VM rollup e publica provas de estado simuladas para um contrato inteligente L1 (Ethereum). O rollup contém uma API simples para enviar transações e consultar saldos de contas.

Introdução

O Espresso é baseado no HotShot, uma rede que alcança consenso em lotes de transações rollup. Em alto nível, um rollup é uma solução de escalonamento L1 que executa cálculos caros fora da cadeia. No caso de zkRollups, um provador envia periodicamente pontos de verificação de estado de rollup junto com provas em lote de validade da transação para o L1. O exemplo ilustrado aqui é uma simulação de zkRollup. Para saber mais sobre os rollups Espresso, leia nossos documentos

Executando o exemplo

Pré-requisitos

Certifique-se de que docker esteja instalado em seu sistema.

Para distribuições Linux, siga as instruções oficiais da sua distribuição Linux ou consulte as instruções oficiais do docker.

Executando o rollup de exemplo no sequenciador Espresso

Primeiro precisamos iniciar uma rede local do Espresso Sequencer.

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

Quando terminar, implante o rollup de exemplo, ele poderá ser executado nativamente.

Para executar nativamente, é necessário um conjunto de ferramentas de ferrugem. Fornecemos um shell nix para instalar todas as dependências. Nix pode ser instalado através do instalador nix. Depois de instalado, execute o seguinte na raiz do projeto:

 nix develop
just dev-demo

Interagindo com a demonstração

Depois de executar just dev-demo , você poderá ver new state event após alguns minutos.

1. Alice assina uma transação transferindo tokens rollup para Bob. Alice envia esta transação para o Rollup através do endpoint submit da API rollup. Se Alice estiver preocupada com a censura, ela poderá enviar sua transação diretamente para o sequenciador.
2. O servidor API de rollup encaminha a transação para o sequenciador. A transação é marcada com o ID de namespace exclusivo do rollup para que o rollup possa identificar suas próprias transações na etapa 4.
3. A rede sequenciadora processa a transação, eventualmente incluindo-a em um bloco. Um nó sequenciador submete o novo estado ao contrato Light Client em L1, que verifica se o consenso foi alcançado sobre o novo estado.
4. O serviço executor recebe notificação do novo estado através de uma assinatura de um serviço de consulta fornecido por um nó sequenciador.
5. O executor também escuta os cabeçalhos do novo bloco que foi sequenciado na rede hotshot. Em seguida, ele busca a prova do namespace, o vídeo comum e o hash do bloco.
6. O executor então processa as transações, executando as seguintes etapas:
   • O executor aplica transações ao estado da VM. Antes da aplicação, cada transação é validada e as transações inválidas são descartadas (um rollup real eventualmente incluiria provas de invalidade da transação). No nosso caso, o bloco contém uma única transação de Alice para Bob. Como a transação contém uma assinatura válida e Alice tem saldo suficiente, a transação é aplicada com sucesso e os saldos são atualizados.
   • Após a aplicação da transação, o executor atualiza o estado da VM com o novo compromisso de bloco e o compromisso de estado anterior.
   • O executor calcula um novo compromisso de estado e gera uma prova simulada de que o estado foi atualizado corretamente em relação ao compromisso do bloco HotShot.
7. O executor publica a prova no contrato rollup.
8. O contrato rollup verifica a prova consultando o último compromisso de bloco certificado do contrato do sequenciador. Observação: em nossa implementação atual, não estamos fazendo muitas verificações no contrato. Para fins de produção, o contrato rollup precisará fazer verificações adicionais com o estado do cliente light.
9. Bob consulta seu saldo usando a API de rollup e vê que recebeu alguns novos tokens. Se este fosse um rollup real, um Bob potencialmente desconfiado poderia verificar seu saldo em relação ao compromisso estadual do contrato de rollup (o exemplo atualmente não inclui esse recurso).

Arquitetura cumulativa

Estado de acúmulo

O estado do rollup de exemplo consiste em:

• Contas : um mapeamento de endereços ECDSA (estilo EVM) para saldos de um token fictício.
• Block Hash : Hash do bloco de consenso mais recente.
• Compromisso de estado anterior : um compromisso criptográfico com o estado do rollup antes da etapa de execução mais recente.
• VM : informações sobre a VM cumulativa. No momento, esta é uma identificação simples.

Executor

O executor é um serviço responsável por assinar o novo estado publicado no contrato de cliente light L1, aplicar transações ao estado rollup e enviar provas simuladas para o contrato rollup. Os rollups geralmente separam as funções de executor e provador em dois serviços distintos, mas este exemplo os combina por uma questão de simplicidade.

API de acúmulo

A API rollup é uma API REST que inclui um endpoint submit e query .

Contrato cumulativo

O contrato de rollup armazena o compromisso de estado de rollup mais recente. O contrato atualiza o compromisso estadual quando recebe do executor uma prova válida de transição de estado.

Café expresso

Neste exemplo, usamos alguns componentes do Espresso conforme descrito abaixo. Mais informações podem ser encontradas nos documentos

Cliente leve

O cliente light é um contrato inteligente que verifica a integridade do estado de rollup. O código do contrato pode ser encontrado aqui

Rede Expresso

Executamos uma rede espresso usando as imagens docker do sequenciador espresso. A rede usa o hotshot para chegar a um consenso sobre o estado de rollup. Arquitetura você encontra aqui

Destaque

A Espresso Network usa o HotShot para chegar a um consenso sobre o estado do rollup.