Seguridad de los contratos inteligentes

¿Qué es la seguridad de los contratos inteligentes?

La seguridad de los contratos inteligentes es la práctica de diseñar, escribir, probar, auditar, desplegar, monitorizar y actualizar contratos inteligentes en blockchain para que protejan los activos de los usuarios y se comporten según lo previsto.

Un contrato inteligente es código almacenado en una blockchain que puede ejecutar reglas, mover activos, gestionar permisos e interactuar con usuarios u otros contratos.

La documentación oficial de Ethereum sobre contratos inteligentes explica que los contratos inteligentes son programas almacenados en una blockchain y ejecutados cuando las transacciones los activan.

La seguridad de los contratos inteligentes es importante porque un contrato puede controlar tokens, NFT, posiciones de staking, mercados de préstamos, vaults, tesorerías, bridges, sistemas de gobernanza y otros activos cripto valiosos.

Un error de software convencional puede causar tiempo de inactividad, pero un error en un contrato inteligente puede provocar pérdidas irreversibles de activos.

La seguridad de los contratos inteligentes no consiste únicamente en corregir código después de detectar un problema.

Es un proceso de ciclo de vida completo que comienza con el diseño del protocolo y continúa después del despliegue.

Los contratos inteligentes seguros requieren una arquitectura cuidadosa, patrones de codificación seguros, pruebas sólidas, revisión independiente, despliegue seguro, monitorización en tiempo real y procedimientos de emergencia claros.

En términos sencillos, la seguridad de los contratos inteligentes consiste en proteger las aplicaciones blockchain frente a errores, exploits, usos indebidos, fallos de gobernanza e interacciones inseguras de los usuarios.

Por qué es importante la seguridad de los contratos inteligentes

La seguridad de los contratos inteligentes es importante porque las transacciones blockchain suelen ser públicas, automáticas y difíciles de revertir tras su confirmación.

Si un contrato inteligente tiene una vulnerabilidad, atacantes de cualquier parte del mundo pueden inspeccionar el código, probar la debilidad y activar el exploit mediante una transacción.

Las aplicaciones cripto son objetivos especialmente atractivos porque los contratos vulnerables pueden contener activos líquidos que se pueden mover rápidamente.

La documentación de consideraciones de seguridad de Solidity advierte que las directrices de seguridad de contratos inteligentes nunca pueden ser completas, ya que siguen apareciendo nuevas vulnerabilidades.

Esto es importante porque la seguridad de los contratos inteligentes es un objetivo en constante evolución.

Nuevos estándares de tokens, nuevos diseños DeFi, nuevos modelos de bridges, nuevos sistemas de cuentas, nuevos rollups y nuevos patrones de actualización pueden crear nuevas superficies de ataque.

La seguridad de los contratos inteligentes también es importante para la confianza de los usuarios.

Los usuarios pueden no leer cada línea de código, pero dependen de desarrolladores, auditores, herramientas, wallets y la verificación pública para reducir el riesgo.

Un contrato seguro aún puede fallar si las claves de administrador se gestionan incorrectamente, los datos de oráculos se manipulan o la autoridad de actualización se ve comprometida.

Esto significa que la seguridad de los contratos inteligentes debe incluir conjuntamente la seguridad técnica del código y la seguridad operativa.

Cómo funciona la seguridad de los contratos inteligentes

La seguridad de los contratos inteligentes funciona reduciendo la probabilidad de que se abuse del código, el diseño, los permisos, las fuentes de datos o los procesos de despliegue.

El proceso comienza con la modelización de amenazas antes de escribir la primera línea de código.

La modelización de amenazas pregunta qué activos están en riesgo, quién puede atacar, en qué supuestos se confía y cómo sería un fallo.

Los desarrolladores escriben después contratos con patrones seguros, complejidad mínima, permisos claros y supuestos probados.

Las pruebas comprueban el comportamiento esperado y el comportamiento ante fallos en casos normales, casos límite y casos hostiles.

Las herramientas de análisis estático analizan el código en busca de patrones de riesgo conocidos.

El fuzzing y las pruebas de invariantes buscan comportamientos inesperados con numerosas entradas generadas.

La verificación formal puede demostrar propiedades seleccionadas cuando el sistema es suficientemente importante y la propiedad está bien especificada.

Las auditorías manuales revisan la arquitectura, el código, la lógica de negocio, la economía y los supuestos de despliegue.

Después del despliegue, la monitorización y la respuesta a incidentes ayudan a detectar y reaccionar rápidamente ante comportamientos anómalos.

Vulnerabilidades comunes de los contratos inteligentes

Las vulnerabilidades comunes de los contratos inteligentes incluyen fallos de control de acceso, reentrancia, manipulación de oráculos, errores lógicos, falta de validación de entradas, llamadas externas no comprobadas, ataques con flash loans, errores aritméticos, aleatoriedad insegura, denegación de servicio y fallos de capacidad de actualización mediante proxy.

El OWASP Smart Contract Top 10 para 2026 enumera categorías importantes como vulnerabilidades de control de acceso, vulnerabilidades de lógica de negocio, manipulación de oráculos de precios, ataques facilitados por flash loans, falta de validación de entradas, llamadas externas no comprobadas, errores aritméticos, ataques de reentrancia, desbordamiento y subdesbordamiento de enteros, y vulnerabilidades de actualización mediante proxy.

Esta lista es útil porque muestra que la seguridad de los contratos inteligentes no se limita a un único tipo de error conocido.

Un protocolo puede fallar porque una función es pública cuando debería estar restringida.

Un protocolo puede fallar porque se puede manipular el precio de un oráculo.

Un protocolo puede fallar porque una actualización cambia el diseño de almacenamiento.

Un protocolo puede fallar porque la lógica de negocio permite una secuencia injusta de acciones.

Un protocolo puede fallar porque una función de emergencia otorga demasiado poder a una única clave.

Una buena revisión de seguridad busca tanto patrones conocidos como riesgos específicos del proyecto.

Los errores más peligrosos suelen ser los que encajan con el diseño único del protocolo.

Control de acceso

El control de acceso consiste en decidir quién puede llamar a funciones sensibles de un contrato inteligente.

La documentación de OpenZeppelin sobre control de acceso explica que el control de acceso puede determinar quién puede acuñar tokens, votar propuestas, congelar transferencias y realizar muchas otras acciones importantes.

