Auditorías de Blockchain: Guía Práctica para el Alcance, la Evidencia y la Verificación

Qué cubre realmente una auditoría de blockchain

Una auditoría de blockchain es una evaluación sistemática de la seguridad, funcionalidad y postura de cumplimiento de un sistema blockchain, respaldada por evidencia que un tercero puede reproducir. El término es ambiguo: puede referirse a una revisión de contratos inteligentes, una evaluación de protocolo y consenso, una revisión de infraestructura y operaciones de nodos, o una auditoría financiera y de cumplimiento de la actividad en cadena. Antes de que cualquier herramienta importe, el alcance debe ser explícito, porque la evidencia, las habilidades y los criterios de aceptación difieren marcadamente entre estas categorías.

Este artículo se centra en el lado de la ingeniería: cómo definir el alcance, recopilar evidencia de nodos y RPC, ejecutar comprobaciones reproducibles e informar hallazgos. No certifica ningún auditor o cadena específicos. Cuando una afirmación depende de tu entorno, se plantea como una medición que debes ejecutar en lugar de una cifra aseverada aquí.

• Auditoría de protocolo: reglas de consenso, redes, transición de estado, criptografía, rutas de actualización y gobernanza.
• Auditoría de contratos inteligentes: lógica, control de acceso, reentrancia, aritmética, supuestos de oráculos y llamadas externas, actualizabilidad.
• Auditoría de infraestructura: configuración de nodos, gestión de claves, exposición de RPC, monitoreo, respaldo y recuperación.
• Auditoría financiera/de cumplimiento: rastreo de transacciones, verificación de saldos, sanciones y obligaciones de reporte.

Requisitos previos y supuestos antes de comenzar

Supón que tienes acceso de lectura al menos a un nodo con capacidad de archivo o a un punto final RPC para la cadena objetivo, la capacidad de ejecutar scripts localmente y autorización por escrito para probar cualquier entorno que no sea de producción. Para auditorías de contratos, supón que tienes el código fuente, la configuración del compilador y el bytecode desplegado para que puedas confirmar que coinciden. Para revisiones de infraestructura, supón que puedes inspeccionar la configuración y los registros del nodo.

Documenta el ID de cadena, el rango de bloques bajo revisión y el commit o despliegue exacto que estás auditando. Una auditoría sin un objetivo fijado no es reproducible. Si necesitas un punto final confiable para la recopilación de evidencia, la guía de puntos finales RPC y la guía de puntos finales RPC multicadena explican cómo difieren los puntos finales; para una elección concreta de proveedor, RPC Assistant cubre recomendaciones breves en lugar de esta página.

El modelo mental: afirmaciones, evidencia y reproducción

Trata cada auditoría como un conjunto de afirmaciones que deben probarse contra evidencia. Una afirmación podría ser "solo el rol de administrador puede pausar el contrato" o "el nodo rechaza transiciones de estado inválidas". La evidencia es el artefacto que respalda o refuta la afirmación: un rastro de transacción, una lectura de una ranura de almacenamiento, una línea de registro, un informe firmado o una prueba que falla cuando la afirmación es falsa.

La característica distintiva de una buena auditoría de blockchain es la reproducibilidad. Dado que las cadenas son de solo añadir y públicas (o al menos observables), la mayoría de las afirmaciones pueden vincularse a una altura de bloque específica y verificarse de nuevo más tarde. Registra el número de bloque, el punto final utilizado, la versión de la herramienta y el comando exacto. Ese registro es lo que convierte una opinión en un hallazgo auditable.

• Afirmación: una declaración falsable sobre comportamiento, acceso o estado.
• Evidencia: datos vinculados a una altura de bloque y a un comando reproducible.
• Hallazgo: una afirmación más evidencia más gravedad y orientación para la remediación.
• Re-prueba: vuelve a ejecutar el mismo comando después de la remediación y compara.

Recopilación de evidencia reproducible a través de RPC

La mayor parte de la evidencia de solo lectura se puede recopilar con métodos JSON-RPC estándar. Fija un número de bloque para que los resultados no varíen y almacena las respuestas sin procesar. El siguiente ejemplo en Python lee un bloque, el bytecode de un contrato y una ranura de almacenamiento a una altura fija. Reemplaza RPC_URL con tu punto final y ajusta la dirección y la ranura.

Ejecútalo dos veces contra la misma altura de bloque y confirma que las salidas son idénticas. Si difieren, tu punto final no está sirviendo un estado histórico consistente, lo cual es en sí mismo un hallazgo sobre tu canal de evidencia.

import json, urllib.request

RPC_URL = "RPC_URL"
BLOCK = 19000000
ADDR = "0x0000000000000000000000000000000000000000"
SLOT = "0x0"

def rpc(method, params):
    body = json.dumps({"jsonrpc":"2.0","id":1,"method":method,"params":params}).encode()
    req = urllib.request.Request(RPC_URL, data=body, headers={"Content-Type":"application/json"})
    with urllib.request.urlopen(req, timeout=30) as r:
        out = json.loads(r.read())
    if "error" in out:
        raise RuntimeError(out["error"])
    return out["result"]

block = rpc("eth_getBlockByNumber", [hex(BLOCK), False])
code = rpc("eth_getCode", [ADDR, hex(BLOCK)])
slot = rpc("eth_getStorageAt", [ADDR, SLOT, hex(BLOCK)])
print(json.dumps({"block": BLOCK, "hash": block["hash"], "code_len": len(code), "slot": slot}, indent=2))

Un procedimiento de diagnóstico para la infraestructura de nodos y RPC

