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

Este artigo apresentará aos leitores 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 prévio:

1. Todo o processo de transações L1 (Camada 1)

2. As causas e impactos das Re-orgs

3. Entendendo as funções e métodos operacionais na arquitetura PBS atual do Ethereum

4. Compreender as diferenças entre o Optimistic Rollup e o Validity (ZK) Rollup

Entendendo as transações L1

Processo de Transação

Depois que um usuário emite e assina uma transação, ele é enviado para a rede peer-to-peer e aguarda um Minerador sob o mecanismo de consenso PoW ou um Proponente sob o mecanismo de consenso PoS para incluí-lo em um bloco. Quando um usuário descobre que sua transação foi incluída no bloco mais recente, ele não pode ter 100% de certeza de que a transação será permanentemente registrada no histórico desse blockchain. Isso se deve à possibilidade de um evento blockchain conhecido como "Re-org". Os usuários devem esperar até que a probabilidade de uma Reorganização ocorrer em um determinado bloco seja suficientemente baixa para ter certeza de que sua transação será registrada no histórico do blockchain.

Ilustração do Processo de Transação L1

Mesmo depois que uma transação é incluída em um bloco, ainda pode ocorrer um Re-org. Deve-se esperar até que seja improvável que ocorra um Re-org para ter confiança de que a transação foi Finalizada.

A probabilidade e o custo de um Re-org variam dependendo do algoritmo de consenso de uma cadeia e do valor de mercado de seus ativos. O método para calcular o custo de um Re-org não será discutido em detalhes aqui.

Compreendendo Transações L2

Processo de Transação

Depois que um usuário L2 gera e assina uma transação, ela normalmente é enviada diretamente para um Sequencer responsável por solicitar transações. Em seguida, o Sequencer inclui essa transação em um bloco L2. Posteriormente, quando o Sequencer grava os dados do bloco L2 de volta para L1 por meio de uma transação L1, os usuários podem ver sua transação incluída no bloco L2 mais recente. No entanto, é importante notar que, como os dados do bloco L2 são carregados para L1 por meio de uma transação L1, ainda há a possibilidade de encontrar uma Reorganização L1. Esse cenário pode levar o bloco L2 a não ser incluído no histórico do blockchain, resultando efetivamente em uma Reorganização L2. Portanto, os usuários devem esperar até que a probabilidade de uma Reorganização L1 seja suficientemente baixa antes de poderem ter certeza de que sua transação será registrada no histórico do blockchain.

Ilustração do processo de transação L2

Os usuários primeiro esperam que sua transação seja incluída em um bloco L2, depois esperam que o bloco L2 seja carregado para L1 via uma transação L1 e, finalmente, esperam que a transação L1 seja finalizada. Embora esperar que uma transação L2 seja incluída em um bloco L2 por um Sequenciador adicione uma etapa em comparação com transações L1, esse período de espera geralmente não é significativo se a capacidade do bloco L2 for grande e a velocidade de geração do bloco for rápida. A maior parte do tempo de espera é realmente gasta na confirmação da transação L1. Assim, no geral, a experiência do usuário para transações L1 e L2 é semelhante. Mas os usuários podem abrir mão de algumas concessões por uma experiência melhor?

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

Os usuários devem, idealmente, testemunhar suas transações L2 (incluídas em blocos L2) sendo incluídas em blocos L1, e até mesmo esperar até que a probabilidade de um Re-org seja suficientemente baixa, antes de confiar que suas transações L2 foram incluídas. Mas e se os usuários estiverem dispostos a confiar no Sequenciador? Suponha que o Sequenciador seja operado pela equipe de desenvolvimento L2 ou por uma instituição respeitável. Se o Sequenciador assegurar aos usuários, ao receber suas transações, que elas serão incluídas imediatamente ou no Xº bloco, essa garantia pode ser suficiente para aqueles dispostos a confiar no Sequenciador. Isso é semelhante a um usuário que confia em seu aplicativo de carteira e não verifica repetidamente o Etherscan para confirmação de transação depois que a carteira os notificou da inclusão.