Los errores de control de acceso pueden permitir a atacantes acuñar tokens ilimitados, vaciar tesorerías, pausar protocolos, cambiar comisiones, actualizar contratos o mover fondos de usuarios.

Un modelo básico de control de acceso puede utilizar una dirección de propietario.

Un modelo más avanzado puede utilizar roles, wallets multifirma, timelocks, gobernanza de DAO, consejos de emergencia o permisos operativos separados.

Un buen control de acceso sigue el principio de mínimo privilegio.

El mínimo privilegio significa que cada rol debe tener únicamente los poderes que necesita y nada más.

El control de acceso también debe ser transparente porque los usuarios necesitan saber quién puede cambiar reglas importantes.

Un contrato puede tener cálculos correctos y seguir siendo inseguro si una clave de administrador oculta puede robar activos.

El control de acceso suele ser la capa de seguridad más importante en sistemas de contratos inteligentes del mundo real.

Reentrancia

La reentrancia se produce cuando un contrato llama a un contrato externo antes de actualizar de forma segura su propio estado, lo que permite al contrato externo volver a llamar al primer contrato en un orden inesperado.

La documentación de seguridad de Solidity trata la reentrancia como una vulnerabilidad conocida y recomienda patrones de interacción más seguros.

Un problema clásico de reentrancia puede permitir retiradas repetidas antes de que se reduzca el saldo original.

La reentrancia moderna también puede aparecer mediante hooks de tokens, sistemas de callbacks, flujos entre funciones, reentrancia de solo lectura e integraciones DeFi complejas.

Una defensa habitual es el patrón Checks-Effects-Interactions.

Este patrón comprueba primero los requisitos, actualiza el estado interno en segundo lugar y llama a contratos externos al final.

Otra defensa es una protección contra reentrancia que bloquea las llamadas anidadas a funciones protegidas.

Sin embargo, las protecciones contra reentrancia no sustituyen una contabilidad correcta.

Los desarrolladores deben identificar cada llamada externa y preguntarse qué podría ocurrir si el contrato llamado se comporta de forma maliciosa.

Los usuarios deben actuar con cautela ante contratos no auditados que gestionen retiradas, callbacks o interacciones complejas con tokens.

Manipulación de oráculos

La manipulación de oráculos ocurre cuando un contrato inteligente depende de datos externos que un atacante puede distorsionar.

La documentación oficial de Ethereum sobre oráculos explica que los oráculos proporcionan a los contratos inteligentes acceso a datos externos porque estos no pueden acceder directamente a información off-chain por sí mismos.

En DeFi, los oráculos de precios son especialmente importantes porque pueden determinar los valores de colateral, liquidaciones, swaps, reembolsos e importes de liquidación.

Si un protocolo utiliza un pool de liquidez reducido como única fuente de precios, un atacante podría manipular temporalmente ese precio y beneficiarse de la confianza del contrato en datos incorrectos.

Los flash loans pueden facilitar la manipulación de oráculos porque permiten a los atacantes pedir prestadas grandes cantidades de liquidez para una sola transacción.

Un diseño de oráculos más seguro puede utilizar feeds de datos descentralizados, precios ponderados en el tiempo, circuit breakers, comprobaciones de coherencia, mecanismos de retraso y múltiples fuentes independientes.

La documentación de Chainlink Price Feeds describe los feeds de precios como datos agregados de muchas fuentes de datos por operadores de nodos independientes y descentralizados.

Incluso los sistemas de oráculos sólidos requieren una integración cuidadosa.

Los desarrolladores deben comprobar decimales, datos obsoletos, estado del secuenciador, frecuencia de actualización y comportamiento de respaldo.

La seguridad de los oráculos es seguridad de contratos inteligentes porque datos incorrectos pueden hacer que código correcto produzca resultados perjudiciales.

Vulnerabilidades de lógica de negocio

Las vulnerabilidades de lógica de negocio ocurren cuando el código sigue las instrucciones escritas, pero esas instrucciones permiten un resultado económico no deseado.

Estos errores pueden ser más difíciles de detectar que los errores de sintaxis porque el contrato puede compilarse, superar pruebas básicas y parecer normal.

Un protocolo de préstamos puede permitir que el colateral se sobrevalore.

Un contrato de staking puede calcular incorrectamente las recompensas tras retiradas parciales.

Un sistema de gobernanza puede permitir que los votos se contabilicen de manera injusta.

Un vault puede permitir que los usuarios entren o salgan a un precio que perjudique a otros depositantes.

La seguridad de la lógica de negocio requiere comprender el modelo financiero, no solo el lenguaje de programación.

Los desarrolladores deben escribir invariantes que describan lo que siempre debe seguir siendo cierto.

Entre los ejemplos se encuentran que el total de participaciones coincida con los activos, que los usuarios nunca retiren más que su saldo y que las reservas nunca sean negativas.

La revisión de lógica de negocio es uno de los motivos por los que las auditorías de contratos inteligentes requieren conocimiento del ámbito de la economía cripto.

Validación de entradas

La validación de entradas consiste en comprobar que los parámetros de una función son aceptables antes de utilizarlos.

Un contrato inteligente debe rechazar direcciones no válidas, importes imposibles, plazos vencidos, longitudes de arrays incorrectas, llamantes no autorizados, firmas obsoletas y valores de configuración inseguros.

La falta de validación puede provocar fondos bloqueados, mala contabilidad, aprobaciones incorrectas, integraciones fallidas o vías de ataque.

Por ejemplo, una función que acepta una dirección de oráculo no debe permitir una dirección cero o una dirección no fiable sin aprobación de gobernanza.

Una función de swap debe validar los parámetros de salida mínima y plazo para proteger a los usuarios frente a una mala ejecución.

Una función de token debe validar los permisos antes de acuñar o quemar.

La validación de entradas debe ser explícita y estar próxima al punto en el que los datos entran en el sistema.

Una buena validación también mejora los mensajes de error y la depuración.

Sin embargo, la validación no debe crear una falsa confianza porque los atacantes aún pueden llamar a las funciones directamente sin utilizar el front end del proyecto.

Toda función pública y externa debe tratarse como un punto de entrada para ataques.

Llamadas externas no comprobadas

