Quando se pode ter certeza de que uma transação da L2 (Camada 2) será incluída em um bloco? Quando se pode ter certeza de que a receita de uma transação da L2 não será descartada devido a uma Re-org?

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

Conhecimento Preliminar:

• O processo inteiro de transações L1 (Camada 1)
• Motivos e impactos das ocorrências de Re-org
• Compreender os papéis e métodos de operação na arquitetura atual da Ethereum PBS
• Diferenças entre Optimistic Rollup e Validity (ZK) Rollup

Compreendendo transações L1

Processo de Transação

Depois que um usuário emite e assina uma transação, ela é enviada para a rede p2p, aguardando inclusão em um bloco por um Miner sob o mecanismo de consenso Proof of Work (PoW) ou um Proposer sob o mecanismo de consenso Proof of Stake (PoS). Quando um usuário percebe que sua transação foi incluída no último bloco, ainda não é certo que a transação será registrada permanentemente na história do blockchain. Essa incerteza é devido à possibilidade de ocorrer uma "Re-org" (reorganização) no blockchain. Os usuários devem esperar até que a probabilidade de uma Re-org acontecer seja suficientemente baixa para ter a certeza de que sua transação será registrada permanentemente na história do blockchain.

Processo de Transação L1 Ilustrado

Mesmo depois que uma transação é incluída em um bloco, uma Re-org ainda pode ocorrer, significando que a confirmação só pode ser assegurada uma vez que a probabilidade de uma Re-org se torna improvável.

A probabilidade e o custo de uma Re-org variam com o algoritmo de consenso de cada blockchain e o valor de mercado de seus ativos. Este documento não entrará em detalhes sobre os métodos de cálculo dos custos de Re-org.

Compreendendo Transações L2

Processo de Transação

Os usuários L2 geram e assinam transações, geralmente as enviando diretamente para um Sequenciador, que então inclui essas transações em um bloco L2. Posteriormente, quando o Sequenciador envia os dados do bloco L2 de volta para L1 por meio de uma transação L1, os usuários podem ver suas transações incluídas no último bloco L2.

No entanto, é importante notar que, como os dados do bloco L2 são enviados para o L1 por meio de uma transação L1, ainda é possível ocorrer um Re-org do L1, resultando potencialmente no bloco L2 não ser permanentemente registrado na história do blockchain. Esse cenário é semelhante a um Re-org do L2, portanto os usuários devem esperar até que a probabilidade de um Re-org do L1 seja suficientemente baixa para ter confiança de que sua transação será permanentemente registrada na história do blockchain.

Processo de Transação L2 Ilustrado

Os usuários devem primeiro esperar que sua transação seja incluída em um bloco L2, depois que o bloco L2 seja publicado no L1 por meio de uma transação L1 e, finalmente, que a transação L1 seja finalizada.

Embora as transações L2 envolvam um tempo de espera adicional para inclusão em um bloco L2 pelo Sequenciador em comparação com as transações L1, essa espera geralmente é curta se a capacidade do bloco L2 for grande e a geração de blocos for rápida, pois o principal período de espera é para a confirmação da transação L1. Assim, a experiência geral do usuário com as transações L1 e L2 é semelhante.

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

Os usuários devem verificar pessoalmente se suas transações L2, juntamente com o bloco L2, foram incluídas em um bloco L1 e até mesmo esperar até que a probabilidade de um Re-org seja suficientemente baixa para confiar que sua transação L2 foi incluída.

Mas e se os usuários estiverem dispostos a confiar no Sequenciador? O Sequenciador poderia ser operado pela equipe de desenvolvimento L2 ou por uma instituição respeitável. Se o Sequenciador garantir aos usuários imediatamente após receberem suas transações que elas serão incluídas em um bloco específico, essa garantia pode ser suficiente para aqueles dispostos a confiar no Sequenciador. É semelhante a um usuário confiar em seu aplicativo de carteira e não verificar obsessivamente o Etherscan para confirmação após ser notificado da inclusão de uma transação.

Tais garantias fornecidas pelo Sequenciador são referidas como Pré-Confirmação, Confirmação Rápida ou Confirmação Suave. Estas são consideradas garantias "preliminares" ou "suaves" da inclusão da transação, não exigindo que a transação L2 seja incluída em um bloco L1. No entanto, estas são meros compromissos verbais do Sequenciador, que podem ser esquecidos devido a um bug ou deliberadamente quebrados por um Sequenciador malicioso, resultando no pior caso em um ataque de gasto duplo.

