Ir para o conteúdo
Financial Context Wiki

Uma assinatura de delegação de governança é segura?

Saiba o que uma assinatura de delegação de governança autoriza, como a separação de domínio EIP-712, os nonces e a expiração reduzem o risco de repetição e o que verificar antes de assinar.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento. Transações e assinaturas de ativos digitais podem causar perdas irreversíveis.

Resposta direta

Uma assinatura de delegação de governança só é segura quando a mensagem decodificada corresponde exatamente à delegação pretendida e o contrato de governança aplica proteção adequada contra repetição. Em um modelo típico de token de votação, a delegação altera quem pode exercer o poder de voto do signatário; ela não transfere o saldo de tokens nem concede aprovação para gastá-los. Porém, o contrato implantado é a autoridade final sobre o que a assinatura faz.

Uma assinatura off-chain pode ser enviada por um retransmissor, de modo que o signatário pode não pagar gas e ainda assim autorizar uma mudança de estado on-chain. Trate a assinatura como uma instrução executável, não como um login nem como uma solicitação inofensiva para conectar uma carteira.

Como funciona

Um fluxo comum de delegateBySig tem quatro etapas:

  1. O aplicativo prepara dados tipados EIP-712 contendo o endereço de um delegado, um nonce e uma expiração.
  2. A carteira assina um resumo vinculado à mensagem tipada e a um domínio EIP-712.
  3. Qualquer conta pode retransmitir a assinatura para o contrato do token ou de governança.
  4. O contrato recupera ou valida o signatário, verifica o nonce e a expiração e registra o novo delegado.

O domínio EIP-712 pode incluir name, version, chainId e verifyingContract. Esses campos separam mensagens que, de outra forma, seriam idênticas entre aplicativos, versões, redes e contratos. A própria EIP-712 declara expressamente que não fornece proteção contra repetição; o contrato precisa consumir um nonce ou tornar cada autorização de uso único de outra forma, e a expiração só limita o período quando o contrato realmente a verifica.

Antes de assinar, verifique todos os itens a seguir em uma interface oficial de governança, na documentação ou em dados do contrato verificados de forma independente:

  • primaryType e os nomes dos campos descrevem uma delegação, não uma permissão, transferência de tokens, ordem ou autorização de gerenciamento de conta.
  • verifyingContract é o contrato de token ou governança pretendido no chainId ativo.
  • delegatee é o endereço do representante que você escolheu, conferido pelo endereço completo, e não pelo nome exibido.
  • nonce corresponde ao nonce atual do contrato para o signatário, e expiry é curta o bastante para o fluxo pretendido.
  • A carteira exibe os dados tipados completos. Rejeite solicitações de assinatura cega ou hashes brutos cujo significado você não consiga reproduzir de forma independente.

As implementações variam. Por exemplo, o contrato COMP da Compound calcula o hash do delegado, do nonce e da expiração, exige que o nonce seja igual ao armazenado para o signatário, incrementa esse nonce e rejeita uma assinatura expirada. A interface Votes da OpenZeppelin também disponibiliza delegateBySig, tratamento de nonces e verificações de expiração. Não presuma que uma função de nome semelhante em outro contrato tenha proteções idênticas.

Exemplo

Mira pretende delegar 10.000 votos para o endereço 0xAB...1234. A carteira mostra primaryType: Delegation, o contrato verificado do token de votação, o ID da cadeia ativa, delegatee: 0xAB...1234, o nonce atual e uma expiração para daqui a 20 minutos. Depois de conferir o endereço em uma segunda fonte confiável, ela assina; um retransmissor envia a mensagem, e o contrato emite o evento de delegação. O saldo de tokens permanece na carteira, enquanto o representante recebe o poder de voto associado conforme as regras do protocolo.

