Análise do processo completo de execução de transações da Camada 2: Avaliação de segurança em cada fase

Camada 2(L2) tecnologia trouxe maior escalabilidade para o Ethereum, mas também aumentou a complexidade da confirmação das transações. Este artigo irá detalhar o fluxo completo de execução das transações L2 e analisar a segurança em cada fase.

Revisão do fluxo de transações L1

Após o usuário enviar a transação, deve aguardar que os mineradores ou validadores a incluam em um bloco. Mesmo que a transação tenha sido incluída, ainda é necessário esperar um certo número de blocos de confirmação para reduzir o risco de reorganização (Re-org). Somente quando a probabilidade de reorganização for suficientemente baixa, a transação pode ser considerada definitivamente confirmada.

Detalhes do processo de negociação da Camada 2

O processo de negociação de Camada 2, em comparação com a Camada 1, tem uma etapa a mais:

1. O usuário envia a transação para o Sequencer
2. Sequencer empacota as transações no bloco L2
3. Sequencer envia os dados do bloco L2 para o L1
4. Aguardar confirmação L1

Entre os passos 2 e 3, são exclusivos da Camada 2. Nesta fase, as transações ainda não estão na cadeia, e os usuários devem confiar na promessa do Sequencer, o que é chamado de "pré-confirmação" ( Pre-Confirmation ).

Mecanismo de confirmação de transações das principais soluções de Camada 2

Arbitrum/Optimism

• As transações podem quase instantaneamente obter recibos, isso é a pré-confirmação do Sequencer.
• O Explorer mostrará o estado da transação, incluindo "Confirmado pelo Sequencer" e o número de confirmações L1
• A Optimism também mostrará o estado de Finalidade L1

StarkNet

• O estado da transação inclui Recebido, Pendente, Aceite na Camada 2, Aceite na Camada 1
• O tempo de confirmação de L2 para L1 é mais longo, cerca de 4-5 horas
• O Explorer não mostrou informações de Finalidade L1

zkSync

• O estado da transação inclui Pending, zkSync Era Processed, Committed, Proven, Executed
• Dividir o processo de L2 para L1 em três fases
• O Explorer fornece informações detalhadas sobre cada fase.

Mecanismo de pré-confirmação da L1

Se for possível saber com antecedência quem é o minerador, a L1 também pode suportar pré-confirmação. Na arquitetura PBS, o Builder pode fornecer serviços de pré-confirmação, mas sua eficácia é relativamente fraca. No futuro, se o Proposer puder participar da criação de blocos, o mecanismo de pré-confirmação pode ser mais confiável.

Melhorar o mecanismo de pré-confirmação

Pode-se permitir que o Builder ou Sequencer deposite um montante em garantia através de contratos inteligentes e assine o conteúdo da promessa. Se a promessa for violada, o usuário pode apresentar provas e penalizar a outra parte, aumentando assim a credibilidade da pré-confirmação.

Resumo

• As transações de Camada 2 têm uma fase adicional de espera para serem enviadas para a Camada 1.
• Antes de carregar a L1, os utilizadores só podem depender da pré-confirmação do Sequencer.
• A maioria dos Exploradores de Camada 2 mostrará o estado de pré-confirmação.
• Aguardar o upload de dados L2 para L1 é a prática mais segura.
• Pode-se aumentar a fiabilidade da pré-confirmação através de mecanismos de incentivos económicos.

A tabela abaixo resume as garantias de confirmação e riscos das transações L1 e Camada 2 em cada fase:

| Fase | Transação L1 | Transação L2 | |------|--------|--------| | Enviar Transação | Sem Garantia | Sem Garantia | | Pré-confirmação | O Builder compromete-se com ( que poderá ) no futuro | O Sequencer compromete-se | | Empacotar blocos | Garantia alta | Garantia média ( depende do Sequencer ) | | Carregar L1 | - | Alta garantia | | Múltiplas confirmações | Garantia extremamente alta | Garantia extremamente alta | | Confirmação Final | Máxima Garantia | Máxima Garantia |