Interpretando todo o processo de implementação da transação L2: qual é o desempenho de segurança de cada etapa?

Autor: Nic@ imToken Labs

Quando posso ter certeza de que uma transação L2 será incluída em um bloco? Quando posso ter certeza de que a receita de uma transação L2 não será descartada por causa da Re-org?

Este artigo apresentará todo o processo de implementação da transação L2 e analisará o desempenho de segurança de cada etapa do processo de transação.

Pré-requisitos:

• Todo o processo de transações L1 (Camada 1)
• Causas e efeitos de Re-org
• Entender o papel atual do Ethereum na arquitetura PBS e como ele funciona
• Entender as diferenças entre Rollups Otimistas e Rollups de Validade (ZK)

Saiba mais sobre as transações L1

PROCESSO DE TRANSAÇÃO

Diagrama do fluxo de transações L1

A reorganização ainda é possível após o Bloco de receitas da transação, e é necessário esperar até que a reorganização não ocorra para ter certeza de que a transação foi finalizada.

A probabilidade e o custo da Re-org variarão dependendo do Algoritmo de Consenso de uma cadeia e da Capitalização de Mercado do ativo, e o cálculo do custo da Re-org não será introduzido aqui.

Saiba mais sobre as transações L2

PROCESSO DE TRANSAÇÃO

Depois que o usuário L2 gera e assina a transação, ela geralmente é enviada diretamente para o Sequencer responsável por classificar a transação, e o Sequencer coleta sua transação no Bloco L2. Em seguida, quando o Sequencer grava dados do Bloco L2 de volta para L1 através de uma transação L1, o usuário pode ver que sua transação está incluída no Bloco L2 mais recente.

No entanto, deve-se notar que, como os dados do Bloco L2 são carregados para L1 através de transações L1, ainda é possível encontrar uma situação em que o L1 Re-org ocorre, resultando no Bloco L2 não sendo escrito no histórico do Blockchain no final, ou seja, equivalente ao L2 Re-org, então o usuário ainda tem que esperar que a probabilidade de L1 Re-org seja baixa o suficiente para ter certeza de que sua transação será escrita no histórico do Blockchain.

Diagrama do fluxo de transações L2

O usuário primeiro espera que a transação seja incluída no Bloco L2, depois espera que o Bloco L2 seja carregado para L1 através de uma transação L1 e, finalmente, espera que a transação L1 seja finalizada.

Embora em comparação com as transações L1, as transações L2 têm um período adicional de tempo para esperar que as transações L2 sejam incluídas nos blocos L2 pelo Sequencer, mas na verdade, quando o tamanho do bloco L2 é grande o suficiente e a velocidade de produção do bloco é rápida o suficiente, esse tempo de espera não levará muito tempo, porque o tempo de espera gastará principalmente as transações L1 no reconhecimento da receita, portanto, no geral, a experiência das transações L1 e L2 é semelhante.

Mas se o usuário estiver disposto a fazer alguns sacrifícios, isso pode ser trocado por uma experiência melhor?

Pré-Confirmação/Confirmação Rápida/Confirmação Suave

O usuário deve ver o Bloco L2 (contendo transações L2) sendo incluído no Bloco L1, e até mesmo esperar até que a probabilidade de ocorrência de Re-org seja baixa o suficiente para acreditar que sua transação L2 foi ganha.

Mas e se o usuário estiver disposto a confiar no Sequencer? Talvez o Sequencer seja executado pela equipe de desenvolvimento L2, executado por uma organização respeitável, e se o Sequencer garantir ao usuário que sua transação será paga imediatamente, no Xth Block, então essa garantia é suficiente para o usuário que está disposto a confiar no Sequencer. Assim como se um usuário confia na Carteira que está usando, ele não irá suspeitamente ao Etherscan para verificar novamente depois que a Carteira o alertou de que a transação foi paga.

A Garantia de Rendimento da Transação fornecida por este Sequenciador é chamada de Pré-Confirmação, Confirmação Rápida ou Confirmação Suave, que pode ser entendida como uma garantia de receita de transação “antecipada” ou “suave”. Não precisa esperar que as transações L2 sejam incluídas no bloco L1, mas é apenas uma promessa verbal dada pelo Sequencer, e o Sequencer pode esquecer a promessa original devido a bugs ou o Sequencer malicioso violará diretamente a promessa, o que pode desperdiçar tempo do usuário ou ser “Double Spend Attack”.