Esta garantia fornecida pelo Sequenciador é referida como Pré-Confirmação, Confirmação Rápida ou Confirmação Suave. Estas podem ser compreendidas como garantias de inclusão de transação “prematuras” ou “suaves”. Elas não exigem esperar que a transação L2 seja incluída em um bloco L1, mas são apenas compromissos verbais do Sequenciador. O Sequenciador pode esquecer sua promessa devido a um bug ou um Sequenciador malicioso pode quebrar sua promessa, resultando em tempo desperdiçado para o usuário ou, no pior caso, exposição a um “ataque de gasto duplo.”

Em seguida, apresentaremos várias maneiras diferentes de apresentar o status da inclusão da transação L2.

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

Atualmente, quando os usuários executam transações na Arbitrum ou Optimism, quase imediatamente recebem um recibo de transação, que inclui o resultado da execução da transação. Isso indica que o Sequenciador já ordenou e simulou a execução da transação localmente, e o recibo de transação funciona como uma Pré-Confirmação para o usuário.

Para obter mais informações sobre o ciclo de vida detalhado da transação na Arbitrum, você pode consultar o documento oficial em:https://docs.arbitrum.io/tx-lifecycle

Para obter uma explicação mais detalhada do ciclo de vida da transação na Optimism, consulte o documento oficial em: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Verificando o status de inclusão de transações no Arbitrum

As transações exibidas no Explorador Arbitrum incluem aquelas com Pré-Confirmação, ou seja, transações ainda não carregadas no L1. Como mostrado na imagem a seguir, uma transação com Número de Bloco 145353000 está marcada como "Confirmado pelo Sequenciador", indicando que foi confirmada pelo Sequenciador, mas ainda não foi carregada no L1:

[Imagem mostra uma transação confirmada pelo Sequenciador mas não carregada para L1]

Em contraste, a próxima imagem mostra uma transação que já foi carregada para L1, com um status de "69 L1 Block Confirmations". Isso significa que o bloco L1 que contém esses dados de transação tem 69 blocos a seguir, o que indica um nível mais alto de segurança:

[Imagem mostra uma transação na L1 com 69 confirmações de bloco]

Outro exemplo é uma transação com 6174 confirmações de bloco L1, como mostrado abaixo, que é considerada muito segura.

No entanto, seria melhor se as informações de Finalidade L1 fossem integradas a esta exibição. Apenas dizer aos usuários o número de Confirmações de Bloco L1 é de ajuda limitada, pois eles têm que entender e calcular que nível de segurança esse número representa. Como a Camada 1 (Ethereum) possui um mecanismo de Finalidade como o Casper FFG, o Explorer poderia exibir diretamente se o bloco da Camada 1 foi Finalizado. Atualmente, o Explorer da Optimism implementou esse recurso.

Verificando o Status de Inclusão da Transação na Optimism

As transações exibidas no Explorador da Optimism também incluem aquelas com Pré-Confirmação, ou seja, transações ainda não enviadas para L1. Como mostrado na imagem a seguir, uma transação com Número do Bloco 111526300 está marcada como "Confirmada pelo Sequenciador":

[A imagem mostra uma transação apenas confirmada pelo Sequenciador, mas não carregada para L1]

No entanto, o Explorer não define claramente o significado de "Confirmado pelo Sequenciador." Ele afirma que "as confirmações do sequenciador são equivalentes a algumas confirmações de bloco no L1", sugerindo que uma transação marcada como "Confirmada pelo Sequenciador" foi enviada para o L1 e tem vários blocos a seguir:

[A imagem mostra transações recentes marcadas como "Confirmado pelo Sequenciador"]

Transações de vários dias atrás, mesmo aquelas passadas do período de desafio, ainda exibem o status “Confirmado pelo Sequenciador”:

[Imagem mostra transações de dias atrás ainda marcadas como 'Confirmadas pelo Sequenciador']

