Otros diseños de cadenas que encuentran los analistas

Las investigaciones rara vez se limitan a Bitcoin y Ethereum: los fondos robados pasan por programas de Solana, las stablecoins se mueven en grandes volúmenes en Tron, los tokens saltan entre cadenas de Cosmos mediante IBC, y algunos rastros desaparecen en Monero o en un pool protegido de Zcash. Cada diseño almacena el valor de manera diferente, por lo que la misma pregunta («¿quién envió qué a quién?») requiere una consulta distinta y, a veces, no tiene respuesta en la cadena. Esta lección presenta los aspectos esenciales de cada diseño y aclara qué información no es visible.

Solana: cuentas, programas y cuentas de tokens

Solana utiliza un modelo de cuentas, pero más literal que Ethereum: todo es una cuenta con cinco campos: lamports (saldo; 1 SOL = 1.000.000.000 lamports), data, owner, executable y rent_epoch. Las direcciones son claves públicas Ed25519 de 32 bytes o direcciones derivadas de programas, y se muestran en base58. Las cuentas deben mantener un saldo mínimo de lamports, reembolsable, que varía según el tamaño de sus datos.

Los programas (los contratos inteligentes de Solana) son cuentas ejecutables que no contienen estado propio. El estado se almacena en cuentas de datos independientes cuyo owner es el programa, y solo el programa propietario puede cambiar los datos de una cuenta o debitar sus lamports.

Los tokens siguen el mismo patrón. Una cuenta mint define un token (suministro, decimales, autoridad de emisión y autoridad de congelación). Los saldos se almacenan en cuentas de tokens, cada una de las cuales registra un mint, un propietario y una cantidad. Una billetera puede tener varias cuentas de tokens para el mismo mint, pero lo habitual es la cuenta de tokens asociada, cuya dirección se deriva de la dirección del propietario, el programa del token y el mint, de modo que cada billetera tiene una cuenta predecible por token. Hay dos programas de tokens: el programa de tokens original y Token-2022 (Token Extensions), que añade funciones como las comisiones por transferencia.

La consecuencia para el analista: las transferencias de tokens se realizan entre cuentas de tokens, no entre billeteras. Para atribuirlas, hay que vincular cada cuenta de tokens con su owner y recordar que el propietario de una cuenta de tokens puede reasignarse, por lo que el vínculo debe corresponder al momento de la transferencia. Los metadatos de la transacción hacen gran parte de este trabajo. Cada transacción enumera de antemano todas las cuentas que toca; el primer firmante paga la comisión y la primera firma es el identificador de la transacción. getTransaction devuelve los saldos anteriores y posteriores:

{
  "fee": 5000,
  "preTokenBalances": [
    { "accountIndex": 1, "mint": "EPx7…t1v", "owner": "7Hq2…ZpA",
      "uiTokenAmount": { "amount": "900000000", "decimals": 6 } },
    { "accountIndex": 2, "mint": "EPx7…t1v", "owner": "9mLc…4Rd",
      "uiTokenAmount": { "amount": "0", "decimals": 6 } }
  ],
  "postTokenBalances": [
    { "accountIndex": 1, "mint": "EPx7…t1v", "owner": "7Hq2…ZpA",
      "uiTokenAmount": { "amount": "650000000", "decimals": 6 } },
    { "accountIndex": 2, "mint": "EPx7…t1v", "owner": "9mLc…4Rd",
      "uiTokenAmount": { "amount": "250000000", "decimals": 6 } }
  ]
}

Al comparar los saldos anteriores y posteriores por índice de cuenta, se observa que el propietario 7Hq2…ZpA perdió 250 tokens (de 900 a 650, con 6 decimales) y que el propietario 9mLc…4Rd ganó 250. Esta comparación suele ser más fiable que decodificar cada instrucción, especialmente cuando un intercambio pasa por varios programas mediante instrucciones internas. Los cambios en lamports aparecen de la misma manera en preBalances y postBalances.

Cardano: UTXO extendido

