*Encaminhar o título original：Explorando o sistema de prova e a ponte canônica Ethereum do Eclipse

Uma visão geral da nossa ponte Canonical

O Eclipse é composto de três camadas:

1. Execução: Uma bifurcação do cliente Solana Labs(v1.17) para execução de transações SVM
2. Liquidação: Nossa ponte canônica que define a regra de fork-choice do Eclipse existe no Ethereum, onde as provas de fraude também serão enviadas
3. Disponibilidade de dados: O Eclipse publica os dados necessários para produzir provas de fraude como blobs de dados no Celestia

O diagrama abaixo ilustra como esses módulos interagem:

O restante deste artigo se concentrará na ponte Ethereum do Eclipse, conforme mostrado no diagrama. O Blobstream retransmitirá atestados assinados pelo conjunto de validadores da Celestia para certificar a Ethereum de que os dados de um lote de slots do Eclipse foram publicados corretamente. Isso permite que a ponte do Eclipse verifique os dados fornecidos para provas de fraude em relação às raízes de dados assinados da Celestia. No restante desta seção, descreveremos os processos pelos quais:

1. os fundos são depositados por meio de nossa ponte,
2. blobs de dados de lotes de blocos do Eclipse são postados no Celestia,
3. as retiradas por meio da ponte são tratadas, e
4. As provas de fraude são geradas nos piores cenários.

Depósito por meio do Ethereum Bridge nativo do Eclipse

O fluxo quando um usuário deposita no Eclipse por meio da ponte Ethereum nativa é resumido da seguinte forma:

1. Um usuário chama o contrato Deposit Bridge do Eclipse no Ethereum
2. A partir do executor SVM do Eclipse [1], o relayer [2] observa o endereço de depósito e de destino do usuário
3. Em seguida, o relayer chama o programa de ponte SVM, que é responsável por transferir o depósito de um usuário para o endereço de destino aplicável
4. O relayer verifica a transação de depósito por meio de um cliente zk-light (a ser implementado)
5. Por fim, o bloco que contém a transação subsequente de transferência pós-depósito é finalizado e publicado por meio de um plug-inSolana Geyser

O diagrama abaixo mostra as interações entre a Ethereum, a Celestia e o SVM Executor durante o fluxo de depósito descrito acima:

Publicando os slots do Eclipse no Celestia como data blobs

O fluxo para publicar lotes de slots do Eclipse no Celestia como blobs de dados está resumido abaixo:

1. O executor do SVM publica cada slot do Eclipse na fila de mensagens por meio do Geyser
2. O executor do SVM envia lotes de slots do Eclipse para o Celestia como blobs de dados
3. O conjunto de validadores do Celestia produz compromissos com os blobs de dados enviados, que podem ser usados para provar a inclusão de uma transação na cadeia do Eclipse em relação à raiz dos dados
4. As raízes de dados contidas em cada cabeçalho de bloco do Celestia são retransmitidas para o contrato de ponte do Eclipse no Ethereum via Blobstream

O diagrama abaixo, da Celestia, explica como o compromisso dos dados em um determinado bloco da Celestia é armazenado no cabeçalho do bloco:

Retirada e envio de provas de fraude para o Ethereum Bridge da Eclipse

Da mesma forma que outras L2s que usam provas de fraude (Arbitrum, Fuel e muitas outras), as retiradas do Eclipse exigem um período de desafio durante o qual os verificadores podem enviar provas de fraude no caso de uma transição de estado inválida:

1. Em uma cadência regular, o executor do SVM publica um compromisso com uma época (um número predeterminado de lotes) dos slots do Eclipse para a Ethereum, juntamente com garantias
2. O contrato de ponte do Eclipse realiza algumas verificações básicas para garantir que os dados postados estejam bem formados (descrito na seção Design de prova de fraude)
3. Se o lote enviado for aprovado nessas verificações básicas, há uma janela predefinida durante a qual os verificadores podem postar provas de fraude caso o compromisso do lote implique uma transição de estado inválida
4. Se um verificador postar uma prova de fraude bem-sucedida, ele ganha a garantia do executor, o lote postado é rejeitado e o estado canônico do Eclipse L2 é revertido para o último compromisso de lote válido. Aqui, a governança da Eclipse teria a capacidade de eleger um novo executor
5. Se o período de desafio passar sem que a prova de fraude seja bem-sucedida, o executor recupera sua garantia junto com uma recompensa
6. Consequentemente, o contrato-ponte do Eclipse agora concluirá todas as transações de retirada que foram incluídas no lote finalizado

