¿Qué es un contrato inteligente?

Un contrato inteligente (smart contract) es un programa desplegado en una red blockchain que se ejecuta según las reglas de su código cuando una transacción u otro programa lo llama. Puede leer datos de entrada y datos registrados en la cadena, verificar condiciones predefinidas y, si la ejecución tiene éxito, actualizar los datos que la blockchain conserva.

La palabra «inteligente» no significa que el programa piense por sí mismo, y «contrato» no garantiza que constituya un contrato en términos legales. El nombre destaca algo más limitado: los participantes pueden escribir un conjunto de reglas de funcionamiento en forma de código, procesado según el protocolo por los nodos que ejecutan el software de la blockchain y verifican las transacciones, en lugar de que un solo servidor decida el resultado.

Primero distingue código, estado y llamada

El código define qué operaciones puede realizar el programa y qué condiciones requiere cada una. El estado son los datos que el programa conserva actualmente en la cadena: saldos, titulares, parámetros o autorizaciones. La transacción o llamada aporta el emisor, la función y los datos de entrada de esa ejecución concreta, y hace que el programa lea o modifique el estado.

El mismo código puede producir resultados distintos con entradas distintas o frente a un estado actual diferente. Por eso, «ejecutarse según el código» no significa que un contrato devuelva siempre la misma respuesta, sino que, con las mismas reglas de la cadena, el mismo estado actual, los mismos datos de la transacción y el mismo contexto de ejecución, los validadores deben llegar al mismo resultado. El contexto de ejecución incluye quién llama, la hora del bloque y otra información que el protocolo aporta para esa ejecución.

Un contrato tampoco se activa por su cuenta para consultar la hora, un precio o un hecho del mundo real. Normalmente espera una transacción o un mensaje del protocolo. Si el programa necesita información fuera de la cadena —un precio de mercado, el clima, el resultado de un partido—, un mecanismo de datos como un oráculo debe enviarla primero a la cadena. Un contrato solo puede ejecutar los datos que recibe: no puede demostrar por sí mismo que una información externa sea verdadera.

El problema que abordan los contratos inteligentes

En una aplicación común, la lógica principal suele ejecutarse en servidores controlados por quien la desarrolla o la presta. Las personas envían solicitudes al servidor, y el servidor lee una base de datos, aplica las reglas y devuelve un resultado. Quien opera ese servidor puede actualizar el programa, cambiar los permisos de la base de datos o detener el servicio.

Un contrato inteligente traslada parte de esa lógica y de ese estado al entorno de ejecución compartido de la blockchain. Cuando la red confirma una transacción que cumple las condiciones, los nodos calculan el resultado con el mismo conjunto de reglas y escriben los cambios de estado válidos en el registro. Los participantes pueden comprobar la transacción y el resultado de forma independiente, en vez de depender solo de los registros que entrega el backend de una aplicación.

Esto no significa que la aplicación deje de necesitar operadores o servidores. El sitio web, la aplicación móvil, la indexación de datos, las notificaciones y la atención al cliente pueden seguir proviniendo de sistemas centralizados, y el propio contrato puede conservar permisos de administración. Para juzgar cómo se controla una aplicación hay que revisar por separado el programa en la cadena, los servicios fuera de la cadena que no se ejecutan en la blockchain y las claves que pueden usar permisos administrativos.

Del despliegue a la ejecución

Las blockchains no usan todas el mismo nombre ni el mismo tratamiento para los contratos inteligentes, pero el proceso suele pasar por despliegue, llamada, ejecución y registro.

Desplegar el programa en la red

Quien desarrolla escribe primero el programa en un lenguaje admitido por la red y luego convierte el código a una forma que el entorno de ejecución de esa red pueda procesar. El despliegue se realiza normalmente mediante una transacción especial; cuando la red la confirma, el programa recibe un identificador en la cadena que otras cuentas o programas pueden llamar.

Quien despliega puede fijar datos y permisos iniciales en el programa: quién puede pausar una función, modificar un parámetro o aprobar una actualización. No todos los contratos tienen estos permisos, y no desaparecen automáticamente porque al código se lo llame «contrato inteligente».

Una persona o un programa envía una llamada

La persona suele iniciar una transacción desde una billetera o la interfaz de una aplicación, indicando la función que se llamará y los datos de entrada. Otro contrato inteligente también puede llamarlo durante su ejecución, y así varios programas se combinan en una sola operación.

El nombre del botón o el aviso de la billetera que se ve antes de la llamada es solo la interpretación que hace la interfaz de la transacción. Lo que realmente se envía son datos codificados. Si la interfaz los muestra de forma incompleta, se conecta a una dirección equivocada u oculta permisos adicionales, el efecto real de la firma puede diferir de lo que la persona creía aprobar.

Los nodos ejecutan y verifican el resultado

Las redes no organizan igual «quién ejecuta primero y quién verifica después». En muchas cadenas públicas orientadas a la ejecución, los nodos validadores vuelven a ejecutar o revisan la ejecución del contrato con las mismas reglas para confirmar los cambios de estado que produce la transacción. El programa lee el estado actual y los datos de entrada, verifica las condiciones en orden y calcula un resultado.

