Ir para o conteúdo
Financial Context Wiki

Saque forçado em L2

Guia por protocolo sobre inclusão forçada, saque forçado e rota de escape: o que cada mecanismo garante, do que depende e como verificar a saída.

Atualizado

Conteúdo apenas educacional; não constitui orientação financeira ou de segurança. Mecanismos de saída, prazos, taxas, permissões de contratos e premissas de disponibilidade de dados variam entre L2 e podem mudar após atualizações.

Resposta direta

Um saque forçado em L2 é uma rota do protocolo que permite ao usuário iniciar ou concluir uma saída sem aprovação do operador da L2. O termo não é padronizado. Em alguns sistemas, significa enviar uma solicitação de saque diretamente a um contrato da L1; em outros, a única primitiva disponível é a inclusão forçada, que garante apenas que uma transação originada na L1 entre na fila de execução da L2. Depois disso, o usuário ainda precisa seguir o fluxo normal de saque e finalização da ponte canônica.

A rota de escape é um caminho emergencial mais forte, usado quando as atualizações normais de estado param. Ela pode congelar a aplicação e permitir que usuários provem saldos contra uma raiz de estado comprometida. Nenhum desses mecanismos promete saída instantânea, determinado valor do ativo ou imunidade a falhas de contratos e poderes de governança. A garantia real vem do código implantado, da configuração vigente, dos dados de estado disponíveis e da capacidade do usuário de criar e enviar as transações ou provas exigidas.

Como funciona

  • Identifique a primitiva. Inclusão forçada, saque forçado e modo de escape resolvem problemas diferentes. A inclusão forçada contorna um sequenciador censor ou indisponível. Uma solicitação de saque forçado obriga o protocolo ou operador a processar a saída ou provar sua invalidade. O modo de escape costuma ser o último recurso: atualizações comuns param e usuários sacam com provas de estado.
  • Entre pela L1. O usuário envia uma transação ao inbox, portal ou contrato de liquidação da L1 documentado pelo protocolo. Na OP Stack, depósitos da L1 são derivados em blocos da L2 dentro da janela de sequenciamento. Na Arbitrum Nitro, uma mensagem entra na Delayed Inbox e, após o atraso configurado, pode ser forçada ao inbox principal se o sequenciador não a incluir.
  • Aguarde o processamento. A confirmação na L1 é apenas o primeiro ponto de controle. A solicitação talvez precise integrar a cadeia canônica da L2, ser executada, aparecer em estado provado ou confirmado, passar por período de contestação ou carência e ser finalizada na L1. Uma transação forçada ainda pode reverter por nonce incorreto, Gas insuficiente, calldata errada, restrições do token ou mudança de estado na L2.
  • Cumpra as condições de saída. StarkEx Spot ilustra um saque forçado e escape reais. O usuário envia fullWithdrawalRequest; a aplicação deve atender à solicitação ou provar que é inválida. Se continuar pendente após FREEZE_GRACE_PERIOD, é possível pedir o congelamento. O escape exige um caminho de Merkle contra a raiz congelada do cofre, verificação da prova, uma chamada escape e a chamada normal on-chain withdraw.
  • Verifique a disponibilidade de dados. Uma raiz de estado é um compromisso, não os saldos ou caminhos de Merkle subjacentes. Quando os dados para reconstruir o estado são publicados na L1, um agente independente pode em princípio montar a prova de saída. Em Validium ou outros projetos com dados off-chain, o usuário pode depender de um comitê ou operador para liberar os dados. Validade da prova e disponibilidade de dados são garantias distintas.
  • Verifique controles e ferramentas. Examine poderes de pausa, congelamento, atualização e governança; endereços exatos e implementações proxy; ativos aceitos; chaves necessárias; Gas em L1 e L2; software de geração de provas; e interface independente. Um mecanismo correto no papel pode ser impraticável sem dados, ferramentas ou fundos suficientes na L1.

Exemplo

Suponha que o sequenciador e a interface oficial de um Rollup estejam indisponíveis, mas a L1 continue finalizando. Primeiro, o usuário confirma o ID da cadeia e os contratos canônicos da L1 na documentação oficial. Se houver apenas inclusão forçada, envia uma transação da L1 para a L2 que chama a função de saque na L2 da ponte canônica. Depois acompanha separadamente o envio na L1, a inclusão forçada, a execução na L2, o compromisso de estado, a fase aplicável de contestação ou prova e a finalização na L1. Um envio bem-sucedido na L1 não comprova que a chamada de saque funcionou.

Em um sistema ao estilo StarkEx, a sequência é diferente: envie a solicitação forçada documentada, aguarde o período de carência configurado, confirme se ela foi atendida ou provada inválida e use congelamento e escape apenas quando as condições do contrato forem satisfeitas. O identificador do cofre, a chave e o caminho de Merkle devem corresponder ao estado congelado. Copiar o procedimento da Arbitrum ou OP Stack seria errado, embora todos sejam às vezes chamados de “saque forçado”.

Antes de depender de qualquer rota, ensaie com um valor pequeno enquanto o sistema está saudável. Registre endereços, assinaturas de funções, eventos esperados, temporizadores e hashes. Verifique o estado com outro RPC ou explorador confiável. Nunca informe seed ou chave privada a um site de “saque emergencial” nem envie pagamento extra de “desbloqueio” a suporte ou mensagens diretas.

Riscos

  • O protocolo tem inclusão forçada, mas não função direta de saque forçado.
  • A solicitação na L1 foi confirmada, mas a chamada na L2 reverteu ou não foi executada.
  • Um período de contestação, prova, carência ou finalização atrasa o acesso.
  • Dados de estado ou caminho de Merkle estão indisponíveis, sobretudo com dados off-chain.
  • São usados cadeia, contrato, proxy, função ou identificador de cofre incorretos.
  • O contrato de saída está pausado, atualizado, congelado incorretamente ou com falha.
  • Governança, conselho de segurança ou outro agente privilegiado pode mudar a rota.
  • O ativo não é aceito, não é padrão, tem pouca liquidez ou segue regras de margem.
  • Alta do Gas na L1 ou falta de Gas nativo impede o envio ou a finalização.
  • Interfaces oficiais, RPCs, indexadores ou ferramentas de prova ficam indisponíveis.
  • Interface falsa, anúncio ou falso suporte rouba credenciais ou fundos.
  • O valor de mercado pode cair durante a demora; saída possível não protege o preço.

Equívocos comuns

  • “Saque forçado” tem um fluxo universal. Nomes e garantias dependem do protocolo; leia documentos e contratos da versão implantada.
  • A inclusão forçada devolve fundos imediatamente à L1. Ela costuma garantir acesso à ordenação ou execução; o saque da ponte ainda tem ciclo próprio.
  • Um hash na L1 prova que a saída ocorreu. Ele prova apenas inclusão na L1; execução na L2 e finalização na L1 exigem verificações separadas.
  • Uma prova de validade garante que os dados de saída estejam disponíveis. Correção da prova e disponibilidade de dados são distintas; dados off-chain criam dependências.
  • A rota emergencial é trustless porque há uma função. Uso real também depende de permissões, configuração, dados, software, Gas e chaves.
  • Uma rota de escape elimina risco financeiro. Ela trata falhas de atividade ou censura, não riscos de preço, liquidez, contrato ou comprometimento de chaves.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...