Heurísticas do modelo de contas

Blockchains baseadas em contas, como Ethereum, não oferecem ao analista nenhuma das duas ferramentas principais do Bitcoin: cada transação tem exatamente um remetente, e os saldos permanecem na mesma conta; por isso, não há entradas gastas em conjunto nem saídas de troco. Ainda assim, os usuários podem criar quantos endereços quiserem, e muitos o fazem. O agrupamento nessas blockchains depende de comportamentos em torno de serviços, tokens e contratos, e as evidências são mais fracas e menos validadas do que em blockchains UTXO.

O que muda no modelo de contas

Em uma blockchain baseada em contas, um único endereço costuma conter todo o histórico de um usuário, o que torna cada endereço mais rico em informações, mas não oferece nenhuma regra integrada para vinculá-lo a outro. Victor (2020, "Heurísticas de agrupamento de endereços para Ethereum") propôs três heurísticas: reutilização de endereços de depósito, participação múltipla em airdrops (vários endereços que reivindicam individualmente um airdrop de tokens e depois encaminham os tokens para um único endereço comum) e autodeclaração de autorização por meio de aprovações de tokens. Ele constatou que, durante os primeiros quatro anos do Ethereum, essas heurísticas agruparam 17,9% de todas as contas externas ativas (EOAs). O artigo reconhece que não havia uma verdade de referência para medir a precisão delas. Um estudo posterior de código aberto sobre a privacidade no Ethereum e no Tornado Cash (Wu et al., 2022) aplicou a mais forte das três, a reutilização de endereços de depósito, e constatou que 26 milhões de EOAs foram agrupadas em 2,5 milhões de clusters; comparada com 1.028 clusters derivados de registros de serviços de nomes, a revocação foi de 39,4%. Esses são os números mais bem documentados disponíveis e mostram que a maioria dos vínculos não é detectada e que a precisão ainda não foi, em grande parte, medida.

As heurísticas abaixo estão listadas aproximadamente da mais forte à mais fraca.

Reutilização de endereços de depósito

Muitas exchanges custodiais atribuem a cada cliente um endereço de depósito exclusivo e transferem periodicamente o saldo dele para uma carteira quente (consulte a aula Rastreando valor por meio de exchanges e serviços). Se duas EOAs enviam fundos para o mesmo endereço de depósito, provavelmente são creditadas na mesma conta de cliente e, portanto, provavelmente são controladas pela mesma pessoa ou organização. Essa é a heurística de endereço de depósito de Victor e a regra mais produtiva do modelo de contas.

Os endereços de depósito não são identificados na blockchain, por isso precisam ser inferidos: trata-se de um endereço que recebe fundos e, pouco depois, encaminha quase o mesmo valor para uma carteira conhecida de uma exchange.

-- Endereços de depósito candidatos e os remetentes que eles vinculam
WITH forwards AS (
  SELECT t_in.to_address   AS deposit_addr,
         t_in.from_address AS sender
  FROM transfers t_in
  JOIN transfers t_out
    ON t_out.from_address = t_in.to_address
   AND t_out.block_number BETWEEN t_in.block_number
                              AND t_in.block_number + 2000
  JOIN labels hw
    ON hw.address = t_out.to_address AND hw.category = 'exchange_hot_wallet'
  LEFT JOIN labels svc
    ON svc.address = t_in.from_address
  WHERE svc.address IS NULL          -- os remetentes não podem ser serviços conhecidos
)
SELECT deposit_addr, COUNT(DISTINCT sender) AS linked_senders
FROM forwards
GROUP BY deposit_addr
HAVING COUNT(DISTINCT sender) >= 2;

A consulta associa cada transferência recebida a uma transferência de saída do mesmo endereço para uma carteira quente identificada como pertencente a uma exchange, dentro de 2.000 blocos; exclui remetentes que já são serviços conhecidos e mantém os endereços de depósito usados por pelo menos dois remetentes. Uma versão de produção também verifica se o valor encaminhado é próximo do valor recebido e se o endereço encaminha fundos de forma consistente ao longo do tempo. A janela de 2.000 blocos é uma suposição que deve ser documentada, não um padrão.

Modos de falha: uma pessoa que deposita fundos na conta de exchange de um amigo ou empregador; processadores de pagamentos e mesas de balcão que depositam em nome de clientes; exchanges que reatribuem ou compartilham endereços de depósito; e o erro de identificar incorretamente um endereço comum de encaminhamento como endereço de depósito.

Padrões de financiamento de gas

Uma EOA nova precisa de moeda nativa para pagar o gas antes de poder fazer qualquer coisa. Sua primeira transferência recebida costuma vir do mesmo operador; portanto, muitas EOAs novas financiadas por um único endereço em um curto intervalo, com valores semelhantes e atividades subsequentes parecidas, sugerem controle comum. Equipes de airdrop usam esse padrão para detectar participantes falsos, e ele é uma pista útil em investigações de explorações (consulte a aula Analisando explorações e ataques).

O ponto fraco é que o financiador costuma ser um serviço. Carteiras de saque de exchanges, bridges e faucets financiam um número enorme de usuários sem relação entre si; por isso, os financiadores devem ser verificados em relação aos rótulos de serviços antes de estabelecer qualquer vínculo. O patrocínio de gas rompe completamente esse vínculo: sob o ERC-4337, um paymaster pode pagar pelas operações de um usuário e, desde o EIP-7702 (ativado em maio de 2025), uma EOA pode delegar a execução a um código e ter um patrocinador que envie e pague por suas transações. A aula O modelo de contas para analistas explica por que o pagador do gas e o signatário são questões diferentes.

