Ir para o conteúdo
Financial Context Wiki

Proxy atualizável não inicializado: risco de tomada do inicializador

Proxies atualizáveis inicializam seu próprio armazenamento por uma chamada de inicialização, não pelo construtor da implementação. Este artigo explica front-running, bloqueio da implementação e verificações de implantação.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Os contratos atualizáveis não usam um construtor para definir o estado do agente, mas dependem do inicializador. Este artigo explica agentes não inicializados, bloqueio de implementação e verificações de implantação.

Quando o novo endereço proxy é implantado, mas a transação de inicialização ainda não foi confirmada, qualquer pessoa pode tentar chamar primeiro o inicializador público e se tornar o Proprietário.

Quando o agente for implantado, o construtor não executará a lógica de inicialização do contrato no armazenamento do agente. Portanto, sistemas atualizáveis ​​geralmente usam um inicializador que só pode ser chamado uma vez para definir o proprietário, os parâmetros do token e os módulos. Se a função não estiver devidamente protegida ou se a implantação e a inicialização forem divididas em duas transações, um invasor poderá chamá-la primeiro.

Como funciona

O processo de segurança coloca calldata de implantação e inicialização na mesma transação atômica e desativa a inicialização ao implementar a construção do contrato para evitar que a própria implementação seja assumida. O reinicializador é usado para adicionar novo status à nova versão e também deve limitar a versão e as permissões de chamada. Apenas verificar o proprietário do agente sem verificar o status de inicialização da implementação ainda pode causar vazamento de riscos.

As operações on-chain são divididas em quatro camadas: a carteira é responsável pela exibição e assinatura, o RPC é responsável pela leitura e transmissão, o código do contrato determina a mudança de status e o consenso do bloco determina se a transação foi finalmente confirmada. A exibição de “sucesso” em qualquer nível não pode substituir a verificação em outros níveis.

Exemplo

O projeto implanta o agente primeiro e planeja chamar a inicialização(team) em seguida. O invasor monitora o mempool e primeiro chama o inicializador (atacante) com uma taxa mais alta, torna-se um administrador e, em seguida, atualiza para uma implementação maliciosa e transfere fundos. A transação de inicialização da própria equipe é revertida, mas neste ponto o controle é perdido.

Gás, deslizamento e tempo de bloqueio na caixa são utilizados para demonstrar o método de cálculo. Antes da operação real, o preço, a liquidez, as permissões e o status do contrato da cadeia atual e do bloco atual devem ser lidos. O valor registra simultaneamente o número de tokens, o valor em dólares e o número inteiro bruto na cadeia.

Riscos

Os retornos devem ser calculados com base no valor real de saída:

Valor líquido de saída = valor de mercado do ativo - choque de preço - taxa de protocolo - imposto de transferência - Gás - desconto de risco de espera

Estabeleça três cenários de estresse de congestionamento de rede, exceção oracle e atualização de administrador. Suponha que o gás se expanda cinco vezes, a profundidade do pool caia 50%, o stablecoin seja descontado em 5% e você não possa sair por um dia. Se o rendimento de um mês não puder cobrir a pressão, o rendimento elevado não proporciona uma compensação suficiente.

Protocolo único, cadeia única, ponte única e moeda estável única definem limites superiores, respectivamente. Quaisquer posições que exijam que administradores, oráculos, pontes, front-ends e um único RPC sejam normais ao mesmo tempo para sair devem ser ainda mais estreitas, e múltiplas dependências relacionadas não devem ser confundidas com dispersão.

Erros comuns

  • Mito 1: O equilíbrio inicial é o fato da cadeia. O front-end pode ser armazenado em cache, indexado tardiamente ou conectado à rede errada e deve ser validado cruzadamente com leituras de contrato.

  • Mito 2: Aumentar o gás ou o deslizamento pode resolver qualquer falha. O gás afeta apenas a classificação e a derrapagem apenas relaxa o preço; erros de permissão, Nonce e condição de contrato não serão reparados automaticamente.

  • Mito 3: Testes bem-sucedidos em pequenas quantidades significam segurança permanente. Atualizações de administradores, parâmetros dinâmicos e alterações de liquidez alterarão os resultados e deverão ser revisados ​​antes de cada expansão de posição.

Tópicos relacionados

Fontes oficiais

Navegação

Pesquisar na wiki...