Las llamadas externas no comprobadas se producen cuando un contrato llama a otro contrato o envía valor sin comprobar debidamente si la llamada se realizó correctamente.

Las llamadas externas pueden fallar por muchas razones, incluidas condiciones de revert, límites de gas, funciones inexistentes, comportamiento fallback o código malicioso.

Si un contrato asume que una llamada externa funcionó cuando no fue así, la contabilidad interna puede ser incorrecta.

Las llamadas no comprobadas también pueden ocultar fallos en sistemas de pagos, transferencias de tokens y mensajes de bridges.

Los desarrolladores deben comprobar los valores de retorno y gestionar claramente las condiciones de fallo.

Algunos contratos de tokens no se comportan exactamente como un ejemplo de estándar sencillo, por lo que los wrappers de transferencia seguros pueden reducir el riesgo de compatibilidad.

Las llamadas externas deben minimizarse y ordenarse cuidadosamente.

Los contratos deben evitar depender de comportamientos externos desconocidos cuando los fondos de usuarios están en juego.

Cuando las llamadas externas sean necesarias, los desarrolladores deben diseñar para el fallo en vez de asumir que tendrán éxito.

Las llamadas externas no comprobadas son peligrosas porque convierten la incertidumbre en corrupción de estado oculta.

Errores aritméticos

Los errores aritméticos se producen cuando un contrato calcula incorrectamente importes, comisiones, participaciones, recompensas, deuda, colateral o precios.

Solidity 0.8.x introdujo aritmética comprobada por defecto para la mayoría de los casos de desbordamiento y subdesbordamiento, pero la seguridad aritmética no queda resuelta automáticamente.

La documentación oficial de Solidity recomienda utilizar versiones actuales del compilador y comprender los cambios del lenguaje porque el compilador evoluciona con el tiempo.

Los errores aritméticos modernos suelen implicar redondeo, pérdida de precisión, discrepancias de decimales, factores de escala, orden de operaciones, comportamiento de comisiones en transferencias y fórmulas de conversión de participaciones.

Un pequeño error de redondeo puede ser grave si los atacantes pueden repetir la acción muchas veces.

Los protocolos DeFi deben probar valores extremos, valores cero, valores máximos, depósitos pequeños, depósitos grandes y decimales de tokens inusuales.

Las invariantes contables deben probarse de forma continua.

Los bloques de aritmética no comprobada pueden ser útiles para la eficiencia de gas, pero solo deben utilizarse cuando el desarrollador pueda demostrar su seguridad.

La seguridad aritmética no consiste únicamente en evitar desbordamientos.

Consiste en garantizar que cada cálculo financiero se ajuste a la economía prevista del protocolo.

Ataques con flash loans

Un ataque con flash loan utiliza liquidez prestada temporalmente dentro de una transacción para manipular los supuestos de un protocolo.

Los flash loans no son intrínsecamente maliciosos porque pueden favorecer el arbitraje, la liquidación y la eficiencia del capital.

Se vuelven peligrosos cuando un protocolo asume que un atacante no puede acceder a grandes cantidades de capital temporal.

Los flash loans pueden amplificar la manipulación de oráculos, los ataques de gobernanza, la manipulación de pools de liquidez y los exploits de farming de recompensas.

Un protocolo seguro debe asumir que los atacantes pueden acceder a grandes cantidades de capital durante periodos breves.

Las defensas pueden incluir oráculos sólidos, datos ponderados en el tiempo, comprobaciones de colateral, retrasos de votación, comprobaciones de coherencia de liquidez y una contabilidad cuidadosa.

Los desarrolladores deben evitar supuestos de seguridad basados en lo caro que sería un ataque sin liquidez prestada.

Las pruebas deben incluir escenarios en los que el atacante tiene mucho más capital del esperado.

La seguridad frente a flash loans consiste principalmente en diseñar protocolos que sigan siendo correctos incluso cuando el capital abunda temporalmente.

Un protocolo vulnerable a los flash loans suele ser vulnerable debido a un supuesto de diseño más profundo.

Aleatoriedad insegura

La aleatoriedad insegura ocurre cuando un contrato utiliza valores predecibles o manipulables como si fueran aleatorios.

La aleatoriedad es importante para juegos, loterías, revelaciones de NFT, sorteos, selección de validadores y distribución de recompensas.

Utilizar datos de bloques directamente como aleatoriedad puede ser inseguro porque los validadores o constructores de bloques pueden influir o predecir algunos valores.

Los atacantes también pueden elegir cuándo llamar a una función después de observar condiciones favorables.

La aleatoriedad segura debe utilizar un diseño adecuado para el valor en riesgo.

Los posibles enfoques incluyen esquemas commit-reveal, funciones aleatorias verificables, revelaciones retrasadas o redes de aleatoriedad fiables, según el sistema.

La aleatoriedad debe revisarse como una dependencia crítica para la seguridad.

Un juego con aleatoriedad débil puede convertirse en un sistema de pagos predecible para los atacantes.

Una revelación de NFT con aleatoriedad débil puede permitir una selección injusta de rasgos.

En cripto, la aleatoriedad es difícil porque todos los nodos deben alcanzar el mismo resultado mientras los atacantes pueden observar datos públicos.

Denegación de servicio

La denegación de servicio en contratos inteligentes significa que un atacante puede impedir que los usuarios normales o las funciones del protocolo operen correctamente.

Un contrato puede sufrir denegación de servicio debido a bucles sin límite, reverts forzados, operaciones con alto consumo de gas, retiradas bloqueadas, crecimiento del almacenamiento o fallos de dependencias.

Por ejemplo, si una función de pago recorre todos los usuarios de una lista grande, puede resultar imposible ejecutarla cuando la lista crece demasiado.

Si un destinatario puede hacer revert y bloquear un pago por lotes completo, todo el sistema puede quedar bloqueado.

Los patrones de pull-payment pueden reducir algunos riesgos de denegación de servicio al permitir que los usuarios retiren individualmente.

Los contratos deben evitar exigir que una transacción procese un número ilimitado de usuarios.

Los desarrolladores deben probar el uso de gas a medida que crece el estado.

También deben diseñar salidas de emergencia y aislamiento de fallos para flujos críticos.

La denegación de servicio puede no robar fondos directamente, pero puede congelarlos o interrumpir las operaciones del protocolo.

La disponibilidad forma parte de la seguridad de los contratos inteligentes.

