Seguridad Web3: un modelo por capas para proteger sistemas onchain

Alcance y la respuesta directa

La seguridad Web3 es la práctica de reducir la probabilidad y el impacto de cambios de estado no autorizados en sistemas descentralizados. Dado que esos sistemas abarcan protocolos de consenso, infraestructura de nodos y RPC, contratos inteligentes, puentes, billeteras y personas, ningún control único es suficiente. La respuesta práctica es un modelo por capas: asumir que cada capa puede fallar, verificar las capas que controlas y medir el resultado en lugar de confiar en la afirmación de un proveedor.

Este artículo cubre el modelo, un procedimiento de diagnóstico ejecutable para las capas de infraestructura y contratos, las señales de verificación esperadas, la resolución de problemas y las ventajas y desventajas de cada enfoque. No publica cifras de referencia de ningún proveedor; cuando la medición es apropiada, te proporciona un procedimiento y una tabla para completar con tus propios resultados.

• Comportamiento documentado: reglas de consenso, semántica de la EVM y contratos de métodos RPC según las especificaciones respectivas.
• Recomendaciones: prácticas de ingeniería como privilegio mínimo, verificación independiente de RPC y defensa en profundidad.
• Mediciones que debes ejecutar: latencia, tasas de error, consistencia entre endpoints y cobertura de detección en tu propio entorno.

Supuestos y requisitos previos

Los procedimientos a continuación asumen que tienes acceso a al menos un endpoint RPC compatible con EVM, un shell con curl y Python 3, y permiso para leer el estado de contratos en la red que estás probando. No necesitas una cuenta con fondos para diagnósticos de solo lectura. Para pruebas de escritura, usa una testnet y una clave desechable.

Mantén los secretos fuera del control de versiones. Usa variables de entorno como RPC_URL y PRIVATE_KEY, y nunca pegues una clave de producción en el historial de una terminal compartida. Si necesitas un endpoint gestionado en lugar de ejecutar tu propio nodo, compara opciones a través de la guía de endpoints del RPC Assistant y el directorio de redes antes de comprometerte.

• Un RPC_URL principal y, idealmente, un segundo RPC_URL_SECONDARY independiente para la verificación cruzada.
• Python 3.9+ con la biblioteca requests, o Node.js 18+ si prefieres JavaScript.
• Una cuenta de testnet con un saldo pequeño para cualquier verificación a nivel de transacción.
• Acceso de lectura al código fuente de tu contrato y a las direcciones de despliegue.

El modelo mental por capas

Trata la seguridad Web3 como una pila donde cada capa tiene sus propios supuestos de confianza y modos de falla. La capa de protocolo depende del consenso y la criptografía. La capa de infraestructura depende de los nodos, los proveedores de RPC y la ruta de red entre ellos. La capa de contratos depende de la corrección del código y el diseño económico. Las capas de aplicación y billetera dependen de cómo se construye y firma la intención. La capa humana depende de la disciplina operativa.

Una regla útil es que un compromiso en cualquier capa puede invalidar las garantías de las capas superiores. Un contrato correcto sigue siendo inseguro si el endpoint RPC devuelve datos obsoletos o falsificados, y un RPC reforzado sigue siendo inseguro si un usuario firma una carga maliciosa. Por eso las auditorías de una sola capa rara vez producen seguridad duradera.

• Protocolo: consenso, finalidad y supuestos criptográficos.
• Infraestructura: nodos, endpoints RPC, DNS, TLS y alojamiento.
• Contratos: lógica, control de acceso, actualizaciones y dependencias.
• Aplicación y billetera: construcción de transacciones, firma y visualización.
• Humano y proceso: gestión de claves, respuesta a incidentes y control de cambios.

Modelado de amenazas antes de las herramientas

Antes de elegir herramientas, escribe qué estás protegiendo, quién puede afectarlo y cómo se ve un ataque exitoso. Para una dApp, los activos son los fondos de los usuarios y el estado del protocolo; los actores incluyen usuarios, operadores, proveedores de RPC y atacantes externos. Para la infraestructura, los activos son las claves de validador, la disponibilidad del RPC y la integridad de los datos.

Un modelo de amenaza ligero es suficiente para empezar: enumera activos, enumera límites de confianza y, para cada límite, anota qué sucede si la otra parte es maliciosa o no está disponible. Este ejercicio suele revelar que el límite del RPC y el límite de firma merecen más atención de la que los equipos asumen inicialmente.

• Activo: qué pierde valor si se compromete.
• Límite de confianza: dónde cruzan datos o control entre las partes.
• Modo de falla: malicioso, no disponible o simplemente incorrecto.
• Detección: cómo notarías la falla en minutos en lugar de días.

