Possibilidade de atualização de contratos inteligentes

O que é a possibilidade de atualização de contratos inteligentes?

A possibilidade de atualização de contratos inteligentes é a capacidade de alterar, substituir, ampliar ou redirecionar a lógica de um sistema de contratos inteligentes implantado após sua implantação inicial.No universo cripto, essa possibilidade é usada porque muitos contratos inteligentes gerenciam ativos reais, e as equipes podem precisar corrigir bugs, aprimorar recursos, atualizar integrações ou responder a problemas de segurança após o lançamento.

A documentação oficial da Ethereum sobre atualização de contratos inteligentes explica que os contratos inteligentes costumam ser considerados imutáveis, mas os desenvolvedores podem usar padrões de atualização quando mudanças futuras são necessárias.

Um contrato inteligente básico já implantado geralmente mantém o mesmo código para sempre, a menos que tenha sido projetado com um mecanismo de atualização.Um sistema de contratos inteligentes atualizável separa os endereços usados pelos usuários, o estado armazenado e a lógica de negócios, permitindo introduzir uma nova lógica sem exigir que os usuários migrem manualmente.O modelo de atualização mais comum usa um contrato proxy com o qual os usuários interagem e um contrato de implementação que contém a lógica atual.Quando a implementação muda, o endereço do proxy pode continuar o mesmo, enquanto o código por trás dele é alterado.Isso é útil para os usuários porque saldos, permissões e integrações podem continuar apontando para o mesmo endereço.Isso envolve riscos porque as pessoas ou o sistema de governança com autoridade de atualização podem conseguir mudar o comportamento do contrato depois que os usuários depositarem fundos.Em termos simples, a possibilidade de atualização de contratos inteligentes consiste em projetar softwares on-chain para que sua lógica possa ser atualizada posteriormente, preservando estados importantes, a continuidade do endereço e o acesso dos usuários.

Por que a possibilidade de atualização de contratos inteligentes é importante

Essa possibilidade é importante porque o código implantado em uma blockchain pode controlar tokens, tesourarias, mercados de empréstimo, sistemas de staking, bridges, NFTs ou direitos de governança.Um bug em um código imutável pode bloquear ativos, interromper funções para os usuários ou expor fundos a invasores.A possibilidade de atualização oferece aos desenvolvedores uma maneira de corrigir problemas críticos e aprimorar um protocolo após a implantação.

O guia da OpenZeppelin sobre atualização de contratos inteligentes explica que implantações atualizáveis podem modificar o código do contrato preservando o endereço, o estado e o saldo.

Essa preservação é importante porque usuários, carteiras, ferramentas de análise e outros protocolos talvez já dependam do endereço original do contrato.Sem essa possibilidade, uma equipe pode precisar implantar um novo contrato e pedir aos usuários que migrem fundos ou aprovações manualmente.A migração pode ser lenta, arriscada, cara e confusa.No entanto, a possibilidade de atualização também altera o modelo de confiança de um contrato inteligente.Um contrato que pode ser atualizado não é totalmente imutável da mesma forma que um contrato sem mecanismo de atualização.Os usuários devem sempre perguntar quem pode atualizar o contrato, como as atualizações são aprovadas, com que rapidez podem ocorrer e se os usuários podem sair antes que uma mudança importante entre em vigor.

Como funciona a possibilidade de atualização de contratos inteligentes

Em geral, ela funciona separando o armazenamento da lógica.O contrato proxy mantém o endereço chamado pelos usuários e normalmente armazena o estado principal do sistema.O contrato de implementação contém a lógica que define o funcionamento das funções.Quando um usuário chama o proxy, ele encaminha a chamada para o contrato de implementação atual.Em sistemas no estilo Ethereum, esse encaminhamento costuma usar delegatecall, que executa a lógica da implementação no contexto de armazenamento do proxy.Isso significa que o código da implementação pode ler e gravar no armazenamento do proxy como se esse armazenamento pertencesse à implementação.Quando o protocolo é atualizado, uma conta autorizada ou um processo de governança altera o endereço da implementação armazenado pelo proxy.Depois da alteração, as chamadas futuras passam a usar a nova lógica de implementação.O armazenamento antigo pode permanecer, permitindo que os saldos dos usuários e o estado do protocolo continuem existindo, desde que o layout de armazenamento seja compatível.Esse projeto é poderoso, mas exige regras rigorosas para layout de armazenamento, inicialização, autorização, auditorias e governança de atualizações.

Contrato proxy

Em muitos sistemas atualizáveis, o contrato proxy é o endereço estável com o qual usuários e outros contratos interagem.Em geral, o proxy armazena o estado e encaminha chamadas de funções para um contrato de implementação.

A documentação da OpenZeppelin sobre o padrão de atualização de proxies descreve o padrão de proxy com armazenamento não estruturado como um componente fundamental dos contratos atualizáveis.

O proxy é útil porque os usuários não precisam mudar os endereços dos contratos sempre que a lógica é atualizada.Aplicativos, carteiras, dashboards e integrações DeFi podem continuar usando o mesmo endereço de proxy.O padrão de proxy também cria complexidade, pois os usuários podem ver um endereço de contrato enquanto a lógica real está em outro endereço.Exploradores de blockchain muitas vezes mostram informações do proxy e os endereços de implementação quando conseguem detectar o padrão.Os usuários devem analisar tanto o proxy quanto a implementação ao revisar contratos atualizáveis.Um proxy não é automaticamente seguro: a segurança depende dos controles de atualização, da compatibilidade do armazenamento e da qualidade do código da implementação.O proxy é a porta de entrada, enquanto a implementação é a lógica por trás dela.

Contrato de implementação

