Solo con fines educativos; no constituye asesoramiento de inversión. Las transacciones con contratos inteligentes pueden causar pérdidas irreversibles.
Respuesta directa
Un contrato inteligente es un programa desplegado en una cadena de bloques o una red de ejecución distribuida similar. Contiene código y, en muchas plataformas, un estado persistente. Una transacción u otro contrato puede llamar a sus funciones; los nodos ejecutan las mismas reglas y aceptan el cambio de estado resultante mediante el proceso de validación y consenso de la red.
«Inteligente» no significa que el programa comprenda la intención, y «contrato» no lo convierte automáticamente en un acuerdo legalmente exigible. El término describe código capaz de imponer condiciones concretas dentro de las funciones y los datos disponibles en su entorno de ejecución.
Los contratos inteligentes pueden:
- mantener o transferir activos digitales bajo condiciones programadas;
- registrar y actualizar el estado de una aplicación; y
- combinarse con otros contratos para crear mercados, sistemas de préstamo, juegos, herramientas de gobernanza y otras aplicaciones en cadena.
Su previsibilidad se limita al código implementado y a sus entradas. Un contrato puede ejecutarse exactamente como fue escrito y aun así producir un resultado no deseado por un defecto, un diseño malicioso, privilegios comprometidos o datos externos incorrectos.
Cómo funciona
Una interacción habitual sigue estos pasos:
- Los desarrolladores escriben y prueban el código fuente, lo compilan cuando la plataforma lo exige y despliegan el programa resultante mediante una transacción.
- El despliegue asigna al programa un identificador o una dirección en cadena y puede inicializar su estado y sus funciones administrativas.
- Un usuario, una aplicación u otro contrato envía una llamada con un selector de función, parámetros y, en ocasiones, activos.
- Cada nodo validador ejecuta la llamada conforme a las mismas reglas de la máquina virtual y del protocolo. Si falla una condición necesaria, la llamada puede revertirse aunque la comisión de transacción aún pueda cobrarse.
- Si la llamada tiene éxito y la red la incluye, los cambios de estado y los eventos emitidos pasan a formar parte del registro de la cadena de bloques.
La ejecución solo es determinista para la información disponible en el contexto de ejecución acordado. Un contrato no puede obtener por sí solo de internet el clima, un precio de mercado o un pago bancario. Las aplicaciones que necesitan hechos externos usan un oráculo, un mensaje firmado, un puente o un operador privilegiado, lo que añade supuestos de confianza y fallo más allá del código.
El código desplegado no siempre constituye todo el sistema. Algunos contratos son inmutables, mientras que los patrones de proxy y gobernanza pueden dirigir las llamadas a una lógica nueva o cambiar parámetros. Por eso deben revisarse las claves de actualización, los poderes administrativos, los controles de pausa, el diseño del oráculo y los contratos conectados, además de la interfaz visible.
Antes de firmar una interacción, verifica:
- la red y la dirección completa del contrato mediante una fuente independiente y fiable;
- la función decodificada, los parámetros, las cantidades de activos y el destinatario;
- las asignaciones de tokens o los permisos de operador creados por la llamada;
- si el contrato está verificado, es actualizable, está pausado o lo controlan cuentas privilegiadas; y
- que, cuando sea práctico, una prueba pequeña cubra la ruta prevista de entrada y salida.
Ejemplo
Considera un contrato de depósito en garantía para un servicio digital. El comprador deposita 1,000 USDC, y el contrato registra comprador, vendedor, importe y condición de liquidación. Si el comprador aprueba la entrega, libera los fondos al vendedor. Si la condición no se cumple en 24 horas, queda disponible la vía de reembolso programada.
El contrato no sabe si el servicio fue satisfactorio salvo que el diseño le aporte ese hecho. Si la aprobación procede de la clave del comprador, una clave comprometida puede autorizar la liberación. Si un oráculo o administrador decide el resultado, esa parte integra el modelo de confianza. Un fallo de control de acceso o de gestión del token también puede frustrar la regla prevista. La ejecución automática reduce parte del procesamiento manual, pero no elimina la necesidad de evaluar cada dependencia.
Riesgos y controles
- Defectos del código: la reentrada, una contabilidad incorrecta, llamadas externas inseguras o casos límite pueden perder o bloquear activos. Prefiere diseños pequeños y bien probados y revisa el código desplegado, no solo una insignia de auditoría.
- Riesgo de privilegios y actualización: un administrador puede pausar el sistema, sustituir la lógica, cambiar comisiones o mover activos. Comprueba quién controla cada función, si se usa un bloqueo temporal o multifirma y qué puede cambiar.
- Riesgo de oráculo e integración: el código correcto puede actuar sobre datos obsoletos, manipulados o con una escala incorrecta, y los fallos de tokens, puentes u otros contratos pueden propagarse por composición.
- Riesgo de transacción y autorización: una interfaz maliciosa puede mostrar una dirección, función, destinatario o asignación ilimitada incorrectos. Decodifica la solicitud y limita los permisos al alcance necesario.
- Riesgo del diseño económico: las transacciones válidas aún pueden provocar liquidaciones, manipulación de precios, fallos de incentivos o una retirada masiva de liquidez limitada. La corrección del código no equivale a solvencia económica.
- Riesgo operativo: la congestión, las reorganizaciones de cadena, las caídas del secuenciador o la indisponibilidad de la interfaz pueden retrasar una acción aunque el contrato siga desplegado.
- Irreversibilidad: las transacciones en cadenas públicas normalmente carecen de devolución de cargo. Si se envían fondos mediante una función equivocada o a un contrato hostil, recuperarlos puede ser imposible.
Una auditoría es evidencia sobre una versión y un alcance definidos, no una garantía. Comprueba que el bytecode desplegado o el código fuente verificado coincide con la versión revisada y si las actualizaciones, dependencias o configuraciones posteriores quedaron fuera del alcance.
Errores comunes
- «El código se ejecuta automáticamente sin transacción». La mayoría de las funciones que cambian estado necesitan una transacción u otra llamada en cadena; las acciones basadas en el tiempo pueden requerir un ejecutor externo.
- «El código no puede cambiar». Un contrato inmutable no reescribe su bytecode desplegado, pero los proxies, la gobernanza y las migraciones pueden cambiar la lógica a la que llegan los usuarios.
- «El código público es seguro». La visibilidad facilita la revisión, pero no prueba corrección, administración honesta ni una economía sólida.
- «Una auditoría garantiza seguridad». Las revisiones están limitadas en tiempo y alcance, pueden omitir defectos o excluir riesgos operativos y económicos.
- «Una transacción exitosa implica que ocurrió la acción prevista». El éxito solo indica que el código llamado no se revirtió; todavía hay que revisar destino, eventos decodificados, movimientos de activos y permisos resultantes.
Temas relacionados
Fuentes
- Descripción general de la tecnología de cadena de bloques - NIST (consultado: 2026-08-21)
- Introducción a los contratos inteligentes - Ethereum.org (consultado: 2026-08-21)
- Consideraciones de seguridad - Solidity documentation (consultado: 2026-08-21)