Posteriormente, vamos apresentar as várias maneiras como os status de inclusão de transações L2 são apresentados.

Status de Inclusão de Transação Arbitrum/Optimism

Atualmente, os usuários na Arbitrum ou Optimism podem quase imediatamente receber um recibo de transação após enviar uma transação, indicando o resultado da execução da transação. Isso significa que o Sequenciador já localmente sequenciou e simulou a transação, fornecendo aos usuários uma Pré-Confirmação.

Saiba mais

Para obter informações mais detalhadas sobre o ciclo de vida da transação do Arbitrum, consulte a documentação oficial:https://docs.arbitrum.io/tx-lifecycle

Para obter informações mais detalhadas sobre o ciclo de vida da transação do Optimism, consulte a documentação oficial: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Status de Rendimento de Negociação para Arbitrum/Optimism

Atualmente, após os usuários enviarem uma transação no Arbitrum ou Optimism, eles quase imediatamente podem obter um recibo de transação (Recibo de Transação), que conterá os resultados da execução da transação. Isso significa que o Sequenciador sequenciou a transação localmente e a simulou uma vez. Este recibo de transação é a Pré-Confirmação dada ao usuário.

aprender mais

Para obter uma introdução mais detalhada ao ciclo de vida da transação do Arbitrum, você pode copiar o link abaixo para o navegador para consultar o documento oficial:

https://docs.arbitrum.io/tx-lifecycle

Para uma introdução mais detalhada ao ciclo de vida da transação do Optimism, você pode copiar o link abaixo para o navegador e consultar o documento oficial:

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Verifique o status de recebimento da transação na Arbitrum

As transações vistas no Explorador Arbitrum incluirão transações Pré-Confirmação, ou seja, transações que não foram enviadas para L1. Para esta transação, conforme mostrado na figura abaixo, você pode ver uma marca Confirmada pelo Sequenciador ao lado do Número do Bloco 145353000:

A imagem acima mostra transações que foram confirmadas apenas pelo Sequenciador, mas ainda não foram carregadas no L1.

Se for uma transação que foi enviada para L1, conforme mostrado na figura abaixo, seu status foi alterado para 69 Confirmações de Bloco L1, o que significa que foi enviada para L1 e o bloco da Camada 1 contendo os dados da transação tem 69 blocos seguintes.

O bloco L1 que contém esses dados de transação já tem 69 blocos seguindo-o. Quanto mais blocos o seguirem, mais seguro ele é.

Ou para esta transação conforme mostrado na captura de tela abaixo, o bloco L1 contendo esses dados de transação já possui 6174 blocos seguindo-o, o que já é muito seguro.

Mas, na verdade, o que pode ser feito de melhor aqui é apresentá-lo em combinação com as informações de Finalidade do L1.

Apenas dizer ao usuário quantas Confirmações de Bloco L1 existem é de ajuda limitada ao usuário, porque o usuário tem que entender e calcular o nível de segurança representado por tal número de Confirmações de Bloco. E como a Camada1 (ou seja, Ethereum) já possui um mecanismo de Finalidade como o Casper FFG, o Explorer pode realmente exibir diretamente se o bloco da Camada1 foi Finalizado na Camada1. Atualmente, o Explorer da Optimism implementou tal função.

Verificação do Status do Recibo da Transação na Optimism

As transações visualizadas no Optimism Explorer podem incluir aquelas marcadas como Pré-Confirmação, indicando que ainda não foram postadas na Camada 1 (L1). Como ilustrado abaixo, a transação com o Número do Bloco 111526300 é marcada como "Confirmada pelo Sequenciador":

Transações apenas confirmadas pelo Sequenciador, mas ainda não postadas no L1

Atualmente, o Explorer parece não ter uma definição clara para "Confirmado pelo Sequenciador", sugerindo que "as confirmações do Sequenciador são equivalentes a algumas confirmações de bloco no L1." Isso implica que ser "Confirmado pelo Sequenciador" significa que a transação foi enviada para o L1 e tem vários blocos a seguir:

No entanto, as transações recém-aparecidas também são exibidas como “Confirmadas pelo Sequenciador”, e até mesmo transações de muitos dias atrás, que passaram pelo período de desafio, permanecem no status de “Confirmadas pelo Sequenciador”.

Transações de dias atrás ainda estão no status "Confirmado pelo Sequenciador"

