Ir para o conteúdo
Financial Context Wiki

Como monitorar upgrades de contratos proxy

Monitore mudanças de implementação, beacon e controle em proxies atualizáveis e, depois da execução, verifique código, compatibilidade de armazenamento, inicialização, permissões e comportamentos críticos.

Atualizado

Apenas para fins educacionais; não constitui recomendação de investimento. Investimentos podem resultar em perdas.

Resposta direta

Monitore o caminho de controle de um sistema atualizável, além do endereço do proxy. Um alerta deve identificar quem pode autorizar e executar um upgrade, qualquer atraso obrigatório, as implementações antiga e nova e os calldata de inicialização. Após a execução, leia de forma independente a configuração on-chain e teste os comportamentos críticos.

O endereço do proxy e seus saldos podem permanecer iguais enquanto o código delegado altera permissões, taxas, contabilidade, pausas ou lógica de saque. Uma auditoria anterior não cobre automaticamente uma nova implementação nem sua inicialização.

Como funciona

Primeiro, identifique o padrão de proxy. O ERC-1967 define slots de armazenamento separados para eip1967.proxy.implementation, eip1967.proxy.beacon e o slot opcional eip1967.proxy.admin. Alterações diretas da implementação devem emitir Upgraded; mudanças do endereço do beacon, BeaconUpgraded; e mudanças do slot de administrador, AdminChanged. Em um proxy beacon, também chame implementation() no beacon, pois ele pode trocar sua implementação sem alterar o slot beacon do proxy.

Não deduza o modelo completo de autoridade pelo slot de administrador. Um proxy Transparent pode ser controlado por um ProxyAdmin, enquanto a autorização de upgrade UUPS é implementada no contrato lógico atual por meio de _authorizeUpgrade. Rastreie proprietários, papéis, limites de multisig, timelocks, governadores, caminhos de emergência e a capacidade de alterar esses controles.

Use assinaturas de eventos e leituras periódicas de estado. O ERC-1967 recomenda os eventos, mas não obriga toda implementação a emiti-los. Registre cadeia, bloco, transação, proxy, implementação ou beacon, hash do código em execução, executor e estado de controle relevante a partir de endpoints RPC independentes. Alerte sobre operações agendadas, canceladas e executadas e aguarde a política de confirmação ou finalidade escolhida para a cadeia antes de considerar o estado definitivo.

Exemplo

Um proxy de empréstimos é controlado por um multisig 3 de 5 por meio de um timelock de 24 horas. Quando um upgrade é agendado, o monitor registra o identificador da proposta, alvo, calldata, horário mínimo de execução, implementação atual, implementação proposta e situação da verificação do código-fonte. Os revisores comparam o código e os layouts de armazenamento, inspecionam a chamada de inicialização e verificam mudanças em papéis, chamadas externas, taxas, regras de pausa e caminhos de saque.

Após a execução, o monitor relê o slot ERC-1967 relevante, verifica o código implantado em execução e confere pós-condições esperadas, como versão da implementação, administradores ou detentores de papéis, estado de pausa, contabilidade dos ativos e prévia de saque somente para leitura. Um novo alerta é disparado se o endereço ou hash observado divergir da proposta revisada ou se a consulta periódica encontrar uma mudança não informada por evento.

Riscos

  • Risco de controle: Um multisig nominal pode ser contornado por outro proprietário, papel, módulo, governador, chave de emergência ou timelock mutável. Siga cada caminho até os signatários finais e o atraso.
  • Risco de código e armazenamento: Código não verificado, layouts incompatíveis, inicialização insegura ou dependência alterada podem corromper o estado ou conceder autoridade indevida. Valide o artefato exato implantado, não apenas uma branch ou o nome de uma auditoria.
  • Risco de monitoramento: Um único RPC, indexador apenas de eventos, front-end ou explorador de blocos pode atrasar ou errar. Concilie eventos com armazenamento, bytecode, recibos de transação e estado do protocolo em fontes independentes.
  • Risco de resposta: Um alerta sem responsável e procedimento testado pode chegar tarde demais. Defina quem revisa, pausa integrações, comunica ou sai durante o atraso e reconheça que aprovações apressadas e links não oficiais de recuperação acrescentam risco.

Procedimento mínimo:

  1. Inventarie cada proxy, beacon, implementação, administrador, papel e ponto de entrada de upgrade em cada cadeia.
  2. Salve uma referência válida de slots, hashes de código, estado de controle e resultados críticos somente para leitura.
  3. Alerte antes da execução quando o agendamento por governança ou timelock permitir e novamente na execução ou no cancelamento.
  4. Compare o alvo, calldata, implementação, bytecode, layout de armazenamento e estado pós-upgrade executados com a proposta revisada.
  5. Escale mudanças inesperadas, pós-condições com falha, ausência de verificação do código-fonte ou atraso reduzido ou contornado; não trate o endereço inalterado do proxy como prova de segurança.

Equívocos comuns

  • Mito 1: “Monitorar Upgraded é suficiente.” Mudanças na implementação do beacon e proxies fora do padrão podem exigir o monitoramento de outro contrato ou consultas de estado; concilie eventos com leituras diretas.
  • Mito 2: “O slot de administrador mostra quem controla todo upgrade.” O slot é opcional, e projetos Transparent, UUPS, beacon, de governança e personalizados colocam a autoridade em contratos e funções diferentes.
  • Mito 3: “Código verificado ou auditoria anterior prova que o upgrade é seguro.” Verifique bytecode implantado, premissas do compilador e construtor, compatibilidade de armazenamento, inicialização, configuração e comportamento da versão exata.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...