Um contrato de implementação contém a lógica de negócios usada por um proxy.Ele pode definir funções para transferências, depósitos, saques, empréstimos, votações, emissão, queima, pausa, liquidações ou outras ações do protocolo.Em geral, os usuários não interagem diretamente com o endereço da implementação em um sistema baseado em proxy.Em vez disso, interagem com o proxy, que delega a execução à implementação.Uma atualização normalmente consiste em alterar o proxy para que ele aponte para um novo contrato de implementação.A nova implementação deve ser compatível com o layout de armazenamento antigo e com as expectativas dos usuários.Uma atualização perigosa da implementação pode adicionar lógica maliciosa, quebrar a contabilidade, alterar permissões ou bloquear saques.Por isso, o código da implementação deve ser verificado, auditado, testado e revisado antes da execução da atualização.Os usuários não devem presumir que um protocolo permanecerá igual para sempre apenas porque o endereço do proxy não mudou.Em sistemas atualizáveis, o endereço da implementação é uma parte essencial da análise de segurança.

Delegatecall

Delegatecall é um mecanismo de baixo nível da EVM que permite que um contrato execute código de outro contrato usando o contexto de armazenamento do chamador.Na atualização por proxy, o delegatecall permite que o proxy use a lógica da implementação enquanto mantém o estado no endereço do proxy.É por isso que uma nova implementação pode mudar o comportamento sem transferir os saldos dos usuários para fora do proxy.O delegatecall é poderoso porque separa o código do estado.Ele também envolve riscos porque a implementação deve considerar que está gravando no armazenamento do proxy, não no próprio armazenamento.Se a implementação usar um layout de armazenamento diferente do esperado, as variáveis podem entrar em conflito ou corromper o estado.Um projeto incorreto de delegatecall pode sobrescrever variáveis de propriedade, saldos, mappings ou valores de configuração.Os desenvolvedores devem evitar criar lógica de delegatecall de proxy personalizada, a menos que compreendam plenamente o armazenamento e a execução da EVM.Os usuários não precisam entender cada opcode, mas devem saber que proxies atualizáveis dependem de uma camada técnica de indireção.O delegatecall é uma das razões pelas quais contratos atualizáveis precisam de auditorias especializadas.

Layout de armazenamento

Layout de armazenamento é a ordem e a localização das variáveis no armazenamento de um contrato inteligente.

A documentação oficial da Solidity sobre layout de armazenamento explica como as variáveis de estado são organizadas e por que as regras de layout são importantes para contratos e bibliotecas.

O layout de armazenamento é um dos riscos mais importantes relacionados à possibilidade de atualização.Se uma nova implementação alterar incorretamente a ordem, o tipo ou a estrutura das variáveis existentes, o proxy poderá interpretar os dados antigos de armazenamento de uma forma nova e incorreta.Por exemplo, um mapping de saldos pode ser deslocado, um endereço de proprietário pode ser sobrescrito ou uma variável de configuração pode ser lida como outro tipo.Isso é chamado de risco de colisão ou corrupção de armazenamento.Em geral, os desenvolvedores adicionam novas variáveis depois das existentes, em vez de inseri-las no meio.Também evitam alterar tipos de variáveis ou a ordem de herança sem um planejamento cuidadoso da migração.Ferramentas modernas de atualização podem comparar layouts de armazenamento antes de permitir uma atualização.Os usuários devem considerar a segurança do layout de armazenamento um elemento central da segurança de contratos atualizáveis.

Slots de armazenamento de proxy ERC-1967

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

O padrão oficial ERC-1967 define slots de armazenamento padronizados para proxies, permitindo que ferramentas e exploradores identifiquem a configuração do proxy com mais confiabilidade.

Esses slots padronizados reduzem a possibilidade de que variáveis de gerenciamento do proxy colidam com variáveis de armazenamento do aplicativo.O ERC-1967 também ajuda os exploradores de blockchain a mostrar aos usuários qual implementação um proxy está usando no momento.Muitos sistemas de proxy modernos usam slots compatíveis com o ERC-1967.O padrão, por si só, não torna as atualizações seguras.Ele fornece principalmente um local previsível para armazenar metadados do proxy.Os desenvolvedores ainda precisam garantir autorização correta, validação do layout de armazenamento, revisão da implementação e execução segura da atualização.Ao analisar contratos atualizáveis, os usuários devem verificar se o proxy segue padrões conhecidos em vez de um padrão personalizado desconhecido.O armazenamento padronizado de proxy melhora a transparência, mas é apenas uma parte da segurança da atualização de contratos inteligentes.

Padrão Transparent Proxy

O padrão Transparent Proxy separa chamadas do administrador das chamadas dos usuários para reduzir a confusão entre seletores de funções do proxy e da implementação.

A documentação de proxies da OpenZeppelin explica que o TransparentUpgradeableProxy possui uma interface integrada de administrador e atualização.

Nesse padrão, usuários comuns interagem com funções da implementação por meio do proxy.O administrador do proxy executa ações de atualização e não deve chamar acidentalmente funções da implementação por meio do proxy da mesma maneira que os usuários.Esse projeto ajuda a evitar conflitos caso uma função do proxy e uma função da implementação compartilhem o mesmo seletor.Proxies transparentes são amplamente usados porque fornecem um modelo administrativo claro.No entanto, ainda exigem gerenciamento seguro das chaves de administrador.Se o administrador do proxy for controlado por uma única chave exposta, todo o protocolo poderá ficar em risco.Proxies transparentes podem ser seguros quando combinados com controle multisig, timelocks, auditorias e governança clara.O padrão reduz um risco técnico, mas não elimina o risco de governança.

Padrão de proxy UUPS