Cardano mantiene el modelo UTXO y lo amplía (eUTXO). Las salidas pueden contener varios activos a la vez: ADA (1 ADA = 1.000.000 lovelace) más tokens nativos identificados por un ID de política y un nombre de activo, sin necesidad de un contrato inteligente para una transferencia simple. Cada salida debe contener una cantidad mínima de ADA, que aumenta según el tamaño de los tokens y los datos que incluye. Las salidas bloqueadas por scripts llevan un datum (datos adjuntos a la salida); para gastarlas, se proporciona un redeemer (un argumento), y el script valida la transacción completa (el contexto del script). Por lo tanto, una orden de un DEX o una posición de préstamo es un UTXO ubicado en una dirección de script, y sus condiciones están en el datum.

Las direcciones de Cardano (Bech32, que empiezan por addr1 en la red principal) suelen tener dos partes: una parte de pago, que controla el gasto, y una parte de delegación, que controla los derechos de participación. Las cuentas de recompensas tienen sus propias direcciones, que empiezan por stake1. En muchos casos, varias direcciones de pago que comparten una misma credencial de delegación pertenecen a la misma billetera: una señal de agrupamiento sólida que no existe en Bitcoin. No es una prueba, porque el estándar permite que las dos partes pertenezcan a partes distintas, y algunas direcciones no tienen ninguna parte de delegación.

Tron

Tron es una cadena con modelo de cuentas cuya máquina virtual es compatible con la EVM, por lo que los tokens TRC-20 emiten los mismos eventos Transfer que los tokens ERC-20, y se aplica la misma decodificación (consulta la lección Lectura de transferencias de tokens). Es una de las principales redes para las transferencias de stablecoins y aparece con frecuencia en investigaciones de fraude y estafas.

Las direcciones son cadenas Base58Check que empiezan por T: un byte de prefijo 0x41 seguido de un cuerpo de 20 bytes derivado de la clave pública, como en Ethereum. Convertir las direcciones T… a su forma hexadecimal permite al analista utilizar herramientas de estilo EVM y cruzarlas con conjuntos de datos de EVM, manteniendo el identificador de la cadena en cada fila.

Las comisiones utilizan un modelo de recursos en lugar de precios de gas. Las transferencias simples consumen ancho de banda (cada cuenta recibe una pequeña asignación diaria gratuita), y las llamadas a contratos, como las transferencias TRC-20, consumen energía. Los recursos se obtienen mediante staking de TRX, de otra cuenta que los delegue o mediante la quema de TRX cuando no hay recursos disponibles por otros medios. La delegación y el alquiler de energía implican que la cuenta cuyos recursos pagaron una transacción puede ser un servicio, no el remitente, de forma similar al patrocinio de gas (consulta la lección El modelo de cuentas para analistas). Una dirección nueva suele activarse en la cadena cuando recibe TRX por primera vez, por lo que el remitente que la activa es una pista útil.

Cosmos e IBC

El ecosistema Cosmos es una familia de cadenas independientes y específicas para cada aplicación, la mayoría creadas con Cosmos SDK y consenso CometBFT, que ofrece finalidad en cuanto se confirma un bloque. Las direcciones son Bech32 con un prefijo específico para cada cadena (cosmos1…, osmo1…). En las cadenas que utilizan la misma derivación de claves, una clave genera direcciones en muchas cadenas con la misma carga de datos y distintos prefijos y sumas de verificación, por lo que volver a codificar una dirección con otro prefijo es una forma rápida de encontrar al mismo titular de la clave en otras cadenas.

Las cadenas intercambian tokens y mensajes mediante IBC (comunicación entre cadenas de bloques), donde cada cadena ejecuta un cliente ligero de la otra y relayers externos a la cadena transportan los paquetes. En una transferencia de tokens fungibles ICS-20, la cadena de origen pone los tokens en custodia y la cadena de destino emite un vale cuya denominación es ibc/ seguido del hash SHA-256 de la ruta y la denominación base. Los ATOM que llegan a Osmosis por transfer/channel-0 aparecen como ibc/2739…5EB2. Cada paquete se identifica por su puerto de origen, canal de origen y número de secuencia, que aparecen en el evento send_packet de una cadena y en los eventos recv_packet y acknowledge_packet de la otra: una clave de unión exacta entre cadenas, a diferencia de la mayoría de los puentes. Resuelve cada hash ibc/ para encontrar su ruta mediante la consulta de seguimiento de denominaciones de la cadena, y recuerda que el mismo activo que llega por dos rutas distintas produce dos denominaciones diferentes que no son intercambiables.

