¿Qué es un contrato inteligente, y qué puede salir mal?

Contrato inteligente es uno de los términos más engañosos en cripto, porque toma prestada una palabra legal para algo que, en sentido estricto, no es un contrato. Es un programa almacenado en una blockchain que se ejecuta automáticamente cuando se cumplen ciertas condiciones, sin un banco, un bróker ni un tribunal de por medio. Esa automatización es el atractivo, y también es la fuente de la mayor parte del riesgo. Esta guía explica qué hace realmente un contrato inteligente, dónde se usa la idea en la práctica, y las principales categorías de cosas que salen mal cuando el código no se comporta como sus autores pretendían.

Qué es en realidad un contrato inteligente

Si se retira el nombre, un contrato inteligente es una pieza de software desplegada en una blockchain, con mayor frecuencia Ethereum o una red programable similar. Una vez desplegado, su código reside en una dirección fija y normalmente no puede modificarse, a menos que los desarrolladores hayan incorporado de antemano un mecanismo de actualización específico. Cualquiera puede enviarle una transacción, y la red de validadores ejecuta el código exactamente como está escrito, actualizando en consecuencia el estado compartido de la blockchain. No hay una línea de atención al cliente y, en la mayoría de los casos, no hay forma de revertir un resultado una vez confirmado.

Esto difiere de un acuerdo tradicional de una manera fundamental. Un contrato en papel describe una intención en lenguaje natural, y un tribunal o árbitro interpreta esa intención si surge una disputa. Un contrato inteligente no tiene intérprete. Hace exactamente lo que dice su código, incluso cuando eso diverge notablemente de lo que las partes asumían que ocurriría. La frase «el código es ley», popular en los primeros días de Ethereum, capta esto de forma literal: el resultado es lo que sea que compute el programa, no lo que nadie considere justo. En la práctica, esta idea tiene límites reales, que las secciones posteriores de esta guía abordan.

Dónde se usan realmente los contratos inteligentes

El concepto suena abstracto hasta que se vincula a ejemplos concretos. Tres casos de uso concentran la mayor parte de la actividad en las blockchains programables hoy en día.

• Intercambios en exchanges descentralizados. Los protocolos construidos sobre diseños de creador de mercado automatizado permiten a los usuarios cambiar un token por otro directamente contra una reserva agrupada, con el tipo de cambio fijado por una fórmula en lugar de un libro de órdenes. El contrato inteligente custodia los fondos y ejecuta el intercambio en una sola transacción.
• Préstamos. Los protocolos de préstamos de DeFi usan contratos inteligentes para aceptar colateral, emitir préstamos, hacer seguimiento de los intereses y, si el valor del colateral cae demasiado, desencadenar una liquidación automatizada, todo sin que un oficial de crédito revise la solicitud.
• Emisión de tokens. La mayoría de los tokens más allá del activo nativo de una blockchain, incluida la mayoría de los activos construidos sobre Ethereum, son en sí mismos contratos inteligentes que definen la oferta, las reglas de transferencia y los registros de propiedad.

En cada caso, el atractivo es el mismo: las transacciones se liquidan automáticamente, según reglas públicas que cualquiera puede inspeccionar de antemano, sin exigir a los participantes que confíen en una institución concreta.

Los límites prácticos de «el código es ley»

Tratar el código como la última palabra suena impecable en teoría, pero choca con la fricción en cuanto el código diverge de lo que la gente pretendía. Un ejemplo muy citado es el colapso en 2016 de un proyecto llamado The DAO, donde un atacante explotó una falla en la lógica del contrato para retirar una gran parte de los fondos agrupados usando funciones que, técnicamente, operaban exactamente como estaban escritas. La respuesta de la comunidad de Ethereum, una división de la red muy controvertida que dio origen a Ethereum y Ethereum Classic, sigue siendo una ilustración viva de que «el código es ley» es una filosofía de diseño, no una ley física. Cuando el resultado es lo bastante disruptivo, los participantes aún pueden optar por intervenir al nivel de la red subyacente.

Fuera de casos tan extremos, la tensión más común es más silenciosa. Un contrato puede ejecutarse sin fallos y aun así producir un resultado que nadie quería, porque el código no anticipó una secuencia particular de transacciones, una condición de mercado particular o una combinación particular de entradas. Por lo general no existe un proceso de apelación incorporado para eso.

