Contrato proxy

O que é um contrato proxy?

Um contrato proxy é um contrato inteligente que recebe chamadas dos usuários e as encaminha para outro contrato, que contém a lógica de negócios efetiva.

Em cripto, os contratos proxy são usados principalmente para permitir a atualização de sistemas de contratos inteligentes, mantendo o mesmo endereço público do contrato e o estado armazenado.

O contrato com o qual os usuários interagem geralmente é chamado de proxy.

O contrato que contém a lógica atual geralmente é chamado de contrato de implementação, contrato de lógica ou cópia mestre.

O padrão de atualização de proxy da OpenZeppelin explica que a possibilidade de atualização baseada em proxy funciona separando o armazenamento do contrato de sua lógica.

Essa separação é importante porque normalmente é difícil ou impossível alterar contratos inteligentes após a implementação.

Se um projeto implementar um contrato comum e descobrir um bug posteriormente, a equipe talvez precise implementar um novo contrato em outro endereço.

Um contrato proxy resolve esse problema mantendo o mesmo endereço de proxy e apontando para um novo contrato de implementação quando uma atualização é aprovada.

Os usuários, as carteiras e os aplicativos continuam interagindo com o endereço do proxy, enquanto a lógica por trás dele pode mudar.

A maneira mais simples de entender um contrato proxy é imaginá-lo como a entrada permanente, enquanto o contrato de implementação é o mecanismo substituível que fica por trás dela.

Por que existem contratos proxy

Os contratos proxy existem porque a imutabilidade da blockchain traz tanto segurança quanto dificuldades.

A imutabilidade é útil porque os usuários podem confiar que o código implementado não será alterado em segredo como um software web comum.

No entanto, a imutabilidade se torna um problema quando os desenvolvedores precisam corrigir bugs, adicionar recursos, responder a problemas de segurança, melhorar o desempenho ou oferecer suporte a novos padrões.

Sem um proxy, atualizar um contrato inteligente costuma significar implementar um novo contrato e pedir aos usuários que migrem ativos ou permissões.

Essa migração pode ser cara, confusa, arriscada e disruptiva.

Um contrato proxy permite manter estável o endereço usado pelos usuários.

Isso é importante para protocolos DeFi, coleções de NFT, DAOs, contratos de tokens, bridges, sistemas de staking, ativos de jogos e carteiras com abstração de contas.

O proxy pode reduzir o atrito para os usuários porque as integrações não precisam trocar os endereços dos contratos sempre que a lógica muda.

Também pode melhorar a segurança porque permite implementar correções urgentes com mais facilidade.

No entanto, a possibilidade de atualização introduz pressupostos de confiança, pois alguém ou algum processo de governança precisa ter permissão para alterar a implementação.

Como funciona um contrato proxy

Um contrato proxy funciona armazenando o estado e encaminhando chamadas de funções a um contrato de implementação.

Quando um usuário chama o proxy, normalmente o próprio proxy não executa a lógica principal do aplicativo.

Em vez disso, ele encaminha a chamada para o contrato de implementação usando um recurso de baixo nível da EVM, como

.

O código da implementação é executado, mas o armazenamento alterado é o do proxy.

Esse é o detalhe essencial que permite criar sistemas proxy atualizáveis.

O proxy mantém saldos, configurações, variáveis de propriedade, oferta de tokens, posições dos usuários e outros estados.

O contrato de implementação fornece o código que sabe como ler e atualizar esse estado.

Se o sistema for atualizado, um novo contrato de implementação será implantado com a nova lógica.

Em seguida, o proxy atualiza o ponteiro para a implementação e passa a apontar para o novo contrato.

O endereço usado pelos usuários e os dados armazenados permanecem no proxy, enquanto as chamadas futuras usam a nova lógica.

Contrato proxy e delegatecall

é o mecanismo de baixo nível usado por muitos contratos proxy.

Em uma chamada externa comum, um contrato chama outro e o contrato chamado usa seu próprio armazenamento.

Com

, o código do contrato chamado é executado no contexto de armazenamento do contrato que fez a chamada.

No caso de um proxy, isso significa que o código do contrato de implementação pode alterar o armazenamento do proxy.