Riesgo de tx.origin

Utilizar tx.origin para la autorización es un patrón peligroso de contratos inteligentes.

Las consideraciones de seguridad de Solidity sobre tx.origin advierten contra el uso de tx.origin para la autorización.

El valor tx.origin se refiere a la cuenta original de propiedad externa que inició la transacción, mientras que msg.sender se refiere al llamante inmediato.

Un contrato malicioso puede engañar a un usuario para que lo llame y después llamar a otro contrato en el que tx.origin siga apuntando al usuario.

Si el contrato objetivo confía en tx.origin, el contrato malicioso podría eludir la autorización prevista.

Por lo general, los contratos deben utilizar msg.sender y comprobaciones de permisos explícitas en su lugar.

Los desarrolladores también deben tener cuidado con las metatransacciones, la abstracción de cuentas, los proxies y los relayers porque la identidad del llamante puede volverse más compleja.

La autorización debe diseñarse en torno al modelo de confianza real.

Un atajo sencillo en las comprobaciones del llamante puede convertirse en una vulnerabilidad grave.

El riesgo de tx.origin es un ejemplo clásico de por qué importa el contexto de ejecución de blockchain.

Riesgos de firmas y repetición

Los riesgos de firmas ocurren cuando los usuarios firman mensajes que pueden reutilizarse, interpretarse erróneamente o aplicarse en contextos no previstos.

Los contratos inteligentes suelen utilizar firmas para permisos, aprobaciones sin gas, órdenes, votos, reclamaciones, bridges y permisos de cuentas.

Un ataque de repetición puede producirse cuando una firma válida se reutiliza más de una vez o se reutiliza en otra cadena, contrato o contexto.

Un buen diseño de firmas incluye nonces, plazos, IDs de cadena, direcciones de contrato, separación de dominios y datos tipados claros.

Los usuarios deben evitar firmar mensajes que no comprendan.

Los desarrolladores deben evitar mensajes ambiguos que parezcan inocuos pero autoricen acciones potentes.

Las wallets deben mostrar información de firma legible cuando sea posible.

Los protocolos deben invalidar las firmas utilizadas y protegerse frente a la repetición cross-chain.

La seguridad de las firmas es importante porque una transacción no necesita ser firmada directamente por el usuario si una firma anterior puede autorizar una acción más adelante.

Un mensaje firmado puede ser tan potente como una transacción firmada cuando un contrato está diseñado para aceptarlo.

Riesgos de estándares de tokens

Los riesgos de estándares de tokens se producen cuando un contrato asume que todos los tokens se comportan de la misma manera.

Algunos tokens cobran comisiones de transferencia, modifican saldos mediante rebase, no devuelven un valor booleano, pausan transferencias, incluyen direcciones en listas negras, utilizan hooks o tienen decimales inusuales.

Un protocolo DeFi que asume que cada token se comporta como un ejemplo sencillo puede fallar al gestionar comportamientos no estándar.

Los estándares NFT también pueden incluir hooks, restricciones de transferencia, royalties, cambios de metadatos y aprobaciones de operadores.

Los desarrolladores deben probar comportamientos inusuales de tokens, no solo tokens de prueba ideales.

Los wrappers seguros pueden ayudar a gestionar tokens que no devuelven los valores esperados.

Los protocolos deben definir qué tokens admiten y por qué.

Listar tokens no compatibles puede crear fallos de contabilidad o retirada.

Los usuarios deben entender que un token compatible con una interfaz habitual no está libre de riesgos.

La seguridad de los contratos inteligentes debe incluir los activos y estándares con los que interactúa el contrato.

Riesgos de actualización

El riesgo de actualización surge de la capacidad de cambiar la lógica del contrato después del despliegue.

La documentación de Ethereum sobre actualización de contratos inteligentes explica que los patrones de actualización pueden permitir a los desarrolladores modificar el comportamiento de los contratos inteligentes después del despliegue.

La capacidad de actualización puede ayudar a corregir errores y añadir funciones.

También puede permitir a administradores o a la gobernanza sustituir lógica segura por lógica insegura.

Los patrones proxy introducen riesgos especiales como corrupción del diseño de almacenamiento, inicializadores sin protección, direcciones de implementación incorrectas, compromiso de la clave de administrador y cambios de lógica ocultos.

La guía de OpenZeppelin para escribir contratos actualizables explica advertencias importantes para desarrollar contratos actualizables.

Los usuarios deben comprobar si un protocolo es actualizable antes de depositar fondos.

También deben comprobar quién controla las actualizaciones, si existe un timelock y si las implementaciones se verifican después de cada actualización.

Una auditoría de la versión uno no cubre automáticamente la versión dos.

La capacidad de actualización es útil, pero constituye una importante hipótesis de confianza.

Riesgos de inicialización

Los riesgos de inicialización ocurren cuando los contratos actualizables no se inicializan correctamente.

En muchos sistemas proxy, los constructores no inicializan el almacenamiento del proxy de la forma habitual.

Los desarrolladores utilizan funciones inicializadoras para establecer propietarios, roles, nombres de tokens, valores de configuración y otros estados iniciales.

Si un inicializador queda abierto, un atacante puede inicializar el contrato y tomar el control.

Si un reinicializador es incorrecto, una actualización posterior puede restablecer permisos o ajustes importantes.

Los contratos de implementación suelen desactivar la inicialización directa cuando no están destinados a utilizarse directamente.

Los scripts de despliegue deben verificar que la inicialización se produjo exactamente una vez y con valores correctos.

Los auditores deben revisar cuidadosamente las rutas de inicialización y reinicialización.

Los usuarios rara vez ven los detalles de inicialización, pero un mal inicializador puede determinar quién controla el protocolo.

La inicialización es una cuestión de seguridad de despliegue, no solo un detalle de codificación.

Riesgos del diseño de almacenamiento

El riesgo del diseño de almacenamiento ocurre cuando un contrato actualizado lee o escribe incorrectamente el almacenamiento antiguo.

La documentación de Solidity sobre el diseño de almacenamiento explica cómo se organizan las variables de estado en el almacenamiento.

En los sistemas proxy, el almacenamiento suele permanecer en el proxy mientras la lógica cambia en la implementación.

Si una nueva implementación cambia incorrectamente el orden o tipo de variables, el estado anterior puede corromperse.

