--- title: "Proxy atualizável não inicializado: risco de tomada do inicializador" description: "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." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Proxy atualizável não inicializado: risco de tomada do inicializador > 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 - [Ataque de inflação no primeiro depósito ERC-4626: Por que as ações do Vault podem ser arredondadas](/pt-br/crypto/erc4626-inflation-attack/) - [contrato de agência](/pt-br/crypto/proxy-contract/) - [contrato inteligente](/pt-br/crypto/smart-contract/) - [Contrato atualizável](/pt-br/crypto/upgradeable-contract/) - [Comprovante de Validade](/pt-br/crypto/validity-proof/) ## Fontes oficiais - [API de Proxy e Initializable](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (acessado em: 20/08/2026) - [Escrevendo contratos atualizáveis](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (acessado em: 20/08/2026) - [Atualização de contratos inteligentes](https://ethereum.org/developers/docs/smart-contracts/upgrading/) - Ethereum.org (acessado em: 20/08/2026) Source: https://wiki.fcontext.com/pt-br/crypto/initializer-takeover/index.mdx