Las auditorías de infraestructura a menudo fallan no por el código sino por supuestos operativos: un punto final que equilibra la carga silenciosamente entre nodos a diferentes alturas, un nodo que carece de datos de archivo o un límite de velocidad que rompe un trabajo de monitoreo. El procedimiento a continuación verifica el ID de cadena, la concordancia de la altura de bloque y la disponibilidad de archivo. Ejecútalo contra cada punto final de tu pila y registra los resultados.

El resultado de verificación esperado es que cada punto final informe el mismo ID de cadena, alturas dentro de una tolerancia pequeña y documentada, y lecturas históricas exitosas para el rango de bloques bajo revisión. Cualquier punto final que falle estas comprobaciones debe excluirse de la recopilación de evidencia o marcarse como un riesgo de confiabilidad.

RPC_URL="RPC_URL"

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"eth_getBlockByNumber","params":["0x1",false]}'

Registro de resultados en una tabla comparable

Mantén una tabla de resultados para que los hallazgos sean comparables entre puntos finales y a lo largo del tiempo. No rellenes números que no hayas medido; deja las celdas en blanco hasta que ejecutes las comprobaciones. Una plantilla como la siguiente, representada como una tabla Markdown en tu informe, mantiene la auditoría honesta sobre lo que se observó versus lo que se asumió.

Completa cada fila a partir del procedimiento de diagnóstico anterior. Si operas infraestructura dedicada, la descripción general de nodos dedicados explica cómo los nodos aislados cambian el perfil de confiabilidad que estás midiendo. Para la planificación de capacidad y costos en torno a la recopilación de evidencia, consulta precios de RPC.

Alcance de contratos inteligentes: coincidencia de código fuente, bytecode y comportamiento

Para auditorías de contratos, la primera comprobación es que el bytecode desplegado coincida con el código fuente y la configuración del compilador que revisaste. Una discrepancia invalida todas las conclusiones posteriores. Después de eso, prueba el control de acceso, las transiciones de estado y los supuestos de llamadas externas con llamadas dirigidas contra una bifurcación o entorno de prueba, nunca contra fondos de producción.

El siguiente ejemplo en JavaScript lee una función de verificación de roles y una bandera de pausa en un bloque fijado. Reemplaza el fragmento de ABI, la dirección y los selectores de función con tu objetivo. Trata cualquier reversión o valor inesperado como una pista para investigar, no como una vulnerabilidad confirmada.

const RPC_URL = "RPC_URL";
const ADDR = "0x0000000000000000000000000000000000000000";
const BLOCK = "0x1220000";

async function call(data) {
  const res = await fetch(RPC_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_call", params: [{ to: ADDR, data }, BLOCK] })
  });
  return res.json();
}

(async () => {
  console.log(await call("0x5c975abb")); // paused()
  console.log(await call("0x91d14854" + "00".repeat(12) + "0000000000000000000000000000000000000000" + "00".repeat(32)));
})();

Solución de problemas comunes de evidencia de auditoría

Cuando la recopilación de evidencia falla, la causa suele ser ambiental en lugar de una vulnerabilidad real. Distingue los fallos de las herramientas de los hallazgos antes de escribir cualquier cosa. Una reversión de eth_call puede significar que tus datos de llamada están mal formados, no que el contrato esté roto. Un bloque histórico faltante generalmente significa que el punto final no tiene capacidad de archivo.

Verifica el objeto de error, no solo la ausencia de un resultado. Registra la solicitud y la respuesta sin procesar. Confirma que la altura de bloque existe en la cadena canónica. Si un punto final devuelve alturas inconsistentes entre llamadas, deja de usarlo para evidencia y cambia a uno que hayas verificado.

• Datos de llamada mal formados: verifica los selectores de función y la codificación de argumentos.
• Historial faltante: confirma el soporte de archivo para el rango de bloques.
• Alturas inconsistentes: el punto final puede estar balanceando la carga entre nodos retrasados.
• Límites de velocidad: agrupa solicitudes y añade reintentos con retroceso exponencial, luego vuelve a verificar.
• Discrepancia de cadena: confirma el ID de cadena antes de confiar en cualquier resultado.

Limitaciones y compensaciones

Ninguna auditoría prueba la ausencia de errores. Una auditoría de protocolo en un momento dado no cubre futuras actualizaciones, y una auditoría de contratos no cubre la infraestructura que lo sirve. Los puntos finales RPC públicos son convenientes para la recopilación de evidencia pero pueden limitar la velocidad, retrasarse o servir un estado inconsistente; los nodos dedicados reducen ese riesgo a un mayor costo y carga operativa.

También existe una compensación de confianza en las herramientas. Los escáneres automatizados detectan patrones pero pasan por alto la lógica y los supuestos económicos; la revisión manual detecta más pero es más lenta y depende de la experiencia del revisor. Las auditorías más sólidas combinan ambos y publican suficientes detalles para que un tercero pueda volver a ejecutar las comprobaciones clave.

Próximos pasos para un programa de auditoría creíble

Convierte los procedimientos anteriores en una lista de verificación repetible vinculada a alturas de bloque y versiones de herramientas, y vuelve a ejecutarla después de cada cambio material. Mantén un conjunto de puntos finales verificados para la recopilación de evidencia y documenta qué puntos finales se utilizaron para cada hallazgo. Si estás eligiendo infraestructura para ese trabajo, comienza con el directorio de redes para confirmar el soporte de la cadena, luego usa RPC Assistant para obtener una recomendación concreta de punto final.

Finalmente, publica el alcance, el rango de bloques y la metodología junto con los hallazgos. La reproducibilidad es lo que separa una auditoría de blockchain de una opinión de seguridad, y es la parte en la que la mayoría de los equipos invierten poco.