Em seguida, veremos algumas das diferentes maneiras pelas quais o status de receita das transações L2 é apresentado.

Status da receita de transação do Arbitrum/Optimism

Atualmente, os usuários que enviam uma transação no Arbitrum ou Optimism podem quase imediatamente obter um recibo de transação, que será o resultado da execução da transação. Isso significa que o Sequencer já sequenciou e simulou a execução das transações localmente, e esse recibo da transação é a pré-confirmação para o usuário.

Para saber mais sobre o Arbitrum, uma descrição mais detalhada do ciclo de vida da transação pode ser copiada para o seguinte link para o documento oficial de referência do navegador:

Para uma introdução mais detalhada ao ciclo de vida das transações do Optimism, copie o seguinte link para o documento oficial de referência do navegador:

Verifique o status da receita da transação no Arbitrum

As transações que você vê no Arbitrum Explorer conterão transações de Pré-Confirmação, ou seja, transações que ainda não foram carregadas para L1, como mostrado na figura a seguir, você pode ver que há um indicador Confirmado pelo Sequencer ao lado do Número do Bloco 145353000:

A imagem acima mostra transações que só foram confirmadas pelo Sequencer, mas ainda não foram carregadas para L1

Se a transação foi carregada para L1 como mostrado na figura abaixo, seu status mudou para 69 Confirmações de Bloco L1, o que significa que ela foi carregada para L1 e contém os dados da transação Bloco e há 69 Bloco atrás dele:

O Bloco L1 que contém esses dados de transação já tem 69 Blocos por trás, e quanto mais Blocos o seguirem, mais seguro ele será.

Ou a transação mostrada na imagem abaixo, o Bloco L1 contendo esses dados de transação tem 6174 Blocos por trás, o que já é muito seguro.

Mas o que pode ser feito melhor aqui é combinar as informações de finalidade L1.

Simplesmente dizer ao usuário quantas Confirmações de Bloco L1 existem é uma ajuda limitada para o usuário, porque o usuário tem que entender e calcular o nível de segurança representado por esse número de Confirmações de Bloco. E como a Camada 1 (ou seja, Ethereum) já tem um mecanismo de finalidade como o Casper FFG, o Explorer pode realmente mostrar diretamente se o Bloco da Camada 1 está atualmente finalizado na Camada 1. Atualmente, o Optimism’s Explorer implementou esse recurso.

Verifique o status dos ganhos da transação no otimismo

As transações que vemos no Optimism Explorer também incluirão transações de Pré-Confirmação, ou seja, transações que ainda não foram carregadas para L1, como mostrado na figura a seguir, podemos ver que há um símbolo Confirmado pelo Sequenciador ao lado do Número do Bloco 111526300:

Transações que só foram confirmadas pelo Sequencer, mas ainda não foram carregadas para L1

No entanto, o Explorer não parece ter uma especificação clara do que significa Confirmado pelo Sequencer, dizendo “As confirmações do Sequencer são equivalentes a algumas confirmações de bloco em L1.”, indicando que Confirmado pelo Sequencer representa um número de Block que foram carregados para L1 e foram seguidos por vários:

Mas, na verdade, a transação mais recente também é mostrada como Confirmada pelo Sequencer, e mesmo dezenas de dias atrás, o status da transação que passou do período de desafio ainda é Confirmado pelo Sequencer:

Dezenas de dias atrás, o status da transação ainda estava preso em “Confirmado pelo Sequencer”

Dica de leitura: A situação acima também pode ser que o explorador marque estados diferentes em lugares diferentes: o Confirmado pelo Sequenciador após o Número do Bloco diz ao usuário que o Bloco foi confirmado pelo Sequenciador, e o usuário tem que confirmar o estado após o upload para L1 através de outras informações, como as informações do “Lote de Estado L1” mencionadas abaixo.

Além disso, a transação que foi carregada para L1 como mostrado na captura de tela abaixo tem duas informações adicionais: “L1 State Batch Index” e “L1 State Root Submission Tx Hash”. Estas duas informações representam o Lote de Estado no qual a transação L2 foi incluída e a transação L1 através da qual o Lote de Estado foi carregado para L1:

