Ir para o conteúdo
Financial Context Wiki

Contrato inteligente atualizável

Um contrato inteligente atualizável preserva o endereço e o estado de um proxy enquanto agentes autorizados substituem ou redirecionam sua implementação. Essa flexibilidade acrescenta riscos de armazenamento, inicialização, governança e monitoramento.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento ou segurança. A capacidade de atualização pode dar a agentes privilegiados poder para mudar o comportamento do contrato e causar perdas.

Resposta direta

Um contrato inteligente atualizável é um sistema implantado cuja lógica efetiva pode mudar sem transferir usuários para outro endereço principal nem descartar o estado ali guardado. Em redes compatíveis com Ethereum, um proxy normalmente mantém o estado e encaminha chamadas por delegatecall a um contrato de implementação. Uma atualização autorizada troca a implementação; endereço, armazenamento e saldo do proxy permanecem.

O bytecode imutável não é reescrito: acrescenta-se uma camada de indireção. Ela pode corrigir falhas e adicionar recursos, mas cria um caminho privilegiado capaz de alterar saques, taxas, permissões ou contabilidade. É preciso avaliar o código atual e as regras para o código futuro.

Nem todo proxy é atualizável e nem todo sistema mutável usa proxy. Alguns projetos implantam novos contratos e migram o estado; outros desativam atualizações definitivamente. Arquitetura e autoridade reais on-chain importam mais que o rótulo da interface.

Como funciona

O proxy lê o endereço de implementação e executa seu código no contexto de armazenamento do proxy por delegatecall. Leituras e escritas afetam o proxy, preservando remetente e valor originais. ERC-1967 padroniza slots de implementação, beacon e administrador.

Proxies transparent separam chamadas administrativas e de usuário. Proxies UUPS colocam a lógica de atualização na implementação e usam compatibilidade ERC-1822, tornando a autorização crítica. Proxies beacon obtêm a implementação de um beacon; uma mudança pode afetar muitos proxies.

Compatibilidade de estado é a principal restrição. Reordenar, remover ou mudar tipos de variáveis, ou alterar herança, pode corromper dados. Layouts somente aditivos, lacunas reservadas ou armazenamento em namespaces ERC-7201 ajudam, mas ainda exigem validação entre versões.

Construtores inicializam a implementação, não o proxy. Por isso chama-se uma vez um inicializador como initialize. A implementação deve bloquear inicialização direta, e migrações posteriores devem usar reinicializadores limitados. Um inicializador público ou repetível pode entregar o controle.

Um processo defensável é:

  1. Fixar fontes, compilador, dependências, layouts, endereços e bytecode esperado das duas implementações.
  2. Revisar diferenças, compatibilidade, inicialização ou migração, autorização, dependências e rollback; testar a transação completa em um fork.
  3. Publicar proposta e endereço e aplicar multisig, governança e timelock declarados sem bypass oculto.
  4. Executar e verificar slot de implementação ou beacon, eventos, bytecode, estado inicializado, papéis e invariantes em um bloco registrado.
  5. Monitorar slots, papéis e parâmetros e planejar incidentes sem presumir que reverter será sempre seguro.

Exemplo

Um protocolo de empréstimo precisa de nova função de pagamento. Seu proxy delega à implementação A. A equipe implanta B, confirma que B apenas acrescenta armazenamento e prepara a migração. A governança publica o bytecode e põe a atualização após um timelock de 48 horas. Depois, o mesmo endereço delega a B e os saldos continuam no proxy.

Usuários devem confirmar a mudança do slot de A para B, a execução única da migração e os papéis e saldos. Se um guardião contorna o timelock ou um signatário substitui B por código arbitrário, esse poder integra o modelo de confiança.

Riscos

  • Substituição privilegiada: administrador, multisig, governador ou chave comprometida pode instalar lógica maliciosa ou defeituosa.
  • Corrupção de armazenamento: layout incompatível pode reinterpretar saldos, proprietários, mappings ou contas.
  • Falha de inicialização: inicializador omitido, repetido ou exposto pode travar o sistema ou transferir controle.
  • Falha específica do padrão: transparent, UUPS, beacon e proxies personalizados falham de formas diferentes; o nome não prova correção.
  • Governança de fachada: timelock ou votação pode ter bypass emergencial, prazo curto, poder concentrado ou signatários frágeis.
  • Migração ou rollback inseguro: o estado pode mudar irreversivelmente; código antigo não necessariamente restaura seu significado.
  • Lacuna de verificação: fonte verificada não prova que o proxy a usa nem que administrador e estado são os esperados.
  • Risco de monitoramento e integração: exploradores, interfaces, auditores e integrações podem seguir versão antiga ou perder mudança do beacon.

Equívocos comuns

  • “O contrato neste endereço é imutável.” O bytecode do proxy pode ser imutável enquanto o slot de implementação ou beacon muda seu comportamento.
  • “Um multisig descentraliza atualizações.” Só reduz dependência de uma chave com signatários independentes, limiar, operação e substituição sólidos.
  • “Um timelock impede atualização maliciosa.” Ele oferece tempo de observação e saída, mas não torna o código seguro.
  • “Passar na verificação de armazenamento prova segurança.” Ela cobre layout, não lógica, autorização, oráculos, migração ou economia.
  • “Renunciar a atualizações sempre elimina controle.” Administrador, beacon, governador, autorização UUPS e caminhos alternativos devem ser verificados on-chain.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...