Aprovações de tokens

Uma chamada approve de ERC-20 permite que um spender mova tokens do saldo do proprietário e emite um evento Approval:

{
  "address": "0x7d1a…c3E0",
  "topics": [
    "0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925",
    "0x000000000000000000000000a1b2…009f",
    "0x000000000000000000000000c4d5…77e2"
  ],
  "data": "0x…ffffffff"
}

O primeiro tópico é o hash da assinatura do evento Approval(address,address,uint256), o segundo é o proprietário, o terceiro é o spender, e o campo de dados contém o limite de gasto autorizado. A maioria das aprovações indica um contrato, como um roteador de DEX. A heurística de autodeclaração de autorização de Victor vincula um proprietário a um spender quando este é outra EOA, com base no raciocínio de que as pessoas raramente permitem que o endereço pessoal de um desconhecido gaste seus tokens.

O modo de falha mais grave é a fraude. O phishing de aprovação induz as vítimas a aprovar um endereço controlado por um atacante, e essas aprovações são exatamente iguais às de autodeclaração de autorização. Antes de estabelecer o vínculo, verifique se o spender esvaziou o saldo do proprietário pouco depois; se isso aconteceu, o vínculo é entre vítima e ladrão, não entre um único proprietário.

Vínculos com o criador de contratos

Todo contrato tem um criador. Com CREATE, o endereço do novo contrato é derivado do endereço do implantador e do nonce; com CREATE2 (EIP-1014), ele é derivado do contrato implantador, de um salt e do hash do código de inicialização. Contratos implantados pela mesma EOA costumam pertencer à mesma equipe, e o implantador de um contrato de exploração costuma ser um nó-chave no cluster do atacante.

Modos de falha: contratos de factory públicos que qualquer pessoa pode usar (a factory, e não o usuário, aparece como criadora), serviços de implantação, chaves de implantador comprometidas e código aberto copiado. Bytecode idêntico indica código compartilhado, não controle compartilhado.

Sinais de horário, nonce e nomes

Horário. Endereços operados pela mesma pessoa ou bot costumam compartilhar padrões diários de atividade, agir nos mesmos blocos ou alternar em um ritmo fixo. Béres et al. (2020, "A blockchain está observando você: criação de perfis e desanonimização de usuários do Ethereum") usaram perfis de horário do dia e configurações de taxas como quase identificadores. As configurações de taxas se tornaram muito menos distintivas após o EIP-1559 (agosto de 2021), quando a maioria das carteiras começou a calcular as taxas automaticamente.

Nonce. O nonce de uma EOA conta as transações que ela enviou. As sequências de nonce revelam o nível de atividade de um endereço e a ordem em que suas ações ocorreram; vários endereços cujos nonces avançam em sincronia, cada um enviando uma transação por rodada em uma ordem fixa, sugerem que um único script os controla.

Serviços de nomes. O ENS vincula nomes a endereços por meio de registros diretos (nome para endereço) e registros reversos opcionais (endereço para nome principal). Um registro reverso é definido pelo proprietário do endereço, portanto, é uma declaração do próprio usuário; confirme se o registro direto do nome aponta de volta para o mesmo endereço. Os nomes expiram e podem ser registrados novamente por outra pessoa; por isso, registre o bloco em que você observou o vínculo. Muitos nomes são pessoais; trate-os conforme descrito na aula Atribuição e rotulagem.

Armadilhas específicas das blockchains baseadas em contas

Nunca agrupe endereços com base no campo from de transações enviadas por uma infraestrutura compartilhada. Um bundler de ERC-4337 envia uma transação que contém as operações de muitos usuários sem relação entre si; relayers e serviços de meta-transações fazem o mesmo. Vincular tudo o que um bundler ou relayer enviou mesclaria milhares de usuários. O mesmo se aplica a contratos que mantêm fundos de muitos usuários, como pools de DEX e bridges.

As carteiras de contratos inteligentes acrescentam outra nuance. Uma carteira de contrato multisig é um endereço controlado por várias EOAs signatárias, cuja lista pode ser lida no estado do contrato. Os signatários cooperam, mas podem ser pessoas diferentes; trate a carteira como a entidade e os signatários como partes relacionadas, não como um único cluster.

Como cada sinal do modelo de contas é fraco por si só, uma boa prática é exigir dois sinais independentes antes de estabelecer um vínculo, por exemplo, financiamento de gas proveniente de um endereço que não seja de um serviço, somado a padrões de horário em sincronia, e registrar ambos na tabela de evidências, cada um com seu próprio nível de confiança.

Foco no exame: por que as blockchains baseadas em contas não têm heurísticas de entradas comuns e de troco; as três heurísticas de Victor (reutilização de endereços de depósito, participação múltipla em airdrops, autodeclaração de autorização) e por que a precisão delas não foi, em grande parte, medida (cobertura de 17,9% sem verdade de referência, revocação de 39,4% para a reutilização de endereços de depósito); inferir endereços de depósito a partir de encaminhamentos para carteiras quentes; financiamento de gas e por que financiadores de serviços, paymasters e patrocinadores do EIP-7702 comprometem essa heurística; interpretar um registro Approval e o falso positivo de phishing de aprovação; vínculos com implantadores de CREATE e CREATE2 e os riscos das factories; evidências de horário, nonce e ENS e suas limitações; nunca agrupar endereços com base no endereço remetente de um bundler ou relayer.