¿Por qué la seguridad de los contratos inteligentes es diferente de la seguridad del software convencional?
La seguridad de los contratos inteligentes es diferente porque el código es público, a menudo gestiona dinero directamente y, por lo general, no puede modificarse una vez implementado. Un error en una aplicación web puede corregirse de un día para otro; cualquier persona que lea el código de un contrato puede detectar un error y aprovecharlo antes de que el equipo se despierte. Ethereum.org estima que las pérdidas por defectos en contratos inteligentes superan los mil millones de dólares y cita el ataque a DAO de 2016 como uno de los primeros ejemplos.
Imagine un estudio ficticio de cuatro personas, Larkspur Labs, que está creando un fondo de ahorro sencillo en el que los miembros depositan fondos y retiran su parte. El desarrollador, Kofi, deja notas de revisión antes del despliegue: 'withdraw envía fondos y después pone el saldo a 0. setFee es pública, restringiré el acceso después. uso una versión antigua del compilador del tutorial. el precio del token de recompensa se obtiene de un único fondo de liquidez pequeño. pruebas: probé depósito + retirada una vez a mano, funciona'. Cada línea corresponde a una clase de vulnerabilidad conocida.
¿Cuáles son las vulnerabilidades más comunes de los contratos inteligentes?
Las vulnerabilidades más comunes de los contratos inteligentes son los fallos de control de acceso, la manipulación de oráculos de precios, los errores de lógica, la falta de validación de entradas y la reentrada, que encabezan la lista de las 10 principales vulnerabilidades de contratos inteligentes de OWASP para 2025. Ethereum.org aborda las mismas categorías principales.
Reentrada
Un contrato envía fondos o llama a otro contrato antes de actualizar sus propios registros. Un receptor malicioso vuelve a llamar al contrato mientras aún figura el saldo anterior y retira fondos de nuevo. La función de retiro de Kofi, que paga antes de poner el saldo a cero, es el caso clásico. La solución habitual es actualizar primero el estado e interactuar con otros contratos al final; este patrón suele llamarse comprobaciones, efectos e interacciones.
Control de acceso
Funciones sensibles que cualquiera puede invocar. La función pública setFee de Kofi permite que cualquier persona ajena cambie la comisión. Ethereum.org describe patrones como un rol de propietario, el acceso basado en roles y la aprobación con múltiples firmas.
Desbordamiento y subdesbordamiento de enteros
Una operación aritmética que, al superar su límite, vuelve al otro extremo del rango, de modo que un saldo inferior a cero se convierte en un número enorme. Ethereum.org señala que Solidity 0.8.0 y las versiones posteriores rechazan esto de forma predeterminada, mientras que el código más antiguo necesita comprobaciones explícitas; por eso importa que el compilador de Kofi sea antiguo.
Manipulación del oráculo
Obtener un precio de un único mercado con poca liquidez que un atacante puede manipular, a menudo mediante un préstamo relámpago, que se solicita y se devuelve dentro de una misma transacción. Los diseños robustos utilizan oráculos descentralizados o precios promediados en el tiempo.
Errores de lógica y validación
Reglas que no se ajustan al diseño previsto o datos de entrada que nunca se comprueban, como un importe de cero o una dirección inesperada.
¿Cómo prueban y auditan los equipos los contratos inteligentes?
Los equipos prueban y auditan los contratos inteligentes por capas, porque ningún método detecta todo: pruebas automatizadas, herramientas de análisis, despliegue en una red de pruebas, revisión independiente y, para los contratos que custodian un valor considerable, una auditoría externa y un programa de recompensas por detectar vulnerabilidades.
1. Pruebas unitarias y basadas en propiedades
Escriba pruebas para cada función, incluidos casos hostiles, como un receptor que vuelve a llamar a la función. Las pruebas de entradas aleatorias prueban automáticamente miles de entradas.
2. Análisis estático
Ethereum.org menciona herramientas como Slither, Mythril y Aderyn, que analizan el código en busca de patrones de riesgo conocidos.
3. Pruebe las redes
Despliegue en una red de pruebas pública antes de hacerlo en la red principal. Ethereum.org recomienda Sepolia para desarrollar aplicaciones y contratos; el ether de la red de pruebas está pensado para no tener valor real, por lo que los errores no cuestan nada.
4. Revisión por pares y bibliotecas auditadas
Use control de versiones, revisores independientes para cada cambio y bibliotecas revisadas a fondo, como OpenZeppelin Contracts, en lugar de escribir el control de acceso desde cero.
5. Auditoría, recompensas y supervisión
Las auditorías independientes aportan una revisión adicional, pero, como señala ethereum.org, no detectan todos los errores. Las recompensas por encontrar errores, las funciones de pausa de emergencia y la supervisión de eventos cubren los riesgos restantes.
¿Cómo se comparan una revisión de seguridad deficiente y una mejorada?
Revisión deficiente: 'Depósito y retirada probados manualmente, funciona bien, listo para desplegar.' Una prueba del caso ideal muestra que el contrato funciona para usuarios honestos, que es precisamente lo que no son los atacantes.
Revisión mejorada: Reentrada: withdraw ahora pone el saldo a cero antes de enviar, y una prueba utiliza un contrato receptor malicioso para intentar volver a llamar a la función. Control de acceso: setFee se restringe a un rol de propietario de una biblioteca auditada, con una prueba que comprueba que la llamada de un desconocido falle. Compilador: actualizado a una versión 0.8 vigente para activar las comprobaciones de desbordamiento. Oráculo: se sustituye el precio de un único fondo de liquidez por una fuente de precios descentralizada, además de un límite de plausibilidad para los movimientos bruscos. Pruebas: pruebas unitarias, una ejecución de pruebas con entradas aleatorias y una pasada de análisis estático con explicación de cada hallazgo; después, dos semanas en Sepolia con un colega intentando provocar fallos. Auditoría externa programada antes de aceptar fondos reales.
¿Cuáles son los errores habituales de seguridad de los contratos inteligentes?
El error más común es probar solo el recorrido previsto, como si todas las personas que invocan el contrato fueran honestas. Otros: dejar abiertas las funciones de administración para restringirlas más adelante, copiar código de un tutorial con un compilador desactualizado, confiar en una única fuente de precios, tratar una auditoría como una garantía, saltarse la etapa de la red de pruebas e implementar sin un plan para pausar o actualizar.
¿Dónde se sitúa esta lección en Tosheo.ai?
Esta es una lección de programación de la categoría de cadena de bloques y del curso de cadena de bloques. Esta página gratuita explica cada paso en texto; la versión práctica completa, en la que se revisa y corrige código real de contratos y se ejecutan pruebas en una red de pruebas, está en el itinerario opcional de programación disponible tras registrarse. Si no conoce los conceptos básicos, empiece por la explicación de los contratos inteligentes. Tosheo.ai no es un programa intensivo a tiempo completo ni una titulación de auditoría profesional, y nada de lo que se ofrece aquí constituye asesoramiento de inversión; los contratos que gestionan activos de valor real necesitan una auditoría especializada.
Fuentes y alcance
ethereum.org, seguridad de los contratos inteligentes (verificado el 19 de octubre de 2026) ↗
ethereum.org, redes y redes de prueba (verificado el 19 de octubre de 2026) ↗