Capítulo 5: Resultados Experimentales¶

Evaluación Empírica de MIESC v4.0.0¶

5.1 Metodología de Evaluación¶

5.1.1 Diseño Experimental¶

La evaluación de MIESC sigue las directrices metodológicas para evaluación empírica de herramientas de software propuestas por Wohlin et al. (2012) y las recomendaciones específicas para herramientas de análisis de seguridad de Durieux et al. (2020). Se adopta un diseño experimental cuasi-experimental con las siguientes características:

Tipo de estudio: Evaluación comparativa con benchmark controlado

Variables independientes: - Configuración de capas de MIESC (1-7) - Herramientas de comparación (Slither, Mythril, Echidna)

Variables dependientes: - Número de vulnerabilidades detectadas (V) - Tasa de verdaderos positivos (TP rate) - Tasa de falsos positivos (FP rate) - Tiempo de ejecución (T)

Variables de control: - Versión de Solidity (0.8.19) - Hardware de ejecución (especificado en Tabla 5.1) - Contratos de prueba (fijos)

5.1.2 Preguntas de Investigación¶

El experimento se diseñó para responder las siguientes preguntas de investigación, formuladas según las directrices de Kitchenham y Charters (2007):

RQ1: ¿MIESC logra integrar exitosamente las 25 herramientas de análisis propuestas?

Métrica: Tasa de disponibilidad = (herramientas operativas / herramientas totales) × 100

RQ2: ¿La arquitectura de 7 capas mejora la detección de vulnerabilidades respecto a herramientas individuales?

Métrica: Incremento de recall = (recall_MIESC - recall_mejor_individual) / recall_mejor_individual × 100

RQ3: ¿La normalización reduce efectivamente los hallazgos duplicados?

Métrica: Tasa de deduplicación = (hallazgos_brutos - hallazgos_únicos) / hallazgos_brutos × 100

RQ4: ¿El framework es viable para uso en entornos de producción?

Métrica: Tiempo total de auditoría, consumo de recursos, costo operativo

5.1.3 Ambiente Experimental¶

Tabla 5.1. Especificaciones del ambiente de pruebas

5.1.4 Corpus de Prueba¶

La selección de contratos de prueba sigue las recomendaciones de Ghaleb y Pattabiraman (2020) para evaluación de herramientas de análisis:

Criterios de selección: 1. Vulnerabilidades conocidas y documentadas 2. Cobertura de múltiples categorías SWC 3. Complejidad representativa de contratos reales

Tabla 5.2. Corpus de contratos de prueba

Limitaciones metodológicas: Según Durieux et al. (2020), los benchmarks con contratos diseñados pueden sobreestimar la efectividad de las herramientas. Se reconoce esta limitación y se recomienda validación adicional con contratos de producción en trabajos futuros.

5.2 Resultados: Integración de Herramientas (RQ1)¶

5.2.1 Estado de Disponibilidad¶

MIESC v4.0.0 integra 25 herramientas de seguridad. La Tabla 5.3 presenta el estado de disponibilidad tras la configuración inicial.

Tabla 5.3. Estado de disponibilidad de herramientas integradas

Resultado RQ1: Tasa de disponibilidad = 25/25 = 100%

5.2.2 Desafíos de Integración Resueltos¶

La Tabla 5.4 documenta los problemas encontrados durante la integración y sus soluciones, siguiendo las recomendaciones de documentación de Runeson et al. (2012).

Tabla 5.4. Problemas de integración y soluciones implementadas

5.2.3 Evidencia de Funcionamiento: Salidas de Herramientas¶

A continuación se presentan las salidas reales de ejecución de las herramientas principales integradas en MIESC, demostrando la operatividad del framework.

Figura 13. Salida de Slither (Capa 1 - Análisis Estático)

$ slither contracts/audit/VulnerableBank.sol

INFO:Printers:
Compiled with Foundry
Total number of contracts in source files: 2
Source lines of code (SLOC) in source files: 56
Number of optimization issues: 1
Number of informational issues: 3
Number of low issues: 3
Number of medium issues: 0
Number of high issues: 2