Un mapping de saldos podría interpretarse incorrectamente.

Una dirección de propietario podría sobrescribirse.

Un valor de reserva podría dejar de tener sentido.

Las herramientas de actualización pueden comparar los diseños de almacenamiento antes de las actualizaciones, pero los desarrolladores deben seguir revisando cuidadosamente los cambios.

El diseño de almacenamiento debe tratarse como parte de la estructura de datos permanente del protocolo.

Un error de almacenamiento puede inutilizar un protocolo incluso si la lógica de la nueva función parece correcta.

Seguridad del front end

La seguridad de los contratos inteligentes también depende del front end con el que interactúan los usuarios.

Un contrato seguro puede seguir siendo peligroso si el sitio web se ve comprometido y pide a los usuarios que firmen transacciones maliciosas.

Los ataques al front end pueden cambiar direcciones de destinatarios, objetivos de aprobación, precios mostrados, botones de reclamación o datos de transacciones.

Los usuarios deben verificar las direcciones de los contratos y las solicitudes de la wallet en lugar de confiar únicamente en el texto del sitio web.

Los desarrolladores deben proteger las canalizaciones de despliegue, los nombres de dominio, los sistemas de distribución de contenido, los registros DNS y las herramientas de compilación.

Los cambios importantes del front end deben revisarse como cambios de código.

La simulación de transacciones en wallets y las solicitudes de firma claras pueden reducir algunos riesgos para los usuarios.

Sin embargo, los usuarios aún pueden aprobar acciones perjudiciales si la interfaz es engañosa.

Una dApp es tan segura como todo el recorrido desde el sitio web hasta la wallet y el contrato inteligente.

La seguridad del front end forma parte de la seguridad de los contratos inteligentes porque los usuarios firman a través de interfaces.

Seguridad de claves privadas y de administrador

La seguridad de las claves privadas protege las cuentas que despliegan, actualizan, pausan, configuran u operan contratos inteligentes.

Una clave de administrador a veces puede causar más daño que un error de código porque puede tener permiso para modificar ajustes esenciales.

Los protocolos deben evitar dar a una hot wallet poder ilimitado sobre contratos de alto valor.

Las wallets multifirma pueden requerir varias aprobaciones antes de realizar acciones sensibles.

Los timelocks pueden retrasar la ejecución para que usuarios y sistemas de monitorización revisen cambios pendientes.

Las hardware wallets, los dispositivos de firma seguros, las políticas de acceso y los manuales operativos pueden reducir el riesgo de compromiso de claves.

Los equipos deben separar los roles para que una clave no controle a la vez el despliegue, las actualizaciones, la tesorería, los ajustes de oráculos y las funciones de emergencia.

Los planes de rotación de claves y recuperación de emergencia deben prepararse antes de que ocurra un incidente.

Los usuarios deben revisar los poderes de administrador antes de confiar en un protocolo.

La seguridad de los contratos inteligentes incluye a las personas y las claves que pueden cambiar los contratos.

Pruebas

Las pruebas son la primera gran defensa técnica contra errores en contratos inteligentes.

Las pruebas unitarias comprueban funciones individuales.

Las pruebas de integración comprueban cómo se comportan conjuntamente varios contratos.

Las pruebas con forks simulan el comportamiento frente a estados de redes reales copiados.

Las pruebas de regresión garantizan que los errores corregidos no reaparezcan después.

Las pruebas negativas confirman que las acciones no autorizadas o no válidas fallan como se espera.

Las buenas pruebas incluyen casos límite, valores cero, valores máximos, decimales de tokens inusuales, tokens con comisión de transferencia, oráculos obsoletos, transferencias fallidas y estados pausados.

Las pruebas también deben incluir scripts de despliegue y scripts de actualización.

Un contrato puede tener buenas pruebas de funciones y aun así fallar durante el despliegue si los valores de configuración son incorrectos.

Las pruebas son necesarias, pero no bastan por sí solas para contratos de alto valor.

Fuzzing y pruebas de invariantes

El fuzzing es un método de prueba que genera muchas entradas para buscar comportamientos inesperados.

Las pruebas de invariantes comprueban si propiedades importantes siguen siendo ciertas a través de muchas acciones y estados.

Una invariante podría indicar que los activos totales deben ser siempre mayores o iguales que el total de reclamaciones de los usuarios.

Otra invariante podría indicar que un usuario no puede retirar más que su saldo.

El fuzzing es útil porque los atacantes probarán entradas en las que los desarrolladores no pensaron.

Las pruebas de invariantes son útiles porque los sistemas DeFi suelen fallar cuando muchas acciones válidas se combinan en un orden inesperado.

El fuzzing debe incluir varios usuarios, varios tokens, acciones repetidas, tiempos límite y contratos hostiles cuando sea posible.

Los desarrolladores deben tratar cada invariante fallida como una señal grave hasta comprenderla.

Los auditores suelen utilizar fuzzing para encontrar errores económicos y de máquinas de estado.

Para contratos inteligentes complejos, el fuzzing y las pruebas de invariantes suelen ser más valiosos que simples pruebas de ejemplo.

Análisis estático

El análisis estático examina código sin ejecutarlo para detectar patrones de riesgo y errores probables.

La documentación de Slither describe Slither como un framework de análisis estático para Solidity y Vyper que ejecuta detectores de vulnerabilidades, muestra información de contratos y ayuda a los desarrolladores a comprender el código.

El análisis estático puede detectar problemas como patrones de reentrancia, variables no utilizadas, llamadas peligrosas, eventos ausentes, visibilidad incorrecta y dependencias sospechosas.

Es rápido y puede integrarse en las canalizaciones de desarrollo.

El análisis estático no es perfecto porque puede producir falsos positivos y pasar por alto errores de lógica de negocio.

Los desarrolladores no deben considerar un informe limpio de análisis estático como prueba de seguridad.

Tampoco deben ignorar advertencias sin revisarlas.

El análisis estático se utiliza mejor desde el inicio y con frecuencia.

Detecta muchos errores sencillos antes de que los auditores dediquen tiempo a problemas más profundos.

Las herramientas automatizadas mejoran la seguridad de los contratos inteligentes cuando se combinan con juicio humano.

Verificación formal

La verificación formal utiliza métodos matemáticos para demostrar que determinadas propiedades del contrato se cumplen bajo supuestos definidos.