Nota de leitura: Esta situação também pode ser devido ao Explorer apresentar diferentes indicadores de status em vários lugares: "Confirmado pelo Sequenciador" ao lado do Número do Bloco informa aos usuários que o bloco foi confirmado pelo Sequenciador. Para verificar o status pós-L1, os usuários devem se referir a outras informações, como os detalhes do "Lote de Estado L1" discutidos abaixo.

Além disso, como mostrado na captura de tela abaixo, uma transação que foi enviada para L1 inclui duas peças adicionais de informação: "Índice do Lote de Estado L1" e "Hash da Transação de Envio de Raiz de Estado L1." Esses detalhes representam em qual Lote de Estado a transação L2 está incluída e por meio de qual transação L1 esse Lote de Estado foi enviado para L1:

Clicando em “Lote de Estado 3480”, seu status é mostrado como Finalizado, correspondente ao status Finalizado na L1 (ou seja, a mainnet Ethereum), que é um status altamente seguro alcançado após acumular votos de validadores ao longo de dois epochs.

△ Estado Batch 3480 está incluído no Bloco L1 18457449, e o Bloco 18457449 foi Finalizado.

Fonte: https://etherscan.io/block/18457449

Se um lote foi postado mas ainda não foi finalizado no L1, ele será exibido como Não finalizado:

Lote de Estado 3494, embora publicado no L1, está incluído em um Bloco L1 que não foi Finalizado：

Comparado ao Explorador Arbitrum, o Explorador Optimism fornece informações mais detalhadas (Lote de Estado) e vincula diretamente as informações de Finalidade L1 ao Explorador L2, permitindo que os usuários saibam se um bloco L1 foi Finalizado, em vez de fazerem seu próprio julgamento com base no número de Confirmações de Bloco para o nível de segurança.

Status da Receita de Transações do StarkNet

Atualmente, quando os usuários enviam transações na StarkNet, eles podem consultar rapidamente o recibo da transação. No entanto, o recibo muitas vezes mostra o status da transação como RECEBIDO. Esse status indica que o nó recebeu a transação e, após verificação, não encontrou problemas. A transação está aguardando para ser incluída em um bloco L2 pelo Sequencer e executada. Transações no status RECEBIDO ainda não terão resultados da execução. Os usuários podem verificar o progresso de suas transações visualizando o status da transação exibido no StarkNet Explorer.

Dica de leitura: Se o Sequenciador processar as transações com rapidez suficiente, pode ignorar o status RECEBIDO e passar diretamente para um estado processado. Para obter uma introdução mais detalhada ao processo de transação no StarkNet, você pode copiar o link abaixo para o seu navegador e consultar os documentos oficiais.

Documentos Oficiais:Ciclo de Vida da Transação StarkNet

Transações vistas no Starkscan, um Explorer StarkNet, também incluem transações de Pré-Confirmação. Como mostrado na seguinte transação, o Status atual é “Aceito no L2,” indicando que foi enfileirado pelo Sequencer em um bloco L2:

Aceito no L2 significa que foi enfileirado pelo Sequenciador em um bloco L2, mas ainda não foi enviado para o L1.

Os dois status anteriores a 'Aceito na L2' são Recebido e Pendente, representando 'a transação foi recebida e verificada' e 'a transação está sendo processada pelo Sequenciador', respectivamente. Após a conclusão da execução do processamento da transação, ela passará para o status 'Aceito na L2':

A transação foi recebida e verificada.

A transação está sendo processada pelo Sequenciador.

Uma vez que os dados da transação forem carregados no L1, o status mudará para "Aceito no L1," como mostrado na seguinte transação:

Os dados da transação foram enviados para L1.

Embora as transações da StarkNet tenham um conjunto mais rico de status para informar os usuários sobre o progresso do processamento, o envio de transações para L1 ainda pode exigir uma espera de várias horas (possivelmente porque a geração de provas de conhecimento zero leva mais tempo). Durante este tempo, os usuários dependem da Pré-Confirmação do Sequenciador.

Além disso, o Explorer exibe apenas "Aceito no L1" para transações enviadas para o L1, sem informações adicionais sobre a Finalidade do L1 ou Confirmação de Bloco. Isso significa que os usuários têm que verificar por si mesmos se o bloco L1 tem blocos subsequentes suficientes ou foi Finalizado.

No geral, devido aos gargalos de desempenho do StarkNet, os usuários precisam confiar na Pré-Confirmação por um período prolongado, e o Explorer não suporta informações de Finalidade L1, resultando em uma experiência do usuário menos satisfatória para a confirmação de receita da transação. Esta é uma área onde o StarkNet precisa melhorar no futuro.

