Los contratos inteligentes y sus límites

Programas cuyos resultados se convierten en estado del libro mayor

Un contrato inteligente es un código implementado en un entorno de cadena de bloques que se ejecuta de acuerdo con las reglas de ese entorno. A pesar de su nombre, un contrato inteligente no es necesariamente un contrato jurídicamente vinculante. Puede simplemente implementar una instrucción automatizada, como «registrar un cambio de saldo cuando se cumplan las condiciones requeridas». Sus resultados pueden actualizar saldos, emitir registros o llamar a otras aplicaciones. La cadena de bloques proporciona un entorno replicado en el que los nodos participantes pueden verificar si la ejecución siguió las reglas acordadas.

Un ejemplo inicial útil es un registro de boletos. Un contrato inteligente puede registrar que el identificador de boleto 417 pertenece a una cuenta específica de la cadena de bloques. Al recibir una solicitud de transferencia autorizada, verifica la titularidad y cualquier restricción antes de actualizar ese registro. El código no sabe por sí solo si el evento subyacente tendrá lugar, si el titular es una persona específica del mundo real o si la legislación local de protección al consumidor permite una restricción. Esas cuestiones corresponden a otros sistemas y acuerdos jurídicos. Los contratos inteligentes hacen que las reglas especificadas sean ejecutables; no hacen que estén disponibles todos los hechos relevantes del mundo real.

Transacciones, estado y ejecución determinista

Una transacción es una instrucción enviada que solicita un cambio en el estado de la cadena de bloques. El estado es la información registrada actualmente, como saldos, permisos de cuentas o variables almacenadas por un contrato. La ejecución determinista significa que los nodos que aplican las mismas instrucciones válidas al mismo estado previo deberían obtener el mismo resultado. Por eso, un contrato típico no puede simplemente abrir un sitio web cualquiera y usar la página actual como entrada confiable. Distintos nodos podrían ver información diferente o encontrar fallas distintas.

Las redes tienen distintos modelos de ejecución. Algunas admiten contratos programables de propósito general; otras ofrecen scripts deliberadamente restringidos. Incluso cuando dos redes ofrecen capacidades similares, pueden utilizar máquinas virtuales, tarifas, estructuras de cuentas y semánticas de transacción diferentes. Esta lección explica la lógica compartida en lugar de exigir que los estudiantes programen en una cadena específica.

La automatización es condicional, no mágica

Un contrato puede incluir condiciones, permisos y eventos. Una condición evalúa hechos visibles para su entorno, como si una cuenta tiene suficientes tokens. Un permiso especifica qué actor puede invocar una función. Un evento es un registro estructurado que se emite para ayudar a las aplicaciones a observar lo ocurrido. No todos los eventos garantizan un movimiento de activos correspondiente, y no todas las interfaces de usuario interpretan correctamente la transacción subyacente. Los revisores deben examinar los cambios de estado realizados correctamente, en lugar de considerar una notificación en pantalla como prueba concluyente.

Los contratos también consumen recursos de ejecución. Muchas redes miden el trabajo computacional y cobran tarifas de transacción, a veces denominadas gas. Si un contrato requiere demasiados cálculos o la transacción no proporciona recursos suficientes, la operación puede fallar. Los requisitos de tarifas ayudan a desalentar los cálculos ilimitados. No garantizan que todos los contratos sean económicos de usar ni que una ruta de código esté libre de errores. La complejidad aumenta la necesidad de pruebas y revisión.

Los oráculos conectan la cadena con hechos externos

Un oráculo es un mecanismo que proporciona a un contrato información originada fuera de su cadena de bloques. Algunos ejemplos podrían ser un tipo de referencia oficial, una confirmación de entrega o un registro verificado de elegibilidad. Un oráculo no elimina la confianza; la traslada a los proveedores de información, los procesos de validación de datos y los canales de entrega. Los datos incorrectos, tardíos, manipulados o no disponibles pueden hacer que un contrato se comporte exactamente como está escrito y, aun así, produzca un resultado comercialmente erróneo. La documentación de Ethereum sobre Oracles describe esta separación entre el código en cadena y la información externa.

En el uso del sector público, un oráculo que suministra registros administrativos plantea otras inquietudes: la autoridad para publicar datos, la privacidad, los procedimientos de corrección y la auditabilidad. Es posible que no sea adecuado escribir información personal de manera permanente en un libro mayor ampliamente replicado. A menudo, los sistemas pueden almacenar en la cadena únicamente una prueba o referencia limitada y conservar los registros sensibles en bases de datos gestionadas. El diseño adecuado depende de las normas de conservación, la accesibilidad y el propósito probatorio del sistema.