Clique no Lote de Estado “3480”, você pode ver que seu estado é Finalizado, o que corresponde ao estado Finalizado de L1 (ou seja, o Ethereum Mainnet), que é um estado muito seguro que acumulou com sucesso os votos de dois validadores Epoch.

△ O Lote Estadual 3480 foi adquirido no Bloco 18457449 L1 e o Bloco 18457449 foi finalizado.

Fonte:

Se o lote tiver sido carregado, mas não tiver sido finalizado em L1, ele será exibido como Não finalizado:

Embora o Lote 3494 do Estado tenha sido carregado para L1, o bloco L1 incluído no lote ainda não foi finalizado.

Em comparação com o Arbitrum Explorer, o Optimism Explorer fornece mais informações (State Batch) para transações e irá encadear diretamente as informações de Finalidade L1 para o L2 Explorer, para que o usuário possa saber diretamente se o Bloco L1 foi finalizado, em vez de julgar o grau de segurança correspondente ao número de Confirmações de Bloco.

Status dos Ganhos de Negociação da StarkNet

Atualmente, depois que o usuário envia uma transação na StarkNet, embora o recebimento da transação possa ser consultado rapidamente, o status da transação exibido no recibo geralmente estará no estado RECEBIDO, o que significa que o Nó recebeu a transação e não há nenhum problema após a transação ser verificada, e aguardará que a transação seja recebida pelo Sequencer L2 Block e executada, enquanto a transação no estado RECEBIDO não terá nenhum resultado de execução da transação. Os usuários podem verificar o progresso de suas transações através do status da transação exibido no StarkNet Explorer.

Dica de leitura: Se o Sequencer processar rápido o suficiente, é possível pular o estado RECEBIDO e ir para o estado onde a transação já foi processada. Para uma introdução mais detalhada ao processo de negociação da StarkNet, você pode copiar o link abaixo para visualizar os documentos oficiais em seu navegador.

Documentos Oficiais: _and_concepts/Network_Architecture/transaction-life-cycle/

As transações vistas no Starkscan, o StarkNet Explorer, também incluirão transações de Pré-Confirmação, como mostrado na figura a seguir, você pode ver que o Status é atualmente Aceito em L2, o que significa que ele foi classificado no Bloco L2 pelo Sequencer:

“Aceito em L2” significa que ele foi colocado em um bloco L2 pelo Sequencer, mas ainda não foi carregado para L1

Os dois primeiros estados de Aceito em L2 são Recebido e Pendente, o que significa que “a transação foi recebida e verificada” e “a transação está sendo processada pelo Sequencer”, e a transação entrará no estado de Aceito em L2 após a transação ser executada:

A transação é recebida e verificada

A transação está sendo processada pelo Sequencer

Depois que os dados da transação forem carregados para L1, o status mudará para Aceito em L1, conforme mostrado na figura a seguir:

Os dados transacionais foram carregados para L1

Embora as transações da StarkNet tenham um estado mais rico que permite aos usuários saber o progresso da transação, pode levar quatro ou cinco horas para que a transação seja carregada para L1 (provavelmente porque leva muito tempo para gerar a Prova de Conhecimento Zero), então os usuários durante esse tempo confiam na pré-confirmação do Sequencer.

Além disso, o Explorer só exibe Aceito em L1 para transações carregadas em L1, e não tem as informações de Finalidade ou Confirmação de Bloco com L1, o que significa que os usuários têm que verificar se há Bloco suficiente no Bloco L1 ou se eles foram finalizados.

No geral, devido ao gargalo de desempenho da própria StarkNet, os usuários precisam confiar na Pré-Confirmação por um longo tempo, e o Explorer não suporta informações de finalidade L1, resultando em uma experiência ruim de reconhecimento de receita de transação StarkNet, que é onde a StarkNet precisa ser melhorada no futuro.

Estado da Receita da Transação do zkSync

Semelhante ao StakrNet, zkSync também tem um estado PENDENTE, o que significa que o Node recebeu a transação e a transação foi verificada sem problemas, ele aguardará que a transação seja Bloqueada e executada pelo Sequencer L2, enquanto a transação no estado PENDENTE não terá nenhum resultado de execução da transação.

Os usuários podem saber o progresso de suas transações através do status da transação exibido no zkSync Explorer.