Diagnósticos de infraestructura ejecutables con curl

Comienza verificando que tu endpoint devuelve un estado de cadena consistente y responde a métodos estándar. Los siguientes comandos usan marcadores de posición; reemplaza RPC_URL con tu endpoint. Ejecuta cada comando varias veces y compara los resultados entre un endpoint principal y uno secundario.

La primera comprobación confirma la identidad de la cadena. La segunda confirma que el endpoint puede leer un bloque reciente. La tercera compara los números de bloque entre dos endpoints para detectar retrasos.

export RPC_URL="https://your-primary-endpoint"
export RPC_URL_SECONDARY="https://your-secondary-endpoint"

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

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

# 3. Compare lag between endpoints
for url in "$RPC_URL" "$RPC_URL_SECONDARY"; do
  echo -n "$url -> "
  curl -s -X POST "$url" \
    -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","id":3,"method":"eth_blockNumber","params":[]}' \
    | python3 -c 'import sys,json; print(int(json.load(sys.stdin)["result"],16))'
done

Verificación del estado del contrato y el bytecode

Una vez que el endpoint es lo suficientemente confiable para lecturas, verifica que el bytecode desplegado coincida con lo que esperas y que las variables de estado clave sean legibles. El script de Python a continuación obtiene el bytecode y llama a una función de vista simple. Utiliza solo métodos JSON-RPC estándar, por lo que funciona con cualquier endpoint compatible.

Reemplaza CONTRACT_ADDRESS y el selector de función con valores de tu propio despliegue. Una discrepancia entre el bytecode esperado y el devuelto es una señal fuerte para detenerse e investigar antes de firmar cualquier transacción.

import os, json, requests

RPC_URL = os.environ["RPC_URL"]
CONTRACT = os.environ.get("CONTRACT_ADDRESS", "0xYourContractAddress")

def rpc(method, params):
    r = requests.post(RPC_URL, json={"jsonrpc":"2.0","id":1,"method":method,"params":params}, timeout=10)
    r.raise_for_status()
    body = r.json()
    if "error" in body:
        raise RuntimeError(body["error"])
    return body["result"]

code = rpc("eth_getCode", [CONTRACT, "latest"])
print("bytecode length:", len(code))
print("bytecode prefix:", code[:42])

# Example: call a no-argument view function by selector
selector = "0x18160ddd"  # totalSupply()
result = rpc("eth_call", [{"to": CONTRACT, "data": selector}, "latest"])
print("raw result:", result)
print("decoded uint256:", int(result, 16) if result != "0x" else None)

Un método de medición reproducible

Las afirmaciones sobre la confiabilidad de un endpoint o la cobertura de detección solo son útiles si puedes reproducirlas en tu entorno. Define una ventana de prueba fija, un conjunto fijo de métodos y un tamaño de muestra fijo. Ejecuta el mismo script contra cada endpoint o control candidato y registra los resultados en una tabla que completes tú mismo. No copies cifras de páginas de marketing.

Un procedimiento práctico: para cada endpoint, emite N solicitudes por método a una tasa constante, registra el éxito, el código de error y la latencia, luego repite en un momento diferente del día. Para los controles de contrato, reproduce un conjunto fijo de entradas maliciosas conocidas y registra si cada una fue bloqueada. La tabla a continuación es una plantilla; los valores deben provenir de tu propia ejecución.

• Métodos: eth_chainId, eth_blockNumber, eth_getCode, eth_call, eth_getLogs.
• Tamaño de muestra: al menos 100 solicitudes por método por endpoint.
• Registra: tasa de éxito, latencia mediana y p95, códigos de error y retraso de bloque frente a un endpoint de referencia.
• Repite: al menos dos ventanas en días diferentes para exponer efectos de la hora del día.

Plantilla de tabla de resultados

Completa esta tabla con tus propias mediciones. Deja las celdas en blanco hasta que tengas datos; no estimes. | Endpoint | Método | Solicitudes | Tasa de éxito | Latencia mediana (ms) | Latencia p95 (ms) | Retraso máximo de bloque | Notas | |---|---|---|---|---|---|---|---| | principal | eth_blockNumber | | | | | | | | secundario | eth_blockNumber | | | | | | | | principal | eth_call | | | | | | | | secundario | eth_call | | | | | | | | principal | eth_getLogs | | | | | | | | secundario | eth_getLogs | | | | | | |

El valor de la tabla no es el número individual sino la comparación. Una gran brecha entre principal y secundario en retraso de bloque o tasa de error es una señal para investigar el enrutamiento, los límites de tasa o el comportamiento del proveedor antes de que se convierta en un incidente.

