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

Este artigo irá apresentar aos leitores todo o processo de implementação da transação 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 da 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 Optimistic Rollup e Validity (ZK) Rollup

Compreender Transações L1

Processo de Transação

Depois de um usuário emitir e assinar uma transação, ela é enviada para a rede peer-to-peer e aguarda que um Miner sob o mecanismo de consenso PoW ou um Proponente sob o mecanismo de consenso PoS a inclua em um bloco. Quando um usuário percebe que sua transação foi incluída no último bloco, não pode ter a certeza de 100% de que a transação será registrada permanentemente na história dessa blockchain. Isso se deve à possibilidade de um evento de blockchain conhecido como "Re-org". Os usuários devem esperar até que a probabilidade de ocorrer um Re-org em determinado bloco seja suficientemente baixa para ter a certeza de que sua transação será registrada na história da blockchain.

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

Mesmo depois de uma transação ser incluída num bloco, ainda pode ocorrer um Re-org. É necessário 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 dos seus ativos. O método para calcular o custo de um Re-org não será discutido em detalhe aqui.

Compreender 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 ordenar transações. O Sequencer então inclui essa transação em um bloco L2. Posteriormente, quando o Sequencer grava os dados do bloco L2 de volta para L1 através 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 através de uma transação L1, ainda há a possibilidade de encontrar uma Reorganização L1. Este cenário pode levar a que o bloco L2 não seja incluído no histórico da blockchain, resultando efetivamente numa 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 utilizadores primeiro esperam que a sua transação seja incluída num bloco L2, depois esperam que o bloco L2 seja carregado para L1 através de uma transação L1 e, finalmente, esperam que a transação L1 seja finalizada. Embora esperar que uma transação L2 seja incluída num bloco L2 por um Sequenciador adicione um passo em comparação com as transações L1, este 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 a confirmar a transação L1. Assim, no geral, a experiência do utilizador para transações L1 e L2 é semelhante. Mas os utilizadores podem abrir mão de algumas concessões por uma experiência melhor?

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

Os utilizadores devem idealmente testemunhar as suas transações L2 (incluídas em blocos L2) serem incluídas em blocos L1 e até esperar até que a probabilidade de uma Re-org seja suficientemente baixa, antes de confiar que as suas transações L2 foram incluídas. Mas e se os utilizadores estiverem dispostos a confiar no Sequenciador? Suponhamos que o Sequenciador é operado pela equipa de desenvolvimento L2 ou por uma instituição reputada. Se o Sequenciador assegurar aos utilizadores, ao receber as suas transações, que estas serão incluídas imediatamente ou no Xº bloco, essa garantia pode ser suficiente para aqueles que estão dispostos a confiar no Sequenciador. Isto é semelhante a um utilizador que confia na sua aplicação de carteira e não verifica repetidamente o Etherscan para confirmação da transação depois de a carteira os ter notificado 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 requerem esperar que a transação L2 seja incluída num bloco L1, mas são meros compromissos verbais do Sequenciador. O Sequenciador pode esquecer a sua promessa devido a um bug ou um Sequenciador malicioso pode quebrar a sua promessa, resultando em tempo desperdiçado para o utilizador ou, no pior dos casos, 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.

Estado de inclusão da transação em Arbitrum/Optimism

Atualmente, quando os utilizadores 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 serve como Pré-Confirmação para o utilizador.

Para obter mais informações sobre o ciclo de vida detalhado da transação na Arbitrum, 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 no Optimism, consulte o documento oficial em: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Verificação do Estado de Inclusão da Transação na Arbitrum

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

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

Por outro lado, a próxima imagem mostra uma transação que já foi carregada para L1, com um status de "69 Confirmações de Bloco L1." Isso significa que o bloco L1 contendo esses dados de transação tem 69 blocos subsequentes, o que indica um nível mais elevado de segurança:

[Imagem mostra uma transação em 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 este visor. Simplesmente informar aos utilizadores o número de Confirmações do Bloco L1 é de pouca ajuda, uma vez que têm de compreender e calcular que nível de segurança este número representa. Uma vez que a Camada 1 (Ethereum) possui um mecanismo de Finalidade como o Casper FFG, o Explorador poderia mostrar diretamente se o bloco da Camada 1 foi Finalizado. Atualmente, o Explorador do Optimism implementou esta funcionalidade.

Verificação do Estado de Inclusão da Transação na Optimism

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

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

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

[Imagem mostra transações recentes marcadas como “Confirmadas 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”:

[A imagem mostra transações de dias atrás ainda marcadas como "Confirmadas pelo Sequenciador"]

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

Como mostrado na captura de ecrã seguinte, uma transação já carregada no L1 inclui informações adicionais: “Índice do Lote de Estado do L1” e “Hash de Transação de Submissão da Raiz do Estado do L1.” Estes detalhes indicam em que Lote de Estado a transação L2 está incluída e qual transação L1 carregou este Lote de Estado para o L1:

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

Clicar no Lote de Estado "3480" revela o seu estado como Finalizado. Este estado Finalizado corresponde à mainnet do Ethereum e indica um estado muito seguro, tendo acumulado com sucesso dois períodos de votos de validadores.

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

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

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

[Mostra um Lote de Estado carregado para L1 mas ainda não finalizado]

Comparado com o Explorador Arbitrum, o Explorador Optimism fornece mais informações (Lote de Estado) e integra diretamente informações de Finalidade L1 no Explorador L2, permitindo que os utilizadores saibam se o bloco L1 foi Finalizado sem terem que interpretar o número de Confirmações de Bloco para segurança.

Status da receita da 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 sem erros. Em seguida, 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 suficientemente rápido, poderá saltar o estado RECEBIDO e avançar 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, as transações que incluem Pré-Confirmação são exibidas. Por exemplo, uma transação mostrada como "Aceite no L2" indica que foi sequenciada num bloco L2:

"Aceite no L2" significa que a transação foi sequenciada num bloco L2, mas ainda não foi carregada para o L1.

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

Transação recebida e verificada

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

Após os dados da transação serem enviados para L1, o estado mudará para Aceite em L1, conforme mostrado na figura abaixo para esta transação:

Os dados da transação foram carregados para L1

Embora as transações StarkNet tenham um conjunto mais rico de estados, permitindo aos usuários acompanhar o progresso de suas transações, o carregamento 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 explorador StarkNet apenas mostra o estado Aceite na L1 sem informações adicionais sobre a Finalidade da L1 ou a Confirmação do Bloco. Os utilizadores precisam de verificar se foram adicionados blocos suficientes após a sua transação na L1 ou se 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 Explorador, a experiência do usuário para a confirmação de inclusão de transações no StarkNet precisa de melhorias.

Estado de Inclusão da Transação zkSync

Similar ao StarkNet, o zkSync também possui um estado PENDENTE, 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 num bloco L2 pelo Sequenciador. Transações em estado PENDENTE ainda não possuem resultados de execução.

Os utilizadores podem acompanhar o progresso das suas transações através do estado exibido no Explorer zkSync.

Dica de leitura: Se o Sequenciador processar as transações com rapidez suficiente, poderá contornar o estado PENDENTE e avançar 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 mostrada na captura de tela abaixo. O Status atual é "Processado pela Era zkSync", indicando que foi organizado em um bloco L2 pelo Sequenciador:

A transação foi organizada num bloco L2 pelo Sequenciador e está atualmente à espera de ser carregada para L1 (Ethereum Sending).

Após o Sequenciador completar um bloco L2, o bloco e suas transações passam por três estágios: Comitido, Provado e Executado. Estes indicam, respetivamente, que "o bloco é enviado para L1," "a validade do bloco é provada" e "o estado L2 pós-execução das transações dentro do bloco é atualizado para L1." Abaixo estão exemplos de blocos e transações nestes diferentes estágios:

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

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

Lote 292000 teve a sua validade comprovada, por isso entra na fase Proven:

Depois de um lote ser comprovado, ele entra no estado Comprovado, com um link para a transação que executa a ação de 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 em L1. Esta é uma medida de proteção na fase Alpha para garantir um tempo de reação amplo em caso de bugs. Uma vez que o lote é executado, ele entra na etapa final de execução:

Após a execução, o lote entra no estado final Executado, 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 com o StarkNet, onde as transações passam 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: Comprometido → Provado → Executado. Embora, como medida protetora, o processo de transação completo leve cerca de um dia, o status Comprometido permite aos usuários saber rapidamente se sua transação foi incluída (após o Comprometido, não é apenas Pré-Confirmação) sem depender apenas 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é mesmo verifique as transições entre os estágios (por exemplo, de Comprometido para Provado, de Provado para Executado).

No entanto, é importante notar que, como medida de proteção na fase Alpha, o Sequenciador zkSync pode atualmente 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 as transações do usuário 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 a L1 também pode suportar a Pré-Confirmação. Tomando o Ethereum como exemplo, o produtor real de blocos é o Builder, que pode oferecer serviços de Pré-Confirmação, fornecendo aos usuários a garantia da inclusão da transação. No entanto, uma vez que o Builder 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 Builder deve ser considerada; se um Builder carece de força competitiva, será difícil para ele ganhar o direito de produzir blocos, diminuindo o valor do seu serviço de Pré-Confirmação.

Uma solução melhor para evitar esses problemas seria o Propositor oferecer serviços de Pré-Confirmação, pois geralmente é predeterminado e certo qual Propositor irá propor qual bloco. No entanto, na arquitetura atual da PBS (Propositor-Construtor Separado), o Propositor é apenas responsável por propor blocos, enquanto o Construtor decide o conteúdo do bloco. Portanto, o Propositor 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 da PBS, como adicionar uma Lista de Inclusão ou permitir que os Propositores participem na produção de blocos, permitindo que os Propositores ofereçam serviços de Pré-Confirmação.

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

Melhorando a Pré-Confirmação

Pré-Confirmação é apenas uma promessa verbal de um Construtor ou Sequenciador de L2, sem obrigação de a cumprir e sem mecanismo de punição pelo não cumprimento. Esta promessa pode ser tornada mais fiá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 garantia no contrato inteligente ao oferecer serviços de Pré-Confirmação e assinar o conteúdo do compromisso. Se os utilizadores verificarem que os Construtores ou Sequenciadores não cumpriram as suas promessas, 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

Depois de uma transação L1 ser incluída num bloco L1, a probabilidade de um Re-org diminui gradualmente e a confiança dos utilizadores na inclusão da sua transação 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 ser incluída num bloco L2 e aguardar para ser carregada para L1.” Durante esta fase, uma vez que os dados ainda não foram carregados para L1, ainda existe a possibilidade de alterações, e assim a única garantia que os utilizadores têm sobre a inclusão da 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, os seus compromissos podem ser quebrados, o que potencialmente levará à falta de confirmação da transação L2 do utilizador.

Atualmente, a maioria dos L2s exibe o estado da transação em seus Explorers, incluindo o estado Pré-Confirmação, como o “Confirmado pelo Sequenciador” da Arbitrum/Optimism ou o “Aceite no L2” da StarkNet. Os utilizadores devem estar cientes da validade temporal da garantia de inclusão da transação fornecida por esses estados.

Se os utilizadores não quiserem confiar na Pré-Confirmação do Sequenciador, terão de esperar mais tempo e validar através das informações fornecidas pelo Explorador L2 sobre os dados L2 que estão a ser carregados para L1.

A Pré-Confirmação pode incluir um mecanismo de incentivo económico, como penalidades através de contratos inteligentes para Sequenciadores que quebram as suas promessas, oferecendo uma proteção mais clara aos utilizadores.

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: [Por favor, note que a tabela não é fornecida na tradução.]

Aviso legal：

1. Este artigo é reproduzido a partir de [GateimToken Labs]. Todos os direitos autorais pertencem ao autor original [Nic]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as 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, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.