Status de receita de transação zkSync

Similar ao StakrNet, zkSync também possui um estado PENDENTE, o que significa que o nó recebeu a transação e não há problemas depois que a transação é verificada. Ele irá esperar para ser incluído no bloco L2 pelo Sequenciador e executado. No entanto, nenhuma transação será executada no estado PENDENTE. o resultado de.

Os usuários podem saber o progresso do processamento de suas transações por meio do status da transação exibido no zkSync Explorer.

Dicas de leitura: Se o Sequencer for processado rápido o suficiente, pode ser possível pular diretamente o estado PENDENTE e entrar no estado em que a transação foi processada.

Para uma introdução mais detalhada ao processo de transação do zkSync, você pode copiar o link abaixo e visualizá-lo em seu navegador: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

As transações vistas no zkSync Explorer também incluirão transações de Pré-Confirmação, como a transação na captura de tela abaixo. Você pode ver que o Status está atualmente Processado pelo zkSync Era, indicando que foi enfileirado no bloco L2 pelo Sequenciador:

Esta transação foi enfileirada no bloco L2 pelo Sequenciador e está atualmente aguardando para ser carregada no L1 (Envio de Ethereum)

Depois que o Sequenciador completa o bloco L2, o bloco e as transações nele passarão pelas três etapas de Comprometido, Comprovado e Executado, o que significa respectivamente "o bloco foi carregado para L1" e "a validade do bloco foi comprovada". E "o status L2 é atualizado para L1 após a execução da transação no bloco." O seguinte mostra três blocos e transações em diferentes estágios:

Lote 292700 foi carregado para L1 e entrou na fase Comprometida. Fonte: https://explorer.zksync.io/batch/292700

O status atual das transações no lote 292700 mudou de Envio Ethereum para Validação Ethereum, indicando que está aguardando verificação por prova de conhecimento zero para verificar sua validade.

Mover a seta sobre o ícone de Validação do Ethereum também mostrará as diferentes etapas, e o link da transação para a etapa anterior (Envio) também será anexado:

Esta transação entrou na fase de “Validação”. O link da transação para fazer upload do lote para L1 na fase anterior (Envio) também pode ser visto diretamente aqui.

A eficácia do Batch 292000 foi comprovada, por isso entra na fase Proven:

Após o lote ser comprovado, ele entra no estado Comprovado, e um link de transação para executar a ação de Prova é anexado.

As transações internas também entrarão na fase de “Execução” a partir da fase de “Validação”, aguardando para serem executadas.

Quando o Batch for comprovado, ele entrará em um período de espera (documentos oficiais dizem que é cerca de 21 horas) antes de executar as transações internas e atualizar o status L2 registrado no L1. Isso se deve principalmente a uma medida de proteção que ainda está na fase Alfa para garantir que haja tempo suficiente para reagir quando ocorrerem quaisquer bugs. Quando o Batch for executado, ele entrará na fase final de Execução:

Depois que o lote é executado, ele entra no estado final Executado e um link de transação para executar a ação Executar é anexado.

O status da transação no lote também é atualizado para 'Executado'. Ao contrário das transações da StarkNet, que são concluídas da Camada 2 (L2) para a Camada 1 (L1) em um único passo, o zkSync divide o processo de transações de L2 para L1 em três estágios mais detalhados: Comprometido → Provado → Executado. Embora isso prolongue o processo de transação inteiro para cerca de um dia como medida de proteção, o status de Comprometido permite que os usuários saibam rapidamente se sua transação foi incluída (uma vez que uma transação entra na fase de Comprometido, ela não é mais apenas Pré-Confirmação), sem depender continuamente da confiança no Sequenciador. Além disso, o Explorador zkSync fornece exibições de dados abrangentes e completas para diferentes estágios, permitindo que qualquer pessoa entenda o status mais recente das transações e até verifique pessoalmente a execução das transações em cada transição de estágio (por exemplo, de Comprometido para Provado, de Provado para Executado). No entanto, é importante observar que, como medida de proteção na fase Alpha, o Sequenciador zkSync pode modificar registros históricos. Isso indica que, mesmo que as transações possam se mover rapidamente além da Pré-Confirmação para entrar na fase de Comprometido, o Sequenciador ainda pode remover transações de usuários dos registros históricos até que atinjam a fase de Executado. Portanto, os usuários ainda precisam confiar no Sequenciador por até um dia.

A Camada 1 também pode suportar Pré-Confirmação