La documentación de Certora Prover describe la verificación formal como una comparación del bytecode de contratos inteligentes con reglas que describen el comportamiento esperado.

La verificación formal puede ser valiosa para protocolos de alto valor, lógica contable principal, invariantes de tokens, mercados de préstamos, bridges y sistemas de gobernanza.

Puede demostrar propiedades como límites de oferta total, conservación de saldos, restricciones de control de acceso o seguridad de retiradas.

La verificación formal es tan buena como las propiedades que se especifican.

Si la especificación omite un riesgo real, la prueba puede seguir superándose mientras el protocolo sigue siendo inseguro.

La verificación formal también requiere tiempo y conocimientos especializados.

No sustituye las auditorías, las pruebas, la monitorización ni las operaciones seguras.

Es más útil cuando las propiedades críticas son claras y hay mucho en juego.

La verificación formal ofrece mayor garantía para afirmaciones específicas, no seguridad universal para todo.

Auditorías manuales

Una auditoría manual de contratos inteligentes es una revisión de seguridad independiente realizada por especialistas.

Una auditoría puede examinar la arquitectura, el código, el control de acceso, las pruebas, la capacidad de actualización, los supuestos económicos, el diseño de oráculos, los scripts de despliegue y la documentación.

Una auditoría debe identificar vulnerabilidades, explicar el impacto, recomendar correcciones y verificar si se aplicaron las correcciones.

Una auditoría no garantiza que un contrato inteligente sea seguro.

Reduce el riesgo al añadir revisión experta antes o después del despliegue.

El alcance de la auditoría importa porque puede cubrir solo determinados contratos, ramas, commits o funciones.

Los usuarios deben comprobar si el código desplegado coincide con el código auditado.

También deben comprobar si las actualizaciones posteriores se auditaron por separado.

Las buenas auditorías forman parte de un proceso de seguridad, no son una insignia de marketing.

Un protocolo serio debe tratar los hallazgos de auditoría como trabajo de ingeniería, no como una simple casilla que marcar.

Bug bounties

Un bug bounty recompensa a investigadores externos por informar responsablemente de vulnerabilidades.

Los bug bounties son útiles porque ningún equipo interno ni auditoría puede encontrar todos los problemas.

Un programa de recompensas público puede atraer investigadores con distintas capacidades, herramientas y mentalidades de atacante.

Un buen programa de bug bounty define el alcance, los niveles de gravedad, los rangos de recompensas, las reglas de divulgación y las reglas de pruebas seguras.

Las recompensas deben corresponderse con el valor en riesgo.

Una recompensa pequeña para un protocolo que mantiene un gran valor puede no motivar una divulgación responsable.

La clasificación de reportes de bug bounty debe ser rápida y profesional.

No se debe ignorar a los investigadores que informan de problemas creíbles.

Los bug bounties no sustituyen las auditorías porque normalmente se producen después de que el código sea público o esté desplegado.

Son una capa de seguridad continua que puede ayudar a encontrar problemas con el tiempo.

Monitorización y seguridad en tiempo de ejecución

La monitorización observa contratos desplegados en busca de actividad sospechosa, transacciones inusuales, movimientos anómalos de precios, grandes retiradas, acciones de gobernanza, llamadas fallidas y eventos de actualización.

La seguridad de los contratos inteligentes no termina con el despliegue.

Los atacantes suelen explotar contratos cuando la liquidez es elevada, los mercados son volátiles o los equipos no están vigilando.

La monitorización puede detectar comportamientos sospechosos lo suficientemente pronto para una pausa de emergencia, una advertencia a usuarios, un cambio de parámetros o una respuesta a incidentes.

Las alertas importantes pueden incluir caídas repentinas del TVL, acuñación inesperada, grandes acciones de administrador, desviación anómala de oráculos, llamadas fallidas repetidas y actualizaciones de implementación.

La monitorización debe incluir contratos inteligentes, front ends, gobernanza, oráculos, claves e infraestructura.

Los equipos deben probar los sistemas de alertas antes del lanzamiento.

Una alerta solo es útil si alguien puede responder rápida y correctamente.

Los usuarios se benefician cuando los protocolos publican informes de incidentes y análisis post mortem después de eventos importantes.

La seguridad en tiempo de ejecución transforma la seguridad de los contratos inteligentes de una revisión puntual en una operación continua.

Respuesta a incidentes

La respuesta a incidentes es el plan sobre lo que hace un protocolo cuando algo sale mal.

Un plan de respuesta puede incluir pausar contratos, desactivar depósitos, actualizar advertencias del front end, contactar con usuarios, coordinarse con investigadores de seguridad, preparar parches y publicar comunicaciones.

Los controles de emergencia pueden proteger a los usuarios, pero también crean riesgo de centralización.

Un protocolo debe documentar quién puede activar acciones de emergencia y en qué condiciones.

Los equipos deben practicar escenarios de incidentes antes de que los fondos reales estén en riesgo.

La comunicación debe ser precisa, rápida y honesta.

Ocultar un incidente puede empeorar las pérdidas de los usuarios.

El análisis posterior al incidente debe identificar las causas fundamentales y las correcciones a largo plazo.

Los protocolos no deben depender de la improvisación durante un exploit activo.

Un plan sólido de respuesta a incidentes es una parte esencial de la seguridad de los contratos inteligentes.

Despliegue seguro

Un despliegue seguro consiste en lanzar contratos inteligentes con código correcto, configuración correcta, propiedad correcta, direcciones correctas y verificación correcta.

Los errores de despliegue pueden ser tan peligrosos como los errores de código.

Un contrato puede estar auditado y seguir siendo inseguro si se despliega con el administrador, oráculo, dirección de token, ajuste de comisiones o autoridad de actualización incorrectos.

Los scripts de despliegue deben revisarse, probarse y mantenerse bajo control de versiones.

Los equipos deben utilizar listas de comprobación antes del despliegue en mainnet.

Los resultados importantes del despliegue deben registrarse, incluidas direcciones de contratos, argumentos de constructor, direcciones de implementación, direcciones de administrador y hashes de transacciones.

El código fuente debe verificarse después del despliegue cuando sea posible.

La documentación de Ethereum sobre verificación de contratos inteligentes explica que la verificación compara el código fuente con el bytecode compilado.

