Por qué se auditan los contratos inteligentes
Casi todo el software se puede corregir después de encontrar un fallo. Un contrato inteligente en una cadena pública normalmente no. ethereum.org señala que el código de un contrato desplegado normalmente no se puede cambiar para parchear fallos de seguridad, y estima que el valor robado o perdido por defectos de seguridad en contratos inteligentes supera con holgura los 1.000 millones de dólares [1]. El código a menudo custodia dinero directamente, es público para que cualquiera lo estudie, y a un atacante le basta con encontrar un solo error.
Esa combinación es la razón por la que los contratos que custodian valor los revisan, antes de desplegarlos, especialistas ajenos al equipo que los escribió. La cuestión no es si hacer esa revisión, sino qué puede hacer por usted y qué no.
Lo que hace una auditoría
Una auditoría es una revisión con tiempo acotado de una versión concreta de sus contratos, a cargo de ingenieros de seguridad que no los escribieron. Un encargo típico es así.
- 01
Alcance
Los auditores acuerdan qué contratos, en qué commit, entran en el alcance, y leen su documentación sobre lo que debe hacer el sistema.
- 02
Revisión manual
Revisores con experiencia leen el código línea a línea, buscando tipos conocidos de vulnerabilidad (reentrada, errores de control de acceso, llamadas sin comprobar, errores aritméticos y de redondeo) y lógica que no coincide con la intención declarada.
- 03
Análisis automatizado
Analizadores estáticos, herramientas de fuzzing y a veces herramientas formales buscan patrones y casos límite que a una persona se le podrían escapar.
- 04
Informe
Los hallazgos se enumeran por gravedad, de crítico a informativo, cada uno con una explicación y una corrección recomendada.
- 05
Revisión de las correcciones
Su equipo corrige los hallazgos y los auditores comprueban las correcciones. El informe final indica qué hallazgos se resolvieron, se asumieron o quedaron abiertos.
Los fallos que más encuentran los auditores, en lenguaje llano
- Reentrada: el contrato envía fondos o llama a otro contrato antes de actualizar sus propios registros, y el otro contrato vuelve a llamar para llevarse los mismos fondos otra vez.
- Control de acceso: una función que debería estar reservada a un administrador la puede llamar cualquiera, o alguien puede hacerse con el rol de administrador.
- Manipulación de precios: el contrato lee un precio de una fuente que un atacante puede mover dentro de una misma transacción, como un fondo de liquidez con poca profundidad.
- Redondeo y precisión: pequeños errores en una división que un atacante repite miles de veces, o que permiten a un primer depositante distorsionar las participaciones de todos los que vienen después.
- Errores de actualización: un proxy que apunta al código equivocado, un almacenamiento que choca entre versiones o un inicializador al que cualquiera puede llamar.
- Lógica que hace lo que dice el código pero no lo que quería el negocio: una comisión cobrada dos veces, un plazo comprobado al revés.
Lo que no cubre una auditoría
ethereum.org lo dice sin rodeos: las auditorías no detectan todos los fallos, y están pensadas sobre todo como una ronda adicional de revisión [1]. Además, la mayoría de las auditorías se limitan al código del contrato. Muchas pérdidas vienen de otro sitio.
| Área | Por qué importa | Qué lo cubre en su lugar |
|---|---|---|
| Código cambiado después de la auditoría | El informe se aplica a un commit. Un cambio posterior, por pequeño que sea, no está auditado. | Una revisión de correcciones o una nueva auditoría por cada cambio en el código auditado |
| Claves privadas y cuentas de administración | Quien tiene la clave de actualización o de administración a menudo puede cambiar o vaciar el sistema. | Carteras multifirma, claves en hardware, bloqueos temporales y procedimientos escritos |
| La web y el backend | Una interfaz web comprometida puede pedir a los usuarios que firmen algo dañino. | Pruebas de seguridad de aplicaciones web y controles de la cadena de suministro de software |
| Oráculos y datos externos | Un contrato que confía en una fuente de precios solo es tan seguro como esa fuente. | Revisión del diseño: elección del oráculo, límites y alternativas de respaldo |
| Diseño económico | El código puede funcionar exactamente como está escrito y aun así ser explotable mediante incentivos o manipulación del mercado. | Revisión económica y de teoría de juegos, simulaciones |
| Despliegue y configuración | Unos argumentos de constructor o unas direcciones erróneos pueden echar por tierra una auditoría perfecta. | Despliegues automatizados y revisados, y verificación en la cadena |
Cómo leer un informe de auditoría
- 01
Compruebe el commit
El informe nombra la versión exacta revisada. Asegúrese de que coincide byte a byte con lo que desplegó, y de que los contratos desplegados están verificados en la cadena.
- 02
Lea el alcance y los supuestos
Qué contratos entraron, cuáles quedaron fuera y qué supusieron los auditores sobre los administradores, los oráculos y otros contratos.
- 03
Mire el estado de cada hallazgo
Resuelto, asumido o abierto. Un hallazgo crítico asumido es una decisión de negocio que alguien debería poder explicar.
- 04
Lea también las notas informativas
A menudo describen decisiones de diseño que a los auditores les parecieron arriesgadas pero no erróneas, algo útil para su próxima versión.
Cómo prepararse para que la auditoría valga la pena
El tiempo de los auditores es escaso y caro, así que cada hora que dedican a entender código confuso o a encontrar fallos que sus pruebas deberían haber detectado es una hora que no dedican a los problemas sutiles por los que les paga. La guía de preparación de OpenZeppelin expone lo que espera antes de una auditoría.
- Documentación que explique la intención, las decisiones de diseño y los supuestos, desde un README y unas notas de arquitectura hasta comentarios en cada función [2].
- Pruebas que cubran los casos límite y la integración con otros contratos, con el objetivo de al menos un 90% de cobertura de código, y fuzzing donde ayude [2].
- Código limpio y legible que siga un estilo coherente, use patrones consolidados como checks-effects-interactions e importe las dependencias mediante un gestor de paquetes en lugar de copiarlas [2].
- Código maduro: probado, documentado y listo para desplegar, no algo que sigue cambiando [2].
Nosotros añadimos dos hábitos propios. El código se congela en un commit etiquetado mientras dura la auditoría, y cada corrección posterior pasa por la misma revisión y el mismo conjunto de pruebas que el trabajo original antes de que la vean los auditores.
Listas de comprobación y estándares, y sus límites
Las listas de comprobación ayudan a que ambas partes estén de acuerdo en lo que se comprobó. También envejecen. El registro Smart Contract Weakness Classification, durante mucho tiempo una referencia común, indica que su contenido no se ha actualizado a fondo desde 2020 y puede estar incompleto, y remite en su lugar a la especificación EEA EthTrust Security Levels y al Smart Contract Security Verification Standard [3]. Pregunte a cualquier auditor con qué estándar comprueba, y tome con cautela una lista de hallazgos referida solo a un registro antiguo.
Ninguna lista sustituye a la comprensión. Las recomendaciones de Consensys Diligence parten de la premisa de que defenderse de las vulnerabilidades conocidas no basta, y de que el desarrollo de contratos necesita la disciplina de campos como los sistemas financieros: prepararse para el fallo y desplegar con cuidado [4].
Seguridad más allá de la auditoría
Una auditoría es una foto fija. El contrato funcionará durante años, el código que lo rodea cambiará y los atacantes seguirán estudiándolo. Las prácticas de abajo son las que mantienen seguro un sistema entre auditorías, y la mayoría cuestan poco comparado con lo que protegen.
- Pruebas basadas en propiedades y fuzzing que siguen ejecutándose a medida que cambia el código, junto a las pruebas unitarias [1].
- Verificación formal de los invariantes más críticos, cuando el coste está justificado [1].
- Un programa de recompensas por fallos después de la puesta en marcha, para que quien encuentre un problema cobre por comunicarlo en lugar de explotarlo [1].
- Un despliegue gradual: límites a los depósitos o a los usuarios al principio, que se elevan a medida que el sistema demuestra su solidez [4].
- Una pausa de emergencia y una vía de actualización, si el diseño lo permite, controladas por una cartera multifirma con bloqueo temporal para que los cambios sean visibles antes de surtir efecto.
- Monitorización de la actividad en la cadena y alertas ante transacciones inusuales, con un plan escrito de quién hace qué si algo sale mal.
Dos proyectos web3, con el precio de nuestra tarifa
Los ejemplos prácticos de abajo muestran la horquilla de nuestra tarifa de hoy, con las horas por perfil y el calendario de pagos. El desarrollo incluye nuestras propias pruebas y una revisión de seguridad interna. Una auditoría externa, cuando el contrato la justifica, la presupuesta la firma auditora y se factura por adelantado a coste, fuera de los hitos.
Ejemplo práctico, con precio de hoy
Un conjunto de contratos inteligentes
Contratos de token o de depósito en garantía con un rol de administrador, conjunto completo de pruebas, fuzzing y scripts de despliegue, listos para una auditoría externa.
- Desarrollo
- ≈ 20.700 US$ a 31.700 US$, delivered within 9 weeksCAD 29,500 to 45,100
Los precios en su moneda son estimaciones con el tipo de cambio de hoy del Banco de Canadá. Toda la facturación se emite en CAD o USD.
Esfuerzo estimado por perfil
- Développement
- 70 to 107 h
- Ingénieur chaîne de blocs
- 32 to 50 h
- Développeur frontal
- 19 to 29 h
- Ingénieur principal
- 16 to 25 h
- Ingénieur assurance qualité
- 15 to 23 h
- Gestionnaire de projet
- 14 to 22 h
- Développeur frontal principal
- 11 to 17 h
- Ingénieur
- 11 to 17 h
- Développeur dorsal principal
- 8 to 12 h
- Développeur frontal junior
- 8 to 11 h
- Développeur dorsal
- 7 to 11 h
- Architecte logiciel
- 4 to 7 h
- Développeur dorsal junior
- 4 to 5 h
- Ingénieur DevOps
- 3 to 5 h
- Rédacteur technique
- 3 to 4 h
- Concepteur de produits
- 2 to 3 h
- Concepteur de produits principal
- 1 to 2 h
Cómo se paga
- Anticipo 30%
- CAD 8,850 to 13,530
- Spécification 10%
- CAD 2,950 to 4,510
- Contrats et tests 30%
- CAD 8,850 to 13,530
- Déploiement sur réseau de test 10%
- CAD 2,950 to 4,510
- Réseau principal 10%
- CAD 2,950 to 4,510
- Holdback, 30 days after launch (10%)
- CAD 2,950 to 4,510
Ejemplo práctico, con precio de hoy
Una dApp con sus contratos
Contratos más una aplicación web con inicio de sesión con cartera, una parte de administración, notificaciones y analítica, con un diseño a medida y un plan de soporte.
- Desarrollo
- ≈ 68.400 US$ a 105.000 US$, delivered within 22 weeksCAD 97,400 to 149,000
Los precios en su moneda son estimaciones con el tipo de cambio de hoy del Banco de Canadá. Toda la facturación se emite en CAD o USD.
Esfuerzo estimado por perfil
- Développement
- 287 to 440 h
- Développeur frontal
- 58 to 89 h
- Gestionnaire de projet
- 50 to 76 h
- Ingénieur assurance qualité
- 50 to 76 h
- Ingénieur chaîne de blocs
- 47 to 71 h
- Concepteur de produits
- 46 to 70 h
- Développeur dorsal principal
- 41 to 62 h
- Développeur dorsal
- 40 to 61 h
- Ingénieur principal
- 37 to 57 h
- Développeur frontal principal
- 35 to 54 h
- Concepteur de produits principal
- 31 to 47 h
- Développeur frontal junior
- 23 to 36 h
- Architecte logiciel
- 21 to 32 h
- Développeur dorsal junior
- 20 to 31 h
- Ingénieur
- 16 to 24 h
- Ingénieur DevOps
- 12 to 18 h
- Rédacteur technique
- 9 to 13 h
Cómo se paga
- Anticipo 20%
- CAD 19,480 to 29,800
- Découverte 3.5%
- CAD 3,409 to 5,215
- Spécification 6.3%
- CAD 6,136.20 to 9,387.00
- Maquettes approuvées 3.5%
- CAD 3,409 to 5,215
- Fonctions principales 10.5%
- CAD 10,227 to 15,645
- Développement complet 7%
- CAD 6,818 to 10,430
- Contrats et tests 19.1%
- CAD 18,603.40 to 28,459.00
- Tests et corrections 3.5%
- CAD 3,409 to 5,215
- Déploiement sur réseau de test 6.3%
- CAD 6,136.20 to 9,387.00
- Mise en ligne 3.5%
- CAD 3,409 to 5,215
- Réseau principal 6.8%
- CAD 6,623.20 to 10,132.00
- Holdback, 30 days after launch (10%)
- CAD 9,740 to 14,900
Cómo elegir un auditor
- 01
Lea sus informes públicos
Las firmas serias publican informes anteriores. Busque hallazgos claros, gravedades sensatas y secciones de alcance honestas.
- 02
Pregunte quién hará el trabajo
Los nombres y la experiencia de los revisores de su encargo importan más que la marca.
- 03
Acuerde el alcance por escrito
Qué contratos, qué commit, qué supuestos y si incluye una revisión de las correcciones.
- 04
Ajuste el esfuerzo al riesgo
Un contrato que va a custodiar un valor importante puede justificar más de una auditoría independiente. Un contrato sencillo construido sobre bibliotecas auditadas puede necesitar menos.
- 05
Reserve con tiempo
Los buenos auditores tienen la agenda llena con semanas de antelación. Programe la auditoría cuando empiece a desarrollar, no cuando termine.
Desarrollamos y probamos contratos, los revisamos internamente, le ayudamos a elegir un auditor y a preparar su encargo, y corregimos los hallazgos. No auditamos nuestro propio trabajo para luego llamarlo independiente.