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 terramotos ocorrem, estas saídas são salva-vidas para a segurança das pessoas. De forma semelhante, no ecossistema Ethereum Camada 2, que detém bilhões de dólares em ativos, a funcionalidade de 'retirada forçada' que permite aos utilizadores repatriar ativos com segurança para a Camada 1 tornou-se uma instalação essencial.

Vitalik também enfatizou em seu recente artigo "Different Types of Layer 2s" que a capacidade dos usuários de retirar suavemente ativos 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 equipas de projetos de Camada 2 não implementaram funções de “retirada forçada” ou “saída 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 a lidar com mais de 12 mil milhões de dólares em ativos, tornou-se um arranha-céus “demasiado grande para falhar”. A ausência de uma saída de segurança num edifício 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 Loopring Protocol V3 e o Arbitrum como exemplos no texto a seguir para explicar por que "funções de retirada sem permissão", como retirada forçada e escotilha de escape, são componentes indispensáveis da Camada 2.

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

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

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

Vale ressaltar que durante a inatividade da Solana, houve casos em que as pessoas não puderam adicionar colateral 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 negação de pedidos de usuário podem levar a perdas econômicas significativas.

Mesmo que apenas alguns indivíduos possam encontrar tais situações, se isso acontecer com alguns 'baleias' detentores de grandes quantias de fundos, todo o mercado poderá sofrer. Por exemplo, suponhamos que alguém com centenas de milhões de dólares em ativos em um protocolo de empréstimo DeFi na Ethereum enfrente liquidação dentro de uma semana, mas seja sancionado pelo OFAC por usar o Tornado. A maioria dos seus fundos está na Optimism (OP) e o Sequenciador OP, em conformidade com o OFAC, recusa os seus pedidos.

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

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 Avalanche através de consenso social. Claramente, neste momento, ainda tem maneiras de retirar rapidamente os seus fundos do Avalanche. No entanto, devemos considerar que é necessário 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, proporcionando ao utilizador escrutinado tempo suficiente para 'escapar'.

Mas a situação pode ser bastante diferente na Camada 2. Os sequenciadores na Camada 2 são geralmente operados pela equipa oficial. Se um sequenciador quiser lançar um ataque de escrutínio contra si, pode 'congelar o seu dinheiro na Camada 2', recusando eficazmente os seus pedidos de transferência de ativos de L2 para L1. De acordo com o mecanismo operacional da L2, se não conseguir contornar o sequenciador para executar uma retirada, é inteiramente possível que o sequenciador congele os seus ativos na L2, impedindo a sua transferência.

Então, como pode ser resolvida esta questão? Em suma, como podemos implementar uma função de retirada 'sem permissão' que permita aos utilizadores retirar os seus ativos em segurança de volta para a Camada 1, mesmo sob escrutínio por um Sequencer ou uma equipa de projeto da Camada 2? Algumas equipas de projeto têm proposto a ideia de Sequencers descentralizados, mas esta é uma solução superficial. Se estes números limitados de Sequencers colaborarem para o escrutinar, ainda podem 'congelar' os seus ativos. Além disso, a questão dos ataques anti-Sybil nos nós de Prova de Participação (PoS) também é problemática (como visto no incidente da Multichain).

A solução mais eficaz é configurar uma ‘saída’ dedicada na blockchain da Camada 1, permitindo que os utilizadores levantem os seus fundos da Camada 2 através desta saída L1 nos casos em que não recebem uma resposta do Sequenciador durante um período prolongado.

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

Os utilizadores podem iniciar diretamente uma retirada forçada na Camada 1 usando a função forcedWithdraw no contrato ExchangeV3. Eles precisam declarar qual é a sua conta na Camada 2 no Protocolo Loopring e qual Token desejam retirar. Posteriormente, o contrato ExchangeV3 emite um evento de blockchain, sinalizando que alguém iniciou um pedido de retirada forçada. Uma vez que todos os nós no Protocolo Loopring, incluindo o Sequenciador, executam o cliente Geth, serão informados sobre a retirada forçada e o evento de blockchain correspondente a partir 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 perceber 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 falhar em responder a um pedido de levantamento forçado de um utilizador dentro de 15 dias, o utilizador pode chamar a função notifyForcedRequestTooOld. Esta ação faz com que o contrato ExchangeV3 emita um evento chamado WithdrawalModeActivated, notificando todos os nós no Protocolo Loopring de que o modo de liquidação de falência foi ativado.

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

No entanto, no modo de liquidação de falência, os utilizadores ainda podem retirar os seus ativos na Camada 1, mas precisam de enviar uma prova de merkle para comprovar o estado dos seus ativos, que pode ser verificado na árvore de estado da Camada 2. (Prove que o saldo dos seus ativos na Camada 2 é consistente com o valor que declarou quando iniciou a retirada.)

O artigo descreve o modelo de liquidação de falência do Protocolo Loopring, também conhecido como mecanismo de "Escape Hatch" no L2BEAT. Este modelo é acionado sob certas condições, como quando o sequenciador falha em responder a um pedido de retirada forçada do usuário dentro de um tempo especificado, ou se o Sequenciador sofrer 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 a situação de seus 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, existe um diagrama específico que ilustra este processo. Se um pedido de Levantamento Forçado de um utilizador da Camada 2 submetido na Camada 1 não obtiver resposta do sequenciador no prazo de 7 dias, o utilizador pode invocar a função de Pedido de Congelação para iniciar um período de congelamento para a Camada 2. Durante este período, o sequenciador da Camada 2 não pode atualizar o estado da Camada 2 na Camada 1. O estado congelado da Camada 2 dura um ano antes de poder ser descongelado. Posteriormente, os utilizadores podem submeter uma prova de Merkle e levantar os 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 Camada 2. Além disso, é necessário um código específico 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 afirmou anteriormente que a Camada 2 deveria configurar um lote de nós completos de acesso aberto e de código aberto, para ajudar os usuários a adquirir o status de todas as contas na L2 (incluindo saldo, número de transações, etc.). Essa ação também destaca a importância de mecanismos de retirada forçada e de escape.

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

No entanto, as retiradas forçadas/cápsulas de fuga não parecem ser a única solução anti-censura. Por exemplo, o Arbitrum emprega o método de 'inclusão de transação forçada', onde os utilizadores podem primeiro submeter as transações/retiradas que precisam de ser processadas pelo Sequenciador ao contrato de Caixa de Entrada atrasada na Camada 1 (L1). Se o Sequenciador falhar ao processá-las dentro de 24 horas, os utilizadores podem chamar a função de Inclusão forçada no contrato de Caixa de Entrada do Sequenciador 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 os nós do Arbitrum que várias transações registadas na Caixa de Entrada atrasada precisam de ser incluídas no livro-razão L2).

O texto discute as abordagens de diferentes protocolos de blockchain no tratamento de transações, com foco particular em 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. Apenas emite um evento on-chain para informar os 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 retirar 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 é totalmente 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 utilizador, isso ainda introduz um grau de pressuposição de confiança, embora seja 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 são também 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 atualmente no Arbitrum não são tão sem permissão quanto o modo de liquidação de falência do Loopring e StarkEx. No entanto, o L2BEAT ainda avalia muito positivamente 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, senão impossível, para os nós desafiantes conluio (o que já é difícil agora).

De acordo com os dados da L2BEAT, atualmente, as plataformas da Camada 2 (L2) com um Valor Total Bloqueado (TVL) superior a 50 milhões de USD, que não oferecem medidas para lidar com Falha do Sequenciador ou Falha do Proponente, incluem OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM e Metis. Estas plataformas L2 poderiam, em casos extremos, levar a que os ativos dos utilizadores fiquem congelados e não possam ser retirados da L2.

Portanto, é evidente que a necessidade de mecanismos como retiradas forçadas ou modos de liquidação por insolvência existe. Embora atualmente eles dependam principalmente da teoria dos jogos entre usuários e classificadores (produtores de pedidos) e não possam ser considerados verdadeiramente "retiráveis a qualquer momento" (Arbitrum tem um atraso de 24 horas que pode falhar, Loopring tem um atraso de até 15 dias, StarkEx tem um atraso máximo de 7 dias), ter esses mecanismos é evidentemente melhor do que não tê-los de todo. A questão do atraso nas retiradas forçadas poderia ser potencialmente resolvida no futuro com designs de mecanismos mais sofisticados. Os designs atuais levam em consideração a exploração potencial de MEV (Valor Máximo Extraível) através do forceInclusion, o que torna necessária 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 muitas roadmap da 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ção anti-censura em retiradas forçadas provavelmente ganharão mais atenção. Isso aproximará o ecossistema da Camada 2 do Ethereum de uma infraestrutura financeira resistente à censura e minimizada em termos de confiança. Se a Camada 2 alcançar uma forma minimizada de confiança para movimentar fundos para dentro e para fora, espera-se que mais criadores de mercado e fornecedores de liquidez entrem na infraestrutura da L2, avançando um passo em direção à adoção em massa da web3.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Faust, Web3 geek]. Todos os direitos autorais pertencem ao autor original [Faust, Web3 geek]. Se houver objeções a esta reimpressão, entre em contato com oGate Learnequipa, e eles vão tratar disso prontamente.
2. Responsabilidade de Isenção: As opiniões expressas neste artigo são unicamente 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, é proibido copiar, distribuir ou plagiar os artigos traduzidos.