Los usuarios deben comparar las direcciones oficiales del proyecto con datos verificados del explorador antes de interactuar.

La seguridad de despliegue es donde el código revisado se convierte en riesgo real on-chain.

Actualizaciones seguras

Las actualizaciones seguras requieren más que desplegar una nueva implementación.

Un equipo debe revisar la diferencia de código, validar el diseño de almacenamiento, probar frente al estado anterior, actualizar la documentación, verificar el código fuente y divulgar el plan de actualización.

Las actualizaciones de alto riesgo deben auditarse antes de ejecutarse.

Los timelocks y las propuestas de gobernanza dan a los usuarios tiempo para revisar los cambios.

Las actualizaciones de emergencia pueden necesitar una ejecución más rápida, pero aun así deben documentarse posteriormente.

Una actualización segura no debe cambiar silenciosamente los supuestos de los usuarios sobre retiradas, comisiones, colateral, gobernanza u oferta de tokens.

Los usuarios deben monitorizar los protocolos de los que dependen porque una actualización puede cambiar el perfil de riesgo sin cambiar la dirección.

Los desarrolladores deben crear manuales de actualización antes de necesitar la primera actualización.

Las claves de actualización deben protegerse con multifirma y controles operativos.

La capacidad de actualización segura consiste en cambios controlados, no en cambios ilimitados.

Diligencia debida de los usuarios

Los usuarios pueden reducir el riesgo de contratos inteligentes comprobando señales básicas de seguridad antes de interactuar.

Deben comprobar si el código fuente del contrato está verificado.

Deben comprobar si existen auditorías y si se corrigieron los hallazgos.

Deben comprobar si el contrato es actualizable y quién controla las actualizaciones.

Deben comprobar los roles de administrador, las funciones de pausa, los derechos de acuñación, los poderes de lista negra, los ajustes de oráculos y las reglas de retirada.

Deben comparar las direcciones de contrato con fuentes oficiales del proyecto.

Deben empezar con importes pequeños al utilizar protocolos nuevos.

Deben evitar firmar transacciones que no comprendan.

Deben revisar las aprobaciones de tokens y revocar permisos no utilizados cuando sea práctico.

La diligencia debida de los usuarios no puede eliminar todos los riesgos, pero puede prevenir muchas pérdidas evitables.

Seguridad de contratos inteligentes para desarrolladores

Los desarrolladores deben diseñar contratos inteligentes como software financiero de alto riesgo desde el principio.

Deben mantener el código sencillo, modular y bien documentado.

Deben utilizar bibliotecas maduras cuando corresponda, en lugar de escribir código personalizado arriesgado para patrones habituales.

Deben definir invariantes antes de implementar lógica financiera compleja.

Deben utilizar pruebas, fuzzing, análisis estático y revisión manual antes de las auditorías.

Deben evitar apresurar despliegues para cumplir plazos de marketing.

Deben revisar versiones de compilador, versiones de dependencias y ajustes de despliegue.

Deben documentar cada rol privilegiado y poder de emergencia.

Deben planificar la monitorización y la respuesta a incidentes antes del lanzamiento.

El desarrollo seguro es un proceso, no un informe final de auditoría.

Seguridad de contratos inteligentes para usuarios

Los usuarios deben entender que los contratos inteligentes pueden ser transparentes y arriesgados al mismo tiempo.

El código fuente verificado significa que el código es visible, no que sea seguro.

Una auditoría significa que expertos revisaron un alcance, no que no exista ningún error.

Un rendimiento elevado puede ser una compensación por un alto riesgo técnico o económico.

Un protocolo popular puede seguir siendo vulnerable.

Un protocolo de larga trayectoria puede verse afectado por una nueva actualización, integración o condición de mercado.

Los usuarios deben utilizar hardware wallets o configuraciones de custodia más sólidas para saldos grandes cuando sea posible.

Deben separar las wallets de uso diario del almacenamiento a largo plazo.

Deben evitar aprobaciones ilimitadas para contratos desconocidos.

Deben recordar que las firmas de wallet pueden autorizar acciones irreversibles de contratos inteligentes.

Errores comunes de seguridad de contratos inteligentes

Un error común es considerar una auditoría como garantía de seguridad.

Otro error es lanzar sin probar casos de fallo.

Un tercer error es utilizar una clave de administrador para demasiados poderes.

Un cuarto error es depender de una fuente de precios manipulable.

Un quinto error es ignorar el diseño de almacenamiento durante las actualizaciones.

Un sexto error es utilizar tx.origin para la autorización.

Un séptimo error es confiar en que todos los tokens se comportan igual.

Un octavo error es dejar funciones inicializadoras sin proteger.

Un noveno error es no monitorizar los contratos desplegados después del lanzamiento.

Un décimo error es asumir que los usuarios comprenderán solicitudes de wallet arriesgadas sin un diseño de interfaz claro.

Ventajas de la seguridad de los contratos inteligentes

La primera ventaja de la seguridad de los contratos inteligentes es la protección de los fondos de los usuarios.

La segunda ventaja es una mayor fiabilidad del protocolo.

La tercera ventaja es una mejor confianza de los usuarios mediante controles transparentes y comportamiento verificado.

La cuarta ventaja es un menor riesgo de cierres de emergencia y pérdidas por exploits.

La quinta ventaja es una integración más sencilla porque otros protocolos pueden confiar con mayor seguridad en contratos bien revisados.

La sexta ventaja es una mejor gobernanza porque los riesgos y poderes de administrador están claramente documentados.

La séptima ventaja es una respuesta a incidentes más rápida porque la monitorización y los manuales están preparados.

La octava ventaja es una mejor mantenibilidad a largo plazo mediante prácticas seguras de actualización y despliegue.

Una buena seguridad también puede reducir el daño reputacional cuando los problemas se gestionan responsablemente.

La seguridad de los contratos inteligentes es una ventaja competitiva porque los usuarios prefieren protocolos que protegen los activos de forma seria.

Riesgos y limitaciones de la seguridad de los contratos inteligentes

Ningún proceso de seguridad puede garantizar que un contrato inteligente sea completamente seguro.

Las auditorías pueden pasar por alto errores.

Las pruebas pueden no detectar casos límite desconocidos.

La verificación formal puede demostrar propiedades incorrectas.

La monitorización puede detectar un ataque demasiado tarde.