En Ethereum, por ejemplo, los contratos inteligentes se llaman mediante transacciones y se ejecutan en la máquina virtual de Ethereum. En Hyperledger Fabric, un programa equivalente se denomina chaincode: los nodos que cumplen la política de endoso simulan primero la ejecución y firman el resultado, y después los nodos peer del canal revisan las firmas de endoso y los registros de lectura y escritura; solo las transacciones verificadas actualizan el estado actual. Una política de endoso es simplemente la regla con la que los miembros de la red acuerdan de antemano qué organizaciones deben aprobar un resultado. Estas diferencias muestran que «contrato inteligente» nombra una categoría de programas, no la implementación particular de una sola cadena pública.

Escribir estado o devolver una lectura

Una llamada que cambia el estado de la cadena debe confirmarse como transacción. Un programa puede actualizar el saldo de un token, registrar una autorización o cambiar quién posee un objeto digital. Si la ejecución falla, el cambio de estado previsto normalmente no surte efecto, aunque el emisor puede asumir la comisión de procesamiento que la red ya consumió; las reglas concretas las define la red.

Leer un estado existente no suele requerir una nueva transacción en la cadena. Una aplicación puede consultar a un nodo un saldo, un parámetro o un registro, y el nodo devuelve el resultado localmente. Como no se modifica el estado compartido, esa lectura no necesita reconfirmación de toda la red. Aun así, las redes y los proveedores pueden establecer sus propias condiciones de consulta o de costo.

Diferencia con un contrato común

Un contrato inteligente es, antes que nada, un programa; un contrato común es, antes que nada, un acuerdo legal entre partes. Ambos pueden estar relacionados —las partes pueden usar un programa para pagar o registrar el cumplimiento—, pero la similitud de los nombres no los vuelve equivalentes.

Lo que un programa puede evaluar son los datos que su código puede leer y las condiciones expresadas de forma explícita. No necesariamente entenderá la intención real de las partes, ni resolverá cláusulas ambiguas, ni detectará un fraude, ni determinará una reparación en el mundo real. Si un resultado en la cadena corresponde a un derecho, y cómo se resuelve una controversia, depende del acuerdo concreto y de las reglas aplicables; no se deduce del nombre del código.

También ocurre lo contrario: un contrato legal no tiene que usar un contrato inteligente. Puede registrarse y cumplirse con sistemas tradicionales. Para evaluar la relación entre ambos conviene preguntar por separado qué hace realmente el código y qué acuerdo legal o de servicio tienen las partes además de él.

Diferencia con una aplicación descentralizada

Un contrato inteligente suele ser solo una parte de una aplicación descentralizada. Una aplicación descentralizada (decentralized application, DApp) puede incluir además una interfaz web o móvil, una conexión de billetera, bases de datos fuera de la cadena, almacenamiento de archivos y servicios de datos.

Cuando alguien hace clic en «intercambiar» en una página web, la interfaz muestra los activos y los parámetros, la billetera permite revisar la solicitud y firmarla, el contrato inteligente aplica las reglas en la cadena y los nodos verifican la transacción. Un error en cualquiera de esas capas puede afectar el resultado final.

Por eso, un contrato desplegado en una blockchain no vuelve descentralizada a toda la aplicación. Un dominio de frontend puede cerrarse, un servicio de datos puede devolver información equivocada y un administrador puede conservar permisos de actualización o de pausa. Evaluar una aplicación implica revisar sus componentes y quién los controla.

¿Un contrato se puede modificar o actualizar?

Algunas blockchains mantienen sin cambios el código de un contrato desplegado, pero eso no significa que la lógica de la aplicación nunca pueda actualizarse. Quienes desarrollan pueden desplegar un contrato nuevo y migrar a las personas que lo usan, o emplear una estructura de proxy en la que un punto de entrada fijo reenvía las llamadas a un contrato de lógica reemplazable.

La capacidad de actualización sirve para corregir fallas o agregar funciones. También implica que ciertas cuentas, esquemas de firma múltiple o procesos de gobernanza pueden tener la facultad de cambiar el comportamiento del programa. Si existe un permiso de actualización, quién puede usarlo, si hay un período de espera y si las personas pueden salir son aspectos que deben revisarse en la estructura y los permisos del contrato concreto.

Incluso cuando el código no se puede modificar, un administrador aún puede cambiar los resultados mediante parámetros, listas de permitidos, un interruptor de pausa o una fuente de datos externa. A la inversa, la ausencia de permisos de actualización no reduce los riesgos: una falla que no se puede corregir puede persistir mucho tiempo.

Usos frecuentes

Los contratos inteligentes permiten combinar activos y datos de la cadena bajo reglas uniformes. Entre los usos frecuentes:

