Por Andrei Belonogov[1] – Uso de información de la cadena de bloques como evidencia de auditoría
Documento original: Using Blockchain Information as Audit Evidence [20/10/2025][2]
Vista de conjunto
Los procedimientos de auditoría para respaldar la completitud, existencia, y exactitud de los saldos de cuentas y transacciones con criptoactivos a menudo usan como evidencia de auditoría información de la cadena de bloques. Los auditores usan varios métodos para adquirir datos relevantes provenientes de cadenas de bloques públicas, incluyendo obtenerla de proveedores de datos. La guía del AICPA “Accounting for and auditing of digital assets” [Contabilidad y la auditoría de activos digitales] de manera breve menciona algunas consideraciones relevantes para los auditores que comprometen a un tercero para obtener información de la cadena de bloques. Pero hoy vamos a intentar profundizar un poco más y entender con mayor detalle el proceso de adquisición de información de la cadena de bloques.
Nos centraremos solo en organizaciones de servicio que suministran datos de la cadena de bloques, pero no autorizan o inician transacciones. Esos proveedores a menudo conectan dados de la cadena de bloques con reportes tabulares organizados y confiables para sistemas de contabilidad, un paso frecuentemente pasado por alto en la literatura.
Como alternativa válida a la ejecución de su propia estructura de nodos, los auditores pueden usar un tercero proveedor. Las firmas pueden contratar directamente un tercero proveedor u obtenerlo del cliente de auditoría. Respectivamente, los auditores que usan información de la cadena de bloques recibida de terceros proveedores de datos seguirán un enfoque de prueba consistente con el enfoque seleccionado para la adquisición de los datos:
Información recibida directamente de la fuente externa cuando usan un enfoque de pruebas sustantivas.
Información recibida de la entidad cuando prueban los controles.
Las secciones que aparecen a continuación esbozan las consideraciones relevantes.
Observabilidad de datos de la cadena de bloques
La mayoría de API [Application Programming Interface][3] raramente por sí solas proporcionan suficiente información para conciliar un saldo de cuenta debido a cambios en el estado de las no-transacciones y otros factores. Los auditores tienen que usar métodos alternativos.
Ahora, discutamos brevemente las estructuras de datos sin procesar de la cadena de bloques y esbozaremos los pasos que se necesitan para acceder a los datos sin procesar de la cadena de bloques.
No todos los datos registrados en la cadena de bloques son relevantes para los auditores, y no todos los datos pertinentes para los auditores están capturados de manera directa en la cadena de bloques. Hay dos elementos de datos generalizados que son relevantes durante la auditoría de estados financieros de compañías que están involucradas en activos digitales:
– Estado, que es un valor asignado a un registro en una altura específica del bloque (es decir, el número de un bloque en la cadena de bloques). En Ethereum, incluye:
“En Ethereum, el estado incluye:
Saldos de cuenta e identificadores únicos
Código del contrato
Almacenamiento del contrato
Datos relacionados-con-el-consenso (algunos hashes[4] recientes del bloque, tíos[5], datos de consenso de la prueba-de-estado tales como claves públicas del validador y registros de actividad en la cadena de balizas, etc.)”
[“A Theory of Ethereum State Size Management” by V. Buterin on 02/12/2021]
– Transición del estado, que es un cambio en un valor asignado a un registro entre la altura especificada del boque y la altura del bloque inmediatamente precedente.
La cadena de bloques no siempre captura cada estado y transición de estado porque hacerlo sería computacionalmente costoso. Algunas cadenas de bloques registran ambos; otras rastrean solo uno, o ninguno, pero permiten el recálculo. Cada cadena de bloques, y cada contrato inteligente, tiene su propia manera de registrar el estado y las transiciones.
El proceso de adquisición de datos incluye los siguientes pasos:
Descargar [Downloading]el software del nodo de la cadena de bloques.
Instalar el software del nodo y poner en marcha [spinning up] el nodo. Esto incluye conectar y sincronizar el nodo con la red. Durante una sincronización, dependiendo del mecanismo de almacenamiento usado por el software del nodo, hay riesgos de descarga incompleta de datos, pérdida parcial, o corrupción de los datos descargados, y la inaccesibilidad o ilegibilidad de los archivos descargados de la información de la cadena de bloques sin procesar. Esto puede ocurrir debido a:
Almacenar bloques individuales en archivos separados (Bitcoin y Bitcoin Cash).
Seleccionar resultados equivocados del modo sincronizado en una pérdida de información acerca de transacciones que ocurrieron antes del período cubierto por un alcance ligero del nodo.
Consulta directa. Una vez que el nodo está sincronizado, puede ser posible consultar el nodo directamente usando su interfaz narrativa RPC[6]. Cuando se consulta la interfaz del nodo RPC, no accedemos u observamos datos brutos de la cadena de bloques. Confiamos que el código del software del nodo esté diseñado adecuadamente y devuelva los datos que promete con base en la documentación (si tal documentación existe, lo cual no siempre es el caso). Sin embargo:
Errores en el software del nodo del cliente que eliminan la capacidad para usar comandos estándar para extraer los datos que se necesitan vía la interfaz del nodo RPC, tal como consultar el estado de la cadena de bloques a una altura específica del bloque.
Indexación de datos. Los datos sin procesar de la cadena de bloques están codificados y son ilegibles. Los auditores que necesitan manipular o filtrar datos tienen que preprocesaros con software indexador. Los indexadores organizan los datos, pero esto requiere entender tanto las estructuras de los datos en-la-cadena como el resultado de la ejecución del código de la cadena de bloque en esos datos. Los riesgos incluyen:
Lógica inapropiada del código de indexación resulta en que los datos incompletos o inexactos son devueltos. Esta no es una tarea trivial. Aquí hay un artículo acerca de una destacada firma de investigación que intenta determinar el número de todos los contratos inteligentes desplegados en Ethereum usando diferentes enfoques y recibiendo resultados drásticamente diferentes.
Archivos de referencia faltantes o incorrectos, incluyendo archivos Genesis que contienen la asignación inicial de tokens a billeteras en el Día 0 e interfaces binarias de aplicación [Application Binary Interfaces (ABI)] de contratos inteligentes. Estos datos no son almacenados en la cadena, y puede no ser posible indexar un contrato inteligente sin conocer su ABI o determinar el saldo de cuenta si el archivo génesis.
Almacenamiento de datos indexados. Los datos indexados típicamente son guardados en una base de datos rápida y moderna (“base de datos de servicio”), que es conveniente para consultas usando SQL para extraer datos leíbles-por-humano con los campos y valores requeridos. Los riesgos que surgen en este punto incluyen:
Pérdida o corrupción de datos que ocurre durante la operación inicial realizada para registrar datos indexados en la base de datos de servicio.
Pérdida o corrupción de datos puede ocurrir cuando se almacenan datos en la base de datos. Por ejemplo, daño físico o funcionamiento defectuoso del disco pueden causar pérdida de dato.
Lógica incorrecta de las consultas SQL de la base de datos indexada resulta en que los datos incompletos o inexactos sean devueltos.
Transmisión. Finalmente, los auditores reciben datos vía correo electrónico o API en la forma de un reporte PDF, archivo Excel o CSV, u otro formato. El principal riesgo es la modificación inapropiada de datos durante la transmisión, por diversas razones.
Entender esos riesgos y las respuestas en funcionamiento para abordarlos es clave para el uso exitoso de la información de la cadena de bloques como evidencia de auditoría.
1) Información recibida directamente de una fuente externa
En el contexto de un compromiso individual de auditoría, el tercero vendedor de datos de cadena de valor usado por la firma de auditoría es una fuente externa de información. Por lo tanto, los auditores necesitan considerar los requerimientos para usar, como evidencia de auditoría, información recibida de fuentes externas.
La Orientación del personal de la PCAOB[7] proporciona algunos recordatorios útiles acerca de cómo los auditores deben abordar la evidencia de auditoría obtenida de fuentes externas. Cuando usan información, como evidencia de auditoría, acerca de saldos históricos recibida directamente de un tercero, los auditores necesitan considerar la relevancia y la confiabilidad de la información.
La relevancia mide qué tan bien la información de auditoría se alinea con el propósito del procedimiento de auditoría. Cuando se prueban saldos de activos digitales, la cantidad de tokens en la billetera al final del período es directamente relevante.
La confiabilidad de la evidencia de auditoría depende de la suficiencia (cantidad) y de lo apropiado (calidad). La información acerca de las cantidades de activos al final de año puede o no ser confiable. ¿Cómo valoramos la confiabilidad?
Muchos profesionales en ejercicio consideran que el SOC 1 o el SOC 2 del vendedor de datos de la cadena de bloques es suficiente para valorar la confiabilidad de la información recibida.
El SOC I Tipo 2, si prueba los controles sobre la completitud y exactitud del reporte, puede ayudar. Cuando los auditores usan directamente los reportes del vendedor, el solo reporte SOC en general no es suficiente para asegurar que la información específica-del-cliente es completa y exacta porque:
a) La presentación de reportes del auditor de servicio sobre el vendedor de datos de cadena de valor aplica procedimientos de auditoría usando muestreo a nivel del vendedor. El tamaño de la muestra puede no ser suficiente para proporcionar el nivel de aseguramiento consistente con el umbral tolerable de declaración equivocada usada para los propósitos de la auditoría de la entidad que reporta.
b) Si la entidad que reporta se basó en información recibida del vendedor de datos de la cadena de bloques con referencia al reporte SOCI I Tipo 2, la administración tendría que realizar una cantidad considerable de trabajo adicional para evitar la deficiencia en sus controles internos (para detalles adicionales refiérase a la siguiente sección). No sería apropiado señalar que las firmas de auditoría puedan basarse en la misma información sin necesitar realizar trabajo adicional para validarlo.
Las consideraciones clave para la evidencia externa y confiable de auditoría externa incluyen:
1. Independencia, competencia, experticia, y capacidades, incluyendo la confiabilidad de la infraestructura del vendedor y el uso de terceros vendedores.
2. Limitaciones y descargos de responsabilidad que afecten el uso de los datos del vendedor.
3. Seguridad cibernética, vulnerabilidades conocidas (no-resueltas), y respuestas implementadas por el vendedor.
4. riesgos asociados con una red específica de cadena de bloques.
5. Respuestas a los riesgos de integridad de los datos que ocurran durante todo el ciclo de vida de los datos (vea la sección anterior).
2) Información recibida de la entidad (El cliente que utiliza una organización de servicio)
Las entidades que reportan (e.g., startups de la web3) pueden basarse en un proveedor de datos de la cadena de bloques si ambas de las siguientes son verdaderas:
a) Durante el período relevante, el vendedor mantuvo controles efectivos sobre el proceso relevante y los reportes específicos de datos usados. Esta valoración se basa en el reporte SOC 1 Tipo 2 recibido de la organización de servicio y de las cartas puente que muestren los resultados de las pruebas subsiguientes durante los períodos intermedios entre el final de año de la organización de servicio y la fecha de final del período de los estados financieros del usuario que están siendo auditados.
b) La administración diseñó e implementó:
Controles complementarios de la entidad usuario identificados en el SOC1 Tipo 2 del vendedor.
Controles de compensación para mitigar cualesquiera deficiencias identificadas en ese reporte; y
Controles específicos-de-la-entidad sobre los riesgos en la entidad que reporta que no están suficientemente cubiertos por el SOC 1 Tipo 2 del vendedor.
De acuerdo con ello, los auditores pueden confiar en datos de la cadena de valor que:
son recibidos del cliente,
que el cliente obtuvo de una organización de servicio,
con un reporte SOC 1 Tipo 2,
que cubren procesos, controles, y reportes relevantes para la entidad, y
están respaldados por controles efectivos implementados al nivel, permitiéndonos asegurar que la información relevante para la entidad que reporta es completa y exacta para los propósitos del estado financiero.
Cuando se cumplen estas condiciones, los auditores pueden ser capaces de basarse en datos de la cadena de bloques recibidos de un vendedor externo. Para confiar, el enfoque de prueba del auditor debe ser diseñado asumiendo la confianza de los auditores en el diseño y operación efectivos de los controles internos relevantes del cliente de auditoría. Para confiar en los controles, los auditores deben probar esos controles, incluyendo los sobre la exactitud y completitud de la información de la cadena de bloques recibida de la organización de servicio (vendedor de datos de la cadena de bloques).
Si esas condiciones no se cumplen, la confianza en datos recibido de la API de un vendedor externo generalmente no es apropiada.
Conclusión
Desafortunadamente, los datos de la cadena de bloques no pueden ser observados directamente por los auditores. El proceso de trasformación de los datos es complicado y propenso a errores. Independiente de la fuente de los datos y del enfoque de prueba, hay numerosos riesgos relacionados con la completitud y exactitud de la representación leíble-por-el-humano de la información de la cadena de bloques usada por los auditores. Para abordar esos riesgos y obtener suficiente evidencia de auditoría, los auditores probablemente requerirán procesos de auditoría adicionales.
[1] Louisville, Kentucky, Estados Unidos. https://www.linkedin.com/in/andrewbelonogov
[2] Traducido por Samuel Mantilla, con autorización de Andrei Belonogov.
[3] API de cadena de bloques: libro mayor descentralizado que registra transacciones a través de múltiples computadores. Asegura transparencia, exactitud e inmutabilidad de los datos (N del t).
[4] Un hash es una cadena de caracteres de longitud fija, generada por un algoritmo matemático (función hash), que representa de forma única y segura un conjunto de datos. Es como una «huella digital» de un archivo o dato, ya que es casi imposible revertir el hash para obtener los datos originales y cualquier cambio mínimo en los datos de entrada resultará en un hash completamente diferente. [By Google].
[5] Un bloque tío [uncle], a veces llamado bloque ommer, es un bloque válido que se crea simultáneamente con otro bloque. Sin embargo, no llega a la cadena canónica o principal. Se descarta u omite de la cadena de bloques, ya que la red solo puede incluir un bloque. [By Google].
[6] Una llamada remota de procedimiento [Remote Procedure Call] o nodo RPC es un tipo de computador que permite que los usuarios lean datos en la cadena de bloques y envíen transacciones a diferentes redes [By Google].
[7] Spotlight Reports “Data and Reports” y “Evaluating Relevance and Reliability of Audit Evidence Obtained from External Sources”
samuelmantilla.com 