Projeto à prova de fraude

Nesta última seção, detalharemos o projeto do sistema de prova de fraude do Eclipse, inspirado por Anatoly Yakovenko e John Adler. Em geral, para qualquer prova de fraude, o verificador deve:

1. Identificar uma transação que contenha uma transição de estado inválida
2. Fornecer as entradas para essa transação com a transição de estado inválida
3. Demonstrar que a reexecução da referida transação com as entradas fornecidas resulta em um resultado que não é igual ao que foi comprometido na cadeia

No caso do Eclipse, (1) o Celestia merkliza blobs de lotes de blocos que o executor SVM do Eclipse lança, permitindo provas de inclusão de transações por meio de testemunhas Merkle. Para (2), ao contrário dos L2s baseados em EVM, que postam uma raiz Merkle na árvore de estado global, por motivos de desempenho o Eclipse não atualiza uma árvore de estado global em uma base de transação por transação, mas explicaremos como garantimos a correção das entradas em mais detalhes abaixo. Por fim, no caso de (3), o verificador do Eclipse gera uma prova zk da(s) saída(s) para uma determinada transação, diferentemente da abordagem de jogo de verificação interativa comum nos L2s baseados em EVM.

Todas as transações do Eclipse podem ser representadas como a obtenção de uma lista de contas de entrada, a execução de uma transação e a produção de uma lista de contas de saída resultantes:

A observação fundamental para o nosso projeto de prova de fraude é que, para a execução da transação, é sempre o caso de que qualquer S_InputAccount deve ter sido a S_OutputAccount de alguma transação anterior. Isso nos permite fazer referência à última transação na cadeia que produziu uma determinada conta de entrada em vez de fornecer uma testemunha Merkle para uma árvore de estado global. Como resultado de nosso projeto, introduzimos tipos adicionais de acusação de fraude, como uma referência à transação anterior não ser válida ou a conta de entrada já ter sido "gasta" por alguma transação posterior. Descrevemos esse processo em mais detalhes a seguir:

Entradas de transação lançadas na Celestia

1. Dados de transação (lançados pelo sequenciador)
2. Dados de transação (lançados pelo executor do SVM) que contêm o seguinte:
   1. Contagem de transações [3].
   2. Localização do namespace Celestia dos dados da transação
   3. Hash da conta [4] para cada entrada, com a contagem de transações resultante em cada
   4. Lista de sysvars usados e o valor de cada um, com a contagem de transações resultante em cada um (se aplicável) [5]
   5. Saída da transação, se a transação foi bem-sucedida; caso contrário, um indicador de que a transação falhou (seja porque não conseguiu analisar ou porque não conseguiu executar)

Compromissos de lote publicados na ponte Ethereum

Além disso, os lotes de dados de transações postados na Celestia têm seus compromissos retransmitidos para o contrato da Ethereum. Os compromissos consistem em:

1. O local do namespace Celestia dos dados de transação da última transação incluída no lote
2. O local do namespace do Celestia dos dados de execução [6] de todas as transações incluídas
3. Uma lista de depósitos, retiradas e substituições, cada uma das quais vem com a contagem de transações da transação Eclipse associada

Critérios para um lote inválido

Conforme explicado acima, há várias maneiras de se descobrir que um lote está incorreto:

1. Um dos locais do namespace do Celestia vinculado está malformado ou não aponta para dados do tipo necessário
2. Há uma transação no Celestia sem dados de execução associados, o que pode ser devido a dois motivos:
   1. A transação, que deveria ser a mais recente do lote, não tem dados de execução associados.
      1. Nesse caso, um verificador verifica se esse é o caso e o contrato de ponte Ethereum verifica se a última entrada na lista de dados de execução não corresponde aos dados de transação corretos
   2. Os dados de execução de uma transação diferente estão faltando
      1. Um verificador publica o local do namespace Celestia dos dados de transação da transação infratora e das transações anteriores e seguintes na ordem em que foram executadas com sucesso. Depois disso, o contrato de ponte verifica se essa transação foi ignorada