Cadenas centradas en la privacidad: Monero y Zcash

Monero oculta por defecto a las tres partes. Cada pago se envía a una dirección sigilosa de un solo uso, por lo que la dirección pública del destinatario nunca aparece en la cadena. Cada entrada se firma con una firma de anillo que mezcla la salida real con señuelos (tamaño del anillo de 16 desde la actualización de agosto de 2022), y una imagen clave impide el doble gasto sin revelar cuál de los miembros del anillo se gastó. Las cantidades se ocultan mediante compromisos RingCT con pruebas de rango (Bulletproofs+ desde 2022). Lo que sigue siendo visible: la transacción, su hora, su comisión, el número de entradas y salidas, los miembros del anillo y los datos adicionales. Un estudio de Möser y sus colegas («An Empirical Analysis of Traceability in the Monero Blockchain», 2018) mostró que muchas transacciones antiguas podían rastrearse, principalmente a través de entradas sin señuelos y de una selección de señuelos que hacía que el miembro más reciente del anillo fuera el real con mayor frecuencia; desde entonces, el protocolo ha hecho obligatorio el tamaño de los anillos y ha mejorado la selección de señuelos. Una actualización prevista (FCMP++) reemplazaría los anillos por pruebas sobre el conjunto completo de salidas, lo que eliminaría las filtraciones derivadas de la selección de señuelos; comprueba si está activa antes de basarte en razonamientos sobre anillos. Los titulares pueden revelar los pagos recibidos mediante una clave de visualización. En la práctica, el análisis de Monero se centra en los puntos de entrada y salida (exchanges y servicios de intercambio) y en sus registros fuera de la cadena, obtenidos mediante un proceso legal.

Zcash combina distintos niveles de privacidad. Las direcciones transparentes (t1…, t3… para multifirma) funcionan como las de Bitcoin y son totalmente visibles. Los pools protegidos (Sprout, con direcciones zc…; Sapling, con zs…; y Orchard desde la actualización NU5 del 31 de mayo de 2022, que se utiliza mediante direcciones unificadas que empiezan por u1) ocultan dentro del pool al remitente, al destinatario, la cantidad y el memo; la comisión sigue siendo visible. Los límites dejan rastros: el blindaje revela al remitente transparente y la cantidad, el desblindaje revela la cantidad y el destinatario transparente, y el valor total de cada pool es público mediante getblockchaininfo. Un estudio empírico de Kappos y sus colegas («An Empirical Analysis of Anonymity in Zcash», 2018) concluyó que la mayor parte de la actividad era transparente y que la coincidencia de cantidades y tiempos entre el blindaje y el desblindaje permitía vincular muchas transacciones. Las claves de visualización permiten la divulgación voluntaria.

Enfoque del examen: Los campos de cuenta de Solana, los programas sin estado, las cuentas mint, las cuentas de tokens y las cuentas de tokens asociadas, y por qué las transferencias deben vincularse con los propietarios de las cuentas de tokens; lectura de preTokenBalances y postTokenBalances; eUTXO de Cardano (datum, redeemer, salidas con múltiples activos) y partes de pago y delegación como señal de agrupamiento; direcciones T de Tron, conversión hexadecimal y modelo de ancho de banda y energía; prefijos Bech32 de Cosmos, transferencias IBC mediante custodia y vales, denominaciones ibc/ y número de secuencia del paquete como clave de unión; direcciones sigilosas de Monero, tamaño del anillo de 16, imágenes clave y RingCT; Zcash transparente frente a pools protegidos y las filtraciones en los límites de los pools.