UUPS significa Universal Upgradeable Proxy Standard.

O padrão oficial EIP-1822 descreve um padrão universal de proxy atualizável no qual a lógica de atualização está vinculada ao projeto da implementação.

A documentação da OpenZeppelin explica que o UUPSUpgradeable inclui o mecanismo de atualização no contrato de implementação, em vez de usar a mesma estrutura integrada de administrador do proxy transparente.Proxies UUPS podem ser mais leves do que proxies transparentes porque o próprio proxy pode ser mais simples.No entanto, a implementação deve incluir e proteger corretamente as funções de atualização.Uma implementação UUPS inadequada pode remover acidentalmente a capacidade de atualização, expor a autoridade de atualização ou permitir atualizações não autorizadas.Os desenvolvedores também precisam se proteger contra atualizações para uma implementação que interrompa o caminho de atualização.O UUPS pode ser eficiente e flexível quando usado com bibliotecas maduras e ferramentas de validação.Não deve ser copiado sem entender a autorização e as verificações de segurança das atualizações.Os usuários devem verificar quem controla as atualizações UUPS e se as atualizações anteriores foram transparentes e auditadas.

Padrão Beacon Proxy

O padrão Beacon Proxy usa um contrato beacon que armazena o endereço da implementação para vários proxies.Em vez de cada proxy armazenar seu próprio endereço de implementação, cada proxy consulta a implementação no beacon.Isso permite atualizar muitas instâncias de proxy em conjunto, alterando um único beacon.Proxies beacon são úteis para sistemas que implantam muitos contratos semelhantes, como cofres, pools, contas ou instâncias de contrato específicas para usuários.Eles podem reduzir a complexidade operacional quando muitas instâncias precisam da mesma atualização.Também podem aumentar o alcance do impacto, pois uma atualização ruim do beacon pode afetar muitos proxies de uma só vez.A documentação de proxies da OpenZeppelin inclui BeaconProxy e UpgradeableBeacon como componentes relacionados a proxies.A autoridade do beacon deve ser protegida cuidadosamente porque pode controlar a lógica de muitos contratos.Os usuários devem verificar se o contrato que usam depende de um beacon e quem pode atualizá-lo.Um beacon é conveniente para desenvolvedores, mas concentra o poder de atualização em um ponto de controle compartilhado.

Padrão Diamond Proxy

O padrão Diamond Proxy permite que um contrato semelhante a um proxy encaminhe chamadas de funções para vários contratos de implementação chamados facets.

O padrão oficial Diamond EIP-2535 define um sistema modular de contratos inteligentes no qual funções podem ser adicionadas, substituídas ou removidas por meio de facets.

Diamonds são úteis para sistemas grandes que ultrapassariam os limites de tamanho de contratos ou precisam de atualizações modulares.Um diamond pode organizar uma lógica complexa em várias facets separadas, mantendo um endereço principal.Essa flexibilidade pode ser útil para grandes sistemas DeFi, jogos, sistemas de contas ou estruturas de protocolos.Ela também aumenta a complexidade, pois usuários e auditores precisam entender o encaminhamento de facets, as tabelas de seletores, os padrões de armazenamento e a autoridade de atualização.Uma atualização de diamond pode substituir apenas parte do sistema, o que torna importante acompanhar as mudanças.O projeto de armazenamento é especialmente importante porque várias facets podem compartilhar o mesmo armazenamento.Os desenvolvedores devem usar padrões claros de armazenamento Diamond ou armazenamento com namespace quando apropriado.Os usuários devem considerar os contratos Diamond sistemas atualizáveis avançados que exigem revisão cuidadosa.

Armazenamento com namespace

O armazenamento com namespace é um método para organizar o armazenamento de contratos, de modo que diferentes módulos usem locais definidos e reduzam o risco de colisões.

O padrão oficial ERC-7201 de layout de armazenamento com namespace define uma convenção para documentar locais de armazenamento desse tipo no código-fonte Solidity.

O armazenamento com namespace é útil em contratos atualizáveis e modulares porque reduz a dependência de uma única ordem simples de variáveis ao longo de uma cadeia longa de herança.Ele pode tornar as atualizações mais seguras quando os contratos são construídos com vários módulos.Também pode ajudar as ferramentas a validar alterações de armazenamento com mais clareza quando há suporte do compilador e da estrutura de desenvolvimento.

As orientações da OpenZeppelin sobre como escrever contratos atualizáveis observam que é necessário usar Solidity 0.8.20 ou superior para que seus plugins de atualização validem layouts de armazenamento com namespace com as informações necessárias do compilador.

O armazenamento com namespace não elimina a necessidade de auditorias.Ele ajuda a estruturar o estado para facilitar o gerenciamento de mudanças futuras.Os desenvolvedores devem usar o armazenamento com namespace de forma consistente caso escolham essa arquitetura.Os usuários se beneficiam indiretamente porque um projeto de armazenamento mais seguro reduz a possibilidade de corrupção de estado relacionada a atualizações.

Inicializadores

Inicializadores são funções especiais de configuração usadas por contratos atualizáveis no lugar de construtores.Em um contrato normal, o construtor é executado quando o contrato é implantado.Em um sistema de proxy, os usuários interagem com o proxy, e os construtores da implementação não inicializam o armazenamento do proxy da maneira normal.Por isso, implementações atualizáveis geralmente usam funções inicializadoras para definir proprietários, nomes de tokens, permissões, valores de configuração e outros estados iniciais.Um inicializador deve ser executado apenas uma vez, a menos que se use um reinitializer cuidadosamente projetado para uma atualização posterior.Se um inicializador ficar aberto, um invasor poderá inicializar o contrato e assumir o controle de funções importantes.Se uma nova implementação precisar de novas variáveis de estado, talvez seja necessário um reinitializer para configurá-las com segurança.Os desenvolvedores devem proteger os inicializadores e, quando apropriado, desabilitar a inicialização em contratos de implementação independentes.Os usuários devem ter cautela quando o histórico de inicialização de um contrato atualizável não estiver claro.Erros de inicialização são uma fonte importante de vulnerabilidades em contratos atualizáveis.