• registrar la emisión, los saldos, las transferencias y las autorizaciones de un token con reglas uniformes;
• intercambiar activos según las reglas de cantidad y precio escritas en el programa;
• gestionar la garantía, el préstamo y el reembolso de activos, incluida su disposición cuando dejan de cumplirse las condiciones;
• registrar el identificador de objetos digitales y la relación de tenencia;
• gestionar activos mediante varias firmas o permisos por rol;
• aplicar cambios de parámetros a partir del resultado de una votación en la cadena.

Estos son tipos de programa y no indican que un contrato determinado sea sólido, razonable o adecuado para nadie. Programas del mismo tipo pueden tener permisos, fuentes de datos y métodos de actualización completamente distintos.

Límites y riesgos

Escribir las reglas como código ejecutable también traslada a la cadena los errores de código y el diseño de permisos. Entre los límites frecuentes:

• Fallas de código: un error en una condición, un cálculo o una verificación de permisos puede hacer que los activos o los datos se traten de forma incorrecta.
• Permisos de administración: un administrador, una cuenta de actualización o quienes participan en una firma múltiple pueden pausar o modificar el programa.
• Datos externos: si un oráculo entrega datos erróneos, demorados o manipulados, el contrato puede ejecutarse con normalidad sobre una entrada equivocada.
• Dependencias de composición: cuando un contrato llama a otros, una falla, una actualización o un cambio en los activos disponibles aguas arriba puede propagarse aguas abajo.
• Orden de las transacciones: otros participantes de la red pueden ver una transacción pendiente antes de su confirmación y enviar operaciones relacionadas antes, lo que cambia las condiciones que finalmente enfrenta la transacción original.
• Interfaces y firmas: una página maliciosa, una dirección equivocada o una solicitud de autorización poco clara pueden llevar a firmar una operación no prevista.
• Costo de ejecución: los cálculos complejos y el almacenamiento en la cadena pueden requerir comisiones más altas; una transacción puede fallar si las comisiones son insuficientes o no se cumplen las condiciones.

Que el código sea público no equivale a que sea comprensible. Lo que se ejecuta en la blockchain puede ser bytecode compilado, es decir, las instrucciones de bajo nivel que lee el entorno de ejecución. Incluso cuando un proyecto publica un código fuente más legible, a una persona no especializada le resultará difícil confirmar que coincide con el programa en la cadena, que se probó lo suficiente, o si un proxy apunta actualmente a otra lógica.

Una auditoría de seguridad puede detectar parte de los problemas, pero no demuestra que un contrato no tenga fallas ni elimina los riesgos que introducen los administradores, los datos externos, las condiciones de mercado o las firmas de las personas. Evaluar un programa concreto exige mirar más allá de una etiqueta de «auditado».

Preguntas frecuentes

¿Los contratos inteligentes se ejecutan automáticamente?

Se ejecutan según su código, pero normalmente necesitan una transacción, otro contrato o un mensaje del protocolo que los active. Desplegar un contrato no significa que vigile el mundo real e inicie todas las operaciones por su cuenta.

¿Todos los contratos inteligentes son públicos?

No necesariamente. En las blockchains públicas, los nodos suelen poder leer el código que se ejecuta y los datos de las transacciones, pero el código fuente no siempre se publica ni se verifica. Las redes con permisos además pueden limitar qué miembros ven los datos y llaman a los programas.

¿Un contrato no se puede cambiar después de desplegarlo?

No necesariamente. El código original puede permanecer igual, pero una aplicación puede migrar a un contrato nuevo o reemplazar la lógica mediante un proxy y permisos de administración. Hay que revisar la estructura de actualización concreta en lugar de confiar en la comunicación sobre inmutabilidad.

¿Un contrato inteligente puede leer datos de un sitio web directamente?

En general no puede tratar el contenido web común como una entrada confiable en la cadena. Necesita un oráculo, un participante autorizado u otro mecanismo que envíe los datos, y esas fuentes crean dependencias adicionales.

¿Una ejecución exitosa significa que la operación fue correcta?

No. Una ejecución exitosa solo indica que la transacción cumplió el código vigente y las reglas de la red. No demuestra que el código corresponda a la intención de la persona, que los datos externos fueran correctos, que los permisos estuvieran bien configurados ni que el programa no tenga fallas económicas o de seguridad.

Conceptos relacionados

Continúa con blockchain, bloque, comisión de gas y nodo de blockchain, o vuelve al glosario de criptomonedas.

Fuentes

• NISTIR 8202: descripción general de la tecnología blockchain — definición general de contratos inteligentes, código y estado, y requisitos de ejecución por los nodos.
• Ethereum.org: introducción a los contratos inteligentes — despliegue, llamadas, estado, composición y límites de los datos fuera de la cadena.
• Ethereum.org: interactuar con contratos inteligentes — diferencia entre leer el estado y enviar un cambio de estado.
• Ethereum.org: actualizar contratos inteligentes — código inmutable frente a estructuras de actualización con proxy.
• Hyperledger Fabric: contratos inteligentes y chaincode — chaincode, endoso, validación y actualización del estado en una red con permisos.