Contratos verificados, proxies e a chave de atualização que ninguém menciona
No explorador de blocos há um visto verde dizendo Código-fonte do contrato verificado, e um número enorme de pessoas lê isso como «este contrato é seguro».
Não é o que significa. Significa algo bem mais estreito e bem mais útil, e confundir as duas coisas é o jeito pelo qual pessoas cuidadosas acabam aprovando coisas com que jamais teriam concordado.
O que «verificado» de fato certifica
Contratos são implantados como bytecode — instruções de máquina, ilegíveis na prática. Verificação é o ato de enviar o código-fonte original e fazer o explorador confirmar que compilá-lo, com a versão e as configurações de compilador declaradas, produz exatamente o bytecode que já vive naquele endereço.
Essa é a afirmação inteira: o código-fonte que você está lendo é genuinamente o que roda.
É uma garantia real e valiosa. Sem ela, você não teria como saber se o código de aparência elegante no GitHub de um projeto guarda qualquer relação com aquilo que sua transação está prestes a tocar.
Mas repare em tudo o que ela não diz. Verificação não é auditoria. Ninguém avaliou se o código está correto, se tem falhas, ou se faz algo parecido com o que os nomes de suas funções sugerem. Um contrato com uma função chamada claimRewards que transfere todo o seu saldo para quem o implantou pode estar verificado, e a verificação seria inteiramente honesta: atestaria fielmente que o roubo é exatamente o que o código diz fazer.
Verificado significa legível, não confiável. Isso move a pergunta de «o que é essa coisa?» para «eu entendi o que acabei de ler?», o que é progresso, mas não responde a segunda por você.
O inverso também importa. Um contrato não verificado não é prova de má-fé — muitas implantações legítimas nunca chegam a se verificar. Mas significa que ninguém — nenhuma ferramenta que você use, nenhum pesquisador que pudesse tê-lo avisado — consegue ler aquilo com que você vai interagir. É razoável ter cautela com isso.
E então os proxies pioram tudo
Aqui o chão se desloca, e é a parte que quase sempre fica sem menção.
A maioria dos contratos não triviais com que você vai interagir não são contratos únicos. São proxies. O proxy é o endereço que você vê, e ele guarda todos os dados — saldos, permissões, estado. Mas quase não contém lógica. Em vez disso, encaminha cada chamada a um contrato de implementação separado e simplesmente executa o que aquele contrato disser.
A razão é a possibilidade de atualização. Contratos imutáveis não podem ser corrigidos, então uma falha é permanente e um recurso ausente é para sempre. Apontar um proxy para uma nova implementação permite que uma equipe conserte erros e entregue melhorias sem pedir que cada usuário migre. Dado quanto valor já se perdeu com falhas inconsertáveis, é uma escolha de engenharia defensável.
Ela tem uma consequência fácil de passar batido. Quando você procura um proxy num explorador e o vê verificado, você verificou a lógica de encaminhamento, não o comportamento. O código que de fato decide o que acontece com seu dinheiro vive no endereço de implementação, que o explorador pode ou não mostrar com destaque, e que pode ser substituído.
Então a pergunta real nunca foi «este contrato está verificado?». É:
Quem pode mudar o comportamento deste contrato, e com que rapidez?
A chave de administração é o verdadeiro modelo de segurança
Todo contrato atualizável tem alguém que pode executar a atualização. Essa autoridade é o modelo de segurança, por melhor que seja o código atual.
A faixa vai de alarmante a razoável:
Uma única conta de propriedade externa. Uma chave privada, na máquina de alguém, pode trocar a lógica do contrato que guarda seus fundos. Se for pescada por phishing, roubada, ou seu dono coagido, o contrato vira o que o atacante quiser. Esse arranjo é mais comum do que deveria.
Um multisig. Vários signatários precisam concordar. Bem melhor — remove o ponto único de falha — ainda que valha saber quantos são, e se são pessoas genuinamente independentes ou quatro laptops da mesma equipe.
Um multisig atrás de uma trava temporal. A atualização é anunciada na cadeia e só pode executar após um atraso fixo, muitas vezes de 24 a 72 horas. Esse é o que importa, porque muda inteiramente sua posição: você recebe aviso prévio da mudança e uma janela para sacar antes que ela entre em vigor. Uma trava temporal não impede uma atualização maliciosa. Torna-a sobrevivível.
Nenhum caminho de atualização. O contrato é imutável. Previsibilidade máxima, nenhum recurso se uma falha aparecer. Escolha legítima, em geral feita por protocolos testados em campo tempo suficiente para apostar nisso.
Nenhuma delas é automaticamente certa. Mas a diferença entre «uma chave» e «multisig mais dois dias de atraso» é a diferença entre torcer para ninguém errar e ter tempo de reagir quando alguém errar.
Por que isso morde justamente nas aprovações
Esta é a parte que se liga a algo que você de fato faz com regularidade.
Quando você concede uma aprovação de tokens, está autorizando um endereço a mover seus tokens. Não um trecho de código — um endereço. A aprovação fica no armazenamento do contrato do token e persiste indefinidamente.
Se esse endereço for um proxy atualizável, então a lógica habilitada a mover seus tokens pode ser substituída depois que você aprovou, sem seu envolvimento e sem nenhuma assinatura nova sua. Você auditou uma coisa e continua exposto a outra.
É por isso que o conselho permanente de revogar aprovações que você não usa mais pesa mais do que parece à primeira vista. Não é só sobre um contrato se revelar falho. É que uma permissão ilimitada a um contrato atualizável é uma permissão concedida a quem quer que controle a chave de atualização, por todo o tempo em que você a deixar aberta.
É também o limite mais nítido da simulação de transações. Simular antes de assinar diz o que uma transação faz contra o estado atual e a implementação atual. É genuinamente útil e não pode dizer o que essa mesma aprovação vai permitir no mês que vem.
O que a SSP mostra, e onde ela para
Quando a SSP Key apresenta uma aprovação, ela decodifica os dados da chamada em vez de mostrar hexadecimal bruto. Reconhece os seletores ERC-20 padrão — approve, transfer, transferFrom, increaseAllowance, setApprovalForAll — e os expressa em linguagem simples, inclusive sinalizando permissões ilimitadas, definidas no código como qualquer quantia igual ou acima de 2^255.
O decodificador é deliberadamente conservador. Seu próprio cabeçalho o descreve como apenas camada de apresentação: ele nunca altera o que é assinado, e falha de modo fechado. Um seletor desconhecido, um comprimento errado, hexadecimal malformado ou preenchimento de endereço fora do padrão fazem com que ele não devolva nada e recue para uma ação genérica com o hexadecimal bruto atrás de uma visão «Avançado». Prefere admitir que não sabe a chutar com confiança e errar. Símbolos e casas decimais de tokens só são anexados quando conhecidos do registro no próprio aparelho, nunca inferidos.
Agora a fronteira honesta. O decodificador não tem nenhuma noção de proxy. Não há em parte alguma dele a ideia de um contrato de implementação. Ele pode dizer, correta e claramente, «você está concedendo uma permissão ilimitada de USDC a 0xABC…» — e não pode dizer que 0xABC é um proxy, quem detém sua chave de atualização, ou que seu comportamento pode ser inteiramente outro semana que vem.
Isso não é tanto um descuido quanto uma fronteira que nenhum decodificador de carteira consegue atravessar. Decodificar descreve a chamada à sua frente. Se a contraparte é atualizável, e quem a governa, é uma propriedade do mundo mais amplo que precisa ser conferida à parte. Preferimos declarar a fronteira a deixar que uma tela de aprovação de aparência confiante sugira uma completude que ela não tem.
Uma conferência prática antes de aprovar algo significativo
Está verificado? Se não, entenda que você está confiando apenas em reputação.
É um proxy? Exploradores rotulam isso — procure um aviso de proxy, ou uma opção «Read as Proxy». Se existir, a implementação é o código que importa.
Quem pode atualizá-lo, e há atraso? É a pergunta de maior valor da lista e a que quase ninguém faz. Um projeto que pensou nisso vai documentar. Um que não pensou, ou não quer dizer, já lhe disse algo.
A aprovação precisa ser ilimitada? Geralmente não. Aprovar a quantia que você realmente pretende gastar limita sua exposição exatamente a isso, seja lá no que o contrato se transformar depois.
Revogue quando terminar. Uma permissão aberta é uma autorização permanente, e ela sobrevive à sua atenção.
O ajuste mental que vale a pena fazer é pequeno, mas muda muita coisa. A verificação diz qual código está rodando agora. A possibilidade de atualização diz quem decide o que vai rodar amanhã. Quase todo o risco mora na segunda pergunta, e quase todo o conforto oferecido trata apenas da primeira.
