*Reencaminhe o título original：Explorando o sistema de prova e a ponte Canonical Ethereum do Eclipse

Uma visão geral da nossa ponte Canonical

O Eclipse é composto por três camadas:

1. Execução: Uma bifurcação do cliente Solana Labs(v1.17) para execução de transacções SVM
2. Liquidação: A nossa ponte canónica que define a regra de escolha do garfo do Eclipse existe no Ethereum, onde as provas de fraude também serão apresentadas
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 a forma como estes módulos interagem:

O resto deste artigo centrar-se-á na ponte Ethereum do Eclipse, tal como apresentado no diagrama. O Blobstream transmitirá atestados assinados pelo conjunto de validadores do Celestia para certificar ao Ethereum que os dados de um lote de slots do Eclipse foram publicados corretamente. Isto permite que a bridge do Eclipse verifique os dados fornecidos para as provas de fraude em relação às raízes de dados assinados do Celestia. No resto desta secção, descreveremos os processos pelos quais:

1. os fundos são depositados através da nossa ponte,
2. Os blocos de dados dos lotes de blocos do Eclipse são publicados no Celestia,
3. as retiradas através da ponte são tratadas, e
4. as provas de fraude são geradas nos piores cenários.

Deposite através do Ethereum Bridge nativo do Eclipse

O fluxo quando um utilizador deposita no Eclipse através da ponte Ethereum nativa é resumido da seguinte forma:

1. Um utilizador chama o contrato Deposit Bridge do Eclipse no Ethereum
2. A partir do executor SVM do Eclipse [1], o retransmissor [2] observa o endereço de depósito e de destino do utilizador
3. Em seguida, o retransmissor chama o programa de ponte SVM, que é responsável pela transferência do depósito de um utilizador para o endereço de destino aplicável
4. A entidade de ligação verifica a transação de depósito através de um cliente zk-light (a ser implementado)
5. Finalmente, o bloco que contém a transação subsequente de transferência pós-depósito é finalizado e publicado através de um Solana Geyser Plugin

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

Publicar as ranhuras do Eclipse no Celestia como blocos de dados

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

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

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

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

À semelhança de outras L2 que utilizam provas de fraude (Arbitrum, Fuel e muitas outras), os levantamentos da Eclipse requerem um período de contestação durante o qual os verificadores podem apresentar provas de fraude no caso de uma transição de estado inválida:

1. Com uma cadência regular, o executor do SVM coloca um compromisso para uma época (um número predeterminado de lotes) das ranhuras do Eclipse no Ethereum, juntamente com garantias
2. O contrato de ponte do Eclipse efectua algumas verificações básicas para garantir que os dados publicados estão bem formados (descrito na secção Conceção da prova de fraude)
3. Se o lote apresentado passar nestas verificações básicas, existe uma janela predefinida durante a qual os verificadores podem apresentar provas de fraude no caso de o compromisso do lote implicar uma transição de estado inválida
4. Se um verificador lançar uma prova de fraude bem sucedida, ganha a garantia do executor, o lote lançado é rejeitado e o estado canónico do Eclipse L2 é revertido para o último compromisso de lote válido. Neste caso, a direção da Eclipse teria a possibilidade de eleger um novo executor
5. Se o período de contestação terminar sem que a prova de fraude seja bem sucedida, o executor recupera a sua garantia juntamente com uma recompensa
6. Consequentemente, o contrato-ponte Eclipse concluirá agora todas as transações de retirada que foram incluídas no lote finalizado

Conceção à prova de fraude

Nesta última secção, vamos detalhar a conceção do sistema de prova de fraude do Eclipse, inspirado por Anatoly Yakovenko e John Adler. Em geral, para qualquer prova de fraude, um verificador deve:

1. Identifique uma transação que contenha uma transição de estado inválida
2. Forneça as entradas para a referida transação com a transição de estado inválida
3. Demonstre que a reexecução da referida transação com os dados de entrada resulta num resultado que não é igual ao que foi confirmado 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 transacções através de testemunhas Merkle. Para (2), ao contrário dos L2s baseados em EVM, que colocam uma raiz Merkle na árvore de estado global, por razões de desempenho o Eclipse não actualiza uma árvore de estado global numa base transação a transação, mas explicaremos como garantimos a correção das entradas em mais detalhe abaixo. Por último, no caso de (3), o verificador Eclipse gera uma prova zk do(s) resultado(s) para uma determinada transação, ao contrário da abordagem de jogo de verificação interactiva comum nas L2 baseadas em EVM.

Todas as transacções Eclipse podem ser representadas como tendo uma lista de contas de entrada, executando uma transação e produzindo uma lista de contas de saída resultantes:

A observação crítica para a nossa conceção de prova de fraude é que, para a execução da transação, é sempre o caso de qualquer S_InputAccount ter sido a S_OutputAccount de alguma transação anterior. Isto permite-nos referenciar a última transação na cadeia que produziu uma determinada conta de entrada em vez de fornecer uma testemunha Merkle a uma árvore de estado global. Como resultado da nossa conceção, introduzimos tipos adicionais de acusação de fraude, tais como uma referência ao facto de a transação anterior não ser válida ou de a conta de entrada já ter sido "gasta" por uma transação posterior. Descrevemos este processo em mais pormenor abaixo:

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 SVM) que contêm o seguinte:
   1. Contagem de transacções [3]
   2. Localização do espaço de nomes Celestia dos dados da transação
   3. hash da conta [4] para cada entrada, com a contagem de transacções resultante em cada
   4. Lista de sysvars utilizados e valor de cada um, com contagem de transacções resultantes em cada um (se aplicável) [5]
   5. Saída da transação, se a transação tiver sido bem sucedida; caso contrário, um indicador de que a transação falhou (ou 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ção publicados na Celestia têm os seus compromissos transmitidos ao contrato Ethereum. As autorizações consistem em

1. A localização do espaço de nomes Celestia dos dados de transação da última transação incluída no lote
2. A localização no espaço de nomes Celestia dos dados de execução [6] de todas as transacções incluídas
3. Uma lista de depósitos, levantamentos e substituições, cada um dos quais com a contagem de transacções da transação Eclipse associada

Critérios para um lote inválido

Como já foi explicado, há várias formas de detetar a incorreção de um lote:

1. Uma das localizações do espaço de nomes Celestia ligado está malformada ou não aponta para dados do tipo necessário
2. Existe uma transação no Celestia sem dados de execução associados, o que pode dever-se a dois motivos:
   1. A transação, que era suposto 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-ponte Ethereum verifica se a última entrada na lista de dados de execução não corresponde aos dados de transação correctos
   2. Faltam os dados de execução de uma transação diferente
      1. Um verificador lança a localização no espaço de nomes Celestia dos dados de transação da transação infratora e das transacções anteriores e seguintes, pela ordem em que foram executadas com êxito. Em seguida, o contrato de ponte verifica que esta transação foi ignorada
3. Existe uma transação cujos dados de execução estão incorrectos, o que pode ser causado pelo seguinte:
   1. A contagem de transacções associada a um hash de conta ou sysvar não produz o resultado pretendido.
      1. Neste caso, um verificador coloca a localização do espaço de nomes Celestia dos dados de execução para a transação dada com a contagem correspondente e o contrato de ponte verifica se o valor dado está incorreto.
   2. A contagem de transacções associada a um hash de conta ou sysvar está desactualizada
      1. Um verificador coloca a localização no espaço de nomes Celestia dos dados de execução de uma transação mais recente, modificando o valor em questão, e o contrato-ponte verifica se este é efetivamente mais recente.
   3. A saída da transação está incorrecta ou a transação utiliza uma entrada que não está listada:
      1. Neste caso, é necessária uma prova zk da execução correcta da transação ou uma prova zk de que a transação utiliza uma entrada que não está listada. Pode obtê-lo de duas formas:
         1. Um verificador publica a prova, ou
         2. Um verificador coloca o índice da transação que se diz ser fraudulenta, e o contrato da bridge Eclipse usa isto 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 existe um depósito correspondente na lista de transacções (incluída no compromisso de lote lançado no contrato de ponte) para os N lotes anteriores. Em alternativa, existe um depósito na lista de transacções sem qualquer transação de depósito Ethereum relacionada, ou a transação existe mas já foi incluída noutro lote Eclipse
      1. O contrato de bridge em todos estes casos pode determinar que isso aconteceu e considerar esse lote inválido
   5. Existe um depósito ou levantamento executado sem qualquer registo correspondente na lista de transacções
      1. Neste caso, um verificador coloca a localização do espaço de nomes Celestia dos dados de execução fornecidos e o contrato de ponte verifica este facto para julgar a transação como inválida
   6. Existe um depósito ou levantamento na lista de transacções cuja transação Eclipse associada não está a executar a ação esperada ou cuja contagem de transacções não se encontra dentro do seu intervalo de contagem de transacções esperado. Nesse caso, pode acontecer qualquer uma das seguintes situações:
      1. A ponte determinará automaticamente que é esse o caso e recusará o lote correspondente
      2. Um verificador repara na transição de estado inválida e coloca uma prova da transação infratora, que é depois verificada pelo contrato-ponte

Se se verificar que algum lote de compromisso está incorreto, o contrato Eclipse bridge reverterá a ponte para o último lote de compromisso comprovadamente correto. Note que as transacções nunca são removidas da cadeia, mesmo em caso de fraude, pelo que apenas o compromisso tem de 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 o nosso design de prova de fraude. Dada a natureza modular do nosso L2 e a nascência da 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 as nossas instruções aqui. Pode contactar-nos no Twitter ou no Discord com perguntas específicas sobre a nossa Testnet, bridge ou questões técnicas.

Notas de rodapé

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

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

[3]: Repare que é o executor, e não o sequenciador, que lança isto. Se fosse incluída nos dados lançados pelo sequenciador, acrescentaria a complicação de o sequenciador poder saltar uma contagem, impossibilitando o executor de fazer o seu trabalho corretamente. Este facto poderia ser compensado na conceção da prova de fraude, mas acrescentaria uma complexidade suplementar. Uma segunda vantagem de ter apenas o executor a lançar a contagem é que torna mais fácil permitir que as substituições de transacções sejam lançadas no Celestia, se desejado.

[4]: As contas SVM podem ser representadas por um hash único. A única forma de este hash ser modificado é através de uma transação.

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

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

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de [[mirror], Todos os direitos de autor pertencem ao autor original[Eclipse]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.