Quando se pode ter a certeza de que uma transação da L2 (Camada 2) será incluída num bloco? Quando se pode ter a 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ções L2 e analisar o desempenho de segurança em cada etapa do processo de transação.

Conhecimento Preliminar:

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

Compreender 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 a inclusão em um bloco por um Minerador sob o mecanismo de consenso Proof of Work (PoW) ou um Proponente sob o mecanismo de consenso Proof of Stake (PoS). Quando um usuário percebe que sua transação foi incluída no bloco mais recente, ainda não é certo que a transação será permanentemente registrada no histórico do blockchain. Esta incerteza deve-se à possibilidade de ocorrer uma "Re-org" (reorganização) na blockchain. Os usuários devem esperar até que a probabilidade de uma Re-org acontecer seja suficientemente baixa para ter certeza de que sua transação será permanentemente registrada no histórico do blockchain.

Processo de Transação L1 Ilustrado

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

A probabilidade e o custo de um Re-org variam com o algoritmo de consenso de cada blockchain e o valor de mercado dos seus ativos. Este documento não irá aprofundar nos métodos de cálculo dos custos de Re-org.

Compreender Transações L2

Processo de Transação

Os utilizadores L2 geram e assinam transações, enviando-as geralmente diretamente para um Sequenciador, que depois inclui essas transações num bloco L2. Posteriormente, quando o Sequenciador publica os dados do bloco L2 de volta para L1 através de uma transação L1, os utilizadores podem ver as suas transações incluídas no último bloco L2.

No entanto, é importante notar que, uma vez que os dados do bloco L2 são enviados para o L1 através de uma transação L1, ainda é possível ocorrer um Re-org no L1, resultando potencialmente no bloco L2 não ser permanentemente registado na história da blockchain. Este cenário é semelhante a um Re-org no L2, portanto os utilizadores devem esperar até que a probabilidade de um Re-org no L1 seja suficientemente baixa para terem a certeza de que a sua transação será permanentemente registada na história da blockchain.

Processo de Transação L2 Ilustrado

Os utilizadores devem primeiro esperar que a sua transação seja incluída num bloco L2, depois que o bloco L2 seja enviado para L1 através 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 a inclusão num bloco L2 pelo Sequenciador em comparação com as transações L1, este tempo de espera é geralmente curto se a capacidade do bloco L2 for grande e a geração de blocos for rápida, uma vez que o principal período de espera é para a confirmação da transação L1. Assim, a experiência geral do utilizador de transações L1 e L2 é semelhante.

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

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

Mas e se os utilizadores estiverem dispostos a confiar no Sequenciador? O Sequenciador poderia ser operado pela equipa de desenvolvimento L2 ou por uma instituição respeitável. Se o Sequenciador garantir aos utilizadores imediatamente após receberem as suas transações que estas serão incluídas num bloco específico, essa garantia pode ser suficiente para aqueles que estão dispostos a confiar no Sequenciador. É semelhante a um utilizador confiar na sua aplicação 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 num bloco L1. No entanto, estas são apenas compromissos verbais do Sequenciador, que podem ser esquecidos devido a um bug ou deliberadamente quebrados por um Sequenciador malicioso, resultando no pior cenário num ataque de gasto duplo.

Posteriormente, iremos apresentar as várias formas como os estados de inclusão de transações L2 são apresentados.

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

Atualmente, os utilizadores na Arbitrum ou na Optimism quase imediatamente podem 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 utilizadores uma Pré-Confirmação.

Saber 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

Estado da Receita de Negociação para Arbitrum/Optimism

Atualmente, depois de os utilizadores enviarem uma transação na Arbitrum ou na Optimism, quase imediatamente podem obter um recibo de transação (Recibo de Transação), que conterá os resultados da execução da transação. Isto significa que o Sequenciador sequenciou a transação localmente e a simulou uma vez. Este recibo de transação é a Pré-Confirmação fornecida ao utilizador.

saber mais

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

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

Para uma introdução mais detalhada ao ciclo de vida da transação da Optimism, 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 estado de receita da transação na Arbitrum

As transações vistas no Arbitrum Explorer incluirão transações Pré-Confirmação, ou seja, transações que não foram carregadas no L1. Para esta transação, como 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 apenas confirmadas pelo Sequencer, mas ainda não foram carregadas para L1.

Se for uma transação que foi carregada para L1 conforme mostrado na figura abaixo, o seu estado mudou para 69 Confirmações de Bloco L1, o que significa que foi carregada para L1 e o bloco Layer1 contendo os dados da transação teve 69 blocos a segui-lo:

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

Ou para esta transação, como mostrado na captura de ecrã abaixo, o bloco L1 que contém os dados desta transação já tem 6174 blocos a segui-lo, o que já é muito seguro.

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

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