Autoridade de atualização

A autoridade de atualização é a conta, o contrato, a carteira multisig, o timelock, a DAO ou o sistema de governança que pode aprovar atualizações.Essa autoridade é uma das premissas de confiança mais importantes em um contrato atualizável.Se uma única chave privada controlar as atualizações, ela poderá substituir a lógica do protocolo.Se uma carteira multisig controlar as atualizações, os usuários precisarão confiar no grupo de signatários e em sua segurança operacional.Se uma DAO controlar as atualizações, os usuários precisarão entender o poder de voto, o quórum, o prazo para propostas, o prazo de execução e os riscos de ataques à governança.Se um timelock controlar as atualizações, os usuários poderão ter tempo para revisar a mudança e sair antes que ela entre em vigor.Um processo de atualização seguro geralmente combina execução multisig, atraso por timelock, divulgação pública da proposta, revisão de auditoria e monitoramento.A autoridade de atualização deve ser visível e documentada.Os usuários não devem considerar contratos atualizáveis sem necessidade de confiança se um pequeno grupo puder alterá-los instantaneamente.Em sistemas atualizáveis, o projeto de governança também é um projeto de segurança.

Timelocks

Um timelock adia a execução depois que uma atualização é proposta ou aprovada.Esse atraso dá a usuários, auditores, pesquisadores e sistemas de monitoramento tempo para revisar a mudança prevista.Um timelock pode reduzir o risco de atualizações surpresa que alteram imediatamente o comportamento do contrato.Também pode dar aos usuários tempo para sacar fundos caso discordem da atualização.No entanto, timelocks não são perfeitos, pois correções emergenciais podem exigir rapidez durante ataques em andamento.Alguns sistemas usam caminhos emergenciais mais curtos e caminhos normais de governança mais longos.Caminhos emergenciais podem proteger usuários contra exploits, mas também podem criar riscos de centralização.Um bom protocolo explica claramente suas regras de timelock.Os usuários devem verificar se as atualizações são adiadas, imediatas ou controladas por poderes emergenciais.Um timelock é valioso porque transforma o poder instantâneo da autoridade de atualização em um poder visível e sujeito a atraso.

Atualizações controladas por governança

Atualizações controladas por governança usam votação de tokens, votação por delegados, aprovação de conselho, propostas de DAO ou sistemas semelhantes para aprovar mudanças na implementação.Isso pode tornar as atualizações mais descentralizadas do que o uso de uma única chave de administrador.Também pode tornar as atualizações mais lentas e complexas.A segurança da governança depende da distribuição dos eleitores, das regras de quórum, dos limites para propostas, do atraso da votação, do atraso de execução, da delegação e da resistência à compra de votos ou a ataques de governança com empréstimos relâmpago.Uma votação de governança não significa automaticamente que uma mudança é tecnicamente segura.Os eleitores podem aprovar códigos que não compreendem plenamente.Uma proposta maliciosa pode ocultar lógica perigosa em um pacote de atualização grande.Os protocolos devem publicar diferenças claras do código, auditorias, resultados de simulações e explicações em linguagem simples antes das votações.Os usuários devem revisar os processos de atualização por governança antes de depositar ativos em um protocolo.A governança pode distribuir o poder, mas não elimina a necessidade de uma revisão técnica de segurança.

Contratos imutáveis vs. contratos atualizáveis

Um contrato inteligente imutável não pode ser alterado após a implantação, a menos que tenha sido projetado com controles externos ou caminhos de migração.Um contrato inteligente atualizável pode mudar sua lógica por meio de um mecanismo de atualização definido.Contratos imutáveis podem ser mais fáceis de avaliar porque o código implantado permanece fixo.Também podem ser perigosos se um bug grave for descoberto e não houver uma correção segura.Contratos atualizáveis podem corrigir bugs e adicionar recursos.Também podem introduzir riscos de confiança porque a lógica futura pode ser diferente do código originalmente analisado pelos usuários.Nenhum dos modelos é sempre melhor.Um contrato simples de token pode preferir a imutabilidade se suas regras nunca devem mudar.Um protocolo DeFi complexo pode precisar de possibilidade de atualização para aplicar correções de segurança e se adaptar às condições de mercado.O projeto adequado depende dos riscos, da complexidade, da maturidade da governança e das expectativas dos usuários.

Migração vs. possibilidade de atualização

Migração significa implantar um novo contrato e transferir usuários, ativos ou integrações do contrato antigo para o novo.A possibilidade de atualização significa alterar a lógica por trás de um endereço ou sistema existente, preservando o estado ou a continuidade para os usuários.A migração pode ser mais fácil de entender porque o contrato antigo permanece inalterado e o novo contrato é separado.A migração pode ser trabalhosa porque os usuários talvez precisem aprovar transferências, mover posições, resgatar novos tokens ou atualizar integrações.A possibilidade de atualização pode proporcionar uma experiência mais fluida porque o mesmo endereço continua ativo.Também pode ocultar grandes mudanças por trás do mesmo endereço.Alguns protocolos usam as duas abordagens, dependendo da gravidade da mudança.Uma pequena correção de bug pode ser feita por meio de uma atualização, enquanto uma reformulação importante pode exigir uma migração.Os usuários devem entender se um protocolo pode mudar no próprio endereço ou se exige migração manual.Os riscos de migração e de atualização são diferentes, mas ambos exigem comunicação cuidadosa.

