Heurísticas do modelo de contas

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

O que muda no modelo de contas

Em uma blockchain baseada em contas, um único endereço frequentemente concentra todo o histórico de um usuário, o que torna cada endereço mais rico em informações, mas não fornece uma regra intrínseca 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, cada um, um airdrop de tokens e depois encaminham os tokens para um endereço comum) e autoautorização por meio de aprovações de tokens. Ele constatou que, nos primeiros quatro anos da Ethereum, elas agruparam 17,9% de todas as contas de propriedade externa (EOAs) ativas. O artigo reconhece francamente que não havia uma verdade de referência com a qual medir sua acurácia. Um estudo posterior de código aberto sobre a privacidade na 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 encontrou 26 milhões de EOAs agrupadas em 2,5 milhões de agrupamentos; quando verificada em relação a 1.028 agrupamentos derivados de registros de serviços de nomes, sua 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 permanece, em grande parte, sem medição.

As heurísticas abaixo estão listadas, aproximadamente, da mais forte para a mais fraca.

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

Muitas exchanges de custódia atribuem a cada cliente um endereço de depósito exclusivo e periodicamente transferem integralmente seu saldo para uma carteira quente (veja a aula Rastreamento por exchanges e serviços de custódia). Se duas EOAs enviam fundos para o mesmo endereço de depósito, provavelmente os valores são creditados na mesma conta de cliente e, portanto, elas provavelmente são controladas pela mesma pessoa ou organização. Essa é a heurística de endereços de depósito de Victor, e é a mais produtiva das regras do modelo de contas.

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

-- Endereços de depósito candidatos e os remetentes que eles vinculam
WITH forwards AS (           -- transfers: uma linha por movimentação de ETH ou token
  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          -- remetentes não devem 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 de entrada a uma transferência de saída do mesmo endereço para uma carteira quente de exchange rotulada dentro de 2.000 blocos, descarta remetentes que sejam 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 realiza encaminhamentos de forma consistente ao longo do tempo. A janela de 2.000 blocos é uma premissa a ser documentada, não um padrão.

Modos de falha: uma pessoa fazendo um pagamento para a conta de exchange de um amigo ou empregador; processadores de pagamentos e mesas de negociação de balcão que depositam em nome de clientes; exchanges que reatribuem ou compartilham endereços de depósito; e o erro de rotular um endereço comum de encaminhamento como endereço de depósito.

Padrões de financiamento de gas

Uma EOA recém-criada precisa de moeda nativa para pagar gas antes de poder fazer qualquer coisa. Sua primeira transferência de entrada frequentemente vem do mesmo operador, portanto muitas EOAs recém-criadas financiadas por um endereço em uma janela curta, com valores semelhantes e atividades posteriores semelhantes, sugerem controle comum. Equipes de airdrops usam esse padrão para detectar participantes falsos, e ele é uma pista útil em investigações de exploração de vulnerabilidades (veja a aula Análise de explorações de vulnerabilidades e ataques).

A fragilidade é que o financiador frequentemente é um serviço. Carteiras de saque de exchanges, pontes e faucets financiam enormes quantidades de usuários sem relação entre si, portanto os financiadores devem ser verificados em relação aos rótulos de serviços antes de se estabelecer qualquer vínculo. O patrocínio de gas rompe completamente esse vínculo: no ERC-4337, um paymaster pode pagar pelas operações de um usuário e, desde a EIP-7702 (ativada em maio de 2025), uma EOA pode delegar a execução a código e ter um patrocinador que envie e pague por suas transações. A aula O modelo de contas e a reconstrução de saldos explica por que identificar quem paga o gas e quem assina são questões diferentes.

Aprovações de tokens

Uma chamada approve do ERC-20 permite que um agente autorizado movimente 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 agente autorizado, e o campo de dados é o limite autorizado. A maioria das aprovações indica um contrato, como um roteador de DEX. A heurística de autoautorização de Victor vincula um proprietário a um agente autorizado quando esse agente é 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 grave é a fraude. O phishing de aprovação engana as vítimas para que aprovem um endereço controlado pelo atacante, e essas aprovações têm exatamente a mesma aparência da autoautorização. Antes de estabelecer um vínculo, verifique se o agente autorizado esvaziou o saldo do proprietário logo depois; nesse caso, o vínculo é entre vítima e ladrão, não de um único proprietário.

Vínculos pelo implantador de contratos

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

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

Sinais de horário, nonce e nomes

Horário. Endereços operados pela mesma pessoa ou bot frequentemente compartilham um padrão diário de atividade, agem nos mesmos blocos ou se alternam em um ritmo fixo. Béres et al. (2020, "A blockchain está observando você: criação de perfis e desanonimização de usuários da 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 a 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 um único script controlando-os.

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 autodeclaração; 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, portanto registre o bloco no qual você observou o vínculo. Muitos nomes são pessoais; trate-os conforme descrito na aula Do endereço à entidade e à pessoa: atribuição e rotulagem.

Armadilhas específicas das blockchains baseadas em contas

Nunca faça agrupamentos pelo campo from de transações enviadas por infraestrutura compartilhada. Um bundler ERC-4337 envia uma transação que contém as operações de muitos usuários sem relação entre si; retransmissores e serviços de metatransações fazem o mesmo. Vincular tudo o que um bundler ou retransmissor enviou reuniria milhares de usuários. O mesmo se aplica a contratos que mantêm fundos de muitos usuários, como pools de DEX e pontes.

As carteiras de contratos inteligentes acrescentam outra particularidade. Uma carteira de contrato com múltiplas assinaturas é 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 agrupamento.

Como cada sinal do modelo de contas é fraco isoladamente, uma prática sólida é exigir dois sinais independentes antes de estabelecer um vínculo, por exemplo, financiamento de gas por um endereço que não seja de serviço mais horários sincronizados, e registrar ambos na tabela de evidências com suas respectivas forças.

Foco no exame: por que as blockchains baseadas em contas não possuem 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, autoautorização) e por que sua acurácia permanece, em grande parte, sem medição (17,9% de cobertura sem verdade de referência, 39,4% de revocação para reutilização de endereços de depósito); inferência de endereços de depósito a partir de encaminhamentos para carteiras quentes; financiamento de gas e por que financiadores que são serviços, paymasters e patrocinadores da EIP-7702 rompem esse vínculo; leitura de um registro Approval e o falso positivo de phishing de aprovação; vínculos de implantadores com CREATE e CREATE2 e armadilhas de fábricas; evidências de horário, nonce e ENS e seus limites; nunca agrupar pelo endereço remetente de um bundler ou retransmissor.