Heurísticas del modelo de cuentas

Las cadenas basadas en cuentas, como Ethereum, no ofrecen al analista ninguna de las dos herramientas fundamentales de Bitcoin: cada transacción tiene exactamente un remitente y los saldos permanecen en la misma cuenta, por lo que no hay entradas gastadas conjuntamente ni salidas de cambio. Los usuarios pueden seguir creando tantas direcciones como deseen, y muchos lo hacen. La agrupación en estas cadenas se basa en el comportamiento relacionado con servicios, tokens y contratos, y la evidencia es más débil y está menos validada que en las cadenas UTXO.

Qué cambia en el modelo de cuentas

En una cadena basada en cuentas, una sola dirección suele contener todo el historial de un usuario, lo que aporta más información sobre cada dirección, pero no proporciona ninguna regla inherente para vincularla con otra. Victor (2020, "Heurísticas de agrupación de direcciones para Ethereum") propuso tres heurísticas: la reutilización de direcciones de depósito, la participación múltiple en airdrops (varias direcciones que reclaman cada una un airdrop de tokens y luego los reenvían a una dirección común) y la autoautorización mediante aprobaciones de tokens. Descubrió que, durante los primeros cuatro años de Ethereum, estas heurísticas agruparon el 17,9% de todas las cuentas de propiedad externa (EOA) activas. El artículo reconoce abiertamente que no había datos de referencia verificados con los que medir su exactitud. Un estudio posterior de código abierto sobre la privacidad en Ethereum y Tornado Cash (Wu et al., 2022) aplicó la más sólida de las tres, la reutilización de direcciones de depósito, y encontró 26 millones de EOA agrupadas en 2,5 millones de grupos; al contrastarla con 1.028 grupos derivados de registros de servicios de nombres, su exhaustividad fue del 39,4%. Estas son las cifras mejor documentadas disponibles y muestran que la mayoría de los vínculos no se detectan y que la precisión sigue sin medirse en gran medida.

Las heurísticas siguientes se presentan, aproximadamente, de la más sólida a la más débil.

Reutilización de direcciones de depósito

Muchos exchanges de custodia asignan a cada cliente una dirección de depósito única y barren periódicamente su saldo hacia una billetera caliente (véase la lección Rastreo a través de exchanges y servicios de custodia). Si dos EOA envían fondos a la misma dirección de depósito, probablemente se abonen a la misma cuenta de cliente y, por tanto, probablemente estén controladas por la misma persona u organización. Esta es la heurística de direcciones de depósito de Victor y es la más productiva de las reglas del modelo de cuentas.

Las direcciones de depósito no están etiquetadas en la cadena, por lo que deben inferirse: una dirección que recibe fondos y reenvía casi el mismo importe a una billetera conocida de un exchange poco después.

-- Direcciones de depósito candidatas y los remitentes que vinculan
WITH forwards AS (           -- transfers: una fila por movimiento de ETH o tokens
  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          -- los remitentes no deben ser servicios conocidos
)
SELECT deposit_addr, COUNT(DISTINCT sender) AS linked_senders
FROM forwards
GROUP BY deposit_addr
HAVING COUNT(DISTINCT sender) >= 2;

La consulta empareja cada transferencia entrante con una transferencia saliente desde la misma dirección hacia una billetera caliente de un exchange etiquetada dentro de un intervalo de 2.000 bloques, descarta a los remitentes que son servicios conocidos y conserva las direcciones de depósito utilizadas por al menos dos remitentes. Una versión de producción también comprueba que el importe reenviado sea cercano al recibido y que la dirección reenvíe fondos de forma sistemática a lo largo del tiempo. El intervalo de 2.000 bloques es un supuesto que debe documentarse, no un estándar.

Casos de fallo: una persona que ingresa fondos en la cuenta de exchange de un amigo o empleador; procesadores de pagos y mesas de operaciones extrabursátiles que depositan fondos en nombre de clientes; exchanges que reasignan o comparten direcciones de depósito; y el error de etiquetar una dirección de reenvío ordinaria como dirección de depósito.

Patrones de financiación del gas

Una EOA nueva necesita moneda nativa para pagar el gas antes de poder hacer cualquier cosa. Su primera transferencia entrante suele proceder del mismo operador, por lo que muchas EOA nuevas financiadas por una dirección en un intervalo breve, con importes similares y una actividad posterior similar, sugieren un control común. Los equipos de airdrops utilizan este patrón para detectar participantes falsos, y es una pista útil en las investigaciones de exploits (véase la lección Análisis de exploits y ataques informáticos).

La debilidad es que quien aporta los fondos suele ser un servicio. Las billeteras de retiros de exchanges, los puentes y los faucets financian a enormes cantidades de usuarios sin relación entre sí, por lo que se debe comprobar si quienes aportan los fondos están etiquetados como servicios antes de establecer cualquier vínculo. El patrocinio del gas rompe el vínculo por completo: con ERC-4337, un paymaster puede pagar las operaciones de un usuario y, desde EIP-7702 (activada en mayo de 2025), una EOA puede delegar en código y hacer que un patrocinador envíe y pague sus transacciones. La lección El modelo de cuentas y la reconstrucción de saldos explica por qué determinar quién paga el gas y quién firma son cuestiones diferentes.

Aprobaciones de tokens

