Auditoría de smart contracts

El precio y el plazo de una auditoría de smart contracts dependen sobre todo del código que entra en el alcance: cuántas líneas y contratos, cuánta lógica propia frente a librerías estándar y con qué sistemas se integra. Por eso el presupuesto se da después de ver el repositorio, no antes.

Qué hace subir el precio

• Tamaño del alcance. Las líneas de código propio y el número de contratos que se revisan.
• Complejidad. Un token estándar se revisa en menos tiempo que un contrato con restricciones de transferencia, oráculos, préstamos o contratos actualizables (proxies).
• Integraciones. Oráculos, puentes y contratos de terceros con los que interactúa el código.
• Valor en juego. Cuantos más fondos gestione el contrato, más escenarios de ataque hay que probar.
• Segunda ronda. La revisión de las correcciones es una ronda más y conviene presupuestarla desde el principio.

Qué alarga el plazo

El plazo lo marcan el tamaño del alcance y el estado en que llega el código: sin documentación, sin pruebas o con cambios a mitad de revisión, la auditoría se alarga. A la revisión inicial hay que sumar el tiempo que tu equipo tarda en corregir los hallazgos y la verificación de esas correcciones. Las partidas de referencia del desarrollo, con la auditoría como partida propia, están en cuánto cuesta desarrollar un smart contract.

Una auditoría de smart contracts no es más que una simple revisión, ya que se encarga de analizar de manera profunda todos los rincones del sistema en busca de vulnerabilidades y posibles riesgos.

En nuestro caso, probamos, cuestionamos y ponemos a prueba cada elemento, para cerciorarnos de que todo esté preparado para rendir de manera correcta. Y lo tenemos claro; después de pasar por nuestras manos, tendrás un mapa claro de los riesgos detectados y de cómo corregirlos. Porque ya sabes que para nosotros la seguridad no es solo un paso más, es la base sobre la que construimos cada uno de nuestros proyectos.

Una auditoría rinde más cuando el código llega preparado. Esta es la lista que revisamos contigo antes de empezar, basada en la guía de preparación de auditorías de Trail of Bits:

• Objetivo de la revisión. Qué te preocupa más: el robo de fondos, el bloqueo de activos o el abuso de los permisos de administración.
• Versión congelada. El commit exacto que se audita; lo que cambie después queda fuera del alcance.
• Avisos del compilador. Activados y resueltos.
• Pruebas. Pruebas unitarias y de funcionalidad al día, y que todas se ejecuten sin fallos.
• Código muerto fuera. Ramas, funciones y librerías que no se usan, retiradas antes de la revisión.
• Documentación. Qué hace el sistema, quién lo usa, qué roles tienen permisos y por qué se diseñó así, con comentarios en el código complejo.
• Entorno reproducible. Cómo compilar, probar y desplegar, con la versión de cada dependencia.
• Historial. Auditorías anteriores y fallos de seguridad conocidos.

Comenzamos con una detallada revisión de los contratos inteligentes, con el objetivo de percibir cualquier debilidad o fallo existente.

Analizamos cada función, interacción y cómo no, cada parte de la lógica del contrato para asegurarnos de que cumpla la función para la que fue desarrollado de manera óptima.

Para una mayor comprensión vamos a desglosar las técnicas, métodos y herramientas utilizados para la revisión de los contratos inteligentes.

1. Análisis estructural

Comenzamos con un detallado análisis en el que examinaremos minuciosamente los patrones de diseño, como la estructura de los smart contract, con la finalidad de que estén estructurados de manera correcta para que no provoquen errores futuros.

2. Análisis estático

En el caso de este paso, se hará uso de herramientas automatizadas para identificar vulnerabilidades en el código, evaluando su seguridad y eficiencia.

3. Revisión de código

Posteriormente, se continuará con un análisis manual del código, que nos será de ayuda para encontrar nuevas vulnerabilidades y verificar las anteriormente encontradas en el análisis estático. Además, nos aseguraremos de que la lógica del contrato coincida con la descrita en el documento técnico.

4. Consumo de gas

En esta última fase, evaluaremos el rendimiento de los contratos inteligentes en un entorno real, dándole prioridad a la cantidad de gas consumido y explorando formas de optimizar el código para un uso más eficiente del gas.

El informe recoge cada hallazgo con su severidad, dónde está en el código, qué impacto tendría y cómo corregirlo, junto con un resumen para quien decide, que no necesita leer el detalle técnico.

• Resumen ejecutivo. Estado general del código y hallazgos que impiden desplegar.
• Hallazgos por severidad. Cada uno con su ubicación, su impacto y la corrección recomendada.
• Optimización de gas. Cambios que reducen el coste de uso sin alterar la lógica.
• Estado de las correcciones. Tras la segunda ronda, qué hallazgos quedan corregidos y cuáles se aceptan como riesgo, con el motivo.

Alcance del informe

Todo informe deja constancia de qué se ha revisado: versión y commit exactos del código, contratos incluidos y dependencias externas o librerías de terceros excluidas del alcance. Los cambios posteriores a esa versión no quedan cubiertos y requieren una nueva revisión.

Un informe de auditoría no certifica que el código esté libre de errores: documenta lo que se encontró en esa versión con las técnicas aplicadas. En contratos que gestionan fondos, conviene completarlo con pruebas de invariantes y un programa de recompensas por fallos tras el despliegue.