3. Há uma transação cujos dados de execução estão incorretos, o que pode ser causado pelo seguinte:
   1. A contagem de transações associada a um hash de conta ou sysvar não produz a saída solicitada.
      1. Nesse caso, um verificador publica o local do namespace do Celestia dos dados de execução da transação em questão com a contagem correspondente, e o contrato de ponte verifica se o valor fornecido está incorreto.
   2. A contagem de transações associada a um hash de conta ou sysvar está desatualizada
      1. Um verificador publica o local do namespace do Celestia dos dados de execução de uma transação mais recente, modificando o valor em questão, e o contrato de ponte verifica se isso é realmente mais recente.
   3. A saída da transação está incorreta ou a transação usa uma entrada que não está listada:
      1. Nesse caso, é necessária uma prova zk da execução correta da transação ou uma prova zk de que a transação usa uma entrada que não está listada. Isso pode ser obtido de duas maneiras:
         1. Um verificador publica a prova, ou
         2. Um verificador publica o índice da transação considerada fraudulenta, e o contrato da ponte Eclipse usa isso para solicitar uma prova zk do Bonsai do RISC Zero
   4. Houve um depósito da Ethereum há mais de N lotes, mas não há nenhum depósito correspondente na lista de transações (incluída no compromisso de lote lançado no contrato de ponte) para os N lotes anteriores. Como alternativa, há um depósito na lista de transações sem nenhuma transação de depósito de Ethereum relacionada, ou a transação existe, mas já foi incluída em outro lote do Eclipse
      1. Em todos esses casos, o contrato de bridge pode determinar que isso aconteceu e considerar esse lote inválido
   5. Há um depósito ou saque executado sem uma entrada correspondente na lista de transações
      1. Nesse caso, um verificador publica o local do namespace Celestia dos dados de execução fornecidos e o contrato de ponte verifica esse fato para julgar a transação como inválida
   6. Há um depósito ou retirada na lista de transações cuja transação Eclipse associada não está executando a ação esperada ou cuja contagem de transações não está dentro do intervalo de contagem de transações esperado. Nesse caso, aconteceria uma das seguintes situações:
      1. A ponte determinaria automaticamente que esse é o caso e recusaria o lote correspondente
      2. Um verificador percebe a transição de estado inválida e publica a prova da transação ofensiva, que é então verificada pelo contrato de ponte

Se algum lote de compromisso for considerado incorreto, o contrato de ponte do Eclipse reverterá a ponte para o último lote de compromisso comprovadamente correto. Observe que as transações nunca são removidas da cadeia, mesmo em caso de fraude, portanto, somente o compromisso precisa ser recalculado.

Pensamentos de despedida

Este artigo tem como objetivo fornecer um guia de alto nível para a ponte de confiança minimizada do Eclipse no Ethereum e explicar alguns detalhes sobre nosso projeto de prova de fraude. Dada a natureza modular do nosso L2 e o início de nossa pilha de tecnologia, continuaremos a lançar artigos e documentação sobre vários aspectos do Eclipse nas próximas semanas.

Para se envolver com o Eclipse Testnet, siga nossas instruções aqui. O senhor pode entrar em contato conosco pelo Twitter ou pelo Discord com perguntas específicas sobre a Testnet, bridge ou questões técnicas.

Notas de rodapé

[1]: O nó que calcula os resultados das transações SVM e aplica o resultado final ao novo estado do Eclipse

[2]: Um operador que passa eventos na cadeia entre o Ethereum e o Eclipse

[3]: Observe que o executor, e não o sequenciador, publica isso. Se fosse incluído nos dados postados pelo sequenciador, isso acrescentaria a complicação de que o sequenciador poderia ignorar uma contagem, impossibilitando que o executor fizesse seu trabalho corretamente. Isso poderia ser compensado no projeto à prova de fraude, mas isso acrescentaria uma complexidade extra. Uma segunda vantagem de fazer com que apenas o executor publique a contagem é que isso facilita permitir que as substituições de transações sejam publicadas no Celestia, se desejado.

[4]: As contas SVM podem ser representadas por um hash exclusivo. A única maneira de modificar esse hash é por meio de uma transação.

[5]: Para fazer isso sem uma quantidade excessiva de hashing, executaremos um rastreamento em cada programa executado para ver quais partes de cada sysvar usado são realmente acessadas. Isso é possível, mas exigirá a modificação do interpretador BPF do Solana.

[6]: Inclui dados de tentativas de transações que não foram executadas.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [[mirror], Todos os direitos autorais pertencem ao autor original[Eclipse]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.