Verificação do Estado 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 publicadas na Camada 1 (L1). Como ilustrado abaixo, a transação com o Número do Bloco 111526300 está marcada como "Confirmada pelo Sequenciador":

Transações apenas confirmadas pelo Sequenciador, mas ainda não publicadas 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 já passaram pelo período de desafio, permanecem no estado de “Confirmadas pelo Sequenciador”.

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

Nota de leitura: Esta situação também pode dever-se ao facto de o Explorador apresentar diferentes indicadores de estado em vários locais: "Confirmado pelo Sequenciador" ao lado do Número do Bloco informa os utilizadores de que o bloco foi confirmado pelo Sequenciador. Para verificar o estado pós-L1, os utilizadores devem consultar outras informações, como os detalhes do "L1 State Batch" discutidos abaixo.

Além disso, como mostrado na captura de tela abaixo, uma transação que foi postada para L1 inclui duas peças adicionais de informação: "Índice do Lote de Estado L1" e "Hash de Transação de Submissão de Raiz de Estado L1." Estes detalhes representam em qual Lote de Estado a transação L2 está incluída e através de qual transação L1 este Lote de Estado foi postado para L1:

Ao clicar em "Lote de Estado 3480", o seu estado é mostrado como Finalizado, correspondendo ao estado Finalizado na L1 (ou seja, na mainnet Ethereum), que é um estado altamente seguro alcançado após acumular votos de validadores ao longo de duas épocas.

△ O Estado Lote 3480 está incluído no Bloco L1 18457449, e o Bloco 18457449 foi finalizado.

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

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

O Lote de Estado 3494, embora publicado para L1, está incluído num Bloco L1 que não foi Finalizado：

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

Estado da Receita da Transação StarkNet

Atualmente, quando os utilizadores enviam transações na StarkNet, podem consultar rapidamente o recibo da transação. No entanto, o recibo frequentemente mostra o estado da transação como RECEBIDO. Este estado indica que o nó recebeu a transação e, após verificação, não encontrou problemas. A transação está à espera de ser incluída num bloco L2 pelo Sequencer e executada. As transações no estado RECEBIDO ainda não terão quaisquer resultados da execução. Os utilizadores podem verificar o progresso das suas transações ao visualizar o estado da transação exibido no Explorador StarkNet.

Dica de leitura: Se o Sequenciador processar transações com rapidez suficiente, poderá ignorar o estado RECEBIDO e passar diretamente para um estado processado. Para uma introdução mais detalhada ao processo de transação no StarkNet, 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 Explorador StarkNet, também incluem transações Pré-Confirmação. Como mostrado na seguinte transação, o Estado atual é “Aceite na L2,” indicando que foi enfileirado pelo Sequenciador num bloco L2:

"Accepted on L2” significa que foi colocado na fila pelo Sequenciador num bloco L2, mas ainda não foi carregado para L1.

Os dois estados anteriores a "Aceite em L2" são Recebido e Pendente, representando "a transação foi recebida e verificada" e "a transação está a ser processada pelo Sequenciador," respetivamente. Após a conclusão da execução do processamento da transação, irá passar para o estado "Aceite em L2":

A transação foi recebida e verificada.

A transação está a ser processada pelo Sequenciador.

Uma vez que os dados da transação são carregados para L1, o estado mudará para "Aceite em L1", conforme mostrado na seguinte transação:

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

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

Além disso, o Explorer apenas exibe "Aceite em L1" para transações enviadas para L1, sem informações adicionais sobre a Finalidade de L1 ou Confirmação de Bloco. Isso significa que os utilizadores têm de verificar por si próprios se o bloco L1 tem blocos subsequentes suficientes ou se foi Finalizado.

Globalmente, devido aos estrangulamentos de desempenho do StarkNet, os utilizadores precisam de depender da Pré-Confirmação por um período prolongado, e o Explorador não suporta informações de Finalidade L1, resultando numa experiência do utilizador menos satisfatória para a confirmação de receitas de transações. Esta é uma área onde o StarkNet precisa de melhorar no futuro.

Estado da receita da transação zkSync

Semelhante ao StakrNet, o zkSync também tem um estado PENDENTE, o que significa que o nó recebeu a transação e não há problemas após a verificação da transação. Ele aguardará 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 utilizadores podem acompanhar o progresso do processamento das suas transações através do estado da transação exibido no explorador zkSync.

Dicas de leitura: Se o Sequenciador 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, pode copiar o link abaixo e visualizá-lo no seu navegador: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

As transações vistas no Explorador zkSync também incluirão transações Pré-Confirmação, como a transação na captura de ecrã abaixo. Pode ver que o Estado é atualmente Processado na Era zkSync, indicando que foi colocado na fila no bloco L2 pelo Sequenciador:

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

Após o Sequenciador completar o bloco L2, o bloco e as transações nele passarão pelas três fases de Compromisso, 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 transação no bloco ser executada.” O seguinte mostra três blocos e transações em diferentes fases:

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