Verificação do código-fonte

A verificação do código-fonte ajuda os usuários a comparar o código-fonte publicado com o bytecode implantado.

A documentação oficial da Ethereum sobre verificação de contratos inteligentes explica que a verificação compara o código-fonte do contrato inteligente com o bytecode compilado.

Em contratos atualizáveis, os usuários devem verificar, quando possível, tanto o proxy quanto a implementação atual.Um proxy verificado, por si só, talvez não revele toda a lógica de negócios.Uma implementação verificada ajuda os usuários a ler a lógica atual, mas ainda é necessário verificar a autoridade de atualização.Quando um protocolo é atualizado, a nova implementação também deve ser verificada.Os usuários não devem presumir que um contrato continua seguro só porque uma implementação anterior foi auditada.Uma atualização pode adicionar novas funções, alterar permissões, modificar a contabilidade ou introduzir novos bugs.A verificação é uma medida de transparência, não uma garantia completa de segurança.Sistemas atualizáveis precisam de verificação contínua após cada atualização.

Espaços reservados de armazenamento

Espaços reservados de armazenamento são slots não utilizados reservados em contratos atualizáveis para que versões futuras possam adicionar variáveis sem deslocar inesperadamente o armazenamento dos contratos derivados.Esse padrão é comum em contratos atualizáveis com muitas camadas de herança.Um espaço reservado pode aparecer como um array não utilizado de tamanho fixo, reservado para variáveis futuras.Quando uma atualização futura adiciona variáveis de estado, os desenvolvedores podem reduzir o tamanho do espaço reservado de forma correspondente.Esses espaços são úteis, mas exigem disciplina.O uso incorreto ainda pode causar problemas no layout de armazenamento.O armazenamento com namespace é uma abordagem mais recente que pode reduzir a dependência de grandes espaços reservados em algumas arquiteturas.Os desenvolvedores devem seguir as orientações da estrutura de atualização e das ferramentas do compilador que utilizam.Os auditores devem revisar os espaços reservados e as alterações de layout durante cada atualização.Os usuários não precisam gerenciar esses espaços, mas se beneficiam quando os desenvolvedores os usam corretamente.

Testes de atualização

Os testes de atualização verificam se uma nova implementação funciona corretamente com o estado existente do proxy.Testes unitários comuns não são suficientes porque podem implantar um contrato novo com armazenamento vazio.Os testes devem simular a versão antiga, preencher um estado realista, executar a atualização e, em seguida, testar a nova versão com o estado existente.Os testes devem verificar saldos, permissões, contabilidade, aprovações de tokens, atribuições de funções, configurações de oráculos, lógica de pausa e posições dos usuários.Também devem verificar se usuários não autorizados não conseguem atualizar o contrato.Testes em fork podem ajudar a simular atualizações usando o estado real da blockchain, quando apropriado.Ferramentas de validação do layout de armazenamento podem detectar muitas alterações inseguras antes da implantação.A cobertura de testes deve incluir tanto os casos esperados quanto os cenários de falha.Cada atualização deve ser tratada como uma nova implantação, com risco adicional de migração.Um protocolo que atualiza sem testes rigorosos expõe os usuários a riscos evitáveis.

Auditorias de atualização

Uma auditoria de atualização analisa a nova implementação, as alterações de armazenamento, a lógica de inicializador ou reinitializer, os controles de acesso e o caminho de execução da governança.A auditoria deve comparar a versão antiga com a nova.O objetivo não é apenas inspecionar o código novo, mas também entender como ele afeta o estado existente e os usuários.Os auditores devem revisar o layout de armazenamento, chamadas externas, permissões, autorização de atualização, controles emergenciais, eventos e compatibilidade com integrações.Também devem verificar se a atualização cria alterações incompatíveis na ABI para aplicativos que chamam o contrato.Uma auditoria não garante segurança, mas reduz riscos.Grandes protocolos devem publicar relatórios ou resumos de auditoria quando as atualizações afetarem fundos dos usuários.Mesmo atualizações pequenas podem ser perigosas se alterarem a contabilidade, as permissões, os saques ou a lógica do oráculo.Os usuários devem verificar se uma atualização importante da implementação foi auditada antes de confiar nela.Auditorias de atualização são uma defesa essencial contra regressões ocultas.

Compatibilidade da ABI

Compatibilidade da ABI significa que aplicativos externos podem continuar chamando o contrato conforme esperado após uma atualização.A ABI define os nomes das funções, entradas, saídas, eventos e erros usados por carteiras e aplicativos.Uma atualização pode quebrar a compatibilidade se remover funções, alterar tipos de retorno, mudar o comportamento dos eventos ou alterar premissas das quais integradores dependem.Alterações incompatíveis na ABI podem fazer aplicativos de interface, bots, sistemas contábeis ou integrações DeFi falharem.Mesmo que o armazenamento esteja seguro, a experiência do usuário pode ser prejudicada se a interface mudar sem coordenação.Os desenvolvedores devem documentar claramente as alterações da ABI antes das atualizações.Os integradores devem monitorar atualizações de implementação nos protocolos dos quais dependem.Os usuários podem ver transações falharem se um aplicativo não for atualizado para uma nova implementação.A compatibilidade da ABI faz parte da segurança das atualizações porque contratos inteligentes existem dentro de um ecossistema mais amplo.Uma atualização tecnicamente válida ainda pode prejudicar usuários reais se as interfaces forem alteradas sem cuidado.

Risco relacionado à chave de administrador

