Explorando somas de verificação de revestimento dinâmico para mitigar o envenenamento de endereço – UI/UX

DR

O envenenamento por endereço funciona porque os humanos verificam apenas o prefixo/sufixo de um endereço. Esta postagem propõe um mecanismo somente de carteira/UI: o destinatário compartilha um código de receptor de curta duração e a carteira do remetente usa Keccak256(address || code) para derivar um impressão digital do invólucro de soma de verificação dinâmica. Se o remetente colar acidentalmente um endereço semelhante envenenado, a verificação falhará porque o invasor não conhece o código.

Motivação: as explorações comuns de envenenamento por hábitos

Na prática, poucos usuários verificam 40 caracteres hexadecimais de ponta a ponta. O fluxo de trabalho dominante – especialmente ao copiar atividades recentes – é:

• verifique os primeiros 4–6 caracteres
• verifique os últimos 4–6 caracteres
• suponha que o meio esteja bem

Os ataques de envenenamento visam diretamente:

1. o invasor gera um endereço com o mesmo prefixo/sufixo visível de um destinatário comumente usado
2. o invasor envia uma transferência de valor 0/poeira para que o sósia apareça no histórico “recente”
3. o usuário copia a entrada errada, o prefixo/sufixo corresponde, os fundos são enviados ao invasor

Isto é principalmente uma falha de UI/verificação humana, não um bug de protocolo.

Intuição: as transferências Ethereum carecem de uma “segunda confirmação”

Em muitos fluxos de pagamento tradicionais, você confirma efetivamente duas coisas:

• o identificador de destino (número da conta)
• um sinal de confirmação independente (nome do beneficiário/prompt de confirmação)

Ethereum tem um identificador de destino forte (o endereço), mas a segunda confirmação geralmente falta quando os usuários estão transferindo para raw 0x… destinatários. O objetivo aqui é adicionar um segundo fator leve que é:

• fora da rede (somente carteira)
• barato (sem etapas extras na cadeia)
• difícil para um envenenador antecipar um pagamento específico

Antecedentes: o que é o checksum case e por que é insuficiente

As carteiras geralmente mostram endereços com “soma de verificação” em letras maiúsculas e minúsculas. A ideia geral é:

• calcular um hash a partir do endereço
• use pedaços desse hash para decidir qual a–f letras hexadecimais são maiúsculas/minúsculas
• se o endereço mudar, é improvável que o padrão de maiúsculas e minúsculas permaneça válido, ajudando a detectar erros de digitação

A convenção Ethereum amplamente usada aqui é o invólucro de soma de verificação EIP-55.

Limitação para envenenamento: esse invólucro é estático por endereço e computável publicamente, portanto, um sósia envenenado também pode ser exibido em um formato de “soma de verificação válida”.

Proposta: fazer com que o checksum case dependa de um código fornecido pelo receptor (impressão digital dinâmica)

Entradas

• addr: endereço do destinatário (20 bytes)
• code: código receptor curto (string; recomendado uma vez ou de curta duração)

Hash

Calculamos:

H = Keccak256(endereço\_bytes || código\_utf8)

onde addr_bytes é o endereço de 20 bytes e code_utf8 é a codificação UTF-8 do código do receptor. Usar o endereço de 20 bytes mantém os limites de concatenação inequívocos.

Regra de caixa

Renderize o endereço como hexadecimal (como de costume). Para cada personagem:

• dígitos 0–9 inalterado
• cartas a–f são maiúsculas/minúsculas de acordo com bits sucessivos de H
  (mesmo espírito do EIP-55, mas usando H acima)

Resultado: o mesmo endereço subjacente agora tem um impressão digital do invólucro específico do código.

Fluxo

Receptor (Alice)

1. Alice gera um código receptor (recomendado gerado pela carteira), por exemplo lamp-snow-47.
2. A carteira exibe o endereço com letras maiúsculas derivadas de H.
3. Alice compartilha (endereço, código) com o remetente.

Remetente (Bob)

1. Bob cola o endereço.
2. Bob insere o código do receptor.
3. A carteira recalcula e verifica a impressão digital da caixa:
   • corresponder → verificado
   • incompatibilidade → avisar/bloquear (código errado, endereço errado ou possível envenenamento)

A intenção é que os usuários confiem em um estado claro de verificado/não verificado, em vez de inspecionar visualmente o invólucro.

Por que isso atenua o envenenamento (para o cenário alvo)

O envenenamento é bem-sucedido quando um usuário seleciona acidentalmente um prefixo/sufixo semelhante ao histórico. Com um código de receptor:

• um invasor ainda pode fabricar endereços semelhantes e colocá-los no histórico do usuário
• mas o invasor não pode validar esse endereço envenenado sob o código do destinatário
• então “copiar endereço errado do histórico” torna-se uma falha de verificação determinística em vez de um sucesso silencioso

Aguardo ansiosamente sua opinião, especialmente sobre as compensações de UX e quaisquer possíveis armadilhas no modelo ou implementação de ameaças que eu possa ter esquecido. Agradecemos antecipadamente pelo feedback!