💻 computer science

Assessing Vulnerability in Smart Contracts: The Role of Code Complexity Metrics in Security Analysis

Esta investigación demuestra que, si bien las métricas de complejidad de software individuales muestran una baja correlación con vulnerabilidades específicas en los contratos inteligentes de Solidity, su análisis colectivo distingue eficazmente entre el código seguro y el vulnerable, exhibiendo los contratos vulnerables consistentemente puntuaciones de complejidad media más altas.

Autores originales: Masoud Jamshidiyan Tehrani

Publicado 2026-01-26

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Masoud Jamshidiyan Tehrani

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que un Contrato Inteligente es como una máquina expendedora autoejecutable construida en una blockchain. Una vez que introduces el dinero y presionas un botón, te entrega un snack automáticamente. No puedes volver atrás para cambiar los engranajes internos de la máquina más tarde; es "inmutable". Si hay un fallo en los engranajes, un hacker puede robar todo el dinero que hay dentro, y no hay forma de arreglarlo sin construir una máquina completamente nueva.

Este artículo trata de intentar encontrar esos engranajes rotos antes de que la máquina sea desplegada. Los investigadores se hicieron una pregunta sencilla: "¿Podemos saber si una máquina expendedora tiene probabilidades de estar rota con solo mirar qué tan complicados son sus planos?"

Aquí está el desgón de sus hallazgos utilizando analogías de la vida cotidiana:

1. La idea central: La complejidad es una "bandera roja"

Los investigadores analizaron 21 formas diferentes de medir qué tan "desordenado" o "complicado" es un fragmento de código. Piensa en estas métricas como formas de medir cosas como:

SLOC (Líneas de Código Fuente): ¿Cuántas páginas tiene el manual de instrucciones?
Anidamiento (Nesting): ¿Cuántas capas de cajas de "si esto, entonces aquello" hay una dentro de otra? (Como una muñeca rusa).
Acoplamiento (Coupling): ¿Con cuántas otras máquinas necesita hablar esta para poder funcionar?

El hallazgo: Encontraron que los planos desordenados suelen significar máquinas rotas.
Cuando analizaron los contratos que habían sido hackeados (vulnerables), sus planos eran casi siempre más complejos, largos y enredados que los planos de los contratos seguros.

2. El problema de la "Bola de Cristal" (Métricas individuales)

Los investigadores intentaron ver si una medición específica podía predecir un hackeo.

Analogía: Imagina intentar adivinar si un coche tendrá un accidente solo mirando el número de portavasos.
Resultado: No funcionó bien. Ninguna métrica individual (como simplemente contar las líneas de código) era una "bola de cristal" perfecta. Si mirabas solo el número de líneas, no podías decir de forma fiable: "Este definitivamente va a ser hackeado". La conexión estaba ahí, pero era débil.

3. El éxito del "Trabajo en Equipo" (Métricas combinadas)

Sin embargo, cuando miraron todas las mediciones juntas, el panorama se volvió muy claro.

Analogía: No puedes saber si una sopa está salada solo probando el salero, pero si pruebas todo el tazón, sabes exactamente qué tan salada está.
Resultado: Aunque una métrica no era suficiente, la combinación de métricas fue muy buena para distinguir entre contratos seguros y peligrosos. Los contratos "vulnerables" tenían consistentemente puntuaciones más altas en todos los aspectos (más líneas, mayor anidamiento, más conexiones) en comparación con los seguros.

4. Las excepciones sorprendentes

Hubo tres cosas que fueron en contra de la regla de "más complejidad = más peligro":

Comentarios (CLOC): Los contratos seguros tenían más comentarios (notas escritas por el programador explicando el código). Los contratos vulnerables tenían menos.
- Conclusión: Escribir notas en tu plano parece ayudar a mantener tu máquina segura.
Descendientes (NOD): Los contratos seguros tenían más "descendientes" (versiones o contratos hijos). Los vulnerables tenían menos.
Parámetros: Los contratos vulnerables tenían, de hecho, ligeramente menos entradas o parámetros en promedio.

5. Qué significa esto para los desarrolladores

El artículo concluye que la complejidad no es la causa del hackeo (como un virus), sino que es una señal de advertencia muy ruidosa.