Los controles de administrador pueden utilizarse indebidamente o verse comprometidos.

La gobernanza puede aprobar cambios perjudiciales.

Los sistemas de oráculos pueden fallar bajo condiciones de mercado inusuales.

Los usuarios aún pueden firmar transacciones maliciosas a través de interfaces inseguras.

El objetivo de la seguridad de los contratos inteligentes es reducir el riesgo, no eliminarlo perfectamente.

Buenas prácticas para la seguridad de los contratos inteligentes

Inicia el trabajo de seguridad durante el diseño en lugar de esperar al despliegue.

Utiliza la modelización de amenazas para identificar activos, atacantes, supuestos de confianza y modos de fallo.

Escribe código sencillo con permisos claros y la mínima complejidad innecesaria.

Utiliza versiones estables actuales del compilador y revisa las advertencias del compilador.

Prueba casos normales, casos límite, casos de fallo y comportamiento hostil de usuarios.

Utiliza fuzzing, pruebas de invariantes, análisis estático y revisión manual antes de auditorías externas.

Audita contratos de alto valor y publica información de auditoría relevante.

Utiliza control multifirma, timelocks y gobernanza transparente para acciones privilegiadas.

Verifica el código fuente y la configuración de despliegue después del lanzamiento.

Monitoriza los contratos activos y prepara una respuesta a incidentes antes de que los usuarios depositen activos significativos.

Preguntas frecuentes

¿Qué significa la seguridad de los contratos inteligentes?

La seguridad de los contratos inteligentes consiste en proteger contratos inteligentes en blockchain frente a errores, exploits, permisos inseguros, datos incorrectos, fallos de actualización e interacciones arriesgadas de los usuarios.

¿Por qué es importante la seguridad de los contratos inteligentes?

La seguridad de los contratos inteligentes es importante porque los contratos inteligentes pueden controlar activos cripto reales y las transacciones blockchain confirmadas suelen ser difíciles de revertir.

¿Cuál es la vulnerabilidad más común de los contratos inteligentes?

No existe una única vulnerabilidad universalmente más común, pero los fallos de control de acceso, la reentrancia, la manipulación de oráculos, los errores lógicos y los errores de actualización se encuentran entre las categorías más importantes.

¿Una auditoría garantiza que un contrato inteligente sea seguro?

No, una auditoría reduce el riesgo, pero no puede garantizar que se haya encontrado cada vulnerabilidad, fallo económico o riesgo de actualización futuro.

¿Qué es la reentrancia en los contratos inteligentes?

La reentrancia es una vulnerabilidad en la que una llamada externa permite que otro contrato vuelva a llamar antes de que el primer contrato actualice su estado de forma segura.

¿Qué es la manipulación de oráculos?

La manipulación de oráculos ocurre cuando un contrato depende de entradas externas de precios o datos que un atacante puede distorsionar para obtener beneficio.

¿Son seguros los contratos inteligentes actualizables?

Los contratos inteligentes actualizables pueden ser seguros cuando se diseñan y gobiernan cuidadosamente, pero añaden riesgos relacionados con la autoridad de administrador, el diseño de almacenamiento, los cambios de implementación y la confianza de los usuarios.

¿Qué herramientas ayudan con la seguridad de los contratos inteligentes?

Entre las herramientas útiles se incluyen pruebas unitarias, pruebas de fuzzing, pruebas de invariantes, analizadores estáticos, sistemas de verificación formal, herramientas de monitorización, exploradores de blockchain y listas de comprobación de despliegue.

¿Cómo pueden los usuarios comprobar la seguridad de un contrato inteligente?

Los usuarios pueden comprobar la verificación del código fuente, auditorías, permisos de administrador, capacidad de actualización, aprobaciones de tokens, diseño de oráculos, documentación del protocolo y direcciones oficiales de contratos.

¿Puede la seguridad de los contratos inteligentes eliminar todos los riesgos?

No, la seguridad de los contratos inteligentes reduce el riesgo, pero no puede eliminar todos los riesgos técnicos, económicos, operativos, de gobernanza, de mercado o de firma por parte del usuario.

Conclusión

La seguridad de los contratos inteligentes es la disciplina completa de proteger contratos blockchain frente a errores técnicos, diseños inseguros, datos incorrectos, permisos débiles, fallos de actualización y comportamiento de atacantes en el mundo real.

Es importante porque los contratos inteligentes pueden mantener y mover activos cripto valiosos con un margen muy limitado para revertir errores.

Una seguridad sólida comienza con la modelización de amenazas y continúa mediante codificación segura, pruebas, fuzzing, verificación formal, auditorías, despliegue seguro, monitorización, bug bounties y respuesta a incidentes.

Las áreas de riesgo clave incluyen el control de acceso, la reentrancia, la manipulación de oráculos, los errores de lógica de negocio, las llamadas externas no comprobadas, los errores aritméticos, los supuestos sobre flash loans, la aleatoriedad insegura, la denegación de servicio y la actualización mediante proxy.

Los desarrolladores deben tratar los contratos inteligentes como sistemas de alto riesgo y utilizar defensas por capas en lugar de confiar en una sola herramienta o auditoría.

Los usuarios deben entender que el código verificado, las auditorías y la popularidad son señales útiles, pero no garantías de seguridad.

La seguridad de los contratos inteligentes es más sólida cuando el código, la gobernanza, la infraestructura, las interfaces de usuario, las solicitudes de wallet, la monitorización y los planes de emergencia funcionan conjuntamente.

Para principiantes, la seguridad de los contratos inteligentes consiste en hacer que los programas blockchain sean más seguros antes de que las personas les confíen activos.

Para usuarios avanzados, es un proceso continuo de gestión del riesgo que abarca el diseño del protocolo, la implementación, la verificación, el despliegue, la operación y la gobernanza.

En el contexto del glosario cripto, la seguridad de los contratos inteligentes significa los métodos y controles utilizados para evitar que los contratos inteligentes pierdan fondos, incumplan reglas, expongan a los usuarios o sean explotados on-chain.

La idea clave es que la seguridad de los contratos inteligentes nunca es una casilla que se marca una sola vez, porque los sistemas cripto seguros requieren revisión continua, controles transparentes, actualizaciones cuidadosas, monitorización activa y un comportamiento prudente por parte de los usuarios.