Un contrato inteligente es un programa que se ejecuta en la cadena de bloques de Ethereum. Reúne código y datos en una dirección concreta. El código define sus funciones; los datos constituyen su estado. Estos tres elementos —código, estado y dirección— permiten responder de forma precisa a la pregunta «¿qué es un contrato inteligente?».
Para entender cómo se interactúa con él, hay que añadir un cuarto elemento: la invocación de una función mediante una transacción. Esta guía explica esa relación, la diferencia entre el control mediante claves privadas y el control mediante código, y el límite que existe cuando hacen falta datos externos a Ethereum.
Código, estado y dirección: la estructura básica
La introducción de Ethereum a los contratos inteligentes describe un contrato como un conjunto de funciones y datos situado en una dirección específica. Cada componente responde a una pregunta diferente:
- Código: ¿qué funciones define el programa?
- Estado: ¿qué datos forman parte del contrato?
- Dirección: ¿de qué contrato estamos hablando?
En este contexto, estado es un término técnico para referirse a los datos. Por ejemplo, una variable llamada contador podría formar parte del estado de un contrato ficticio utilizado en clase. Su nombre no indica cuál es su valor inicial ni qué operaciones lo afectan.
Las funciones pertenecen al código. Su nombre puede facilitar la explicación, pero no basta para establecer su comportamiento. Para comprender un contrato concreto hace falta conocer las funciones y los datos particulares que intervienen.
De esta estructura se deduce una distinción útil: la dirección identifica el contrato del que hablamos, mientras que sus funciones y su estado describen aspectos diferentes de ese programa. Por tanto, facilitar una dirección no explica por sí solo su comportamiento. Esta es una deducción de la definición, no una garantía sobre una dirección determinada.
La secuencia de las transacciones es una cuestión distinta de la función de un contrato. Si necesitas ese contexto, consulta nuestra guía sobre el nonce de una cuenta de Ethereum y la secuencia de transacciones. Aquí el foco sigue siendo la estructura del contrato y la invocación de sus funciones.
Cómo cambia el control según el tipo de cuenta
La documentación de Ethereum sobre cuentas distingue entre una cuenta de propiedad externa, denominada EOA por sus siglas en inglés, y una cuenta de contrato. Una EOA está controlada por quien posee sus claves privadas. Una cuenta de contrato está controlada por el código del contrato inteligente.
Conviene mantener claro el sujeto de cada afirmación. La descripción de la EOA identifica un modelo de control mediante claves privadas. La descripción de la cuenta de contrato identifica el código como lógica de control. Ninguna de las dos, por sí sola, evalúa la seguridad de una cuenta o de un programa concreto.
Que el código controle el contrato tampoco significa que las personas no puedan interactuar con él. Interacción y control responden a preguntas distintas: quién realiza una petición y qué programa rige el comportamiento del contrato.
Un recurso útil al leer una explicación consiste en sustituir la expresión genérica «la cuenta» por «la EOA que envía la petición» o «la cuenta de contrato», según corresponda. Así resulta más fácil seguir el papel de cada participante sin suponer que todas las cuentas de Ethereum funcionan igual.
Qué significa invocar una función del contrato
Las cuentas de usuario pueden interactuar con un contrato inteligente enviando transacciones que invocan funciones definidas en él. En esta explicación conceptual, lo fundamental es la relación entre una cuenta de usuario, un contrato concreto y una de sus funciones.
Al leer la descripción de una interacción, identifica estos tres elementos:
- ¿Qué cuenta de usuario realiza la petición?
- ¿A qué dirección de contrato se dirige?
- ¿Qué función definida en ese contrato se invoca?
Estas preguntas describen el mecanismo de interacción. No establecen que la ejecución haya tenido éxito ni que el estado haya adquirido un valor determinado. Por eso, afirmar que alguien ha enviado una transacción debe seguir siendo una afirmación sobre el envío, salvo que existan pruebas para sostener una conclusión adicional.
La distinción también ayuda a redactar ejemplos: nombrar la cuenta, el contrato y la función permite explicar qué interacción se plantea sin atribuirle un resultado que todavía no se ha establecido.
Ejemplo hipotético: un contrato con un contador
Imagina un contrato inventado exclusivamente para un ejercicio didáctico. Estipulamos que contiene una variable de estado llamada contador y una función llamada registrarVisita. Son nombres de un programa hipotético, no referencias a un contrato real.
Podemos resumir el supuesto en tres líneas:
- Contrato: el programa ficticio, situado en una dirección de Ethereum sin especificar.
- Estado: una variable denominada
contador. - Función: una función definida con el nombre
registrarVisita.
Ahora imaginamos que una cuenta de usuario envía una transacción que invoca registrarVisita. Con ello hemos relacionado la estructura del programa con el mecanismo de interacción: la petición se refiere a una función definida en nuestro contrato hipotético.
El supuesto termina ahí. No hemos establecido un valor inicial para el contador, una regla de incremento ni ningún otro cambio de la variable. En particular, los nombres contador y registrarVisita no sustituyen a una explicación de la lógica de la función.
De esas premisas se deduce que no tenemos información suficiente para calcular un valor resultante. Harían falta condiciones adicionales. Dejar ese valor sin especificar permite separar lo que afirma el ejercicio de lo que podríamos imaginar al leer los nombres.
Por qué los datos externos necesitan un oráculo
Los contratos inteligentes, por sí solos, no pueden obtener datos de fuentes externas a la cadena de bloques, también llamadas fuentes offchain. La expresión «por sí solos» es esencial: esta limitación no significa que las aplicaciones de cadena de bloques nunca puedan utilizar información externa.
La documentación de Ethereum describe los oráculos como herramientas que recogen datos externos y los ponen a disposición de los contratos inteligentes. El contrato y el mecanismo que suministra esa información desempeñan, por tanto, papeles distintos en la explicación.
Como ampliación hipotética del ejercicio anterior, supongamos que alguien propone que el contador dependa de una asistencia registrada fuera de Ethereum. Esa propuesta introduce una necesidad de datos externos. El nombre registrarVisita no explica cómo llegan esos datos al contrato.
La deducción tiene un alcance limitado: dado que la información propuesta está fuera de la cadena y el contrato no puede obtenerla por sí solo, hay que explicar cómo se suministra. Describir el papel de un oráculo no establece, por sí mismo, la exactitud ni la fiabilidad de los datos que proporciona.
Lista de comprobación para leer una explicación
- Identifica el programa. Mantén la explicación vinculada a Ethereum y al contrato del que se está hablando.
- Separa código y estado. Distingue las funciones de los datos sin inventar valores iniciales.
- Aclara el control. Diferencia el modelo de claves privadas de la EOA del control mediante código de la cuenta de contrato.
- Concreta la interacción. Identifica el contrato y la función que intervienen en la descripción de la transacción.
- Ajusta las conclusiones a las pruebas. El envío no establece un resultado, y los nombres de las funciones no explican por sí solos su comportamiento.
- Localiza los datos externos. Si la explicación depende de información ajena a la cadena, comprueba si indica cómo se pone a disposición del contrato.
Esta lista sirve para valorar si una explicación hace visibles sus supuestos. La atribución a fuentes técnicas respalda los conceptos expuestos; no acredita la seguridad ni la corrección de un contrato particular.
Material educativo elaborado con ayuda de IA. El ejemplo hipotético es un ejercicio de comprensión y no recomienda enviar transacciones ni firmar solicitudes de una cartera.