Preservación de evidencia en la cadena

Una cadena de bloques conserva su historial, pero casi todo lo que un investigador utiliza para consultar ese historial puede cambiar. Los exploradores rediseñan sus páginas y modifican las etiquetas de las 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 la evidencia en la 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 contrastarlo con la propia cadena.

Qué es lo que realmente debe preservarse

El libro mayor en bruto es la única parte de un caso que rara vez necesita ser rescatada: una vez que un bloque es final, cualquier nodo honesto devolverá los mismos datos. Lo que debe preservarse es el contexto que lo rodea. La tabla enumera los elementos habituales.

Trate los datos en bruto como la evidencia y todo lo demás como una vista fechada de ella. Si una captura de pantalla de un explorador y el nodo discrepan, prevalece el nodo, y la discrepancia se registra en sus notas.

Vincular 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 usted examinó. Para cada transacción en la que se apoye, registre:

• la cadena y la red (red principal de Bitcoin, Ethereum con ID de cadena 1, una L2 identificada por su nombre y su ID de cadena);
• el txid y, para las cadenas con modelo de cuentas, el índice de registro de cualquier evento en el que se apoye;
• la altura del bloque y el hash del bloque;
• las confirmaciones o el 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 por su nombre;
• la hora de consulta en UTC y el archivo en el que se guardaron los datos en bruto, 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": "own node, client v30.x",
  "cross_check": "public explorer API, retrieved 2026-10-14T10:05Z, fields match",
  "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, y con un archivo de datos en bruto guardado cuyo hash puede comprobarse. Los resúmenes hash se abrevian para su impresión; el registro real contiene los 64 caracteres hexadecimales. La línea de comprobación cruzada registra que una segunda fuente independiente proporcionó los mismos valores. La lección Calidad, normalización y procedencia de los datos presenta un registro similar para conjuntos de datos completos; el añadido forense es 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 quedar invalidados por una reorganización, en la que los nodos pasan a una rama competidora y los bloques recientes quedan obsoletos. La lección Bloques, cabeceras y API de nodos explica el funcionamiento. Para la evidencia, las reglas son sencillas:

1. No preserve como final lo que no es final. En Bitcoin, seis confirmaciones es la convención habitual, y la evidencia para un informe debe superar ampliamente ese umbral. En Ethereum, utilice bloques situados en el punto de control finalized o antes de él, normalmente unos 13 minutos por detrás de la cabecera de la cadena.
2. Registre el estado en el momento de la captura. Si tuvo que capturar los datos de forma temprana, por ejemplo, para documentar un robo mientras ocurre, marque el registro como provisional.
3. Vuelva a verificar los registros provisionales una vez que sean finales: consulte de nuevo la transacción, confirme que se encuentra en un bloque con el mismo hash y anote la comprobación. Si el hash del bloque cambió, la transacción puede haberse movido o desaparecido, y debe revisarse todo lo que se haya elaborado a partir de ella.
4. Las capas 2 requieren una segunda revisión. Los bloques propios de un rollup pueden parecer finales en cuestión de segundos, pero la garantía más sólida solo llega cuando el lote que los contiene es final en la cadena base, y los retiros de los rollups optimistas añaden un período de impugnación. Registre en qué nivel de finalidad se apoyó.

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

Verificación con una segunda fuente

Una sola fuente puede estar equivocada: un explorador puede decodificar incorrectamente un token, mostrar un saldo desactualizado o asignar una etiqueta errónea. 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 no relacionados. La consulta siguiente supone que el examinador ha cargado 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 está en un bloque diferente, 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 es un problema que debe resolverse antes de emitir el informe. Un txid ausente de la segunda fuente suele indicar un error de escritura; el mismo txid en un bloque diferente significa que el registro se capturó en una rama que después fue reemplazada en una reorganización; un valor diferente suele indicar un error de unidades o decimales. Un resultado vacío, con la consulta y ambas fuentes registradas, constituye por sí mismo un registro útil de verificación.

Capturas del estado de las etiquetas y los resultados de herramientas

Las etiquetas pierden vigencia. Una dirección etiquetada como procesador de pagos este año puede volver a etiquetarse como exchange el año siguiente, o integrarse en un clúster mayor. Si su informe afirma que un depósito llegó a "Exchange X", un revisor debe poder ver la etiqueta tal como estaba cuando usted se apoyó en ella. Exporte, para cada etiqueta utilizada: el nombre de la entidad, la dirección o el clúster que abarca, la fuente (publicación de la propia entidad, registro de un proveedor, lista comunitaria, herramienta de análisis), la versión o fecha de la fuente y su calificación de A a D. La lección De la dirección a la entidad y a la persona: atribución y etiquetado aborda la calificación de etiquetas; aquí el objetivo es fijarlas.

Los resultados de las herramientas necesitan el mismo tratamiento. Guarde el archivo nativo del proyecto si la herramienta dispone de él, una exportación legible (CSV o JSON de nodos y aristas) y una imagen renderizada, y registre la versión de la herramienta, el método de rastreo, los límites de saltos y otros ajustes. Volver a ejecutar el mismo caso en una versión posterior puede producir un grafo diferente, y tendrá que explicar la diferencia. La lección Herramientas, reproducibilidad y validación explica cómo conciliar herramientas que discrepan.

Archivado de evidencia web

Las páginas fuera de la cadena suelen contener la atribución: un sitio fraudulento que enumera direcciones de depósito, una publicación en un foro que ofrece fondos robados, las condiciones de uso de un servicio. El Protocolo de Berkeley sobre Investigaciones en Fuentes Abiertas Digitales, 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 ese material de forma profesional. Los métodos de captura se abordan en la lección OSINT y vinculación de identificadores dentro y fuera de la cadena. El registro de preservación debe incluir:

• un archivo de preservación en formato WARC (ISO 28500:2017), que conserva el contenido de la página y las respuestas del servidor;
• una captura de pantalla de la página completa, para su lectura por personas;
• 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 resulte útil, una copia en un archivo web público como corroboración independiente, nunca como única copia.

Para demostrar que una captura existía en un momento determinado, puede obtener un sello de tiempo de confianza para su hash (RFC 3161 define un protocolo para ello) o anclar el hash en una transacción de una cadena de bloques pública. OpenTimestamps es un ejemplo de código abierto del segundo enfoque.

El paquete de evidencia que puede volver a verificarse

Todo esto se reúne 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 figura debajo
  facts.json              registros de hechos (F-001 ... F-088)
  raw/                    transacciones y bloques en bruto 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 consultar cada transacción en 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 nuevo manifiesto y registre el motivo. La lección Cálculo de hashes, registro, cadena de custodia y gestión de la calidad explica cómo pasa después el paquete por la cadena de custodia.

Enfoque del examen: por qué los datos en bruto finales de la cadena rara vez necesitan ser rescatados, mientras que las páginas de exploradores, las etiquetas, los resultados de herramientas, las páginas web y los precios sí lo necesitan; los campos que vinculan un hecho (cadena, txid, índice de registro, altura y hash del bloque, finalidad en el momento de la captura, fuente y versión del cliente, hora UTC, hash del archivo en bruto); no tratar los datos no finales como finales, marcar las capturas provisionales y volver a verificarlas; finalidad del rollup frente a finalidad de la cadena base; comprobación cruzada con una fuente independiente; exportación de capturas del estado de las etiquetas y de la configuración de las herramientas; WARC, capturas de pantalla, hashes y sellos de tiempo de confianza para la evidencia web conforme al Protocolo de Berkeley; el paquete de evidencia, su manifiesto y el uso de versiones en lugar de la edición.