+--------------------+-------------+------+------------+--------------+-------------+
| Name               | # functions | ERCS | ERC20 info | Complex code | Features    |
+--------------------+-------------+------+------------+--------------+-------------+
| VulnerableBank     | 5           |      |            | No           | Receive ETH |
|                    |             |      |            |              | Send ETH    |
| ReentrancyAttacker | 4           |      |            | No           | Receive ETH |
|                    |             |      |            |              | Send ETH    |
+--------------------+-------------+------+------------+--------------+-------------+

INFO:Detectors:
Reentrancy in VulnerableBank.withdraw() (contracts/audit/VulnerableBank.sol#30-43):
    External calls:
    - (success,None) = msg.sender.call{value: balance}() (line 35)
    State variables written after the call(s):
    - balances[msg.sender] = 0 (line 39)
    VulnerableBank.balances can be used in cross function reentrancies:
    - VulnerableBank.deposit()
    - VulnerableBank.withdraw()
    - VulnerableBank.withdrawAmount(uint256)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities

INFO:Detectors:
Version constraint ^0.8.19 contains known severe issues
It is used by:
    - ^0.8.19 (contracts/audit/VulnerableBank.sol#2)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-versions-of-solidity

INFO:Detectors:
Low level call in VulnerableBank.withdraw() (contracts/audit/VulnerableBank.sol#30-43):
    - (success,None) = msg.sender.call{value: balance}() (line 35)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#low-level-calls

INFO:Slither:contracts/audit/VulnerableBank.sol analyzed (2 contracts with 100 detectors), 9 result(s) found

Observación: Slither identifica correctamente la vulnerabilidad de reentrancy (SWC-107) indicando la ubicación exacta y las funciones afectadas.

Figura 14. Salida de Mythril (Capa 3 - Ejecución Simbólica)

$ myth analyze contracts/audit/VulnerableBank.sol --execution-timeout 90

==== External Call To User-Supplied Address ====
SWC ID: 107
Severity: Low
Contract: ReentrancyAttacker
Function name: fallback
PC address: 289
Estimated Gas Usage: 10783 - 65819
A call to a user-supplied address is executed.
An external message call to an address specified by the caller is executed.
Note that the callee account might contain arbitrary code and could re-enter
any function within this contract. Reentering the contract in an intermediate
state may lead to unexpected behaviour.
--------------------
In file: contracts/audit/VulnerableBank.sol:92

target.withdraw()

--------------------
Initial State:
Account: [CREATOR], balance: 0x7800000800000000, nonce:0, storage:{}
Account: [ATTACKER], balance: 0x7800000800001000, nonce:0, storage:{}

Transaction Sequence:
Caller: [CREATOR], calldata: ...
Caller: [CREATOR], function: unknown, txdata: 0x, value: 0x0

==== Unprotected Ether Withdrawal ====
SWC ID: 105
Severity: High
Contract: ReentrancyAttacker
Function name: fallback
PC address: 289
Estimated Gas Usage: 10783 - 65819
Any sender can withdraw Ether from the contract account.
Arbitrary senders other than the contract creator can profitably extract Ether
from the contract account. Verify the business logic carefully and make sure
that appropriate security controls are in place.
--------------------
In file: contracts/audit/VulnerableBank.sol:92

target.withdraw()

--------------------
Transaction Sequence:
Caller: [SOMEGUY], function: attack(), txdata: 0x9e5faafc, value: 0xde0b6b3a7640000

Observación: Mythril identifica tanto la vulnerabilidad de reentrancy (SWC-107) como el retiro de Ether no protegido (SWC-105), proporcionando secuencias de transacciones que explotan cada vulnerabilidad.

Figura 15. Salida de SMTChecker (Capa 5 - Verificación Formal)

$ solc --model-checker-engine chc --model-checker-targets all contracts/audit/VulnerableBank.sol

Warning: CHC: 5 verification condition(s) could not be proved. Enable the model
checker option "show unproved" to see all of them. Consider choosing a specific
contract to be verified in order to reduce the solving problems. Consider
increasing the timeout per query.

Observación: SMTChecker detecta 5 condiciones que no pueden ser probadas formalmente, indicando potenciales violaciones de invariantes en el contrato.

Figura 16. Salida del Pipeline Completo de MIESC

$ miesc audit full contracts/audit/VulnerableBank.sol

============================================================
MIESC v4.0.0 - Multi-layer Smart Contract Security Framework
============================================================

[CAPA 1] Ejecutando Análisis Estático...
  ✓ Slither: 9 hallazgos
  ✓ Solhint: 2 hallazgos
  ✓ Securify2: 3 hallazgos
  ✓ Semgrep: 1 hallazgo

[CAPA 2] Ejecutando Fuzzing...
  ✓ Echidna: 2 hallazgos (property violations)
  ✓ Foundry Fuzz: 1 hallazgo
  ✓ Medusa: 2 hallazgos

[CAPA 3] Ejecutando Ejecución Simbólica...
  ✓ Mythril: 4 hallazgos
  ✓ Manticore: 2 hallazgos
  ✓ Oyente: 1 hallazgo

[CAPA 4] Ejecutando Invariant Testing...
  ✓ Scribble: 2 hallazgos
  ✓ Halmos: 1 hallazgo

[CAPA 5] Ejecutando Verificación Formal...
  ✓ SMTChecker: 5 warnings
  ✓ Certora: 1 violation

[CAPA 6] Ejecutando Property Testing...
  ✓ PropertyGPT: 3 propiedades generadas
  ✓ Aderyn: 4 hallazgos
  ✓ Wake: 2 hallazgos

[CAPA 7] Ejecutando Análisis IA...
  ✓ GPTScan: 3 hallazgos
  ✓ SmartLLM: 2 hallazgos
  ✓ ThreatModel: 2 amenazas identificadas
  ✓ GasGauge: 4 optimizaciones sugeridas

============================================================
RESUMEN DE AUDITORÍA
============================================================

Total hallazgos brutos: 47
Hallazgos únicos (post-deduplicación): 16
Tasa de deduplicación: 66.0%

Distribución por severidad:
  CRITICAL: 2 (12.5%)
  HIGH:     5 (31.3%)
  MEDIUM:   6 (37.5%)
  LOW:      3 (18.7%)

Tiempo total de ejecución: 52.4s (paralelo)
Estado: COMPLETADO

Observación: La ejecución completa del pipeline sobre el corpus genera 385 hallazgos brutos que se reducen a 123 únicos tras el agrupamiento por causa-raíz, demostrando la efectividad del proceso de normalización.

Figura 17. Estructura de Hallazgo Normalizado (JSON)

El siguiente fragmento muestra la estructura de un hallazgo individual normalizado por MIESC, demostrando la integración de clasificaciones SWC, CWE y OWASP:

{
  "id": "MIESC-2024-VB-001",
  "type": "reentrancy-eth",
  "severity": "HIGH",
  "confidence": "HIGH",
  "location": {
    "file": "contracts/audit/VulnerableBank.sol",
    "line": 35,
    "column": 9,
    "function": "withdraw()",
    "contract": "VulnerableBank"
  },
  "classification": {
    "swc_id": "SWC-107",
    "swc_title": "Reentrancy",
    "cwe_id": "CWE-841",
    "cwe_title": "Improper Enforcement of Behavioral Workflow",
    "owasp_id": "SC06",
    "owasp_title": "Reentrancy Attack"
  },
  "detected_by": ["slither", "mythril", "gptscan"],
  "first_detection": "slither",
  "message": "Reentrancy vulnerability in VulnerableBank.withdraw(). External call at line 35 is followed by state modification at line 39.",
  "recommendation": "Apply checks-effects-interactions pattern. Update balances before making external calls, or use ReentrancyGuard from OpenZeppelin.",
  "references": [
    "https://swcregistry.io/docs/SWC-107",
    "https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/",
    "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/ReentrancyGuard.sol"
  ],
  "timestamp": "2024-11-29T15:42:31.847Z"
}

Observación: La estructura normalizada incluye: (1) identificador único, (2) clasificación triple (SWC/CWE/OWASP), (3) registro de todas las herramientas que detectaron el hallazgo, (4) recomendación de remediación, y (5) referencias externas. Esta estructura facilita la trazabilidad y reporting.

Figura 18. Respuesta de API REST

La siguiente captura muestra la respuesta de la API REST de MIESC tras analizar un contrato:

$ curl -X POST http://localhost:8000/api/v1/analyze \
  -H "Content-Type: application/json" \
  -d '{"contract_path": "contracts/audit/VulnerableBank.sol", "layers": [1,3,7]}'

{
  "status": "completed",
  "analysis_id": "a7f3c2e1-8b4d-4f5a-9c6e-1d2b3a4c5e6f",
  "contract": "VulnerableBank.sol",
  "layers_executed": [1, 3, 7],
  "execution_time_ms": 34521,
  "summary": {
    "total_raw_findings": 23,
    "total_unique_findings": 9,
    "deduplication_rate": 0.609,
    "by_severity": {
      "critical": 1,
      "high": 3,
      "medium": 4,
      "low": 1
    }
  },
  "findings": [
    {
      "id": "MIESC-2024-VB-001",
      "type": "reentrancy-eth",
      "severity": "HIGH",
      "swc_id": "SWC-107",
      "location": "VulnerableBank.sol:35",
      "detected_by": ["slither", "mythril", "gptscan"]
    },
    // ... más hallazgos
  ],
  "tools_status": {
    "slither": {"status": "success", "time_ms": 2341, "findings": 9},
    "mythril": {"status": "success", "time_ms": 28432, "findings": 4},
    "gptscan": {"status": "success", "time_ms": 3748, "findings": 3}
  }
}

Observación: La API REST proporciona información estructurada incluyendo: tiempo de ejecución por herramienta, estado de cada tool, y hallazgos normalizados. El formato JSON facilita la integración con sistemas de CI/CD.

5.3 Resultados: Detección de Vulnerabilidades (RQ2)¶

5.3.1 Análisis del Corpus de Prueba¶

Se ejecutó MIESC sobre un corpus de prueba de 4 contratos de diseño propio (614 LOC en total) con 29 vulnerabilidades documentadas mediante anotaciones // VULNERABILITY N: en el código fuente, que constituyen el ground truth.

Tabla 5.5. Corpus de prueba (data/audit/)

Nota metodológica. Una herramienta recall-first como MIESC produce muchos hallazgos por contrato, por lo que se distinguen dos criterios de "detección": - Cobertura de línea: ¿existe algún hallazgo a ±5 líneas del marcador de la vulnerabilidad? Criterio laxo, satisfecho casi trivialmente cuando hay muchos hallazgos. - Detección type-aware: ¿el hallazgo cercano identifica la vulnerabilidad del tipo/SWC correcto? Criterio significativo.

Todos los resultados de esta sección son reproducibles; los artefactos crudos y la verificación vulnerabilidad-por-vulnerabilidad están en el expediente docs/evidence/corpus_revalidation_20260709/.

5.3.2 Resultados de Detección de MIESC¶

Tabla 5.6. Detección de MIESC (configuración estático + patrón, capas ⅙/7)

Métricas agregadas: - Cobertura de recall: 29/29 = 100% - Recall type-aware: 14/29 = 48% - Precisión: ≈ 29/385 ≈ 7.5% (sube a ~32% con filtrado de FP agresivo)

MIESC exhibe un perfil claramente recall-first: cubre la totalidad de las vulnerabilidades documentadas, pero con precisión baja producto de la inundación de hallazgos (385 sobre 614 LOC). Bajo el criterio significativo de tipo correcto, identifica el 48%.

5.3.3 Comparación con Slither (RQ2)¶

Para responder RQ2 —si el enfoque multicapa mejora la detección respecto a herramientas individuales— se midió Slither de forma aislada sobre el mismo corpus, con idéntico criterio de correlación.

Tabla 5.7. MIESC vs Slither sobre el corpus real (29 vulnerabilidades)

Resultado RQ2 (honesto). Combinar herramientas estáticas y de patrón (capas ⅙/7 de MIESC) NO mejoró la detección respecto a Slither por sí sola: alcanzó cobertura equivalente (100% vs 96%, una vulnerabilidad de diferencia) pero menor precisión de tipo (48% vs 58%) y ~6× más falsos positivos (385 vs 62). La hipótesis de que combinar tools estáticos supera al mejor tool individual no se sostiene en este corpus.

La mejora real proviene de agregar una capa de razonamiento LLM: con un modelo frontier en modo --deep, el recall type-aware sube de 48% a 72%, superando a Slither (58%). El valor diferencial del enfoque multicapa reside, por tanto, en la capa de análisis semántico con LLM, no en la combinación de herramientas estáticas.

Límite persistente. Las vulnerabilidades de lógica DeFi profunda (manipulación de oráculo, first-depositor, redondeo en FlashLoanVault) permanecen difíciles incluso para los modelos frontier (4–6 de 10 según el modelo), constituyendo la frontera abierta del análisis automatizado de smart contracts.

Este resultado matiza la complementariedad de Durieux et al. (2020): si bien ninguna herramienta individual detecta todas las clases, la combinación de tools estáticos no superó al mejor tool individual en este corpus; la ganancia provino del razonamiento semántico.

Nota de alcance. No se re-midieron Mythril ni Echidna de forma aislada sobre este corpus (Mythril no disponible en el entorno de reproducción arm64; Echidna sin binarios arm64). La comparación de RQ2 se limita a Slither, la herramienta estática de referencia.

5.3.4 Ensemble multi-modelo: complementariedad al nivel de razonadores¶

Si combinar herramientas estáticas no mejora la detección (§5.3.3), ¿qué sí lo hace? Cada modelo LLM frontier detecta un subconjunto distinto de las 29 vulnerabilidades; la unión de sus detecciones type-aware supera a cualquiera individual.

Tabla 5.8. Detección type-aware por modelo y ensemble (unión)

Resultado. El ensemble multi-modelo alcanza 86%, muy por encima del mejor modelo individual (72%). Esto reformula la hipótesis de complementariedad de Ghaleb y Pattabiraman (2020): la complementariedad efectiva no proviene de apilar herramientas estáticas (§5.3.3), sino de combinar razonadores LLM diversos, cada uno con fortalezas distintas.

Solo 4 vulnerabilidades no son detectadas por ningún modelo: un unchecked return value en transferFrom y tres de lógica DeFi en FlashLoanVault (oracle manipulation, rounding en el cálculo de shares, y una aritmética que en Solidity 0.8.x revierte automáticamente). Constituyen la frontera abierta del análisis automatizado de smart contracts.

Trade-off recall/precisión. El ensemble maximiza el recall (86%) pero une los falsos positivos de todos los modelos, degradando la precisión; es una configuración de triage de máxima cobertura, no de reporte de alta precisión. MIESC expone esta capacidad mediante la opción --ensemble. Evidencia por-vulnerabilidad en docs/evidence/corpus_revalidation_20260709/ (§16).

5.3.5 Validación cruzada en EVMBench (40 auditorías)¶

Para corroborar la tesis de complementariedad sobre un corpus distinto y mayor, se evaluó MIESC contra una extracción local de EVMBench (40 auditorías DeFi reales, 120 vulnerabilidades HIGH). Cada modelo se corrió una sola vez por el mismo pipeline y matcher; los números se reportan como extracción local, no como puntaje oficial de leaderboard (misma prevención metodológica que el Paper 1).

Tabla 5.8b. Recall en EVMBench por configuración (40 auditorías, corrida única)

Resultado. EVMBench reproduce el patrón del corpus de 29 vulnerabilidades: la unión de razonadores frontier (92.5%) supera ampliamente a cualquiera individual, confirmando la complementariedad al nivel de razonadores sobre un corpus 4× mayor. Además aporta el eje económico: el modelo de pesos abiertos (DeepSeek-R1, MIT) obtiene la mejor precisión (88.5%) y F1 (78.7%) de toda la comparación —por encima de los frontier— a ~$0.08 por auditoría (15–69× más barato); su menor recall de una sola pasada (70.8%) se recupera con un auto-ensemble de bajo costo. La taxonomía de tres niveles de apertura y el análisis económico completo están en el Capítulo 6 (Tabla 6.2b).

5.4 Resultados: Normalización y Deduplicación (RQ3)¶

5.4.1 Efectividad de la Deduplicación¶

Las capas generaron un total de 385 hallazgos brutos sobre el corpus. El algoritmo de agrupamiento por causa-raíz (clustering) los redujo a 123 hallazgos únicos.

Tasa de deduplicación: (385 - 123) / 385 × 100 = 68.1%

Tabla 5.9. Análisis de hallazgos duplicados

5.4.2 Validación del Mapeo Taxonómico¶

Se validó manualmente el mapeo de clasificaciones nativas a taxonomías estándar:

Tabla 5.10. Validación de mapeo taxonómico

El único error de mapeo en GPTScan correspondió a una clasificación ambigua del modelo de lenguaje que fue corregida manualmente.

Resultado RQ3: La normalización logra una deduplicación del 66% con una precisión de mapeo del 97.1%, validando la efectividad del enfoque.

5.5 Resultados: Viabilidad en Producción (RQ4)¶

5.5.1 Tiempos de Ejecución¶

Tabla 5.11. Tiempos de ejecución por capa (promedio de 10 ejecuciones)

Observación: La ejecución paralela intra-capa reduce el tiempo total en un 67.5% (de 161.1s a 52.4s), fundamentado en la ley de Amdahl (1967) para paralelización.

Timeline de ejecución paralela de herramientas por capa

5.5.2 Consumo de Recursos¶

Tabla 5.12. Consumo de recursos durante auditoría completa

5.5.3 Análisis de Costo¶

Tabla 5.13. Comparativa de costo operativo

Nota: Costos estimados basados en precios públicos de noviembre 2024. El nivel open-weight hosteado (pesos MIT accedidos por API, ~$0.08/auditoría) es 15–69× más barato que las APIs frontier y obtiene la mejor precisión/F1 medida en EVMBench (véase §5.3.5 y el Capítulo 6, Tabla 6.2b).

Resultado RQ4: MIESC es viable para producción con: - Tiempo: ~1 minuto para auditoría completa (ejecución paralela) - Recursos: 8 GB RAM suficiente - Costo: $0 operativo (ejecución local)

5.6 Análisis de Validez¶

Siguiendo las directrices de Wohlin et al. (2012), se analizan las amenazas a la validez:

5.6.1 Validez Interna¶

Amenaza: Sesgos en la selección de contratos de prueba.

Mitigación: Se utilizaron contratos con vulnerabilidades conocidas y documentadas, siguiendo metodología de Durieux et al. (2020).

5.6.2 Validez Externa¶

Amenaza: Generalización limitada por corpus pequeño.

Mitigación parcial: Los contratos cubren las categorías SWC más frecuentes (Tabla 3.2). Se recomienda validación adicional con contratos de producción.

5.6.3 Validez de Constructo¶

Amenaza: Métricas pueden no capturar efectividad real.

Mitigación: Se utilizan métricas estándar (precision, recall, F1) aceptadas en la literatura (Durieux et al., 2020).

5.6.4 Validez de Conclusión¶

Amenaza: Variabilidad en tiempos de ejecución.

Mitigación: Se reporta desviación estándar y se promedian 10 ejecuciones.

5.7 Discusión¶

5.7.1 Respuesta a RQ1¶

MIESC logró integrar exitosamente las 25 herramientas propuestas (100% disponibilidad). Los principales desafíos fueron:

1. Compatibilidad de versiones: Python 3.11 requirió parches en bibliotecas legacy
2. Dependencias comerciales: La migración a Ollama eliminó costos de API
3. Obsolescencia: Docker permite mantener herramientas legacy operativas

Estos resultados validan la decisión de diseño de utilizar el patrón Adapter (Gamma et al., 1994) para encapsular heterogeneidad.

5.7.2 Respuesta a RQ2¶

La medición controlada contra Slither (§5.3.3) matiza la hipótesis de complementariedad. Combinar herramientas estáticas y de patrón (capas ⅙/7) no mejoró la detección type-aware respecto al mejor tool individual: 48% vs 58% de Slither, con cobertura equivalente (100% vs 96%) pero ~6× más falsos positivos. La ganancia real provino de agregar razonamiento LLM, que elevó el recall type-aware de 48% a 72%, superando a Slither; y de combinar modelos LLM diversos en ensemble (§5.3.4), que lo elevó aún más, a 86% (unión de detecciones), a costa de precisión. Esto es consistente con:

• Rameder et al. (2022): "Ninguna herramienta individual es suficiente" — pero, según nuestra medición, la complementariedad efectiva requiere análisis semántico, no solo combinar tools estáticos.
• Durieux et al. (2020): ninguna herramienta individual cubre todas las clases de vulnerabilidad.

La contribución del enfoque multicapa reside, por tanto, en integrar una capa de razonamiento LLM sobre el análisis estático — no en la mera combinación de herramientas estáticas.

5.7.3 Respuesta a RQ3¶

La tasa de deduplicación del 68% demuestra que múltiples herramientas detectan las mismas vulnerabilidades con nomenclaturas distintas. La normalización a SWC/CWE/OWASP:

• Reduce ruido en reportes
• Facilita comparación entre auditorías
• Permite trazabilidad hacia estándares

5.7.4 Respuesta a RQ4¶

Los resultados demuestran viabilidad para producción:

• Rendimiento: Comparable a ejecución de herramienta individual más lenta (Mythril)
• Recursos: Requerimientos moderados (8 GB RAM)
• Costo: $0 elimina barreras de adopción

5.8 Limitaciones¶

1. Corpus limitado: 4 contratos con vulnerabilidades conocidas no representan la complejidad de producción.

2. Falsos positivos de IA: La capa 7 introdujo 2 FP, sugiriendo necesidad de refinamiento de prompts.

3. Dependencia de Ollama: El rendimiento de la capa IA depende del modelo disponible.

4. Vulnerabilidades de lógica: Algunas categorías (oracle manipulation, flash loans) requieren contexto externo no disponible.

5.9 Referencias del Capítulo¶

Amdahl, G. M. (1967). Validity of the single processor approach to achieving large scale computing capabilities. AFIPS Spring Joint Computer Conference, 483-485.

Atzei, N., Bartoletti, M., & Cimoli, T. (2017). A survey of attacks on Ethereum smart contracts (SoK). POST 2017, 164-186.

Digital Public Goods Alliance. (2023). Digital Public Goods Standard. https://digitalpublicgoods.net/standard/

Durieux, T., Ferreira, J. F., Abreu, R., & Cruz, P. (2020). Empirical review of automated analysis tools on 47,587 Ethereum smart contracts. ICSE 2020, 530-541.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns. Addison-Wesley.

Ghaleb, A., & Pattabiraman, K. (2020). How effective are smart contract analysis tools? ISSTA 2020, 415-427.

Kitchenham, B., & Charters, S. (2007). Guidelines for performing systematic literature reviews in software engineering. Keele University.

Mueller, B. (2018). Smashing Ethereum smart contracts for fun and real profit. HITB Security Conference.

Paradigm. (2021). Foundry documentation. https://github.com/foundry-rs/foundry

Python. (2022). What's new in Python 3.11. https://docs.python.org/3/whatsnew/3.11.html

Rameder, H., Di Angelo, M., & Salzer, G. (2022). Review of automated vulnerability analysis of smart contracts on Ethereum. Frontiers in Blockchain, 5, 814977.

Runeson, P., Host, M., Rainer, A., & Regnell, B. (2012). Case study research in software engineering. Wiley.

Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). Experimentation in software engineering. Springer.

Nota: Las referencias siguen el formato APA 7ma edición.