Qué puede salir mal: las principales categorías

Los reportes de fallos de contratos inteligentes tienden a agruparse en un puñado de categorías recurrentes, y distinguir entre ellas importa, porque exigen distintos tipos de escrutinio antes de confiar en un protocolo.

• Errores y exploits. Fallos en el propio código, como controles de acceso deficientes, desbordamientos de enteros, o lógica que permite llamar a una función en un orden no previsto (un patrón detrás de muchos exploits de reentrancy), pueden permitir que un atacante vacíe fondos o acuñe tokens sin autorización. Se trata de errores de programación, y una vez que un contrato está activo e inmutable, a menudo son difíciles o imposibles de parchear.
• Manipulación de oráculos. Los contratos inteligentes no pueden ver fuera de su propia blockchain. Cuando un contrato necesita datos externos, como el precio de un activo, depende de un servicio «oráculo» para introducir esa información. Si un atacante logra distorsionar el precio que reporta un oráculo, aunque sea brevemente, puede engañar a un contrato de préstamo o trading para que actúe sobre información falsa, una técnica detrás de varias pérdidas de alto perfil en DeFi.
• Riesgo de claves de administrador y de actualización. Muchos contratos incluyen una puerta trasera por diseño: una clave de administrador o un monedero multisig que puede pausar el contrato, cambiar parámetros o actualizar el código. Esta flexibilidad ayuda a los equipos a corregir errores rápidamente, pero también significa que el sistema no es totalmente autónomo. Si esa clave se ve comprometida, o si el equipo que la posee actúa de mala fe, los usuarios enfrentan pérdidas que no tienen nada que ver con un fallo en la lógica central.
• Fallos de diseño económico. No todo fallo es un error de programación. Un contrato puede implementarse exactamente como se pretendía y aun así fallar porque sus supuestos económicos eran erróneos, por ejemplo una estructura de incentivos que funciona en condiciones normales pero se rompe durante una volatilidad extrema o una crisis de liquidez. Esta categoría es más difícil de auditar, porque el código no está «lleno de errores» en un sentido técnico; el modelo subyacente de cómo se comportarían los participantes simplemente estaba incompleto.

Auditorías, recompensas por errores, y sus límites

Dados estos riesgos, la mayoría de los proyectos serios encargan una auditoría de seguridad externa antes del lanzamiento, y muchos mantienen programas continuos de recompensas por errores que pagan a investigadores independientes por reportar vulnerabilidades. Ambas prácticas reducen el riesgo de forma significativa. Una auditoría realizada por una firma experimentada suele detectar patrones de error comunes, y un programa de recompensas bien financiado da a los investigadores de sombrero blanco un incentivo económico para encontrar fallos antes que los atacantes.

Ninguna de las dos es una garantía. Una auditoría es una revisión del código tal como existía en un momento específico, realizada bajo restricciones de tiempo y presupuesto, y no puede demostrar la ausencia de todo fallo posible, solo la ausencia de los fallos que a los revisores se les ocurrió buscar. Contratos que han pasado varias auditorías igualmente han sido explotados, a veces mediante una vulnerabilidad fuera del alcance auditado, a veces mediante un ataque económico en lugar de un error a nivel de código. Tratar una insignia de auditoría como un certificado de seguridad, en lugar de como una entrada más entre varias, es un error común y costoso.

Para cualquiera que use un protocolo construido sobre contratos inteligentes, una base razonable incluye comprobar si el contrato ha sido auditado, por quién, hace cuánto tiempo, si existe una clave de administrador y quién la controla, y cómo ha manejado el protocolo momentos de tensión en el pasado. Nada de esto elimina el riesgo, pero sustituye la confianza ciega por un juicio informado, que es el estándar más realista que los contratos inteligentes pueden ofrecer. Quienes quieran incorporar este hábito a una cartera pueden encontrar útil como punto de partida un marco de riesgo más amplio, como el descrito en la metodología de roo2ya, junto con prácticas generales de investigación como DYOR.

Este artículo tiene fines informativos y no constituye asesoramiento financiero.