No mundo real, quase todos os arranha-céus têm um elemento indispensável: uma saída de emergência. Quando eventos imprevistos como incêndios ou terremotos ocorrem, essas saídas são salva-vidas para a segurança das pessoas. Da mesma forma, no ecossistema da Camada 2 do Ethereum, que detém bilhões de dólares em ativos, a funcionalidade de "saque forçado" que permite aos usuários repatriar com segurança os ativos de volta para a Camada 1 se tornou uma instalação essencial.

Vitalik também enfatizou em seu artigo recente 'Diferentes Tipos de Camada 2' que a capacidade dos usuários de retirar ativos de forma suave da Camada 2 de volta para a Camada 1 é um indicador de segurança muito importante.

No entanto, a questão das "retiradas suaves" parece ter sido ignorada pela maioria no passado, e muitas equipes de projetos da Camada 2 não implementaram funções de "retirada forçada" ou "escapamento de emergência". Na era em que o ecossistema da Camada 2 ainda não estava maduro, ignorar as "retiradas sem permissão" parecia não ser um problema. Mas agora, com a Camada 2 movimentando mais de 12 bilhões de dólares em ativos, tornou-se um arranha-céu "grande demais para falhar". A ausência de uma saída de segurança em um prédio tão imponente é inimaginável.

Com a intenção de conscientizar os leitores sobre os riscos de segurança da Camada 2, “Geek Web3” usará o Protocolo Loopring V3 e o Arbitrum como exemplos no texto a seguir para explicar por que as “funções de saque sem permissão” como saque forçado e saída de emergência são componentes indispensáveis da Camada 2.

(De acordo com o navegador L2BEAT dYdX, até agora, a função de negociação/retirada forçada da dYdX foi usada um total de 152 vezes, com saques grandes excedendo um milhão de dólares em 7 casos) A resistência à censura é um grande problema: E se o Sequenciador recusar deliberadamente o seu pedido?

Artigos populares passados sobre a Camada 2 frequentemente tinham um problema: eles enfatizavam principalmente a 'segurança' e a 'usabilidade' superficial, mas negligenciavam a 'resistência à censura'. Mesmo ao discutir soluções descentralizadas de sequenciamento, o que muitas pessoas notaram foi se o MEV é descentralizado, em vez de melhorias na resistência à censura.

Em outras palavras, a maioria das pessoas tende a se concentrar em saber se as transições de estado na Camada 2 são eficazes, se os sequenciadores podem roubar moedas e se são empregados sistemas de provas de fraude/validade. No entanto, eles ignoram um risco que não deve ser negligenciado: E se o Sequenciador continuamente recusar suas solicitações de transação, ou simplesmente estiver com mau funcionamento por um período prolongado, ou até mesmo desligar?

Vale ressaltar que durante a inatividade da Solana, houve casos em que as pessoas não puderam adicionar garantias a tempo devido aos riscos de liquidação de ativos, resultando em milhões de dólares em ativos em risco. Tais cenários de negar solicitações de usuários podem levar a perdas econômicas significativas.

Mesmo que apenas algumas pessoas possam encontrar tais situações, se isso acontecer com alguns 'baleias' detentores de grandes quantias de fundos, o mercado inteiro poderá sofrer. Por exemplo, suponha que alguém com centenas de milhões de dólares em ativos em um protocolo de empréstimo DeFi no Ethereum enfrente a liquidação dentro de uma semana, mas seja sancionado pelo OFAC devido ao uso do Tornado. A maior parte de seus fundos está no Optimism (OP), e o OP Sequencer, em conformidade com o OFAC, recusa seus pedidos.

Vamos projetar essa questão em blockchains independentes como Avalanche ou Polygon, separadas do Ethereum. Se mais de dois terços dos nós de consenso do Validador no Avalanche decidirem realizar o escrutínio de transações contra você, eles poderão se recusar a incluir suas transações em um bloco ou negar o reconhecimento de um bloco contendo suas transações. Neste caso, os seus fundos estão essencialmente enterrados nesta cadeia e não podem ser levantados:

A menos que consiga persuadir alguns Validadores para que menos de dois terços estejam envolvidos no ataque de escrutínio, ou consiga reunir pessoas para bifurcar o Avalanche através do consenso social. Claramente, neste momento, ainda tem maneiras de retirar rapidamente os seus fundos do Avalanche. No entanto, devemos considerar que leva tempo para que mais de dois terços dos Validadores se unam e iniciem um escrutínio de transação contra um endereço específico, dando ao usuário escrutinado tempo suficiente para 'escapar'.

Mas a situação pode ser bastante diferente na Camada 2. Os sequenciadores na Camada 2 geralmente são gerenciados pela equipe oficial. Se um Sequenciador quiser lançar um ataque de escrutínio contra você, ele pode ‘congelar seu dinheiro na Camada 2,’ recusando efetivamente suas solicitações de transferência de ativos de L2 para L1. De acordo com o mecanismo operacional de L2, se você não puder contornar o Sequenciador para executar um saque, é totalmente possível para o Sequenciador congelar seus ativos na L2, impedindo sua transferência.