O estado atual das transações no Lote 292700 mudou de Envio de Ethereum para Validação de Ethereum, indicando que está à espera de ser verificado por prova de conhecimento zero para verificar a 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 carregar o Lote para L1 na fase anterior (Envio) também pode ser visto diretamente aqui.

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

Depois que o Batch for comprovado, ele entra no estado Comprovado e um link de transação para executar a ação de Provar é anexado.

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

Quando o Batch é comprovado, ele entrará então num período de espera (documentos oficiais indicam que são cerca de 21 horas) antes de executar as transações internas e atualizar o estado L2 registado no L1. Isto deve-se 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 é executado, ele entrará na fase final Executado:

Após a execução do lote, ele entra no estado final Executado e é anexado um link de transação para executar a ação Executar.

O estado da transação no lote também é atualizado para 'Executado'. Ao contrário das transações StarkNet, que são concluídas de Camada 2 (L2) para 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 -> Comprovado -> Executado. Embora isso prolongue o processo de transação inteiro para cerca de um dia como medida de proteção, o estado Comprometido permite aos usuários saber rapidamente se sua transação foi incluída (uma vez que uma transação entra no estágio Comprometido, ela não é mais apenas Pré-Confirmação), sem depender continuamente da confiança no Sequenciador. Além disso, o zkSync Explorer fornece exibições de dados abrangentes e completas para diferentes estágios, permitindo a qualquer pessoa entender o estado mais recente das transações e até verificar pessoalmente a execução das transações em cada transição de estágio (por exemplo, de Comprometido para Comprovado, de Comprovado para Executado). No entanto, é importante notar que, como medida de proteção na fase Alpha, o Sequenciador zkSync pode modificar registros históricos. Isso indica que, embora as transações possam se mover rapidamente além da Pré-Confirmação para entrar no estágio Comprometido, o Sequenciador ainda pode remover transações de usuário dos registros históricos até chegarem ao estágio 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 pela produção de blocos, então L1 também pode suportar a Pré-Confirmação. Tomando o Ethereum como exemplo, o produtor de blocos real é o Construtor, que pode oferecer serviços de Pré-Confirmação, dando aos usuários uma garantia de inclusão de transação. No entanto, uma vez que o Construtor 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 Construtor deve ser considerada; se um Construtor 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 Proponentes forneçam serviços de Pré-Confirmação, pois geralmente é predeterminado e certo qual Proponente irá propor qual bloco. No entanto, na arquitetura atual do PBS, os Proponentes apenas propõem blocos, e a produção real de blocos e a tomada de decisão de conteúdo são feitas pelos Construtores, então os Proponentes não podem inserir diretamente uma transação em um bloco ou exigir que um Construtor faça isso. No futuro, se a arquitetura do PBS mudar, por exemplo, adicionando uma Lista de Inclusão ou permitindo que os Proponentes participem na produção de blocos, os Proponentes podem ter a oportunidade de oferecer serviços de Pré-Confirmação. Para obter mais informações sobre o PBS, por favor visite o link fornecido.

Melhorando a Pré-Confirmação:

Pré-Confirmação é meramente um compromisso verbal pelos Construtores ou Sequenciadores L2, sem obrigação de cumprir a promessa e sem mecanismo de penalização para o não cumprimento. No entanto, é possível tornar este compromisso mais confiável usando contratos inteligentes para padronizar Construtores ou Sequenciadores. Eles poderiam fornecer serviços de Pré-Confirmação enquanto também depositam uma fiança no contrato inteligente e assinam o conteúdo ao fazer uma promessa de inclusão de transação. Se os utilizadores descobrirem que os Construtores ou Sequenciadores não cumpriram as suas promessas, 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 anteriormente 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 de contrato semelhante.

Resumo:

Depois que as transações L1 são 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 têm 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 upload para L1." No entanto, como os dados não foram carregados para L1 nesta etapa, ainda há uma possibilidade de variância, então 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 status de transação em seus Explorers que incluem status de Pré-Confirmação, como Arbitrum/Optimism's Confirmed by Sequencer ou StarkNet's Accepted on L2. 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 confiar na Pré-Confirmação do Sequencer, eles precisarão esperar mais tempo e verificar através das informações do L2 Explorer sobre os dados L2 que estão sendo carregados para L1. A pré-confirmação pode incorporar um mecanismo de incentivo econômico, como penalizar os sequenciadores 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 da transação e os cenários de risco correspondentes fornecidos pelas transações L1 e L2 em diferentes fases do processo de transação.

Aviso legal:

1. Este artigo é reimpresso de [Gateaicoin]. Todos os direitos autorais pertencem ao autor original [Foresight News]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão tratar disso prontamente.
2. Responsabilidade de Isenção: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum 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.