Agora altere um detalhe: a página solicita primaryType: Permit e informa um gastador de tokens, ou verifyingContract é um contrato não relacionado. Essa não é a mesma instrução de delegação. Ela pode autorizar o gasto de tokens, mesmo que a página rotule o botão como “Delegar” e o signatário não pague gas. Mira deve rejeitá-la.

Riscos e controles

  • Delegado errado: envenenamento de endereços, mensagens privadas e nomes de exibição copiados podem substituir delegatee por um endereço controlado por um invasor. Verifique o endereço completo em uma proposta oficial ou no perfil do delegado.
  • Ação errada: uma interface maliciosa pode solicitar outro tipo EIP-712, como uma permissão. Leia primaryType, todos os campos e o contrato de verificação; o rótulo do botão não oferece segurança.
  • Repetição: verificações de nonce fracas ou ausentes podem permitir que uma assinatura seja reutilizada. Um domínio sem vínculo com a cadeia ou o contrato pretendidos também pode permitir seu uso em um contexto indesejado. Confirme o código de verificação real, pois a EIP-712, sozinha, não protege contra repetição.
  • Assinatura de longa duração: uma mensagem assinada ainda não usada pode continuar executável até a expiração ou até seu nonce se tornar inválido. Prefira uma expiração curta, não publique a assinatura e, se precisar cancelá-la, use apenas o método de invalidação documentado pelo protocolo.
  • Exibição enganosa da carteira: campos truncados, um domínio desconhecido ou a assinatura cega impedem um consentimento significativo. Cancele e inspecione a solicitação de dados tipados com uma carteira ou um decodificador que mostre a mensagem completa.
  • Diferenças de contas de contrato: carteiras de contrato inteligente podem validar assinaturas por ERC-1271, em que a validade pode depender do estado e da política de autorização da carteira. Confirme a compatibilidade tanto da carteira quanto do contrato de governança, em vez de presumir a recuperação própria de uma EOA.
  • Consequências para a governança: a delegação pode concentrar poder de voto ou permitir que um delegado não confiável vote contra seus interesses. Analise a identidade, o histórico de votação e os conflitos do delegado, além do processo do protocolo para redelegação.

Depois do envio, verifique a transação na cadeia correta: confira o contrato de destino, a função decodificada, o signatário recuperado ou informado pelo evento, o novo delegado e o nonce. Uma transação bem-sucedida do retransmissor prova apenas que o contrato aceitou a chamada; não prova que a intenção assinada era segura.

Se você assinou, mas ainda não viu um envio, pare de compartilhar a assinatura e consulte o procedimento documentado pelo protocolo para cancelamento ou invalidação do nonce. Se uma delegação indesejada foi executada, redelegue pelo contrato oficial e verifique o novo estado. Uma delegação isolada normalmente não cria uma aprovação de tokens, portanto não confunda redelegação com revogação de aprovações. Se você também assinou uma permissão ou expôs uma frase-semente ou chave privada, trate isso como um incidente de carteira separado e de maior gravidade.

Erros comuns

  • “Sem gas significa sem autoridade.” O retransmissor pode pagar o gas enquanto a assinatura fornece a autorização do signatário.
  • “A EIP-712 torna toda assinatura segura.” Ela padroniza o hash de dados tipados e a separação de domínio, mas o padrão não inclui proteção contra repetição e não pode verificar se o usuário pretendia realizar a ação exibida.
  • “A delegação transfere meus tokens.” A delegação de voto convencional move ou atribui poder de voto, não a propriedade dos tokens, mas somente o contrato implantado e a mensagem decodificada podem determinar o efeito real.
  • “Sempre posso revogar uma assinatura off-chain.” Não existe uma transação universal de revogação de assinatura. Expiração, consumo ou invalidação do nonce e redelegação são mecanismos específicos de cada contrato.
  • “Trocar de delegado apaga os votos anteriores.” A redelegação altera o poder de voto futuro ou atual conforme as regras do protocolo; ela pode não desfazer votos já depositados nem alterar snapshots históricos.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...