Nota: O Explorer pode exibir diferentes status em lugares diferentes: “Confirmado pelo Sequenciador” ao lado do Número do Bloco indica que o bloco foi confirmado pelo Sequenciador. Para verificar o status após ser carregado para L1, os usuários precisam procurar por outras informações, como o “Lote de Estado L1” mencionado abaixo.

Como mostrado na captura de tela a seguir, uma transação já enviada para L1 inclui informações adicionais: “Índice do Lote de Estado L1” e “Hash da Transação de Submissão de Raiz de Estado L1.” Esses detalhes indicam em qual Lote de Estado a transação L2 está incluída e qual transação L1 enviou esse Lote de Estado para L1:

[Imagem mostra uma transação com informações de lote de estado L1]

Clicar no Lote de Estado '3480' revela seu status como Finalizado. Esse status Finalizado corresponde à mainnet do Ethereum e indica um estado muito seguro, tendo acumulado com sucesso duas épocas de votos de validadores.

[Imagem mostra Lote de Estado 3480 finalizado no Bloco L1 18457449]

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

Se um Lote tiver sido carregado, mas ainda não tiver sido Finalizado em L1, ele será exibido como Não Finalizado:

[Imagem mostra um lote de estado carregado para L1, mas ainda não finalizado]

Em comparação com o Arbitrum Explorer, o Optimism Explorer fornece mais informações (Lote de Estado) e integra diretamente as informações de Finalidade L1 no Explorer L2, permitindo que os usuários saibam se o bloco L1 foi Finalizado sem ter que interpretar o número de Confirmações de Bloco para segurança.

Status de Receita de Transação StarkNet

Atualmente, quando os usuários enviam transações na StarkNet, eles podem acessar rapidamente o recibo da transação. No entanto, o status frequentemente exibido no recibo é RECEBIDO, indicando que o nó recebeu e validou a transação como livre de erros. Em seguida, ele aguardará a inclusão e execução em um bloco L2 pelo Sequenciador. Transações no status RECEBIDO ainda não têm resultados de execução. Os usuários podem monitorar o progresso de suas transações por meio do status exibido no Explorador StarkNet.

Nota: Se o Sequenciador processar as transações com rapidez suficiente, ele pode pular o status RECEBIDO e ir diretamente para um estado processado. Para obter uma introdução mais detalhada ao processo de transação do StarkNet, consulte o documento oficial emhttps://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

No Starkscan, um explorador StarkNet, transações, incluindo Pré-Confirmação, são exibidas. Por exemplo, uma transação mostrada como "Aceita no L2" indica que foi sequenciada em um bloco L2:

“Aceito na L2” significa que a transação foi sequenciada em um bloco L2, mas ainda não foi carregada para L1.

Os dois estados anteriores, Recebido e Pendente, representam "transação recebida e validada" e "transação sendo processada pelo Sequenciador." Após o processamento, o status muda para Aceito no L2.

Transação recebida e verificada

A transação está sendo processada pelo Sequenciador

Depois que os dados da transação forem carregados no L1, o status mudará para Aceito no L1, conforme mostrado na figura abaixo para esta transação:

Os dados da transação foram enviados para L1

Embora as transações da StarkNet tenham um conjunto mais rico de status, permitindo que os usuários saibam o progresso de suas transações, o envio para L1 pode levar várias horas, principalmente devido ao tempo necessário para gerar provas de conhecimento zero. Portanto, os usuários dependem da Pré-Confirmação do Sequenciador durante este período.

O Explorer StarkNet mostra apenas a Aceitação no status L1 sem informações adicionais sobre a Finalidade L1 ou a Confirmação de Bloco. Os usuários precisam verificar se blocos suficientes foram adicionados após sua transação em L1 ou se ela foi Finalizada.

Devido às limitações de desempenho do StarkNet, à longa dependência da Pré-Confirmação e à falta de suporte para informações de Finalidade L1 no Explorer, a experiência do usuário para confirmação de inclusão de transações no StarkNet precisa de melhorias.

Status de inclusão de transações do zkSync