Isso é poderoso porque o proxy pode manter o estado e, ao mesmo tempo, mudar qual código de implementação é usado.

Também é perigoso porque o código de implementação precisa ser escrito considerando a estrutura de armazenamento do proxy.

Se a implementação gravar no slot de armazenamento errado, poderá corromper dados importantes.

Se o proxy encaminhar chamadas para uma implementação maliciosa, a lógica maliciosa poderá drenar ativos ou alterar permissões.

O alerta SWC-112 sobre delegatecall recomenda que os desenvolvedores usem

com cuidado e evitem chamar contratos não confiáveis.

Em sistemas proxy,

não é apenas um detalhe técnico: é o centro do modelo de segurança.

Contrato proxy vs. contrato de implementação

O contrato proxy e o contrato de implementação têm responsabilidades diferentes.

O contrato proxy mantém o endereço chamado pelos usuários e geralmente armazena o estado do sistema.

O contrato de implementação contém as funções e regras que determinam como o estado muda.

Por exemplo, um proxy de token pode manter os saldos no armazenamento do proxy, enquanto a implementação define a lógica de transferência, aprovação, emissão, queima ou controle de acesso.

Quando um novo recurso é necessário, os desenvolvedores implementam um novo contrato de implementação.

Então, o proxy é atualizado para apontar para essa nova implementação.

O endereço do proxy permanece o mesmo, portanto, os usuários e as integrações não precisam migrar para outro endereço.

Esse modelo é útil, mas significa que os usuários devem perguntar quem controla as atualizações.

Se uma única chave privada controlar o administrador do proxy, essa chave poderá ter enorme poder sobre o contrato.

Se a governança controlar as atualizações por meio de um timelock e de um processo de votação, os usuários poderão ter mais tempo para analisar as mudanças antes de elas entrarem em vigor.

Contrato proxy vs. contrato inteligente comum

Um contrato inteligente comum geralmente contém o armazenamento e a lógica no mesmo contrato.

Após a implementação, o código desse contrato costuma permanecer fixo.

Um sistema baseado em proxy divide o armazenamento e a lógica entre pelo menos dois contratos.

O proxy armazena o estado e encaminha as chamadas.

A implementação contém a lógica e pode ser substituída se o mecanismo de atualização permitir.

Isso torna o sistema proxy mais flexível do que um contrato comum.

Também torna o sistema mais difícil de auditar, pois a segurança depende do proxy, da implementação, dos controles administrativos, do processo de inicialização, da estrutura de armazenamento e do histórico de atualizações.

Um contrato comum pode ser mais simples para os usuários, pois o código no endereço é o código executado.

Em um contrato proxy, usuários e auditores precisam analisar o proxy para identificar a implementação ativa.

Por isso, os exploradores de blockchain frequentemente identificam contratos proxy verificados e mostram o endereço da implementação atual quando conseguem detectá-la.

Contrato proxy e possibilidade de atualização

A possibilidade de atualização é o motivo mais comum para usar um contrato proxy.

Contratos atualizáveis permitem que os desenvolvedores alterem a lógica após a implementação sem mudar o endereço do proxy.

Isso pode ser útil para corrigir bugs, adicionar recursos, melhorar o uso de gas, criar novas integrações, alterar a governança ou atualizar protocolos.

No entanto, a possibilidade de atualização muda o modelo de confiança.

Um contrato que pode ser atualizado não é totalmente imutável como um contrato que não permite atualizações.

Os usuários confiam que a autoridade responsável pelas atualizações não introduzirá mudanças maliciosas ou descuidadas.

A autoridade pode ser um único proprietário, uma carteira multisig, uma DAO, um controlador timelock ou outro contrato de governança.

Os projetos mais seguros costumam tornar a autoridade de atualização transparente e mais difícil de abusar.

Por exemplo, um timelock pode dar aos usuários tempo para sair antes da execução de uma atualização importante.

Sem controles robustos, um contrato proxy pode se tornar uma porta dos fundos oculta para os fundos dos usuários.

Padrão de proxy ERC-1967

O ERC-1967 é um padrão amplamente usado para slots de armazenamento de proxies.