Cuatro límites que toda persona responsable de tomar decisiones debería reconocer

En primer lugar, persiste el riesgo del código. Un defecto de programación, una norma mal interpretada o una interacción insegura entre aplicaciones puede causar resultados no deseados. El código fuente publicado facilita la revisión, pero no demuestra que sea correcto. En segundo lugar, persiste el riesgo de gobernanza. Algunos contratos tienen administradores que pueden pausar funciones o actualizar el código. Una interfaz que parece inmutable puede ocultar dependencias modificables. En tercer lugar, persiste el riesgo de los datos cuando el contrato depende de oráculos, fuentes de datos o repositorios de documentos. En cuarto lugar, la exigibilidad jurídica sigue siendo una cuestión aparte: la ejecución en la cadena de bloques puede ocurrir incluso cuando existe una disputa sobre la autoridad, el consentimiento o la titularidad.

El usuario debería distinguir entre la inmutabilidad de los registros históricos del libro mayor y la inmutabilidad del comportamiento de la aplicación. Una transacción histórica puede seguir siendo visible aunque un contrato proxy apunte más adelante a un nuevo código de implementación. Un sistema también puede incluir controles legítimos de recuperación o emergencia, sujetos a sus propios riesgos. La descripción binaria «totalmente descentralizado frente a centralizado» suele ocultar preguntas más útiles: quién controla las actualizaciones, qué firmas se requieren, qué se puede congelar y quién puede resolver las disputas.

Cómo evaluar una afirmación de cumplimiento automático

Imagine un contrato que se anuncia como capaz de liberar automáticamente un pago cuando el equipo llega a un almacén gubernamental. Los inspectores deberían preguntar cómo se mide la llegada, quién la certifica, qué ocurre si falla un sensor y cómo se ingresan las correcciones. Si el sistema acepta como condición desencadenante la confirmación de un empleado autorizado, el contrato hace cumplir la existencia de esa confirmación, no la llegada física en sí. Esta diferencia es crucial para determinar si los registros prueban un hecho, una declaración o ambas cosas.

Conforme a la orientación del GAFI de 2021 sobre activos virtuales, el análisis regulatorio también depende de la función y el control, incluido si hay personas que operan o controlan servicios sujetos a la normativa. No debe suponerse que una aplicación que se autodenomina «autónoma» está exenta de todas las obligaciones legales. También pueden aplicarse leyes nacionales y regionales según la actividad; no es correcto suponer que el simple hecho de implementar código resuelve la cuestión regulatoria.

Una secuencia práctica de revisión

Para alguien que no programa, la revisión más sencilla comienza por identificar la función prevista y, luego, trazar las entradas, la autoridad, la ejecución y los resultados. A continuación, se examina si algún actor puede cambiar las reglas. Por último, se determina qué hechos y derechos se establecen fuera de la cadena de bloques. Según la importancia del caso, puede ser necesaria una opinión jurídica, una auditoría de seguridad o una revisión contable. Esto no constituye un fallo de los contratos inteligentes: toda tecnología opera dentro de instituciones y políticas. Su contribución útil es ejecutar de forma consistente reglas claramente especificadas y verificables cuando se cumplen los supuestos.

Nota sobre pruebas y rendición de cuentas

El registro técnico de una llamada a un contrato puede responder a las preguntas «¿qué cuenta envió esta instrucción?» y «¿qué registró el software?». Por lo general, no puede responder a «¿quién estaba autorizado según la política de la organización?» sin consultar registros de identidad y aprobación. Por lo tanto, los registros de actividad, el historial de implementación, las versiones de los contratos y los inventarios de controles de acceso deberían conservarse conjuntamente. En las adquisiciones públicas o las operaciones reguladas, la automatización puede reforzar la coherencia solo si alguien sigue siendo responsable de las entradas incorrectas, los resultados excepcionales y los cambios de reglas.

Normas y referencias jurídicas

La documentación de Ethereum, Introduction to Smart Contracts y Oracles, describe la ejecución y las dependencias externas a la cadena. Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers del GAFI (octubre de 2021) presenta consideraciones pertinentes basadas en la actividad.

Enfoque del examen: Explique qué ejecuta un contrato inteligente, distinga los hechos deterministas en cadena de los hechos externos suministrados por oráculos y reconozca que la ejecución técnica no resuelve por sí sola la exigibilidad jurídica.