Una llamada approve de ERC-20 permite a una dirección autorizada gastar tokens del saldo del propietario y emite un evento Approval:

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

El primer tema es el hash de la firma del evento Approval(address,address,uint256), el segundo es el propietario, el tercero es la dirección autorizada para gastar y el campo de datos es el importe autorizado. La mayoría de las aprobaciones designan un contrato, como un enrutador de DEX. La heurística de autoautorización de Victor vincula a un propietario con una dirección autorizada para gastar cuando esta es otra EOA, con el razonamiento de que las personas rara vez permiten que la dirección personal de un desconocido gaste sus tokens.

El caso de fallo grave es el fraude. El phishing de aprobaciones engaña a las víctimas para que autoricen una dirección controlada por un atacante, y estas aprobaciones tienen exactamente el mismo aspecto que una autoautorización. Antes de establecer un vínculo, compruebe si la dirección autorizada vació el saldo del propietario poco después; de ser así, el vínculo es entre víctima y ladrón, no de un mismo propietario.

Vínculos con el desplegador de contratos

Todo contrato tiene un creador. Con CREATE, la dirección del nuevo contrato se deriva de la dirección y el nonce del desplegador; con CREATE2 (EIP-1014), del contrato que realiza el despliegue, una sal y el hash del código de inicialización. Los contratos desplegados por la misma EOA suelen pertenecer al mismo equipo, y el desplegador de un contrato de exploit suele ser un nodo clave en el grupo del atacante.

Casos de fallo: contratos de fábrica públicos que cualquiera puede utilizar (la fábrica, no el usuario, aparece como creador), servicios de despliegue, claves de desplegadores comprometidas y código abierto copiado. Un bytecode idéntico demuestra que se comparte código, no control.

Señales temporales, de nonce y de nombres

Patrones temporales. Las direcciones operadas por la misma persona o bot suelen compartir un patrón de actividad diaria, actuar dentro de los mismos bloques o alternarse con un ritmo fijo. Béres et al. (2020, "La cadena de bloques te observa: elaboración de perfiles y desanonimización de usuarios de Ethereum") utilizaron perfiles de actividad según la hora del día y configuraciones de comisiones como cuasiidentificadores. Las configuraciones de comisiones se volvieron mucho menos distintivas después de EIP-1559 (agosto de 2021), cuando la mayoría de las billeteras comenzaron a calcular las comisiones automáticamente.

Nonce. El nonce de una EOA cuenta las transacciones que ha enviado. Las secuencias de nonce revelan lo activa que es una dirección y en qué orden se produjeron sus acciones; varias direcciones cuyos nonces avanzan de forma sincronizada, cada una enviando una transacción por ronda en un orden fijo, sugieren que un único script las controla.

Servicios de nombres. ENS vincula nombres con direcciones mediante registros directos (de nombre a dirección) y registros inversos opcionales (de dirección a nombre principal). El propietario de la dirección establece el registro inverso, por lo que se trata de una afirmación propia; confirme que el registro directo del nombre apunta a la misma dirección. Los nombres caducan y otra persona puede volver a registrarlos, por lo que debe registrar el bloque en el que observó el vínculo. Muchos nombres son personales; trátelos como se describe en la lección De la dirección a la entidad y a la persona: atribución y etiquetado.

Errores específicos de las cadenas basadas en cuentas

Nunca agrupe por el campo from de las transacciones enviadas por infraestructura compartida. Un agrupador de ERC-4337 envía una transacción que contiene las operaciones de muchos usuarios sin relación entre sí; los retransmisores y los servicios de metatransacciones hacen lo mismo. Vincular todo lo que envió un agrupador o retransmisor fusionaría a miles de usuarios. Lo mismo se aplica a los contratos que mantienen fondos de muchos usuarios, como los pools de DEX y los puentes.

Las billeteras de contratos inteligentes añaden otra particularidad. Una billetera de contrato multifirma es una dirección controlada por varias EOA firmantes, cuya lista puede leerse en el estado del contrato. Los firmantes cooperan, pero pueden ser personas diferentes; trate la billetera como la entidad y a los firmantes como partes relacionadas, no como un solo grupo.

Como cada señal del modelo de cuentas es débil por sí sola, una práctica sólida consiste en exigir dos señales independientes antes de establecer un vínculo, por ejemplo, financiación del gas desde una dirección que no sea un servicio junto con patrones temporales sincronizados, y registrar ambas en la tabla de evidencias con su propia solidez.

Enfoque del examen: por qué las cadenas basadas en cuentas carecen de heurísticas de entradas comunes y de cambio; las tres heurísticas de Victor (reutilización de direcciones de depósito, participación múltiple en airdrops y autoautorización) y por qué su exactitud sigue sin medirse en gran medida (17,9% de cobertura sin datos de referencia verificados, 39,4% de exhaustividad para la reutilización de direcciones de depósito); inferencia de direcciones de depósito a partir del reenvío a billeteras calientes; financiación del gas y por qué los servicios que aportan fondos, los paymasters y los patrocinadores de EIP-7702 rompen ese vínculo; lectura de un registro Approval y el falso positivo del phishing de aprobaciones; vínculos con desplegadores mediante CREATE y CREATE2 y errores relacionados con las fábricas; evidencia temporal, de nonce y de ENS y sus límites; nunca agrupar por la dirección del remitente de un agrupador o retransmisor.