Señales de verificación esperadas

Después de ejecutar los diagnósticos, deberías ver un pequeño conjunto de señales esperadas. La identidad de la cadena debe coincidir con la red que pretendes usar. Los números de bloque deben avanzar entre llamadas. El bytecode debe coincidir con tu registro de despliegue. Las llamadas de vista deben devolver valores consistentes con tu propio indexador o con un segundo endpoint.

Si falta alguna de estas señales, trátala como un hallazgo en lugar de una molestia. Una discrepancia en el ID de cadena significa que estás apuntando a la red incorrecta. Un número de bloque congelado significa que el endpoint está obsoleto o que la solicitud se está almacenando en caché incorrectamente. Una discrepancia en el bytecode significa que la dirección que estás leyendo no es el contrato que crees que es.

• El ID de cadena coincide con el ID de red documentado.
• El número de bloque aumenta en llamadas repetidas.
• El prefijo del bytecode coincide con tu artefacto de despliegue.
• Los resultados de las llamadas de vista coinciden entre dos endpoints independientes.
• Las respuestas de error incluyen un objeto de error JSON-RPC en lugar de una página HTML.

Solución de problemas comunes

La mayoría de las fallas de infraestructura se dividen en unas pocas categorías: autenticación y límites de tasa, problemas de red y TLS, datos obsoletos o inconsistentes y solicitudes malformadas. Comienza revisando el estado HTTP y el objeto de error JSON-RPC; muchos problemas son visibles allí antes de cualquier depuración más profunda.

Si ves 401 o 403, verifica que tu clave API esté presente y correctamente delimitada. Si ves 429, estás siendo limitado por tasa; reduce la velocidad y considera un endpoint dedicado. Si ves tiempos de espera, prueba desde una ruta de red diferente. Si los resultados discrepan entre endpoints, compara primero los números de bloque y luego compara las cargas útiles exactas de las solicitudes.

• 401/403: credenciales faltantes o inválidas, o discrepancia en la lista de IP permitidas.
• 429: límite de tasa; reduce la concurrencia o pasa a un nodo dedicado.
• Tiempos de espera: problema de DNS, TLS o enrutamiento; prueba con curl -v.
• Datos inconsistentes: retraso de bloque o almacenamiento en caché; verifica con un segundo endpoint.
• Solicitud malformada: verifica la versión JSON-RPC, el nombre del método y los tipos de parámetros.

Limitaciones y compensaciones

La seguridad por capas mejora la cobertura pero agrega costo operativo. Ejecutar tus propios nodos reduce la confianza en terceros pero aumenta la carga de mantenimiento. Verificar cada lectura contra dos endpoints mejora la integridad pero duplica la latencia y el costo. Las auditorías y la verificación formal detectan clases de errores que las pruebas pasan por alto, pero no cubren la infraestructura ni el error humano.

El equilibrio correcto depende del valor en riesgo. Un panel de solo lectura puede tolerar un único endpoint gestionado; un puente o un sistema de custodia no debería. Documenta la compensación explícitamente para que los cambios futuros no debiliten silenciosamente un control que se eligió por una razón.

• Nodos autoalojados: máximo control, mayor sobrecarga operativa.
• RPC gestionado: menor sobrecarga, pero heredas las propiedades de disponibilidad e integridad de datos del proveedor.
• Verificación de doble endpoint: mayor integridad, mayor costo y complejidad.
• Auditorías y métodos formales: fuertes para la lógica de contratos, ciegos a la infraestructura y la firma.

Próximos pasos

Convierte los diagnósticos en una verificación recurrente. Programa los scripts de curl y Python para que se ejecuten con una cadencia fija, almacena los resultados en una tabla de series temporales y alerta sobre desviaciones de tu línea base. Extiende el modelo de amenaza a la ruta de firma revisando cómo se construyen y muestran las transacciones a los usuarios.

Si necesitas un endpoint gestionado para la siguiente fase, comienza con la guía de endpoints RPC, compara redes en el directorio de redes y revisa los precios antes de escalar. Para los equipos que ejecutan cargas de trabajo en producción, un nodo dedicado elimina los efectos de vecinos ruidosos y te da una línea base de medición más clara.

• Automatiza el procedimiento de medición y mantén una línea base continua.
• Agrega la revisión de la ruta de firma a tu modelo de amenaza.
• Elige endpoints deliberadamente usando la guía del RPC Assistant y el directorio de redes.
• Vuelve a ejecutar el diagnóstico completo después de cualquier cambio de infraestructura.