Similar ao StarkNet, zkSync também tem um status PENDING, o que indica que o nó recebeu e verificou a transação sem problemas. A transação então aguardará para ser incluída e executada em um bloco L2 pelo Sequenciador. Transações no status PENDING ainda não têm resultados de execução.

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

Dica de leitura: Se o Sequencer processar as transações com rapidez suficiente, pode ignorar o status PENDENTE e passar diretamente para um estado em que a transação já foi processada.

Para uma introdução mais detalhada ao processo de transação do zkSync, siga este link: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

As transações visualizadas no Explorer zkSync também incluem transações de Pré-Confirmação, como a que está na captura de tela abaixo. O status é atualmente “Processado na era zkSync,” indicando que foi arranjado em um bloco L2 pelo Sequenciador:

A transação foi organizada em um bloco L2 pelo Sequencer e atualmente está aguardando para ser carregada no L1 (Ethereum Sending).

Depois que o Sequencer conclui um bloco L2, o bloco e suas transações passam por três estágios: Confirmado, Comprovado e Executado. Estes indicam, respectivamente, que "o bloco é carregado em L1", "a validade do bloco é comprovada" e "o estado L2 pós-execução de transações dentro do bloco é atualizado para L1". Abaixo estão exemplos de blocos e transações nessas diferentes etapas:

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

O status das transações no lote 292700 muda de Envio de Ethereum para Validação de Ethereum, indicando que estão aguardando a validação da prova de conhecimento zero de 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:

Essa 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.

O lote 292000 teve sua validade comprovada, então ele entra na fase Comprovada:

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

As transações passam de "Validando" para "Executando", o que significa que estão aguardando para serem executadas.

Depois que um lote é comprovado, há um período de espera (cerca de 21 horas de acordo com a documentação oficial) antes de executar as transações dentro dele e atualizar o estado L2 registrado no L1. Esta é uma medida de proteção na fase Alpha para garantir tempo de reação suficiente em caso de bugs. Uma vez que o lote é executado, ele entra na fase final Executado:

Após a execução, o Lote entra no estado Executado final, com um link para a transação que executa a ação Executar.

O status das transações dentro do Lote também é atualizado para "Executado."

Comparado ao StarkNet, onde as transações se movem do L2 para o L1 em um único passo, o zkSync divide o processo do L2 para o L1 em três estágios mais detalhados: Committed → Proven → Executed. Embora como medida de proteção, o processo de transação inteiro leve cerca de um dia, o status Committed permite aos usuários saber rapidamente se sua transação foi incluída (pós-Committed, não é apenas Pré-Confirmação) sem depender exclusivamente da confiança no Sequenciador. Além disso, o zkSync Explorer fornece dados abrangentes para cada estágio, permitindo que qualquer pessoa acompanhe o status mais recente das transações e até verifique as transições entre os estágios (por exemplo, de Committed para Proven, de Proven para Executed).

No entanto, é importante observar que, como medida de proteção na fase Alpha, o Sequenciador zkSync atualmente pode modificar registros históricos. Isso significa que, mesmo que as transações possam sair rapidamente da Pré-Confirmação para a fase Comprometida, o Sequenciador ainda pode remover transações de usuários do registro histórico até que atinjam a fase Executada. Portanto, os usuários ainda precisam confiar no Sequenciador por até um dia.

L1 Também Pode Suportar Pré-Confirmação

Se for possível saber antecipadamente quem é responsável pela produção de blocos, então L1 também pode suportar a Pré-Confirmação. Tomando Ethereum como exemplo, o produtor de bloco real é o Construtor, que pode oferecer serviços de Pré-Confirmação, fornecendo aos usuários uma garantia de inclusão de transação. No entanto, como o Construtor não tem o direito garantido de produzir um bloco específico, mas deve licitar pelo direito de produzir cada bloco, a eficácia desta Pré-Confirmação é relativamente fraca. Além disso, a força do Construtor deve ser considerada; se um Construtor carece de força competitiva, será difícil para ele ganhar o direito de produzir blocos, diminuindo o valor de seu serviço de Pré-Confirmação.

