Preservación de evidencia en cadena

Una blockchain conserva su historial, pero casi todo lo que un investigador utiliza para leerlo puede cambiar. Los exploradores rediseñan páginas y vuelven a etiquetar direcciones, las herramientas de análisis actualizan sus atribuciones, los sitios web y las publicaciones en foros desaparecen, y los bloques más recientes aún pueden ser reemplazados. Preservar evidencia en cadena significa fijar cada una de estas vistas en un momento conocido, para que un revisor pueda comprobar años después exactamente lo que usted vio y confirmarlo con la propia cadena.

Qué hay que preservar realmente

El libro mayor sin procesar es la única parte de un caso que rara vez necesita rescate: una vez que un bloque alcanza la finalidad, cualquier nodo honesto devolverá los mismos datos. Lo que hay que preservar es el contexto que lo rodea. La tabla enumera los elementos habituales.

Considere los datos sin procesar como la evidencia y todo lo demás como una vista de esos datos con fecha. Si una captura de pantalla de un explorador no coincide con el nodo, prevalece el nodo, y la discrepancia debe constar en sus notas.

Anclar cada hecho a un bloque

Un txid identifica una transacción, pero por sí solo no fija dónde se encuentra esa transacción en la cadena que examinó. Registre, para cada transacción en la que se base:

• cadena y red (Bitcoin mainnet, Ethereum chain ID 1, una L2 identificada y su chain ID);
• txid y, para cadenas con modelo de cuentas, el índice del registro (log index) de cualquier evento en el que se base;
• altura del bloque y hash del bloque;
• confirmaciones o estado de finalidad en el momento de la captura;
• la fuente: su propio nodo y la versión de su cliente, o una API pública identificada;
• hora de recuperación en UTC y el archivo donde se guardaron los datos sin procesar, con su hash SHA-256.

{
  "fact_id": "F-012",
  "chain": "bitcoin-mainnet",
  "txid": "4f3a…c21e",
  "block_height": 966204,
  "block_hash": "0000…3b9e",
  "confirmations_at_capture": 4828,
  "source": "nodo propio, cliente v30.x",
  "cross_check": "API de explorador público, recuperada el 2026-10-14T10:05Z, los campos coinciden",
  "retrieved_utc": "2026-10-14T09:42:10Z",
  "raw_file": "raw/4f3a_c21e.json",
  "raw_file_sha256": "0072…33a9"
}

Este registro vincula un hecho utilizado en el informe (F-012) con la transacción, el bloque y la fuente exactos, así como con un archivo de datos sin procesar guardado cuyo hash se puede comprobar. Los resúmenes se acortan para la publicación impresa; el registro real contiene los 64 caracteres hexadecimales completos. La línea de verificación cruzada indica que una segunda fuente independiente proporcionó los mismos valores. La lección de IDFE-BA Calidad, normalización y procedencia de los datos ofrece un registro similar para conjuntos de datos completos; la adición forense consiste en que cada hecho citado en un informe puede rastrearse hasta uno de estos registros.

Reorganizaciones y finalidad

Los datos capturados cerca de la punta de la cadena pueden deshacerse mediante una reorganización, en la que los nodos cambian a una rama competidora y los bloques recientes quedan obsoletos. La lección de IDFE-BA Bloques y encabezados como datos explica la mecánica. Para la evidencia, las reglas son sencillas:

1. No preserve como definitivo algo que aún no lo es. En Bitcoin, seis confirmaciones son la convención habitual, y la evidencia para un informe debería estar muy por encima de ese umbral. En Ethereum, utilice bloques en el punto de control finalized o por debajo de este, normalmente unos 13 minutos por detrás de la cabeza de la cadena.
2. Registre el estado en el momento de la captura. Si tuvo que capturar los datos antes, por ejemplo, para documentar un robo mientras está ocurriendo, marque el registro como provisional.
3. Vuelva a verificar los registros provisionales una vez que alcancen la finalidad: obtenga de nuevo la transacción, confirme que está en un bloque con el mismo hash y anote la comprobación. Si el hash del bloque cambió, es posible que la transacción se haya trasladado o haya desaparecido, y se debe revisar todo lo que se haya construido a partir de ella.
4. Las L2 requieren una segunda comprobación. Los bloques propios de un rollup pueden parecer definitivos en cuestión de segundos, pero la garantía más sólida solo llega cuando el lote que los contiene alcanza la finalidad en la cadena base; además, los retiros de los rollups optimistas añaden un período de impugnación. Registre el nivel de finalidad en el que se basó.

La documentación en vivo sigue siendo valiosa: una captura temprana muestra qué era visible y cuándo. Simplemente debe etiquetarse según lo que es.

Verificar con una segunda fuente

Una sola fuente puede estar equivocada: un explorador puede decodificar mal un token, mostrar un saldo desactualizado o asignar una etiqueta incorrecta. Antes de que una extracción se convierta en evidencia, compárela con una fuente independiente, idealmente su propio nodo frente a uno público, o dos proveedores sin relación entre sí. La consulta siguiente supone que quien realiza el examen cargó los hechos citados en el informe en evidence_facts y una extracción reciente de una segunda fuente en node_check.

