Chaves de administração e imutabilidade

Curiosidade

1. O que é uma autoridade de mint e o que ela permite ao seu detentor fazer?
2. Por que um proxy atualizável pode ser ao mesmo tempo uma funcionalidade de segurança e uma porta dos fundos?
3. Se remover as chaves de administrador elimina ataques, mas também impede correções, quem decide qual risco uma comunidade aceita?

Explorar

Parte IChaves de administração: a raiz do roubo de contratos

1. Muitos rug pulls têm origem em um poder retido. Uma autoridade de cunhagem permite que seu detentor imprima tokens ilimitados e os venda no mercado conforme desejar. Uma autoridade de congelamento ou lista negra impede que determinados detentores movam seus saldos. Um imposto definido pelo proprietário pode elevar a taxa de venda a cem por cento, prendendo a liquidez no lugar. Cada um desses é uma chave nas mãos de alguém, e cada uma delas pode ser usada contra as próprias pessoas para quem foi criada.
2. Proxies atualizáveis separam o armazenamento da lógica: o estado fica em um endereço, enquanto o código é executado a partir de outro, que pode ser trocado pelo administrador a qualquer momento. Isso permite a aplicação de correções quando erros são encontrados, mas também significa que as regras de um token podem mudar retroativamente para todos os detentores. Em explorações no setor DeFi, as atualizações de proxies têm sido usadas indevidamente para redirecionar fundos ou alterar o comportamento do protocolo após sua implementação. O token Squid Game (novembro de 2021) mostra para onde leva o controle retido: seu contrato permitia que qualquer pessoa comprasse, mas impedia os detentores comuns de venderem, e quando seus criadores fizeram o resgate do valor, o preço caiu quase a zero em poucos minutos.
3. O trade-off é estrutural. Remova a chave de mint e ninguém poderá imprimir tokens extras; remova o caminho de saque da liquidez do pool e ninguém poderá retirar as reservas. O custo disso é que nenhum desenvolvedor, auditor ou membro da comunidade poderá corrigir um erro, responder a uma emergência ou ajustar parâmetros quando as condições mudam. Em um mercado sem permissões, todo poder administrativo é simultaneamente uma superfície de ataque e uma ferramenta de manutenção. Qual lado ele serve depende se o detentor da chave age de boa-fé e mantém a chave segura.
4. As defesas em camada de carteira não podem substituir o design em nível de contrato. Um usuário pode revogar as aprovações de tokens, evitar assinar transações desconhecidas e verificar os endereços dos contratos antes de interagir, mas essas práticas não têm efeito algum contra uma autoridade de criação de tokens que esteja sendo utilizada ativamente ou contra um upgrade de proxy que altera as regras durante a transação. Nos tokens SPL, a autoridade de criação é sempre definida no momento da criação e permanece assim até ser definida como Nenhuma; a autoridade de bloqueio é opcional e, se omitida, nunca pode ser adicionada. De qualquer forma, uma autoridade ativa funciona independentemente do cuidado do usuário.
5. A documentação de proxy do OpenZeppelin deixa a arquitetura explícita: um contrato de implementação contém a lógica, enquanto o proxy mantém o estado e encaminha todas as chamadas feitas a ele por meio de delegatecall. Atualizar significa direcionar o proxy para um novo endereço de implementação. É assim que as equipes enviam correções, mas isso também significa que qualquer detentor da autoridade de atualização pode substituir todo o conjunto de regras em uma única transação. A distinção entre um patch e um roubo é puramente comportamental, não técnica.
6. Ao inspecionar o contrato de um token, é possível saber quais chaves estão ativas. Em uma cadeia EVM, verifique se existe um papel de proprietário no contrato e se ele está por trás de um proxy atualizável; em Solana, verifique as autoridades de criação e congelamento de tokens, bem como quaisquer extensões do tipo Token-2022, como delegado permanente, mecanismo de transferência ou taxa de transferência. Cada poder que esteja ausente ou revogado elimina uma possível classe de ataque. O risco restante passa a ser humano: phishing, falsificação de identidade e manipulação social operam completamente fora do código.

Parte IIImutabilidade e a ausência de chaves de administrador

7. Muitos contratos inteligentes podem ser alterados após o lançamento. Na Solana, os programas são atualizáveis por padrão por meio de uma chave de “autoridade de atualização”; nas cadeias EVM, como a Ethereum, os contratos são imutáveis, a menos que sejam desenvolvidos com padrões de proxy que redirecionem a execução para um contrato de implementação substituível. Esse design permite a correção de erros e a adição de novas funcionalidades, mas também significa que o código com o qual os usuários interagem hoje pode não ser o mesmo código que eles leram ontem.
8. O risco de mutabilidade está relacionado à confiança concentrada. Se um desenvolvedor possuir uma chave administrativa, ele pode, teoricamente, alterar a oferta de tokens, congelar contas de usuários ou esvaziar os pools de liquidez a qualquer momento. Isso cria um “modo deus” que contradiz o ethos descentralizado das blockchains. Quando o The DAO foi hackeado em junho de 2016, a comunidade Ethereum debateu se deveria realizar um hard fork para reverter o roubo — uma medida que dividiu a cadeia em Ethereum e Ethereum Classic. Esse evento destacou como até mesmo mudanças em nível de rede acarretam riscos significativos para a governança.
9. A imutabilidade elimina completamente esse risco. Ao revogar todas as autoridades administrativas — como as de cunhagem, congelamento e atualização de programas em Solana, ou ao ser implementado sem proxies ou papéis de proprietário nas cadeias EVM — o contrato se torna um cofre selado. Ninguém pode alterar as regras após a implementação. O código em uso pode ser verificado uma única vez em relação ao código auditado, e permanece assim. Isso elimina a ameaça de abuso por parte de pessoas internas, além de congelar permanentemente quaisquer bugs potenciais.
10. O custo da imutabilidade é a permanência. Se existir um bug crítico, não há correção disponível; apenas uma migração para um novo contrato ou um fork de rede pode resolvê-lo. Isso aumenta a importância da verificação pré-lançamento. As equipes precisam investir pesadamente em verificação formal, testes extensivos e auditorias com várias partes envolvidas antes da implantação. O ônus passa da manutenção pós-lançamento para o rigor na fase pré-lançamento. Um único caso limite negligenciado pode se tornar uma característica permanente do sistema.
11. O Bitcoin serve como ponto de referência para uma “neutralidade confiável”. Suas regras mudam apenas por meio de um amplo consenso entre milhares de nós independentes, e não por decisão de uma única entidade. Não existe nenhuma chave administrativa que possa alterar a recompensa por bloco ou a validade das transações. Essa rigidez é parte importante do motivo pelo qual muitos consideram o Bitcoin confiavelmente neutro: nenhuma parte isolada pode reescrever suas regras.
12. Para os projetistas de tokens, escolher a imutabilidade sinaliza um compromisso com a transparência. Os usuários podem verificar que o código implementado não pode ser alterado. No entanto, essa escolha exige aceitar que erros são irreversíveis. O trade-off é claro: obter previsibilidade que os usuários possam verificar ou manter a flexibilidade ao custo de introduzir um único ponto de falha e potenciais abusos.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• Solana Program Library, SPL Token documentation
• OpenZeppelin, 'Proxy Upgrade Pattern' documentation
• Contemporary reporting on the Squid Game token collapse (November 2021)
• Chainalysis, Crypto Crime Report (2024)
• Solana documentation: deploying programs (upgrade authority)
• V. Buterin, 'Credible Neutrality as a Guiding Principle' (2020)