Dica de leitura: Se o Sequencer processar rápido o suficiente, é possível pular o estado PENDING e ir para o estado onde a transação já foi processada.

Para uma introdução mais detalhada ao processo de transação do zkSync, você pode copiar o seguinte link para visualizá-lo em seu navegador:

As transações que você vê no zkSync Explorer também incluirão as transações de Pré-Confirmação, como a da captura de tela abaixo, você pode ver que o Status é atualmente zkSync Era Processed, o que significa que ele foi classificado no Bloco L2 pelo Sequencer:

Esta transação foi colocada no bloco L2 pelo Sequencer e está atualmente esperando para ser carregada para L1 (Ethereum Sending)

Depois que o Sequencer criar um Bloco L2, o Bloco e as transações nele passarão por três fases em sequência: Confirmado, Comprovado e Bloqueado, indicando que “Bloco foi carregado para L1”, “A validade do bloco foi comprovada” e “O status L2 foi atualizado para L1 após a transação do Bloco ter sido executada”. Bloco e transação em diferentes estágios são mostrados abaixo:

O lote 292700 foi carregado para L1 e está na fase de Confirmação. Fonte:

O estado atual da transação no Lote 292700 mudou de Envio Ethereum para Validação Ethereum, indicando que está esperando para ser verificado pela Prova de Conhecimento Zero.

Mover a seta sobre o ícone de Validação do Ethereum também mostrará os diferentes estágios, e o link da transação do estágio anterior (Envio) também será anexado:

Esta transação entra na etapa “Validação”, e o link para a transação que carregou o Lote para L1 na etapa anterior (Envio) também pode ser visto aqui.

A eficácia do Lote 292000 foi comprovada, por isso entre na fase Comprovada:

Depois que o lote é provado, ele entra no estado Proven com um link para a transação que executa a ação Provar.

A transação também passará de “validação” para “uting”, ou seja, aguardando para ser executada.

Quando o lote é comprovado, ele entra em um período de espera (cerca de 21 horas em documentos oficiais) antes que a transação no interior seja executada e o estado L2 registrado em L1 seja atualizado. Isso se deve principalmente a uma salvaguarda que foi adicionada na fase alfa para garantir que haja tempo suficiente para reagir a quaisquer bugs que surjam. Quando o lote é executado, ele entra na fase final:

Depois que o lote é executado, ele entra no estado uted final com um link de transação que executa a ação ute.

O status da transação no Batch também foi atualizado para “uted”

Em contraste com a StarkNet, onde as transações de L2 para L1 são concluídas em uma etapa, o processo do zkSync de mover L2 para L1 é dividido em três etapas mais detalhadas: Committed → Proven → uted.

Embora todo o processo de transação seja estendido para cerca de um dia ou mais como salvaguarda, o estado Comprometido permite que os usuários saibam rapidamente se uma transação foi obtida (e não é mais apenas uma pré-confirmação quando a transação entra em Compromisso) sem ter que confiar na confiança no Sequencer continuamente.

Além disso, o zkSync Explorer fornece exibição de dados rica e completa para diferentes estágios, para que qualquer pessoa possa entender o status mais recente das transações através do explorador e até mesmo ser capaz de verificar pessoalmente a execução da transação de cada transição de estágio (como de Committed para Provenified, de Proven para uted).

No entanto, deve-se notar que, como medida de proteção para a fase alfa, o histórico pode ser modificado pelo zkSync Sequencer neste momento.

Isso sugere que, embora uma transação possa sair rapidamente da pré-confirmação e entrar na fase comprometida, o Sequencer pode realmente remover uma transação do usuário do histórico antes que a transação entre na fase de atualização. Portanto, os consumidores ainda precisam confiar no Sequencer por até um dia.

L1 também pode suportar Pré-Confirmação

Se você puder saber com antecedência quem é responsável pela produção de blocos, o L1 também pode suportar a pré-confirmação.

Tomando o Ethereum como exemplo, a pessoa que realmente produz blocos é o Construtor, e o Construtor pode fornecer serviços de Pré-Confirmação para dar aos usuários uma garantia de renda de transação. Mas como o Construtor não obtém necessariamente o direito a uma determinada saída e a um determinado Bloco, mas deve licitar o direito a cada saída de Bloco, então a eficácia desta Pré-Confirmação será relativamente fraca, e a força do Construtor deve ser considerada, se o Construtor não for competitivo o suficiente, então é difícil para o Construtor obter o direito de produzir Bloco, então a Pré-Confirmação fornecida pelo Construtor O serviço ficará muito comprometido.

