Capa 2, cadenas laterales y otras cadenas

Muchos rastros salen de Ethereum y Bitcoin hacia rollups, cadenas laterales, Tron o Solana, donde el modelo de datos, las marcas de tiempo, las reglas de finalidad y las herramientas disponibles son diferentes. Un examinador que aplique a estas cadenas los hábitos de Ethereum interpretará mal los movimientos de tokens, calculará mal el momento de los eventos y pasará por alto a los operadores que conservan registros. Esta lección cubre lo que aporta cada familia a la evidencia y cómo trabajar en una cadena para la que sus herramientas apenas ofrecen soporte.

Depósitos y retiros de rollups como evidencia

Los mecanismos se explican en la lección de IDFE-BA Capa 2, cadenas laterales y puentes como fuentes de datos. Los puntos forenses son los siguientes.

Los depósitos de L1 a L2 son vínculos deterministas. En las cadenas OP Stack, el portal de L1 emite TransactionDeposited, y L2 crea una transacción de depósito sin firma (tipo 0x7E), cuyo sourceHash se calcula a partir del hash del bloque de L1 y del índice del registro: una clave de unión exacta. Como la transacción de L2 no lleva firma, su autoridad y su atribución proceden del remitente de L1. En Arbitrum, un ticket reintentable que no se canjea automáticamente puede esperar hasta una semana, por lo que un depósito de L1 puede mostrar su efecto en L2 días después. Cuando un contrato de L1 envía el mensaje, su dirección de L2 tiene un alias (con un desplazamiento de 0x1111…1111); busque el alias, no la dirección original.

Los retiros canónicos de los rollups optimistas se inician en L2 y se completan en L1 después de un período de impugnación de aproximadamente una semana en muchas cadenas. En las cadenas OP Stack, se realizan en tres pasos (iniciar en L2, demostrar en L1 y finalizar en L1) vinculados por un hash de retiro; Arbitrum no tiene un paso de demostración separado. Ese retraso representa una oportunidad investigativa: una vez que el inicio es visible, se conocen con días de antelación el destinatario de L1 y el momento más temprano en que pueden llegar los fondos. Si el destinatario es una dirección de depósito de un exchange, se puede alertar al exchange antes de que lleguen los fondos (consulte la lección Opciones de congelamiento y confiscación). Dos advertencias: la dirección que demuestra o finaliza suele pertenecer a un retransmisor, no al propietario; además, los períodos de impugnación varían entre cadenas y cambian a medida que evolucionan los sistemas de prueba, así que registre el parámetro vigente en esa fecha según la documentación de la cadena.

Como una semana es mucho tiempo, los infractores suelen salir de los rollups mediante puentes de liquidez, que pagan en L1 con fondos de un retransmisor y reemplazan el vínculo canónico por el ID de depósito propio del puente (consulte la lección Puentes: bloqueo y emisión, quema y liberación, y puentes de liquidez).

Datos del secuenciador y de los lotes

La mayoría de los rollups tienen un único secuenciador que ordena las transacciones, asigna marcas de tiempo de L2 dentro de los límites que impone el protocolo y publica lotes en L1. Esto tiene tres consecuencias para la evidencia:

• La finalidad es por capas. Una transacción confirmada solo por el secuenciador aún puede reorganizarse; una derivada de datos publicados en L1 es más segura; una derivada de bloques finalizados de L1 es final. Registre qué cabeza consultó y la transacción de L1 que ancló el lote.
• La copia de L1 caduca parcialmente. Desde el 13 de marzo de 2024, la mayoría de los rollups publica lotes como blobs, que los nodos de consenso podan después de unos 18 días; solo queda un hash con versión en L1. Si necesita demostrar que el historial de L2 puede reconstruirse de forma independiente de los propios nodos de L2, conserve los datos del blob dentro de ese plazo o indique el archivo de blobs en el que se basó (consulte la lección Conservación de evidencia en cadena).
• El secuenciador es un operador. Por lo general, los secuenciadores son operados por una empresa o fundación que recibe transacciones a través de sus propios puntos de conexión RPC. Que registre metadatos de envío, como direcciones IP, y durante cuánto tiempo, depende de sus políticas; puede ser el destinatario de una solicitud precisa, como cualquier proveedor de servicios. También pueden serlo los proveedores públicos de RPC que utiliza la billetera del sujeto.

Cadenas laterales y cadenas de aplicaciones

El historial de una cadena lateral es tan confiable como su conjunto de validadores. Una cadena con un conjunto pequeño puede detenerse, actualizarse o, en el peor de los casos, quedar bajo el control de quien tenga la mayoría de las claves: el robo de Ronin de marzo de 2022 utilizó cinco de las nueve claves de validadores para firmar retiros de su puente. Para la evidencia, registre las reglas de consenso y de finalidad de la cadena vigentes en ese momento, el conjunto de validadores si está publicado y si se basó en el único explorador de la cadena o en un nodo que usted ejecutó. Los puentes a cadenas laterales suelen estar firmados por validadores, por lo que un vínculo de puente «determinista» solo lo es dentro de la confianza depositada en esos validadores; indíquelo en el informe.

Flujos de Tron y USDT

Tron transporta una gran parte del USDT en circulación y aparece constantemente en casos de estafa, OTC y conversión a efectivo. Su máquina virtual es compatible con EVM, por lo que las transferencias TRC-20 emiten el mismo evento Transfer que las transferencias ERC-20 (consulte la lección de IDFE-BA Otros diseños de cadenas que encuentran los analistas). Los bloques llegan aproximadamente cada 3 segundos. Estos son los puntos importantes para el trabajo de casos:

• Formatos de direcciones. Las direcciones T… son codificaciones Base58Check de un byte de prefijo 0x41 más un cuerpo de 20 bytes. Conviértalas a hexadecimal para unirlas con herramientas de EVM y conserve el identificador de la cadena en cada fila, porque los mismos 20 bytes en Ethereum corresponden a una cuenta diferente.
• Pagadores de comisiones. Las transferencias consumen ancho de banda y energía, que se pueden delegar o alquilar. La cuenta cuyos recursos pagaron puede pertenecer a un servicio de alquiler, no al remitente, y no constituye evidencia de control.
• Activación. Por lo general, una dirección nueva se activa cuando recibe TRX por primera vez. El remitente que la activa, a menudo un retiro de un exchange o un servicio de alquiler, es una pista útil.
• Congelamientos del emisor. El contrato de USDT permite al emisor congelar una dirección, lo que emite AddedBlackList, y luego quemar el saldo congelado, lo que emite DestroyedBlackFunds. Compruebe si los fondos que está rastreando fueron congelados y cuándo, antes de describirlos como disponibles.

-- USDT en Tron enviado a direcciones del sujeto, con cualquier congelamiento del destinatario por parte del emisor
SELECT t.txid, t.block_time, t.to_hex, t.amount_raw / 1e6 AS usdt,
       f.block_time AS frozen_at
FROM trc20_transfers t
LEFT JOIN usdt_freeze_events f
  ON f.target_hex = t.to_hex AND f.event_name = 'AddedBlackList'
WHERE t.token_contract = 'TR7N…Lj6t'          -- contrato de USDT en Tron (truncado)
  AND t.to_hex IN ('41a3c9…7e10', '41f08b…22c4') -- direcciones del sujeto en formato hexadecimal
  AND t.block_time >= TIMESTAMP '2026-06-16 00:00:00'
ORDER BY t.block_time;

La consulta enumera las transferencias de USDT a las direcciones del sujeto, convierte el importe sin procesar utilizando los 6 decimales del token y agrega la hora de cualquier evento de congelamiento que nombre al destinatario. El LEFT JOIN conserva las direcciones no congeladas, cuyo campo frozen_at está vacío. Los nombres de las tablas y columnas dependen del conjunto de datos; la forma hexadecimal de cada dirección debe calcularse y verificarse antes de ejecutar la consulta.

Solana y otros modelos de cuentas

El modelo de Solana se explica en la lección de IDFE-BA Otros diseños de cadenas que encuentran los analistas. Puntos forenses:

• Cuentas de tokens, no billeteras. Los tokens se mueven entre cuentas de tokens; asigne cada cuenta a su propietario en el momento de la transferencia, porque la titularidad puede reasignarse.
• Identificadores y tiempo. Una transacción se identifica por su primera firma; se encuentra en un slot y blockTime es una hora Unix estimada. Registre tanto el slot como la hora.
• Historial. Muchos nodos RPC conservan solo el historial reciente; el historial completo procede de nodos de archivo o proveedores. Indique la fuente y vuelva a consultar una muestra en una segunda fuente.
• Diferencias de saldo. Los saldos anteriores y posteriores en los metadatos de la transacción muestran el efecto neto de llamadas complejas a programas de forma más confiable que decodificar cada instrucción interna.
• Pagadores de comisiones. Al igual que en Tron, el pagador de la comisión puede ser un servicio o un retransmisor.

Las cadenas de Cosmos vinculadas por IBC proporcionan una clave exacta entre cadenas (puerto de origen, canal y secuencia del paquete), lo que convierte las transferencias IBC en vínculos deterministas.

Comparación de las familias:

Para cada salto, registre la clave del vínculo, la altura del bloque, la hora UTC, el estado de finalidad y la fuente de datos.

Cadenas sin buenas herramientas

Tarde o temprano, un rastro llega a una cadena que sus herramientas no decodifican. Siga una lista de verificación fija y registre cada paso:

1. Lea la documentación: modelo de datos, formato de direcciones, identificadores, marcas de tiempo y finalidad, en una versión fechada.
2. Obtenga los datos de dos fuentes: idealmente, de su propio nodo; de lo contrario, de dos exploradores o API independientes. Guarde las respuestas sin procesar y calcule sus hashes (consulte la lección Hashing, registro y cadena de custodia).
3. Valide con datos conocidos: vuelva a derivar un saldo que pueda comprobar y decodifique una transacción cuyo significado ya conozca, como un depósito en un exchange cuyos registros conserva.
4. Decodifique con cautela: informe solo los campos que haya validado y marque el resto como no interpretado.
5. Apóyese en los extremos: el puente o exchange por el que los fondos entraron y salieron de la cadena suele conservar mejores registros de los que muestra el explorador de la cadena.
6. Indique las limitaciones: fuente única, decodificador no validado, historial incompleto. Una limitación clara es defendible; una oculta, no (consulte la lección Herramientas, reproducibilidad y validación).

Enfoque del examen: Depósitos de OP Stack y sourceHash como clave de unión, y atribución a través del remitente de L1; retrasos de tickets reintentables y alias de direcciones en Arbitrum; retiros canónicos (tres pasos en las cadenas OP Stack) y el período de impugnación como tiempo para alertar a un exchange; retransmisores como quienes demuestran y finalizan; finalidad por capas, poda de blobs después de unos 18 días y conservación de datos de lotes; secuenciadores y proveedores de RPC como posibles custodios de registros; confianza en los validadores de cadenas laterales; conversión de direcciones de Tron, pagadores de recursos, activación y eventos de congelamiento de USDT; cuentas de tokens, firmas, slots e historial de archivo de Solana; claves de paquetes IBC; lista de verificación para cadenas sin buenas herramientas.