O risco relacionado à chave de administrador é a possibilidade de que a chave ou conta que controla as atualizações seja roubada, usada indevidamente, perdida ou controlada por uma parte não confiável.Se um invasor obtiver autoridade de atualização, poderá implantar lógica maliciosa que drene fundos ou altere saldos.Se uma chave de administrador for perdida, a equipe poderá ficar impossibilitada de corrigir bugs futuros.Se uma pessoa controlar a chave de administrador, os usuários precisarão confiar que ela não agirá de forma maliciosa ou negligente.Carteiras multisig podem reduzir o risco de uma única chave ao exigir várias aprovações.Timelocks podem reduzir o risco de atualizações surpresa ao acrescentar um atraso.A governança de uma DAO pode distribuir o poder de atualização, mas introduz riscos de ataques à governança.Os protocolos devem divulgar quem controla as atualizações e como as chaves são protegidas.Os usuários devem considerar o controle administrativo oculto ou pouco claro um importante sinal de alerta.Em contratos atualizáveis, a segurança administrativa costuma ser tão importante quanto a segurança do código.

Atualizações emergenciais

Atualizações emergenciais são atualizações rápidas usadas para corrigir vulnerabilidades críticas ou interromper ataques em andamento.Elas podem proteger fundos dos usuários quando esperar por um ciclo completo de governança seria lento demais.Também podem criar riscos de centralização, pois talvez contornem os processos normais de revisão, votação ou atraso por timelock.Um protocolo deve definir seus poderes emergenciais antes que ocorra uma emergência.Os controles emergenciais devem ser limitados, documentados, monitorados e regidos por processos confiáveis.Após uma atualização emergencial, a equipe deve divulgar informações claras sobre o que mudou e por quê.Os usuários devem entender se um protocolo possui direitos de atualização emergencial.Um protocolo sem caminho emergencial pode demorar mais para responder a exploits.Um protocolo com poderes emergenciais ilimitados pode exigir confiança excessiva.O melhor projeto equilibra proteção rápida com transparência e responsabilidade.

Tokens atualizáveis

Tokens atualizáveis são tokens cujos contratos podem ter a lógica alterada após a implantação.Isso pode permitir correções de bugs, mudanças de conformidade, novos modelos de taxas, alterações de bridges ou atualizações de recursos.Também pode permitir mudanças perigosas, como novos direitos de emissão, restrições de transferência, listas de bloqueio ou taxas inesperadas.Os usuários devem verificar se o contrato de um token é atualizável antes de presumir que suas regras são fixas.Um token com autoridade de atualização pode mudar de comportamento mesmo que seu nome, símbolo e endereço continuem iguais.Os detentores de tokens devem revisar as funções de administrador, a autoridade de emissão, os controles de pausa, as funções de lista de bloqueio e a governança das atualizações.O código-fonte verificado deve ser revisado após atualizações importantes.Provedores de liquidez devem ter cautela especial, pois mudanças nas regras de um token podem afetar pools de negociação.Um token atualizável pode ser legítimo, mas seu modelo de confiança é diferente do de um token imutável.A possibilidade de atualização de um token deve ser claramente informada aos usuários.

Protocolos DeFi atualizáveis

Protocolos DeFi atualizáveis podem mudar a lógica de empréstimos, swaps, staking, liquidações, estratégias de cofres, taxas de juros ou regras de colateral.Essa flexibilidade pode ser útil porque os mercados DeFi mudam rapidamente e os bugs podem ser graves.Ela também pode criar riscos porque as regras do protocolo podem mudar depois que os usuários depositarem fundos.Uma atualização pode alterar a lógica de saque, os cálculos de taxas, os parâmetros de risco, as fontes de oráculos ou o comportamento de liquidação.Os usuários devem verificar se as atualizações de um protocolo DeFi são controladas por uma equipe, uma carteira multisig, um timelock ou um processo de governança.Também devem verificar se os contratos críticos são imutáveis ou atualizáveis.Um protocolo pode ter alguns contratos imutáveis e outros atualizáveis.O risco de atualização em DeFi é especialmente importante porque os contratos frequentemente mantêm liquidez agrupada.Uma única atualização inadequada pode afetar muitos usuários ao mesmo tempo.DeFi atualizável exige monitoramento contínuo, não confiança pontual.

Possibilidade de atualização e oráculos

Oráculos fornecem dados externos, como preços de ativos, a contratos inteligentes.Um protocolo atualizável pode conseguir alterar a lógica ou os endereços dos oráculos.

A documentação oficial da Ethereum sobre oráculos explica que eles são necessários porque contratos inteligentes não conseguem acessar dados off-chain diretamente por conta própria.

A possibilidade de atualizar oráculos pode ser útil quando um feed antigo se torna pouco confiável ou uma fonte melhor fica disponível.Isso pode ser perigoso se um administrador puder trocar o oráculo por um manipulável ou malicioso.Em sistemas de empréstimos e derivativos, uma atualização inadequada do oráculo pode causar liquidações injustas ou liquidações incorretas de contratos.Os usuários devem verificar quem pode alterar as fontes dos oráculos e se essas alterações estão sujeitas a timelock.Os desenvolvedores devem usar governança e monitoramento robustos para os oráculos.Alterações em oráculos devem ser tratadas como atualizações de alto risco.As fontes de dados fazem parte da lógica do contrato inteligente mesmo quando estão fora do código principal do contrato.

Possibilidade de atualização e bridges