Se você quiser evitar os problemas acima, é melhor ter Proponente fornecer o serviço de Pré-Confirmação, porque o “qual Proponente irá propor o primeiro Bloco” é geralmente uma situação pré-calculada, determinística.

No entanto, como na arquitetura PBS atual, o Proponente propõe apenas o papel de Bloco, e o papel de realmente fazer Bloco e determinar o conteúdo de Bloco é Construtor, então o Proponente não pode inserir diretamente uma transação em um Bloco ou pedir ao Construtor para preencher uma transação. Quando a arquitetura PBS mudar no futuro, como adicionar uma Lista de Inclusão ou permitir que os Proponentes participem da produção de blocos, o Proponente terá a oportunidade de fornecer serviços de Pré-Confirmação.

Dica de leitura: Para obter mais informações sobre PBS, copie o link abaixo para ler em seu navegador: _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Melhorar a pré-confirmação

A Pré-Confirmação é apenas uma promessa verbal do Construtor ou do Sequenciador L2, e a outra parte não tem obrigação de cumprir a promessa, e não há mecanismo de penalização pelo não cumprimento.

É possível tornar esta promessa mais segura? Na verdade, sim, porque a pessoa responsável pela produção do Bloco e o conteúdo de sua promessa (por exemplo, “no Bloco 1.350.000 a transação de receita”) pode ser escrita como uma verificação de condição. Portanto, podemos usar o contrato inteligente para regular o Construtor ou Sequenciador, pedir-lhes para fornecer serviços de Pré-Confirmação ao garantir o depósito no Contrato Inteligente, e assinar o conteúdo ao dar a promessa de receita de transação, quando o usuário descobre que o Construtor ou Sequenciador não cumpriu o compromisso, o conteúdo prometido e a assinatura da outra parte podem ser enviados para o Contrato Inteligente, e o Contrato Inteligente pode verificar se o compromisso foi cumprido (como “no primeiro 1.350.000 Receita de Bloco para esta transação”).

Embora o cenário de aplicação do contrato acima ainda esteja na fase de prova de conceito, o vídeo de apresentação mostrado no link abaixo mostra um exemplo de uma das candidaturas ao contrato, copie o link abaixo para ver os detalhes no seu navegador:

Resumo

• Depois que as transações L1 forem incluídas nos blocos L1, a probabilidade de Re-org cairá gradualmente e a confiança dos usuários na receita das transações aumentará gradualmente.
• Um fluxo de trabalho de transação a mais para transações L2 do que transações L1 é o estágio em que as transações L2 são incluídas em blocos L2 e aguardam para serem carregadas para L1.
• No entanto, no fluxo de trabalho de transações onde as transações L2 são mais do que transações L1, porque os dados ainda não foram carregados para L1 nesta fase, ainda existe a possibilidade de variáveis, então a garantia de renda da transação que os usuários podem obter nesta etapa é a promessa verbal do Sequencer, que é chamada de Pré-Confirmação ou Confirmação Rápida, Confirmação Suave.
• Se o Sequencer for malicioso, ou se houver um bug simples, então a promessa feita pelo Sequencer pode ser violada, resultando em nenhum reconhecimento de receita para as transações L2 do usuário.
• Atualmente, a maioria dos status de transação L2 em seu Explorer inclui um status de Pré-Confirmação, como Confirmado pelo Sequencer para Arbitrum/Optimism ou Aceito em L2 para StarkNet. Quando vir essas informações, preste atenção à validade temporal da garantia de receita da transação fornecida por essas informações.
• Se você não quiser confiar na Pré-Confirmação fornecida pelo Sequencer, você precisará esperar um pouco mais e verificar com as informações fornecidas pelo L2 Explorer sobre os dados L2 que estão sendo carregados para L1.
• A pré-confirmação pode ser acoplada com o design de incentivos econômicos, como penalidades através de contrato inteligente quando o Sequencer viola compromissos, para que os usuários possam obter uma proteção mais clara.

A tabela abaixo ilustra a garantia de receita da transação e os cenários de risco correspondentes fornecidos pelas transações L1 e L2 em diferentes estágios do processo de transação: