Autor: Fausto, Geek Web3
No mundo real, quase todos os edifícios altos têm um ingrediente indispensável: uma saída de segurança. Quando ocorrem emergências como incêndios e terramotos, as saídas de segurança salvam vidas para garantir a segurança da vida das pessoas. No sistema de plataforma de custódia Ethereum Layer 2, que carrega dezenas de bilhões de dólares em ativos, a função de “retirada forçada”, que permite aos usuários retirar ativos com segurança para a Camada 1, tornou-se uma facilidade indispensável e necessária.
Em seu recente artigo “Different types of layer 2s”, Vitalik também enfatizou que a capacidade dos usuários de retirar ativos sem problemas da camada 2 para a camada 1 é um indicador de segurança muito importante.
No entanto, a questão da “retirada suave” não parece ter recebido muita atenção da maioria das pessoas no passado, e mesmo muitos projetos da Camada 2 não lançaram a função “retirada forçada” ou “escape pod”. Na era em que o ecossistema L2 não está em pleno andamento, ignorar “retiradas sem permissão” não parece ser um problema. Mas agora que a Camada 2 tem mais de US$ 12 bilhões em ativos, tornou-se um edifício “grande demais para falir”. Se tal arranha-céu não tiver uma saída de segurança, as consequências são simplesmente inimagináveis.
Com o objetivo de fazer com que os leitores prestem atenção aos riscos de segurança da Camada 2, “Geek Web3” tomará o Loopring Protocol V3 e o Arbitrum como exemplos abaixo para explicar por que “funções de retirada sem permissão”, como tração forçada e escape hatch, são uma parte indispensável da Camada 2.
(De acordo com o navegador L2BEAT dYdX, a função de transação/retirada forçada dYdX foi usada 152 vezes até agora, e houve 7 grandes saques de mais de US$ 1 milhão.)
A resistência à censura é o grande problema: o que fazer se o sequenciador rejeitar deliberadamente o seu pedido****
No passado, artigos científicos populares sobre a Camada 2 muitas vezes tinham um problema, ou seja, na maioria das vezes eles se concentravam em “segurança” e “usabilidade” na superfície, mas ignoravam a “resistência à censura”. Mesmo quando se fala em soluções de sequenciadores descentralizados, muitas pessoas prestam atenção se o MEV é descentralizado, não a resistência à censura.
Em outras palavras, a maioria das pessoas tende a se concentrar em saber se as transições de estado da Camada 2 são válidas, se o sequenciador pode roubar moedas e se o sistema de prova de validade de fraude/validade está em uso, mas ignoram um risco que não deve ser negligenciado: e se o Sequencer continuar rejeitando suas solicitações de transação, ou simplesmente falhar por um longo tempo, ou até mesmo cair? **
Você sabe, durante a interrupção de Solana, houve pessoas que não conseguiram cobrir suas posições a tempo porque seus ativos estavam enfrentando liquidação, colocando milhões de dólares em ativos em risco. **Uma vez que tal rejeição do pedido do usuário ocorre, o prejuízo econômico causado não é desprezível.
Mesmo que apenas algumas pessoas pudessem estar nessa situação, se caísse em alguma baleia com muito dinheiro, todo o mercado poderia sofrer (digamos que alguém tenha centenas de milhões de dólares em ativos em um protocolo de empréstimo Defi no Ethereum que poderia ser liquidado em uma semana, mas ele está na lista de sanções do OFAC por usar o Tornado). A maior parte dos fundos desta pessoa está no PO e o sequenciador do PO trabalha com o OFAC para rejeitar o seu pedido)
Podemos muito bem projetar esse problema em cadeias públicas, como avalanche ou polígono, que são independentes do Ethereum. Se mais de 2/3 dos nós de consenso do validador no Avalanche decidirem censurar suas transações, eles podem se recusar a incluir seu Txn em um bloco ou não reconhecer o bloco que contém seu Txn. Neste momento, o seu dinheiro está basicamente enterrado nesta cadeia e não pode sair:**
A menos que você possa cooptar alguns validadores para que menos de 2/3 dos validadores estejam envolvidos no ataque de censura, ou você pode chamar algumas pessoas para bifurcar o Avalanche através do consenso social. Obviamente, neste ponto, você ainda tem uma maneira de retirar fundos rapidamente do Avalanche, e temos que considerar que mais de 2/3 dos Validadores unem forças para iniciar uma revisão de transação de um determinado endereço, o que leva um tempo para conseguir, o que deixará tempo suficiente para os usuários censurados “escaparem”.
Mas na camada 2, a situação pode ser muito diferente. O Sequencer de Camada 2 é geralmente executado pelo próprio funcionário, e se o Sequencer quiser lançar um ataque de censura contra você, ele pode “congelar seu dinheiro na Camada 2”, ou seja, rejeitar completamente sua solicitação de transação para cruzar ativos de L2 para L1. Obviamente, de acordo com o mecanismo de operação de L2, se você não pode ignorar o sequenciador para executar uma operação de retirada, é totalmente possível que o Sequencer congele os ativos em L2 e não possa ser transferido.
Então, como resolver esse tipo de problema? Na verdade, para ser franco, como implementar a função de retirada “sem permissão”, para que os usuários possam retirar seus ativos para a Camada 1 sem qualquer dano quando forem revisados pelas partes do projeto Sequencer ou da Camada 2? Existem alguns projetos que propuseram o Sequencer descentralizado, mas esta não é uma solução paliativa, e se um número muito limitado de sequenciadores unir forças para revisá-lo, você ainda pode “congelar” seus ativos, e anti-bruxa de nós POS também é um problema complicado (veja Eventos Multichain).
A maneira mais eficaz de fazer isso é configurar uma “saída” diretamente na cadeia L1, permitindo que os usuários retirem fundos de L2 através de uma saída dedicada em L1 se não obtiverem uma resposta do Sequencer por um longo tempo. **
Protocolo de Loopring V3 Modelo de Retirada Forçada e Liquidação de Falência
Aqui tomamos a versão V3 do protocolo Loopring como exemplo, que lista dois cenários diferentes para retiradas forçadas iniciadas pelo usuário, o primeiro caso é:
Os usuários podem iniciar uma retirada forçada diretamente na Camada 1 através da função forcedWithdraw no contrato ExchangeV3 e declarar qual conta L2 eles têm no protocolo Loopring e que tipo de token eles querem retirar. Depois disso, o contrato ExchangeV3 lança um evento on-chain para indicar que alguém iniciou uma solicitação de retirada forçada. Como todos os nós do protocolo Loopring (incluindo o Sequencer) estão executando clientes Geth, sabe-se pelo bloco Ethereum que alguém iniciou uma retirada forçada e acionou o evento on-chain correspondente.
É importante notar que os levantamentos forçados não são processados imediatamente, mas são colocados na fila pendenteForcedWithdrawals e estão pendentes. **O Sequencer notou que depois que alguém inicia uma retirada forçada na Camada 1, a função Processo no contrato ExchangeV3 é acionada dentro de 15 dias para transferir o token para o iniciador de retirada na cadeia Ethereum (do endereço de depósito da parte do projeto L2 na cadeia Ethereum para transferir dinheiro para o saqueador).
Se o Sequencer não responder à solicitação de retirada forçada do usuário dentro de 15 dias, o usuário poderá chamar a função notifyForcedRequestTooOld para que o contrato ExchangeV3 lance um evento chamado WithdrawalModeActivated para notificar o nó completo do protocolo Loopring de que o modo de liquidação de falência está ativado. **
**Se o modo de liquidação for ativado, o Loopring V3 deixará de receber novos blocos L2 enviados pelo Sequencer, o que significa que todo o protocolo Loopring deixará de funcionar. Este processo dura pelo menos 30 dias.
No entanto, no modo de liquidação de falência, os usuários ainda podem retirar seus ativos na Camada 1, mas precisam enviar uma prova merkle para provar seu status/status de ativos, que pode ser verificada na árvore de estados L2. (Prove que o seu saldo de ativos na Camada 2 é consistente com o montante que declarou quando iniciou o levantamento)
Este modelo de liquidação de falência do Protocolo Loopring também é conhecido como o mecanismo Escape Hatch no L2BEAT. Esse modo é acionado em um pré-requisito para que o sequenciador não responda à solicitação de retirada forçada do usuário dentro do tempo especificado, ou se o sequenciador tiver uma falha ou tempo de inatividade de longo prazo. Neste momento, o usuário pode acionar manualmente o contrato de Rollup no modo de congelamento/parar de executar. Em seguida, os usuários podem construir provas merkle para provar seus ativos na Camada 2 e retirar seus próprios ativos do endereço de depósito do grupo do projeto L2 em L1. **
Na documentação da StarkEx, um diagrama esquemático dedicado deste processo também é desenhado. Se o usuário L2 não receber uma resposta sequenciadora no final da janela de 7 dias quando o usuário L2 enviar uma solicitação de retirada forçada em L1, o usuário L2 pode chamar a função de solicitação de congelamento para fazer com que o L2 entre no período de congelamento. Neste caso, o sequenciador L2 não será capaz de atualizar o estado de L2 em L1, e levará 1 ano após o estado L2 ser congelado para ser descongelado. Depois disso, os usuários podem enviar uma prova Merkle e retirar dinheiro.
No entanto, para construir Merkle Proof, você precisa conhecer a árvore de estado L2 completa primeiro, ou seja, você precisa encontrar um nó completo L2 para pedir dados e, ao mesmo tempo, você precisa de um pedaço de código para gerar merkle Proof, o que obviamente requer um certo limite técnico. Para a conveniência da maioria dos usuários, L2BEAT afirmou anteriormente que a Camada 2 deve configurar um número de nós completos com permissões abertas e código fonte aberto para ajudar os usuários a saber o status de todas as contas em L2 (incluindo saldo, número de transações, etc.). Este movimento também ilustra a importância das retiradas obrigatórias e dos mecanismos de escape pod.
Funcionalidade “Transações de inclusão forçadas” da Arbitrum
Mas retiradas forçadas/cápsulas de fuga não parecem ser a única solução resistente à censura. Por exemplo, o Arbitrum usa o método de “forçar a inclusão de transações”, o usuário pode primeiro enviar o Txn/retirada que precisa ser processado pelo Sequencer no contrato de Caixa de Entrada atrasado em L1, e se o Sequenciador não o processou por mais de 24 horas, o usuário pode chamar a função de Inclusão de força do contrato de Caixa de Entrada do Sequencer em L1. Deixe Txn ser incluído diretamente na sequência de transações do Arbitrum** (lance um evento on-chain para informar aos nós completos do Arbitrum que Txn com alguns registros de caixa de entrada atrasados precisam ser incluídos no livro-razão L2).
Em contraste, a abordagem do Arbitrum é mais simples, mas ainda é um pouco inexistente: ele apenas lança um evento on-chain dizendo ao nó Arbitrum que há algumas transações que o sequenciador ignora que precisam ser incluídas na cadeia mais longa L2, em vez de permitir que os usuários retirem dinheiro diretamente no L1 como o Loopring Protocol e o modo de falência/pod de fuga da StarkEx fazem. Se os nós desafiantes da Arbitrum se unirem para lançar um ataque de censura, parece que ainda seria possível congelar o dinheiro dos usuários no L2. **
Portanto, a força de inclusão do Arbitrum não é permissível o suficiente, e embora fosse bom dizer que o sequenciador ignorou a solicitação forceInclusion de um usuário, desde que houvesse um nó honesto disposto a postar uma prova de fraude, isso ainda introduz um certo grau de presunção de confiança, embora em menor grau.
Mais precisamente, “transações que precisam ser incluídas obrigatoriamente” devem ser reconhecidas por pelo menos um nó challenger ARB, que atualmente tem 9 nós que têm o direito de decidir quais mensagens de cadeia cruzada L2-L1 permitir, e agora apenas eles podem emitir provas de fraude. **Enquanto esses 9 nós colidirem, teoricamente a “transação forçada” do usuário ainda pode ser invalidada. **
Portanto, a atual inclusão obrigatória de transações/retiradas no Arbitrum não é como o modelo de liquidação de falência da Loopring e StarkEx, que não requer permissão do nó L2. No entanto, o L2BEAT ainda deu à Arbitrum uma classificação elevada para esta solução. Porque no futuro, a Arbitrum lançará um mecanismo de liberação à prova de fraude sem permissão chamado BOLD, e será difícil ou impossível para nós desafiantes conluiarem naquele momento (na verdade, é difícil conluiar agora).
De acordo com o L2BEAT, o TVL atual é superior a US $ 50 milhões, e não há resposta para qualquer uma das Falhas do Sequenciador ou Falhas do Proponente: **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. Esses L2s podem fazer com que os ativos do usuário sejam congelados em L2 em casos extremos. **
Então, obviamente, o modelo de retirada forçada ou liquidação de falência tem sua necessidade, embora no momento só conte com o usuário-sequenciador como um jogo de contraparte para funcionar, ** não está realmente “pronto para retirar” ** (Arbitrum tem um atraso de 24 horas e pode falhar, Loopring tem um atraso máximo de 15 dias, StarkEx tem um atraso máximo de 7 dias), mas é claro que “algo é melhor do que nada”. Além disso, acredita-se que o problema dos atrasos nos levantamentos forçados seja devidamente resolvido no futuro com uma conceção de mecanismos mais sofisticada** (atualmente, isso deve-se principalmente ao facto de alguns cientistas MEV poderem utilizar o forceInclusion para iniciar transações de execução prévia, pelo que é necessário introduzir atrasos). Para mais detalhes, consulte os documentos oficiais das principais partes do projeto L2).
Com a inclusão do Sequencer descentralizado em mais e mais roteiros L2, e a Fundação Ethereum liderada por Vitalik continua a educar as pessoas sobre a segurança da Camada 2, os recursos de transação resistentes à censura, como saques forçados, devem receber cada vez mais atenção, o que tornará o sistema Ethereum Layer2 mais próximo de um sistema de infraestrutura financeira resistente à censura e sem confiança. Se a Camada 2 implementar acesso sem confiança a fundos, acredita-se que mais criadores de mercado e provedores de liquidez entrarão na infraestrutura L2, e a adoção em massa de toda a web3 será empurrada um passo adiante.