Bridges costumam usar contratos atualizáveis porque sua lógica precisa responder a novas redes, formatos de mensagens, conjuntos de validadores, controles de risco e correções de segurança.A possibilidade de atualização de bridges pode melhorar sua adaptabilidade.Também pode criar grandes riscos de confiança porque bridges podem controlar grandes quantidades de ativos bloqueados ou emitidos.Uma atualização maliciosa de uma bridge pode alterar as regras de saque, emitir indevidamente ativos wrapped ou redirecionar fundos.Os usuários devem verificar a autoridade de atualização da bridge, a governança dos validadores, os timelocks, as auditorias e os controles emergenciais.Bridges já são complexas porque dependem de várias redes e premissas de verificação.A possibilidade de atualização acrescenta outra camada de risco.Um contrato de bridge com governança de atualização robusta pode ser mais seguro do que um controlado por uma única chave.No entanto, nenhum processo de atualização elimina todos os riscos das bridges.Antes de transferir ativos, os usuários de bridges devem entender tanto as premissas técnicas quanto as de governança.

Possibilidade de atualização e confiança dos usuários

A possibilidade de atualização envolve uma compensação em termos de confiança.Os usuários se beneficiam de correções de bugs e melhorias de recursos.Ao mesmo tempo, aceitam o risco de que a lógica futura mude de maneiras que não lhes agradem.Um processo transparente de atualização pode aumentar a confiança ao mostrar o que será alterado antes da mudança.Um processo oculto ou instantâneo pode reduzir a confiança porque os usuários não conseguem avaliar as mudanças a tempo.Os protocolos devem explicar em linguagem simples os direitos de atualização.Devem publicar endereços de implementação e de administrador, detalhes de timelocks, relatórios de auditoria e propostas de governança.Os usuários não devem perguntar apenas se um contrato foi auditado.Também devem perguntar se o código auditado pode ser substituído amanhã.Em contratos inteligentes atualizáveis, a confiança depende tanto do código atual quanto do controle de mudanças futuras.

Como verificar se um contrato é atualizável

Comece verificando a página do contrato em um explorador de blockchain para saber se ele está identificado como proxy.Em seguida, verifique o endereço da implementação, caso o explorador o mostre.Confira se o proxy segue um padrão conhecido, como ERC-1967, Transparent Proxy, UUPS, Beacon Proxy ou Diamond.Verifique se o código-fonte da implementação está verificado.Confira quem controla as atualizações por meio dos endereços de administrador, funções de proprietário, carteiras multisig, timelocks ou contratos de governança.Revise eventos recentes para encontrar mudanças de implementação ou transações de atualização.Leia a documentação do protocolo para entender a política de atualização.Consulte os relatórios de auditoria para saber se a possibilidade de atualização foi incluída no escopo.Monitore propostas de governança se o protocolo usar atualizações controladas por uma DAO.Um endereço de contrato, por si só, não é suficiente: sistemas atualizáveis exigem analisar em conjunto o proxy, a implementação e a estrutura de autoridade.

Erros comuns relacionados à possibilidade de atualização de contratos inteligentes

Um erro comum é alterar a ordem das variáveis de armazenamento durante uma atualização.Outro é esquecer de proteger as funções inicializadoras.Um terceiro erro é usar uma única chave privada como único administrador de atualização.Um quarto erro é atualizar sem timelock ou aviso público.Um quinto erro é implantar uma nova implementação sem verificar o código-fonte.Um sexto erro é presumir que uma auditoria antiga ainda cobre uma nova implementação.Um sétimo erro é alterar a ABI de uma maneira que interrompa integrações.Um oitavo erro é não testar atualizações com um estado de produção existente ou semelhante.Um nono erro é usar lógica de proxy personalizada sem uma revisão aprofundada.Um décimo erro é dizer aos usuários que um sistema é descentralizado quando um pequeno grupo de administradores pode substituir a lógica instantaneamente.

Benefícios da possibilidade de atualização de contratos inteligentes

O primeiro benefício é a capacidade de corrigir bugs após a implantação.O segundo é a possibilidade de adicionar recursos sem exigir que os usuários migrem manualmente.O terceiro é a continuidade do endereço para usuários, carteiras e integrações.O quarto é uma capacidade de resposta maior durante emergências.O quinto é uma melhor manutenção de longo prazo para protocolos complexos.O sexto é uma evolução mais fluida dos produtos em mercados cripto em rápida mudança.O sétimo é a capacidade de atualizar integrações de oráculos, parâmetros de risco ou dependências externas.O oitavo é a redução de obstáculos à migração quando o projeto do protocolo evolui.Esses benefícios explicam por que muitos aplicativos cripto sofisticados escolhem arquiteturas atualizáveis.Os benefícios são maiores quando a autoridade de atualização é transparente, segura, sujeita a atrasos, auditada e gerida com responsabilidade.

Riscos e limitações da possibilidade de atualização de contratos inteligentes

O primeiro risco é uma autoridade de atualização maliciosa ou comprometida.O segundo é a corrupção de armazenamento durante uma alteração insegura da implementação.O terceiro é o uso indevido de inicializadores ou reinitializers.O quarto é a centralização oculta por meio de chaves de administrador.O quinto são integrações interrompidas por mudanças na ABI ou no comportamento.O sexto é a confusão dos usuários porque o endereço visível pode permanecer igual enquanto a lógica muda.O sétimo é o uso abusivo de atualizações emergenciais.O oitavo é a falsa confiança em uma auditoria que cobriu apenas uma implementação antiga.O nono é a captura da governança ou uma votação apressada.O décimo é a complexidade que torna o sistema mais difícil de entender para usuários e auditores.

Boas práticas para desenvolvedores