-- Hechos cuyo txid falta, o aparece en un bloque distinto, en la segunda fuente
SELECT f.fact_id, f.txid, f.block_hash AS cited_block, n.block_hash AS check_block
FROM evidence_facts f
LEFT JOIN node_check n ON n.txid = f.txid
WHERE n.txid IS NULL
   OR n.block_hash <> f.block_hash
   OR n.value_sats <> f.value_sats;   -- para cadenas EVM, compare el valor en wei y log_index

Cada fila devuelta representa un problema que debe resolverse antes de emitir el informe. Si falta un txid en la segunda fuente, normalmente se trata de un error de escritura; el mismo txid en un bloque distinto significa que el registro se capturó en una rama que luego fue reemplazada en una reorganización; un valor diferente suele indicar un error de unidades o decimales. Un resultado vacío, junto con la consulta y ambas fuentes registradas, constituye por sí mismo un registro útil de verificación.

Capturar instantáneas de etiquetas y resultados de herramientas

Las etiquetas se deterioran. Una dirección etiquetada como procesador de pagos este año puede volver a etiquetarse como exchange el año próximo o integrarse en un clúster más grande. Si su informe afirma que un depósito se envió a «Exchange X», un revisor debe poder ver la etiqueta tal como era cuando usted se basó en ella. Exporte, para cada etiqueta utilizada: el nombre de la entidad, la dirección o el clúster que abarca, la fuente (publicada por la propia entidad, registro del proveedor, lista de la comunidad, herramienta de análisis), la versión o fecha de la fuente y su nivel de confianza. La lección de IDFE-BA Atribución y etiquetado aborda la evaluación de etiquetas; aquí, el objetivo es fijarlas.

Los resultados de las herramientas requieren el mismo tratamiento. Guarde el archivo de proyecto nativo si la herramienta lo tiene, una exportación legible (CSV o JSON de nodos y aristas) y una imagen renderizada; registre también la versión de la herramienta, el método de rastreo, los límites de saltos y otros ajustes. Si vuelve a ejecutar el mismo caso en una versión posterior, el gráfico puede ser diferente y tendrá que explicar la diferencia. La lección Herramientas, reproducibilidad y validación aborda cómo conciliar herramientas que no coinciden.

Archivar evidencia web

Las páginas externas a la cadena suelen contener la atribución: un sitio de estafa que enumera direcciones de depósito, una publicación en un foro que ofrece fondos robados o las condiciones de uso de un servicio. El Protocolo de Berkeley sobre investigaciones digitales de fuentes abiertas, publicado en 2020 por la Oficina de Derechos Humanos de la ONU y el Centro de Derechos Humanos de UC Berkeley, establece cómo recopilar y preservar este material de forma profesional. Los métodos de captura se abordan en la lección Metodología OSINT. El registro de preservación debe incluir:

• un archivo de archivo en formato WARC (ISO 28500:2017), que conserva el contenido de la página y las respuestas del servidor;
• una captura de pantalla de página completa, para facilitar la lectura;
• la URL, la hora de captura en UTC, la herramienta utilizada y si la captura fue atribuible o no;
• el hash SHA-256 de cada archivo, calculado en el momento de la captura;
• cuando sea útil, una copia en un archivo web público como corroboración independiente, nunca como única copia.

Para demostrar que una captura existía antes de una hora determinada, puede obtener una marca de tiempo confiable para su hash (RFC 3161 define un protocolo) o anclar el hash en una transacción de una blockchain pública. OpenTimestamps es un ejemplo de código abierto del segundo método.

El paquete de evidencia verificable de nuevo

Todo esto se integra en un paquete de evidencia: una carpeta que permite a un revisor comprobar cada hecho sin tener que confiar en usted.

CF-2026-041_onchain_v1/
  README.txt              cómo volver a verificar, fuentes, versiones de software
  manifest.sha256         una línea SHA-256 por cada archivo que aparece abajo
  facts.json              registros de hechos (F-001 ... F-088)
  raw/                    transacciones y bloques sin procesar del nodo
  labels/labels_2026-10-12.json
  tool/trace_graph_export.json
  web/forum_post_capture.warc
  web/forum_post_capture.png

El manifiesto enumera el hash de cada archivo; el hash del propio manifiesto (para esta versión, 4b91…199f) se incorpora al registro del caso y al registro de evidencia, de modo que un solo valor protege todo el paquete. El README indica cómo obtener cada transacción de cualquier nodo, compararla con raw/ y volver a calcular los hashes. Nunca edite un paquete después de sellarlo: emita la versión 2 con un manifiesto nuevo y registre el motivo. La lección Hashing, registro y cadena de custodia aborda cómo se transfiere después el paquete bajo custodia.

Enfoque del examen: por qué los datos finales sin procesar de la cadena rara vez necesitan rescate, mientras que sí lo necesitan las páginas de exploradores, las etiquetas, los resultados de herramientas, las páginas web y los precios; los campos que anclan un hecho (cadena, txid, índice del registro, altura y hash del bloque, finalidad en el momento de la captura, fuente y versión del cliente, hora UTC, hash del archivo sin procesar); no tratar los datos que aún no alcanzan la finalidad como definitivos, marcar las capturas provisionales y volver a verificarlas; finalidad del rollup frente a la de la cadena base; verificación cruzada con una fuente independiente; exportación de instantáneas de etiquetas y ajustes de herramientas; WARC, capturas de pantalla, hashes y marcas de tiempo confiables para la evidencia web conforme al Protocolo de Berkeley; el paquete de evidencia, su manifiesto y el control de versiones, en lugar de editarlo.