La analogía: Si ves una casa con un lío de cables enredados, tuberías expuestas y un plano de planta confuso, no sabes con certeza que se va a incendiar, pero sabes que es mucho más probable que ocurra que en una casa con un cableado ordenado y organizado.
El consejo: Los desarrolladores deberían intentar mantener su código simple. Si un contrato se está volviendo demasiado complicado, es una señal para detenerse y buscar agujeros de seguridad. Además, escriban más comentarios; los datos sugieren que el código bien documentado es más seguro.

Resumen

El artículo demuestra que la complejidad es un fuerte indicador de riesgo en los contratos inteligentes. No puedes confiar en un solo número para predecir un hackeo, pero si miras el "desorden" general del código, puedes detectar los contratos peligrosos mucho mejor que si ignoraras la complejidad por completo. Es una herramienta para ayudar a los auditores y desarrolladores a priorizar qué contratos necesitan una inspección más cuidadosa.

Resumen Técnico: Evaluación de la Vulnerabilidad en Contratos Inteligentes mediante Métricas de Complejidad de Código

Planteamiento del Problema
Los contratos inteligentes desplegados en plataformas blockchain como Ethereum son inmutables y a menudo gestionan transacciones financieras de alto valor, lo que hace que el aseguramiento de la seguridad sea crítico. Si bien la blockchain subyacente es segura, los contratos inteligentes en sí mismos son vulnerables a exploits derivados de la negligencia del programador o errores de codificación. Las herramientas de análisis estático tradicionales suelen depender del reconocimiento de patrones para detectar tipos específicos de vulnerabilidades. Sin embargo, existe la necesidad de comprender si las propiedades estructurales del código, específicamente la complejidad del software, pueden servir como indicadores complementarios para identificar áreas vulnerables. Los autores postulan que el código que difiere de las mejores prácticas establecidas (es decir, mayor complejidad) puede exhibir una mayor exposición a defectos de seguridad, aunque la relación específica entre las métricas de complejidad y las vulnerabilidades de los contratos inteligentes en Solidity sigue siendo un problema abierto que requiere validación empírica.

Metodología
El estudio emplea un enfoque cuantitativo y empírico para analizar la relación entre 21 métricas distintas de complejidad de software y la presencia de vulnerabilidades en contratos inteligentes de Solidity.

Conjunto de Datos: La investigación utiliza un conjunto de datos derivado de Liu et al., que consiste en 16,239 contratos individuales (258 vulnerables, 15,981 neutrales) extraídos de Etherscan. Los contratos vulnerables fueron etiquetados basándose en ocho tipos específicos de vulnerabilidad: Desbordamiento/Subdesbordamiento de Enteros (Integer Underflow/Overflow), Igualdad Estricta de Ether Peligrosa (Dangerous Ether Strict Equality), Reentrada (Reentrancy), Dependencia de Marca de Tiempo (Timestamp Dependency), Dependencia de Número de Bloque (Block Number Dependency), Delegatecall Peligroso (Dangerous Delegatecall), Ether Congelado (Ether Frozen) y Llamada Externa no Verificada (Unchecked External Call).
Extracción de Métricas: Se utilizó la herramienta de análisis estático Solmet para extraer 21 métricas de complejidad para cada contrato. Estas incluyen métricas de tamaño (SLOC, LLOC, CLOC), métricas estructurales (NF, WMC, NOS), métricas de anidamiento (NL, NLE), métricas de herencia (DIT, NOA, NOD), métricas de acoplamiento (CBO, NOI, NA) y versiones promedio de estas métricas.
Análisis Estadístico:
- Análisis de Correlación: Se utilizó el coeficiente de correlación de rango de Spearman para evaluar las relaciones monotónicas e identificar redundancias entre las métricas mismas.
- Comparación de Grupos: Se empleó la prueba U de Mann-Whitney para determinar si la distribución de los valores de las métricas difería significamente entre los contratos vulnerables y los neutrales.
- Tamaño del Efecto: Se calculó el Delta de Cliff ( $\delta$ ) para cuantificar la magnitud de la diferencia entre los dos grupos.
- Intervalos de Confianza: Se utilizaron para comparar la tendencia central (medias) de las métricas entre los grupos vulnerable y neutral.

Contribuciones Clave
El artículo aborda cuatro preguntas de investigación (RQ) específicas para evaluar la utilidad de las métricas de complejidad:

RQ1 (Interdependencia de Métricas): El estudio identifica una redundancia significativa entre ciertas métricas. Por ejemplo, SLOC está fuertemente correlacionado con NOI, NOS, WMC y NF. Del mismo modo, las métricas de anidamiento (NL, NLE) y sus promedios muestran una alta correlación, lo que sugiere que no todas las 21 métricas proporcionan información única para la detección de vulnerabilidades.
RQ2 (Correlación Métrica-Vulnerabilidad): El análisis revela que, si bien las 21 métricas muestran una correlación estadísticamente significativa ( $p < 0.05$ ) con la presencia de vulnerabilidades, la fuerza de estas correlaciones es generalmente débil (coeficientes mayoritariamente por debajo de 0.3). Esto contrasta con los hallazgos en lenguajes de programación tradicionales donde las correlaciones suelen ser más fuertes. En consecuencia, ninguna métrica actúa como un predictor fuerte por sí sola.
RQ3 (Poder Discriminativo): A pesar de las débiles correlaciones individuales, la prueba U de Mann-Whitney confirma que todas las métricas pueden distinguir estadísticamente entre códigos vulnerables y neutrales ( $p < 0.05$ ). La mayoría de las métricas exhiben un gran tamaño de efecto (por ejemplo, SLOC, LLOC, NF, WMC, NL, NOS, CBO, NA, NOI), lo que indica que las distribuciones de estas métricas son prácticamente diferentes entre los dos grupos.
RQ4 (Direccionalidad de la Diferencia): El estudio encuentra que los contratos vulnerables generalmente exhiben puntuaciones de complejidad media más altas que los contratos neutrales para la mayoría de las métricas. Sin embargo, existen tres excepciones notables donde los contratos vulnerables tienen valores menores:
- CLOC (Líneas de Comentarios): Los contratos neutrales tienen más comentarios, lo que sugiere que la documentación puede mitigar la vulnerabilidad.
- NOD (Número de Descendientes): Los contratos vulnerables tienen menos descendientes.
- Avg. NUMPAR (Promedio de Parámetros): Los contratos vulnerables tienen menos parámetros en promedio.

Resultados y Significado
El artículo concluye que las métricas de complejidad son indicadores más que causas directas de la vulnerabilidad. La principal significancia de los hallazgos reside en los siguientes puntos:

Utilidad Colectiva: Aunque las métricas individuales tienen un poder predictivo débil, el estudio demuestra que, cuando se analizan colectivamente, las métricas de complejidad poseen capacidades discriminativas fuertes. Esto respalda su uso como características complementarias en herramientas de detección de vulnerabilidades automatizadas.
Gestión de Redundancia: La identificación de métricas altamente correlacionadas (por ejemplo, SLOC vs. WMC vs. NF) sugiere que los modelos de predicción de vulnerabilidades pueden optimizarse seleccionando un subconjunto de características no redundantes, mejorando la eficiencia sin sacrificar la precisión.
Matiz Contextual: Los hallazgos resaltan características únicas de Solidity en comparación con el software tradicional. Por ejemplo, la relación inversa con la densidad de comentarios (CLOC) sugiere que, en el contexto de los contratos inteligentes, la falta de documentación es un marcador específico de riesgo.
Aplicación Práctica: Los autores proponen que estas métricas pueden integrarse en las herramientas de análisis estático existentes para priorizar los esfuerzos de auditoría. Los contratos con puntuaciones de complejidad altas pueden ser señalados para una revisión manual más profunda, y los desarrolladores pueden utilizar estos conocimientos para adherirse a las mejores prácticas, tales como minimizar el anidamiento, reducir el acoplamiento y asegurar una documentación adecuada.

Los autores mantienen una postura modesta, enfatizando que las relaciones observadas son asociaciones estadísticas. Reconocen que la alta complejidad a menudo se correlaciona con un "dominio del problema" más grande (por ejemplo, los protocolos DeFi complejos requieren naturalmente más código), lo que puede ser el motor subyacente para el aumento del riesgo de vulnerabilidad, en lugar de que las métricas de complejidad sean el único mecanismo causal. Se sugiere que el trabajo futuro incluya la estratificación específica del dominio y la exploración de métricas de complejidad cognitiva.