Quando possível, use bibliotecas de atualização maduras e bem revisadas, em vez de criar código de proxy personalizado.Escolha um padrão de atualização claro, como Transparent Proxy, UUPS, Beacon Proxy ou Diamond, somente depois de entender suas compensações.Valide o layout de armazenamento antes de cada atualização.Proteja cuidadosamente inicializadores e reinitializers.Use controle multisig, timelocks e processos de governança para exercer uma autoridade de atualização significativa.Publique endereços de implementação, transações de atualização e explicações em linguagem simples.Verifique o código-fonte de cada nova implementação.Execute testes de atualização com um estado semelhante ao de produção e em ambientes fork, quando apropriado.Audite atualizações importantes antes da execução.Monitore eventos de atualização e prepare planos de reversão ou resposta a incidentes quando a arquitetura permitir.

Boas práticas para usuários

Verifique se um contrato é atualizável antes de depositar fundos.Analise quem controla a autoridade de atualização.Dê preferência a protocolos que usem timelocks, controles multisig, auditorias e governança pública para atualizações.Verifique se o código-fonte da implementação atual está verificado.Não presuma que uma auditoria antiga cobre uma nova implementação.Monitore os anúncios de grandes atualizações do protocolo se você o utiliza com frequência.Entenda se atualizações emergenciais podem contornar atrasos normais.Revise funções administrativas, controles de pausa, controles de oráculos e permissões de emissão de tokens.Quando possível, considere sacar fundos antes de atualizações controversas ou pouco claras.Trate a possibilidade de atualização como uma premissa de confiança, não como um detalhe técnico secundário.

Perguntas frequentes

O que significa a possibilidade de atualização de contratos inteligentes?

Significa que um sistema de contratos inteligentes implantado pode alterar sua lógica após a implantação por meio de um mecanismo de atualização projetado para esse fim.

Por que os contratos inteligentes são atualizados?

Os contratos inteligentes são atualizados para corrigir bugs, adicionar recursos, melhorar a segurança, atualizar integrações, ajustar controles de risco ou responder às necessidades em evolução do protocolo.

Contratos inteligentes atualizáveis são menos seguros?

Contratos inteligentes atualizáveis não são automaticamente menos seguros, mas acrescentam riscos relacionados ao controle administrativo, ao layout de armazenamento, à governança e a mudanças futuras na implementação.

O que é um contrato proxy?

Um contrato proxy é um endereço estável que encaminha chamadas para um contrato de implementação, geralmente preservando o estado do sistema.

O que é um contrato de implementação?

Um contrato de implementação contém a lógica que um proxy executa por delegação.

Qual é o maior risco de atualizações de contratos inteligentes?

O maior risco é que uma autoridade de atualização autorizada ou comprometida substitua uma lógica segura por uma lógica defeituosa ou maliciosa.

O que é o risco de layout de armazenamento?

É a possibilidade de que uma nova implementação leia ou grave incorretamente no armazenamento existente do proxy e corrompa estados importantes.

O que é um timelock no contexto de atualizações?

Um timelock adia a execução de uma atualização para que usuários e revisores tenham tempo de analisar as mudanças propostas antes que entrem em vigor.

Um código-fonte verificado significa que um contrato atualizável é seguro?

Não. O código-fonte verificado melhora a transparência, mas os usuários ainda precisam analisar a autoridade de atualização, as auditorias, a segurança do armazenamento, a governança e os riscos de mudanças futuras.

Como posso saber se um contrato é atualizável?

Você pode verificar os rótulos de proxy em exploradores de blockchain, os endereços de implementação, os slots ERC-1967, os eventos de atualização, as funções administrativas, a documentação de governança e os relatórios de auditoria.

Conclusão

A possibilidade de atualização de contratos inteligentes é uma abordagem de projeto que permite que aplicativos blockchain alterem a lógica dos contratos após a implantação, preservando endereços e estados importantes.Ela é amplamente usada porque aplicativos cripto frequentemente precisam de correções de bugs, melhorias de recursos, correções de segurança e atualizações de integrações após o lançamento.Os projetos de atualização mais comuns usam proxies, contratos de implementação, delegatecall, slots de armazenamento padronizados e autoridade de atualização controlada.A possibilidade de atualização pode tornar os protocolos mais fáceis de manter e mais resilientes, mas também altera o modelo de confiança porque o código futuro pode ser diferente daquele que os usuários analisaram originalmente.A segurança de um sistema atualizável depende da disciplina no layout de armazenamento, da proteção dos inicializadores, da verificação do código-fonte, de testes, auditorias, segurança das chaves de administrador, timelocks e governança transparente.Os usuários nunca devem tratar um contrato atualizável como totalmente imutável, a menos que a autoridade de atualização tenha sido removida ou impossibilitada pelo próprio projeto.Os desenvolvedores nunca devem tratar a possibilidade de atualização como um atalho simples, pois esse padrão acrescenta responsabilidades importantes de engenharia e governança.Para iniciantes, a possibilidade de atualização de contratos inteligentes pode ser entendida como uma forma de atualizar softwares blockchain após a implantação.Para usuários avançados, trata-se de um modelo completo de segurança que envolve arquitetura de proxy, compatibilidade de armazenamento, controle de acesso, execução de governança, monitoramento e direitos de saída dos usuários.No contexto do glossário cripto, a possibilidade de atualização de contratos inteligentes é a capacidade de um sistema de contratos inteligentes implantado alterar sua lógica por meio de um mecanismo controlado, mantendo intactos estados on-chain importantes e endereços usados pelos usuários.O principal ponto é que essa possibilidade pode proteger usuários contra bugs permanentes e apoiar a evolução do protocolo, mas precisa ser gerenciada com transparência, controles robustos, testes cuidadosos e divulgação clara, pois o poder de atualização também pode se tornar uma importante fonte de risco.