Uma solução melhor para evitar esses problemas seria o Proponente oferecer serviços de Pré-Confirmação, pois é geralmente predeterminado e certo qual Proponente proporá qual bloco. No entanto, na arquitetura atual de PBS (Proposer-Builder Separation), o Proponente é apenas responsável por propor blocos, enquanto o Construtor decide o conteúdo do bloco. Portanto, o Proponente não pode inserir diretamente uma transação em um bloco ou pedir ao Construtor para fazê-lo. Essa situação pode mudar com modificações futuras na arquitetura de PBS, como adicionar uma Lista de Inclusão ou permitir que Proponentes participem na produção de blocos, possibilitando que os Proponentes ofereçam serviços de Pré-Confirmação.

Dica de leitura: Para mais informações sobre PBS, por favor copie o link abaixo para o seu navegador para ler: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Melhorando Pré-Confirmação

Pré-Confirmação é apenas uma promessa verbal de um Construtor ou Sequenciador L2, sem obrigação de cumpri-la e sem mecanismo de punição para o não cumprimento. Esta promessa pode ser tornada mais confiável? Sim, porque o conteúdo do compromisso (por exemplo, "incluir esta transação no bloco 1350000") feito pela pessoa responsável pela produção de blocos pode ser escrito como uma verificação condicional. Assim, podemos usar contratos inteligentes para regular Construtores ou Sequenciadores, pedindo-lhes para depositar garantias no contrato inteligente ao oferecer serviços de Pré-Confirmação e assinar o conteúdo do compromisso. Se os usuários constatarem que os Construtores ou Sequenciadores não cumpriram suas promessas, eles podem submeter o compromisso e a assinatura ao contrato inteligente para verificação.

Embora a aplicação de tais contratos ainda esteja na fase de prova de conceito, o seguinte link para um vídeo de apresentação mostra um exemplo de aplicação de contrato:

https://www.youtube.com/watch?v=Uw5HxSYXwYo

Resumo

Após uma transação L1 ser incluída em um bloco L1, a probabilidade de um Re-org diminuir gradualmente, e a confiança dos usuários em sua transação ser incluída aumenta.

As transações L2 têm um fluxo de trabalho adicional em comparação com as transações L1: a fase de “transação L2 sendo incluída em um bloco L2 e aguardando para ser enviada para L1.” Durante esta fase, uma vez que os dados ainda não foram enviados para L1, ainda existe a possibilidade de alterações, e assim a única garantia que os usuários têm sobre a inclusão de sua transação é o compromisso verbal do Sequenciador, conhecido como Pré-Confirmação, Confirmação Rápida ou Confirmação Suave.

Se o Sequenciador for malicioso ou encontrar um bug, seus compromissos podem ser quebrados, o que pode levar à falta de confirmação para a transação L2 do usuário.

Atualmente, a maioria dos L2s exibe o status da transação em seus Explorers, incluindo o status de Pré-Confirmação, como "Confirmado pelo Sequenciador" do Arbitrum/Optimism ou "Aceito no L2" do StarkNet. Os usuários devem estar cientes da validade temporal da garantia de inclusão da transação fornecida por esses status.

Se os usuários não quiserem confiar na Pré-Confirmação do Sequenciador, eles precisarão esperar mais tempo e validar por meio das informações fornecidas pelo Explorador L2 sobre os dados L2 sendo enviados para L1.

Pré-confirmação pode incluir um mecanismo de incentivo econômico, como penalidades através de contratos inteligentes para Sequenciadores que quebram suas promessas, oferecendo uma proteção mais clara aos usuários.

A tabela abaixo mostra as garantias de inclusão de transações e os cenários de risco correspondentes para diferentes estágios de transações L1 e L2: [Observação: a tabela não é fornecida na tradução.]

Aviso Legal：

1. Este artigo foi republicado de [imToken Labs]. Todos os direitos autorais pertencem ao autor original [Nic]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As 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. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.