Então, como pode ser resolvido esse problema? Simplesmente, como podemos implementar uma função de saque 'sem permissão' que permita aos usuários retirar com segurança seus ativos de volta para a Camada 1 mesmo quando estiverem sob escrutínio de um Sequenciador ou de uma equipe de projeto da Camada 2? Algumas equipes de projeto propuseram a ideia de Sequenciadores descentralizados, mas esta é uma solução superficial. Se esses números limitados de Sequenciadores se unirem para escrutiná-lo, ainda podem 'congelar' seus ativos. Além disso, o problema dos ataques anti-Sybil em nós de Prova de Participação (PoS) também é problemático (como visto no incidente da Multichain).

A solução mais eficaz é configurar uma 'saída' dedicada na blockchain da Camada 1, permitindo que os usuários retirem seus fundos da Camada 2 através desta saída L1 nos casos em que não recebem resposta do Sequenciador por um período prolongado.

No contexto da versão 3 do Protocolo Loopring, ele descreve dois cenários diferentes para saques forçados iniciados pelo usuário. O primeiro cenário é o seguinte:

Os usuários podem iniciar diretamente uma retirada forçada na Camada 1 usando a função forcedWithdraw no contrato ExchangeV3. Eles precisam declarar qual é sua conta de Camada 2 no Protocolo de Loopring e qual Token desejam retirar. Posteriormente, o contrato ExchangeV3 emite um evento blockchain, sinalizando que alguém iniciou uma solicitação de retirada forçada. Como todos os nós no Loopring Protocol, incluindo o Sequencer, executam o cliente Geth, eles serão informados sobre a retirada forçada e o evento blockchain correspondente dos dados do bloco Ethereum.

É importante notar que um saque forçado não é processado imediatamente, mas sim colocado na fila de saques forçados pendentes, aguardando processamento. Ao notar um saque forçado iniciado na Camada 1, o Sequenciador geralmente aciona a função Process no contrato ExchangeV3 dentro de 15 dias. Esta função executa a transferência de tokens na cadeia Ethereum para o iniciador do saque (do endereço de depósito do projeto da Camada 2 na cadeia Ethereum para o sacador).

Se o Sequenciador não responder a uma solicitação de saque forçado do usuário dentro de 15 dias, o usuário pode chamar a função notifyForcedRequestTooOld. Essa ação faz com que o contrato ExchangeV3 emita um evento chamado WithdrawalModeActivated, notificando todos os nós no Protocolo Loopring que o modo de liquidação de falência foi ativado.

Se o modo de liquidação por falência for ativado, o Loopring Protocol V3 deixará de receber novos blocos L2 enviados pelo Sequenciador, o que significa que todo o Loopring Protocol deixará de operar neste momento. Esse processo durará pelo menos 30 dias.

No entanto, no modo de liquidação de falência, os usuários ainda podem sacar seus ativos na Camada 1, mas precisam enviar uma prova de merkle para comprovar o status de seus ativos, que pode ser verificado na árvore de status da Camada 2. (Provar que o saldo de seus ativos na Camada 2 está consistente com o valor declarado ao iniciar o saque.)

O artigo descreve o modelo de liquidação de falência do Protocolo Loopring, também conhecido como mecanismo 'Escape Hatch' no L2BEAT. Esse modelo é acionado sob certas condições, como quando o sequenciador falha em responder a uma solicitação de saque forçado de um usuário dentro de um tempo especificado, ou se o Sequenciador enfrenta uma falha ou desligamento de longo prazo. Em tais casos, os usuários podem acionar manualmente um processo que coloca o contrato Rollup em um estado congelado ou interrompido. Os usuários podem então construir uma Prova de Merkle para demonstrar sua situação de ativos na Camada 2 e retirar sua parte de ativos do endereço de depósito do projeto da Camada 2 na Camada 1.

Na documentação do StarkEx, há um diagrama específico ilustrando esse processo. Se uma solicitação de retirada forçada do usuário da Camada 2 enviada na Camada 1 não for respondida pelo sequenciador dentro de uma janela de 7 dias, o usuário pode invocar a função de solicitação de congelamento para iniciar um período de congelamento para a Camada 2. Durante esse período, o sequenciador da Camada 2 não pode atualizar o status da Camada 2 na Camada 1. O estado congelado da Camada 2 dura um ano antes de poder ser descongelado. Depois, os usuários podem enviar uma prova de Merkle e retirar seus fundos.

Mas para construir uma Prova de Merkle, é necessário primeiro obter a árvore de estado completa da Camada 2, o que significa adquirir dados de um nó completo da L2. Além disso, é necessário um pedaço específico de código para gerar a Prova de Merkle, apresentando claramente um certo nível de barreira técnica. Para facilitar isso para a maioria dos usuários, o L2BEAT havia afirmado anteriormente que a Camada 2 deveria configurar um lote de nós completos de acesso aberto e open-source, para ajudar os usuários a adquirir o status de todas as contas na L2 (incluindo saldo, número de transações, etc.). Essa medida também destaca a importância dos mecanismos de saída forçada e de escape.

Recurso de 'Inclusão Forçada de Transação' do Arbitrum

No entanto, as retiradas forçadas/pods de fuga não parecem ser a única solução anti-censura. Por exemplo, o Arbitrum emprega um método de 'inclusão forçada de transações', onde os usuários podem primeiro enviar as transações/saques que precisam ser processados pelo Sequencer para o contrato de Inbox atrasado na Camada 1 (L1). Se o Sequencer não conseguir processá-los dentro de 24 horas, os usuários podem chamar a função de inclusão forçada no contrato de Inbox do Sequencer L1, permitindo que a transação seja incluída diretamente na sequência de transações do Arbitrum (lançando um evento on-chain informando aos nós do Arbitrum que várias transações registradas no Inbox atrasado precisam ser incluídas no livro-razão da Camada 2 (L2)).

O trecho discute as abordagens de diferentes protocolos de blockchain no tratamento de transações, focando particularmente no Arbitrum em comparação com Loopring e StarkEx. Aqui está a tradução:

“Comparado com outros, o método da Arbitrum é um pouco mais simples, mas ainda tem falhas. Ele meramente emite um evento on-chain para informar aos nós da Arbitrum que várias transações ignoradas pelo sequenciador precisam ser incluídas na cadeia mais longa da L2, ao contrário do protocolo Loopring e do modo de falência/pod de escape do StarkEx, que permitem aos usuários retirarem diretamente seus fundos na L1. Se os nós desafiadores na Arbitrum se unirem para lançar um ataque de censura, parece possível congelar os fundos dos usuários na L2.

Portanto, o mecanismo de inclusão forçada da Arbitrum não é completamente sem permissão. Embora um único nó honesto possa publicar uma prova de fraude para apontar uma solicitação de inclusão forçada ignorada pelo sequenciador de um usuário, isso ainda introduz um grau de pressuposição de confiança, embora menor.

Mais especificamente, as 'transações que necessitam de inclusão forçada' devem ser reconhecidas por pelo menos um nó desafiante ARB. Atualmente, existem nove desses nós, e eles têm a autoridade para decidir quais mensagens entre cadeias cruzadas entre L2 e L1 aprovar, e eles também são os únicos que podem emitir provas de fraude. Se esses nove nós conspirarem juntos, teoricamente poderiam invalidar uma 'transação forçada' de um usuário.

Portanto, as transações de inclusão ou retirada de força atuais no Arbitrum não são tão permissivas quanto o modo de liquidação de falência da Loopring e StarkEx. No entanto, o L2BEAT ainda classifica muito bem essa abordagem do Arbitrum. No futuro, o Arbitrum lançará um mecanismo de publicação de prova de fraude sem permissão chamado BOLD, tornando difícil, se não impossível, para os nós desafiantes conluio (o que já é difícil agora).

De acordo com os dados da L2BEAT, atualmente, plataformas de Camada 2 (L2) com um Valor Total Bloqueado (TVL) superior a 50 milhões de dólares, que não oferecem medidas para lidar com Falha de Sequenciador ou Falha de Proponente, incluem OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM e Metis. Essas plataformas L2 podem, em casos extremos, levar a ativos dos usuários sendo congelados e incapazes de serem retirados da L2.

Portanto, é evidente que existe a necessidade de mecanismos como retiradas forçadas ou modalidades de liquidação de insolvência. Embora atualmente, eles se baseiem principalmente na teoria do jogo entre usuários e classificadores (produtores de pedidos), e não podem ser considerados verdadeiramente "retiráveis a qualquer momento" (Arbitrum tem um atraso de 24 horas que pode falhar, Loopring tem até 15 dias de atraso, StarkEx tem um atraso máximo de 7 dias), ter esses mecanismos é evidentemente melhor do que não tê-los. A questão do atraso nas retiradas forçadas poderia ser potencialmente resolvida no futuro com projetos de mecanismos mais sofisticados. Os projetos atuais levam em consideração a potencial exploração de MEV (Maximal Extractable Value) por meio da forceInclusion, exigindo a introdução de atrasos. Para mais detalhes, a documentação oficial de vários projetos L2 deve ser consultada.

Com a crescente inclusão de Sequenciadores descentralizados em muitos roteiros de Camada 2 e esforços contínuos de entidades como a Fundação Ethereum, liderada por Vitalik Buterin, para educar as pessoas sobre a segurança da Camada 2, funcionalidades como funções de transações anticensura em saques forçados provavelmente ganharão mais atenção. Isso aproximará o ecossistema da Camada 2 do Ethereum de uma infraestrutura financeira resistente à censura e minimizada em confiança. Se a Camada 2 alcançar uma maneira minimizada em confiança de movimentar fundos para dentro e para fora, espera-se que mais formadores de mercado e provedores de liquidez entrem na infraestrutura da L2, avançando um passo em direção à adoção em massa do web3.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Camada 2Faust, Web3 geek]. Todos os direitos autorais pertencem ao autor original [Faust, Geeks Web3]. Se houver objeções a esta reimpressão, entre em contato com oGate Learnequipe, e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer tipo de 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.