O padrão ERC-1967 define slots de armazenamento específicos para informações de proxy, como os endereços de implementação, administrador e beacon.

O objetivo é evitar colisões de armazenamento entre o proxy e o contrato de implementação.

Uma colisão de armazenamento ocorre quando duas variáveis usam o mesmo slot de armazenamento sem intenção.

Em sistemas proxy, isso pode ser especialmente perigoso porque o armazenamento do proxy e a lógica da implementação interagem por meio de

.

O ERC-1967 também ajuda exploradores de blockchain e ferramentas de desenvolvimento a identificar a implementação ativa por trás de um proxy.

Isso facilita a análise e a auditoria dos sistemas proxy.

Muitos padrões comuns de proxy atualizável usam slots ERC-1967.

Usar um padrão conhecido não torna um proxy seguro automaticamente.

Mas isso reduz confusões evitáveis e ajuda as ferramentas a identificar onde ficam armazenados dados importantes do proxy.

Proxy transparente

Um proxy transparente é um padrão que separa as chamadas administrativas das chamadas dos usuários.

Nesse padrão, os usuários comuns chamam o proxy, que encaminha suas chamadas para a implementação.

O administrador pode executar ações relacionadas a atualizações, mas geralmente não pode chamar acidentalmente funções da implementação por meio do proxy.

Esse projeto ajuda a evitar conflitos entre os seletores de funções administrativas do proxy e as funções da implementação.

A documentação de proxy da OpenZeppelin lista

como um proxy com administrador e interface de atualização integrados.

Proxies transparentes são comuns porque a lógica de atualização fica claramente localizada no lado do proxy do sistema.

No entanto, eles podem ter um custo um pouco maior do que modelos de proxy mais enxutos.

Também exigem uma gestão cuidadosa do administrador do proxy.

Se o administrador do proxy for comprometido, o invasor poderá conseguir atualizar o contrato para uma lógica maliciosa.

Um proxy transparente só é tão seguro quanto o código da implementação e a segurança administrativa.

Proxy UUPS

UUPS significa Universal Upgradeable Proxy Standard.

O padrão UUPS ERC-1822 descreve um projeto de proxy no qual a compatibilidade com atualizações é gerenciada pela lógica da implementação.

Em um projeto UUPS, o proxy pode ser mais enxuto porque a função de atualização fica no contrato de implementação, e não em uma interface administrativa complexa do proxy.

Isso pode reduzir o custo de implementação e a complexidade do proxy.

No entanto, os desenvolvedores precisam proteger corretamente a função de atualização dentro do contrato de implementação UUPS.

Se o controle de acesso estiver incorreto, um invasor poderá conseguir atualizar o sistema.

Se uma nova implementação remover ou comprometer a função de atualização, poderá ser difícil ou impossível atualizar o proxy novamente.

As ferramentas UUPS da OpenZeppelin incluem proteções para reduzir o risco de perda acidental da capacidade de atualização, mas os desenvolvedores ainda precisam fazer uma revisão cuidadosa.

Os proxies UUPS são poderosos porque são flexíveis e eficientes.

São arriscados quando as equipes não entendem completamente onde está a autoridade de atualização.

Proxy beacon

Um proxy beacon obtém o endereço da implementação de um contrato beacon separado.

Em vez de cada proxy armazenar seu próprio endereço de implementação, vários proxies podem apontar para um único beacon.

Quando o beacon é atualizado, todos os proxies que o utilizam podem começar a usar a nova implementação.

Esse projeto é útil quando um projeto precisa implementar muitos contratos semelhantes que devem ser atualizados em conjunto.

Por exemplo, uma factory pode criar muitos cofres, pools, contas ou contratos relacionados a NFTs para compartilhar a mesma lógica.

Um proxy beacon pode simplificar atualizações em massa.

Também pode aumentar o risco, pois uma atualização do beacon pode afetar várias instâncias de proxy ao mesmo tempo.

O administrador do beacon precisa ser protegido com cuidado.

Os usuários devem entender se seu contrato depende de um beacon, pois uma alteração nele pode mudar o comportamento de muitos contratos.

Proxies beacon são eficientes para conjuntos de contratos, mas concentram o poder de atualização no beacon.

Proxy mínimo e ERC-1167

Um proxy mínimo é um contrato proxy muito pequeno, projetado para replicar o comportamento de outro contrato de implementação a um baixo custo de implementação.

O padrão de proxy mínimo ERC-1167 define um padrão mínimo de bytecode para clones de contratos baratos que encaminham chamadas a uma implementação fixa.

Os proxies mínimos costumam ser chamados de clones.

Eles são úteis quando um projeto precisa implementar muitas cópias da mesma lógica, como carteiras, cofres, pools, contas ou instâncias de marketplace.

Cada clone tem seu próprio endereço e estado, mas reutiliza a lógica da implementação.

Isso pode economizar gas, pois não é necessário implementar repetidamente todo o código da implementação.

Nem todo proxy mínimo é atualizável.

Muitos clones ERC-1167 apontam para uma implementação fixa e não podem mudar esse destino, a menos que outra lógica de atualização seja adicionada.

Essa distinção é importante porque um proxy mínimo serve para criar clones baratos, enquanto um proxy atualizável permite substituir a lógica.

Alguns sistemas combinam as duas ideias, mas elas não devem ser confundidas.

Estrutura de armazenamento em contratos proxy

A estrutura de armazenamento é um dos aspectos mais importantes do projeto de contratos proxy.

Como o proxy armazena o estado e a implementação fornece a lógica, a implementação precisa ler e gravar o armazenamento na ordem correta.

Se uma nova implementação alterar incorretamente a ordem das variáveis, poderá interpretar o armazenamento antigo como o tipo errado de dados.

Por exemplo, um mapeamento de saldos pode ser substituído acidentalmente por uma variável de proprietário, ou um valor de configuração pode ser sobrescrito por uma nova variável.

Isso pode comprometer o contrato ou criar vulnerabilidades de segurança.

Estruturas para contratos atualizáveis geralmente exigem que os desenvolvedores acrescentem novas variáveis, em vez de reordenar ou excluir as antigas.

Às vezes, lacunas de armazenamento são usadas para reservar espaço para variáveis futuras.

Verificações da estrutura de armazenamento podem detectar muitos erros de atualização antes da implementação.

Os desenvolvedores devem tratar a estrutura de armazenamento como parte do modelo público de segurança do contrato.

Os usuários devem ter cautela quando um projeto atualizável não explica como verifica a estrutura de armazenamento durante as atualizações.

Inicialização em contratos proxy

Contratos proxy atualizáveis geralmente usam funções de inicialização em vez de construtores.

Um construtor é executado apenas quando o contrato de implementação é implantado.

No entanto, em um sistema proxy, os usuários interagem com o proxy, e é o armazenamento do proxy que precisa ser inicializado.

Por isso, a configuração geralmente é executada por meio de uma função de inicialização chamada através do proxy.

A inicialização pode definir o proprietário, o nome do token, o endereço do tesouro, as funções administrativas, os valores de oferta, as configurações de taxas ou os parâmetros de governança.

Se a inicialização for esquecida, o proxy poderá ficar desprotegido.

Se um invasor chamar primeiro a função de inicialização, poderá se tornar proprietário ou administrador.

Se a função de inicialização puder ser chamada mais de uma vez, as configurações críticas poderão ser sobrescritas.

Por esse motivo, contratos atualizáveis precisam de proteções de inicialização que impeçam inicializações repetidas.

Falhas de inicialização estão entre os erros mais comuns e perigosos em contratos atualizáveis.

Administrador do proxy e autoridade de atualização

O administrador do proxy é a conta ou o contrato que pode atualizar a implementação do proxy.

Essa função pode ser controlada por uma única carteira, uma carteira multisig, uma votação de DAO, um timelock ou um contrato de governança.

A função administrativa é extremamente importante porque permite alterar o código que controla os ativos dos usuários.

Se o administrador atualizar o sistema para uma lógica maliciosa, os usuários poderão perder fundos, mesmo que a implementação anterior fosse segura.

Se a chave do administrador for roubada, o invasor poderá conseguir substituir a implementação.

Se o administrador for lento demais ou excessivamente descentralizado, poderá ser difícil implementar correções de emergência.

Uma boa governança de proxy equilibra segurança, capacidade de resposta, transparência e direito de saída dos usuários.

Um timelock pode aumentar a confiança ao atrasar as atualizações depois que são anunciadas.

Uma carteira multisig pode reduzir o risco de uma única chave, exigindo vários signatários.

Propostas públicas de atualização e auditorias podem ajudar os usuários a entender o que está mudando.

Contrato proxy e exploradores de blockchain

Os exploradores de blockchain frequentemente ajudam os usuários a analisar contratos proxy.

Um bom explorador pode indicar que um endereço é um proxy e identificar o endereço da implementação atual.

Também pode mostrar informações sobre o administrador do proxy se ele seguir um padrão conhecido, como o ERC-1967.

Isso ajuda usuários e auditores a analisar o código que está sendo executado de fato.

Sem a detecção de proxy, os usuários podem analisar apenas o bytecode do proxy e deixar passar a lógica da implementação.

Isso pode gerar uma falsa sensação de segurança, pois o proxy pode conter muito pouco código visível do aplicativo.

Os usuários devem verificar se o contrato de implementação foi verificado.

Também devem verificar se a implementação mudou ao longo do tempo.

Uma auditoria antiga pode não ser aplicável se o proxy tiver sido atualizado para uma nova lógica.

Em interações de alto valor, é muito mais seguro analisar o proxy, a implementação, o administrador e o histórico de atualizações do que verificar apenas o endereço visível.

Contrato proxy e contratos de tokens

Muitos contratos de tokens usam proxies para permitir atualizações futuras.

Um token atualizável pode manter o mesmo endereço enquanto suas regras de transferência, taxas, emissão, queima, bridges, conformidade ou governança são alteradas.

Isso pode ser útil quando um token precisa se adaptar ao longo do tempo.

Também pode ser arriscado, pois as regras nas quais os usuários confiam podem mudar depois que compram ou recebem o token.

Por exemplo, uma atualização pode adicionar restrições de transferência, alterar o comportamento das taxas, incluir poderes de pausa ou modificar os controles de acesso.

Antes de presumir que as regras de um token são permanentes, os usuários devem verificar se o contrato é atualizável.

Também devem verificar quem controla as atualizações e se a governança impõe atrasos às mudanças.

Um token com proxy não é automaticamente inseguro.

Ele simplesmente tem um modelo de confiança diferente do de um contrato de token totalmente imutável.

A questão importante é se a autoridade de atualização é transparente e bem protegida.

Contrato proxy e protocolos DeFi

Os protocolos DeFi costumam usar contratos proxy porque aplicativos financeiros precisam de manutenção.

Um protocolo de empréstimo, formador de mercado automatizado, sistema de derivativos, cofre de staking ou estratégia de rendimento pode precisar de atualizações após auditorias, mudanças de mercado, melhorias em oráculos ou descobertas de bugs.

Os contratos proxy permitem que esses sistemas evoluam sem obrigar todos os usuários a migrar suas posições.

Isso é conveniente porque as posições DeFi podem ser complexas e estar conectadas a vários protocolos.

No entanto, a possibilidade de atualização também cria risco sistêmico.

Uma atualização inadequada em um contrato DeFi amplamente usado pode afetar muitos usuários e integrações ao mesmo tempo.

Um protocolo DeFi atualizável deve ter testes rigorosos, auditorias, monitoramento, controles de governança e procedimentos de emergência robustos.

Os usuários não devem perguntar apenas se o protocolo foi auditado.

Devem perguntar se a implementação atual foi auditada e se as atualizações futuras exigem análise pública.

Em DeFi, os contratos proxy melhoram a capacidade de manutenção, mas aumentam a importância da governança.

Contrato proxy e NFTs

Projetos de NFT podem usar contratos proxy para permitir a atualização da lógica de metadados, emissão, integração com marketplaces, royalties, sistemas de staking ou mecânicas de jogos.

Um proxy de NFT pode permitir que um projeto adicione recursos após o lançamento.

Também pode permitir mudanças no comportamento dos metadados se a implementação controlar a lógica de URI do token.

Isso pode ser útil quando um projeto evolui de simples itens colecionáveis para jogos, associações ou sistemas de identidade digital.

Pode ser controverso quando os colecionadores esperam regras fixas ou metadados permanentes.

Os compradores de NFTs devem verificar se o contrato do NFT é atualizável e se os metadados podem mudar.

Também devem verificar quem controla o administrador de atualização.

Tanto um NFT totalmente imutável quanto um atualizável podem ser legítimos, mas oferecem garantias diferentes.

Os colecionadores devem entender se estão comprando regras on-chain fixas ou participando de um projeto que pode evoluir.

Os contratos proxy dão flexibilidade ao desenvolvimento de NFTs, mas também exigem confiança no processo de atualização do projeto.

Contrato proxy e DAOs

DAOs podem usar contratos proxy para atualizar módulos de governança, ferramentas de tesouraria, sistemas de votação, contratos de staking ou parâmetros de protocolo.

Um proxy controlado por uma DAO pode ser mais transparente do que um proxy com administrador único, pois as atualizações podem exigir propostas e votações.

No entanto, a governança de uma DAO não torna as atualizações automaticamente seguras.

Baixa participação dos eleitores, compra de votos, ataques de governança, propostas apressadas ou alterações de código pouco claras ainda podem criar riscos.

Um bom processo de atualização de DAO deve incluir resumos compreensíveis, diferenças técnicas do código, links para auditorias, análise de riscos, prazos de votação e atrasos de timelock.

Os membros da DAO devem saber quais contratos são atualizáveis e quais poderes a governança tem.

Se a governança puder atualizar contratos de tesouraria, contratos de tokens ou a lógica central do protocolo, os eleitores serão responsáveis por decisões importantes de segurança.

Os contratos proxy podem ajudar as DAOs a se adaptar ao longo do tempo.

Também podem dar à governança o poder de alterar regras que os usuários acreditavam ser estáveis.

A possibilidade de atualização de uma DAO deve ser visível, documentada e cuidadosamente controlada.

Benefícios dos contratos proxy

O primeiro benefício de um contrato proxy é a possibilidade de atualização.

Os projetos podem corrigir bugs, adicionar recursos e melhorar a lógica sem mudar o endereço principal do contrato.

O segundo benefício é a continuidade do estado.

Saldos, posições, permissões e configurações dos usuários podem permanecer no proxy enquanto a lógica da implementação muda.

O terceiro benefício é a estabilidade das integrações.

Carteiras, dApps, indexadores e outros contratos podem continuar usando o mesmo endereço.

O quarto benefício é a redução do atrito de migração.

Os usuários talvez não precisem transferir manualmente os ativos para um novo contrato após cada atualização.

O quinto benefício é a eficiência de gas nos padrões de clone.

Proxies mínimos podem implementar muitos contratos semelhantes por um custo menor do que implementar todo o código repetidamente.

O sexto benefício é a arquitetura modular.

As equipes podem separar com mais clareza o armazenamento, a lógica, o controle de atualização e os padrões de implementação.

Esses benefícios só são valiosos quando os contratos proxy são projetados, auditados, governados e monitorados com cuidado.

Riscos dos contratos proxy

O primeiro risco são as atualizações maliciosas.

Se a autoridade de atualização for comprometida ou agir de má-fé, poderá substituir uma lógica segura por uma lógica maliciosa.

O segundo risco é a colisão de armazenamento.

Se a estrutura de armazenamento estiver incorreta, uma atualização poderá corromper estados importantes do contrato.

O terceiro risco é uma falha de inicialização.

Um proxy ou uma implementação não inicializados podem permitir que um invasor assuma o controle.

O quarto risco é o conflito entre seletores de funções.

Funções administrativas do proxy e funções da implementação podem entrar em conflito se o padrão for mal projetado.

O quinto risco é a incompatibilidade com auditorias.

Um contrato pode ter sido auditado no passado, mas a implementação atual pode ser diferente.

O sexto risco é a complexidade oculta.

Os usuários podem não perceber que estão interagindo com um proxy, e não com um contrato simples e imutável.

O sétimo risco é a captura da governança.

Um invasor pode influenciar o processo de atualização por meio do poder de voto, do acesso administrativo ou de engenharia social.

O oitavo risco é a interpretação incorreta pelas ferramentas.

Exploradores de blockchain, carteiras e indexadores podem não exibir corretamente os detalhes de um proxy se ele for personalizado ou não seguir um padrão.

Como verificar um contrato proxy antes de interagir

Primeiro, os usuários devem verificar se o endereço do contrato está identificado como proxy em um explorador de blockchain.

Devem procurar o endereço da implementação atual.

Devem verificar se o código-fonte do contrato de implementação foi publicado e verificado.

Devem verificar se a implementação mudou recentemente.

Devem analisar quem controla o administrador do proxy ou a autoridade de atualização.

Devem verificar se as atualizações passam por uma carteira multisig, DAO, timelock ou chave privada única.

Devem comparar as datas das auditorias com as datas de implementação do contrato.

Devem consultar a documentação oficial para entender se o contrato foi intencionalmente projetado para ser atualizável.

Não devem presumir que o contrato é imutável apenas porque o endereço do proxy não mudou.

Em depósitos elevados, os usuários devem incluir a análise do proxy na diligência prévia habitual.

Boas práticas para desenvolvedores

Os desenvolvedores devem usar estruturas de proxy bem avaliadas, em vez de escrever lógica de proxy personalizada sem uma análise especializada.

Quando apropriado, devem seguir padrões como o ERC-1967 para que as ferramentas possam consultar o estado do proxy.

Devem proteger as funções de atualização com controles de acesso robustos.

Devem usar carteiras multisig, timelocks ou contratos de governança para controlar autoridades de atualização de alto valor.

Devem escrever cuidadosamente as funções de inicialização e impedir que sejam executadas repetidamente.

Devem testar a estrutura de armazenamento antes de cada atualização.

Nunca devem reordenar, excluir ou alterar variáveis de armazenamento existentes sem entender as consequências.

Devem verificar os contratos de implementação em exploradores de blockchain.

Devem publicar anúncios de atualização, auditorias e explicações técnicas antes de mudanças importantes.

Devem monitorar eventos de atualização e estar preparados para responder rapidamente se uma atualização falhar.

Boas práticas para usuários

Os usuários devem entender que um proxy atualizável não é igual a um contrato inteligente totalmente imutável.

Antes de depositar quantias significativas, devem verificar quem pode atualizar o proxy.

Devem verificar se as atualizações são atrasadas por um timelock.

Devem analisar se a implementação mais recente foi verificada e auditada.

Devem ter cautela quando o administrador do proxy é controlado por uma única carteira desconhecida.

Os usuários devem monitorar eventos de atualização nos protocolos em que mantêm posições elevadas.

Devem evitar conceder permissões ilimitadas de tokens a contratos atualizáveis, a menos que entendam o risco.

Devem revogar aprovações desnecessárias depois de usar um protocolo.

Devem lembrar que uma atualização pode mudar o comportamento futuro, mesmo que o comportamento anterior parecesse seguro.

Os usuários devem tratar contratos proxy como sistemas flexíveis que exigem avaliações contínuas de confiança.

Equívocos comuns sobre contratos proxy

Um equívoco é pensar que um contrato proxy é automaticamente inseguro.

Um contrato proxy pode ser seguro quando usa um padrão comprovado, bom controle de acesso, governança robusta, auditorias e atualizações transparentes.

Outro equívoco é pensar que um contrato proxy é automaticamente seguro por usar uma estrutura popular.

Até mesmo um proxy padrão pode ser perigoso se a implementação for maliciosa ou o administrador for comprometido.

Outro equívoco é acreditar que o endereço do proxy contém toda a lógica que os usuários precisam analisar.

Na realidade, a lógica importante do aplicativo costuma estar no contrato de implementação.

Outro equívoco é acreditar que uma auditoria sempre cobre o código atual.

Se o proxy tiver sido atualizado, a auditoria antiga talvez não cubra a nova implementação.

Outro equívoco é acreditar que proxies mínimos são sempre atualizáveis.

Muitos proxies mínimos são apenas clones baratos que encaminham chamadas para uma lógica fixa.

Perguntas frequentes

O que significa contrato proxy?

Um contrato proxy é um contrato inteligente que encaminha chamadas para outro contrato, geralmente para que o sistema mantenha o mesmo endereço e armazenamento enquanto altera a lógica da implementação.

Por que projetos cripto usam contratos proxy?

Os projetos usam contratos proxy para permitir atualizações, corrigir bugs, adicionar recursos, reduzir o atrito de migração, manter endereços estáveis e implementar vários contratos semelhantes com eficiência.

Um contrato proxy é atualizável?

Muitos contratos proxy são atualizáveis, mas nem todos, pois alguns proxies mínimos apontam para uma lógica fixa.

O que é um contrato de implementação?

Um contrato de implementação contém a lógica executada pelo proxy por meio de encaminhamento ou de

.

O que é delegatecall em um contrato proxy?

é uma operação da EVM que permite que um proxy execute o código da implementação usando o contexto de armazenamento do próprio proxy.

O que é ERC-1967?

ERC-1967 é um padrão que define slots de armazenamento específicos para dados do proxy, como os endereços de implementação, administrador e beacon.

O que é um proxy transparente?

Um proxy transparente é um padrão de proxy atualizável que separa as chamadas administrativas de atualização das chamadas comuns dos usuários para reduzir o risco de conflito entre funções.

O que é um proxy UUPS?

Um proxy UUPS é um padrão de proxy atualizável no qual a lógica de atualização é gerenciada no contrato de implementação, e não principalmente no proxy.

O que é um proxy beacon?

Um proxy beacon obtém o endereço da implementação de um contrato beacon, permitindo atualizar vários proxies em conjunto por meio da alteração do beacon.

O que é um proxy mínimo?

Um proxy mínimo é um pequeno contrato clone, geralmente baseado no ERC-1167, que encaminha chamadas para uma lógica de implementação compartilhada a fim de reduzir o custo de implementação.

Contratos proxy são arriscados?

Sim. Contratos proxy podem ser arriscados se a autoridade de atualização for fraca, a estrutura de armazenamento estiver incorreta, a inicialização não for segura ou os usuários não entenderem que a lógica pode mudar.

Como posso verificar se um contrato é um proxy?

Você pode consultar um explorador de blockchain para encontrar rótulos de proxy, endereços de implementação, slots de armazenamento ERC-1967, código-fonte verificado e eventos de atualização.

Conclusão

Um contrato proxy é um padrão de projeto de contrato inteligente que separa o endereço usado pelos usuários e o estado armazenado da lógica que executa o comportamento do contrato.

Esse padrão é amplamente utilizado em cripto porque permite atualizar contratos inteligentes sem obrigar usuários e integrações a migrar para outro endereço.

O proxy recebe chamadas, mantém o armazenamento e encaminha a execução para um contrato de implementação, geralmente por meio de

.

Padrões como ERC-1967, ERC-1822 e ERC-1167 ajudam a organizar projetos comuns de proxy, incluindo proxies transparentes, proxies UUPS, proxies beacon e proxies mínimos.

Os contratos proxy trazem benefícios importantes, como possibilidade de atualização, continuidade do estado, estabilidade das integrações e implementação de clones a um custo menor.

Também introduzem riscos sérios, como atualizações maliciosas, colisões de armazenamento, contratos não inicializados, chaves administrativas comprometidas, governança pouco clara e auditorias desatualizadas.

Para os desenvolvedores, um contrato proxy deve ser tratado como um componente arquitetônico de alto risco, que exige projeto, testes, controle de acesso e documentação pública cuidadosos.

Para os usuários, um contrato proxy deve ser analisado de forma diferente de um contrato comum e imutável, pois a lógica por trás do proxy pode mudar com o tempo.

A maneira mais simples de entender um contrato proxy é que ele mantém o mesmo endereço on-chain e permite substituir o código por trás desse endereço sob condições controladas.

Essa flexibilidade pode tornar os sistemas cripto mais seguros e fáceis de manter, mas somente quando o poder de atualização é transparente, limitado e cuidadosamente governado.