Se for conhecido antecipadamente quem é responsável por produzir blocos, então L1 também pode suportar a Pré-Confirmação. Tomando o Ethereum como exemplo, o produtor de bloco real é o Builder, que pode oferecer serviços de Pré-Confirmação, dando aos usuários a garantia de inclusão da transação. No entanto, como o Builder não necessariamente tem o direito de produzir um determinado bloco, mas deve licitar pelo direito de produzir cada bloco, a eficácia da Pré-Confirmação pode ser mais fraca. Além disso, a competitividade do Builder deve ser considerada; se um Builder não for suficientemente competitivo, será difícil para ele garantir o direito de produzir blocos, reduzindo significativamente a confiabilidade de seus serviços de Pré-Confirmação. Para evitar esses problemas, uma abordagem melhor seria permitir que os Proposers forneçam serviços de Pré-Confirmação, já que geralmente é predefinido e certo qual Proposer proporá qual bloco. No entanto, na arquitetura atual da PBS, os Proposers apenas propõem blocos, e a produção real de blocos e a tomada de decisão de conteúdo são feitas pelos Builders, então os Proposers não podem inserir diretamente uma transação em um bloco ou exigir que um Builder o faça. No futuro, se a arquitetura da PBS mudar, por exemplo, adicionando uma Lista de Inclusão ou permitindo que os Proposers participem da produção de blocos, os Proposers podem ter a oportunidade de oferecer serviços de Pré-Confirmação. Para obter mais informações sobre a PBS, visite o link fornecido.

Melhorando a Pré-Confirmação:

A Pré-Confirmação é meramente um compromisso verbal por parte dos Construtores ou Sequenciadores L2, sem obrigação de cumprir a promessa e sem mecanismo de penalização por não cumprimento. No entanto, é possível tornar este compromisso mais fiável através do uso de contratos inteligentes para padronizar os Construtores ou Sequenciadores. Eles poderiam fornecer serviços de Pré-Confirmação enquanto também depositam uma garantia no contrato inteligente e assinam o conteúdo ao fazer uma promessa de inclusão de transação. Se os usuários perceberem que os Construtores ou Sequenciadores não cumpriram suas promessas, eles podem submeter o conteúdo da promessa e a assinatura ao contrato inteligente, que pode então verificar se a promessa foi cumprida. Embora o cenário de aplicação do contrato mencionado ainda esteja na fase de prova de conceito, o link abaixo mostra um vídeo de apresentação de um exemplo de aplicação desse contrato.

Resumo:

Após as transações L1 serem incluídas nos blocos L1, a probabilidade de reorganização diminui, e a confiança dos usuários na inclusão das transações aumenta gradualmente. As transações L2 possuem um fluxo de trabalho adicional em comparação com as transações L1: 'As transações L2 são incluídas nos blocos L2 e aguardam o envio para L1.' No entanto, como os dados ainda não foram enviados para L1 nesta etapa, ainda há uma possibilidade de variação, portanto, a garantia que os usuários podem obter sobre a inclusão da transação nesta etapa é o compromisso verbal do Sequencer, conhecido como Pré-Confirmação ou Confirmação Rápida/Confirmação Suave. Se o Sequencer for malicioso ou simplesmente encontrar um bug, sua promessa pode ser quebrada, levando a uma falta de confirmação para a transação L2 do usuário. Atualmente, a maioria dos L2s exibe os status das transações em seus Explorers que incluem o status de Pré-Confirmação, como 'Confirmado pelo Sequencer do Arbitrum/Optimism' ou 'Aceito no L2 do StarkNet'. Ao ver essas informações, é importante prestar atenção à eficácia temporal da garantia de inclusão da transação fornecida. Se os usuários não quiserem depender da Pré-Confirmação do Sequencer, eles precisarão esperar mais tempo e verificar por meio das informações do Explorer L2 sobre os dados L2 sendo enviados para L1. A Pré-Confirmação pode incorporar um mecanismo de incentivo econômico, como penalizar os Sequencers por meio de contratos inteligentes quando eles quebram suas promessas, fornecendo aos usuários uma proteção mais clara. A tabela abaixo mostra as garantias de inclusão de transações e os cenários de risco correspondentes fornecidos pelas transações L1 e L2 em diferentes estágios do processo de transação.

Aviso Legal:

1. Este artigo é reproduzido a partir de [Gateaicoin]. Todos os direitos autorais pertencem ao autor original [Foresight News]. Se houver objeções a essa reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.