El Ajedrez de Cristal: ¿Por qué los Smart Contracts son un juego infinito?

El otro día hablando con un amigo (también dev, por cierto) me dijo que, por la cantidad de piezas y casilleros que tiene el tablero de ajedrez, las posibles combinaciones existentes para una partida tienden al infinito. Por supuesto, en el momento no le creí y estuvimos un buen tiempo discutiendo. Más tarde me puse a buscar y efectivamente: ese número de posibles combinaciones, conocido como el Número de Shannon, es $10^{120}$.

Es un número bastante más grande que la cantidad de átomos en todo el universo observable.

Esa misma tarde, desarrollando un smart contract en Stellar, me puse a pensar: ¿Cuántas posibles combinaciones de ataques existen hacia un contrato? Esto varía, por obvias razones, entre lenguajes y la arquitectura del contrato en sí; pero para entenderlo mejor, vamos a usar esta analogía e intentar comprender dónde está la verdadera fuente de posibilidades, el paraíso para los atacantes.

La realidad es que el código es solo el tablero; la verdadera batalla está en la lógica de las jugadas. Las auditorías de máximo nivel utilizan el siguiente proceso para intentar verificar que el código funcione:

"Matematizar" un Contrato (Verificación Formal)

Imagina que tienes la función close_position(). En lugar de probarla con valores al azar, la conviertes en una Ecuación Lógica.

• Definir Invariantes: Son verdades que nunca deben cambiar. Ejemplo: "La suma de todos los balances de los usuarios siempre debe ser menor o igual al dinero total en el contrato".

• Convertir a Lógica Simbólica: El código se traduce a fórmulas. Si el código dice $x = a + b$, la herramienta crea una prueba de que no existe ningún valor de $a$ y $b$ que haga que $x$ se comporte de forma inesperada (como un overflow).

• El "Solver" (Resolutor): Usamos herramientas como Z3 o Certora. Es como una computadora que intenta "ganarle" a tu ecuación buscando un solo caso donde la lógica falle. Si no lo encuentra, el contrato está "Matemáticamente Verificado".

Esto está muy bien y, evidentemente, es algo que DEBE hacerse para asegurar un contrato. Sin embargo, el problema es que este proceso es buenísimo para determinar el "determinismo" del código, pero no siempre alcanza a prever la complejidad de la lógica y el estado que hay detrás.

En el ajedrez, el número de Shannon estima $10^{120}$ posiciones. En blockchains como Ethereum, el número es órdenes de magnitud superior y, técnicamente, tiende al infinito.

Para explicar mejor lo de la lógica y el estado:

En el Ajedrez: Tienes 32 piezas y 64 casillas.

En un Smart Contract (SC):

• Variables de Estado: Cada vez que un usuario interactúa, el "tablero" cambia (balances, precios, timestamps).
• Combinaciones de Funciones: Puedes llamar a depositar, luego abrir_posicion, luego flash_loan, luego retirar. El orden de los factores sí altera el producto.
• Interacciones Externas: Tu contrato no juega solo. Está jugando 100 partidas de ajedrez simultáneas contra otros contratos (piezas Lego), y lo que pase en la partida de al lado (un cambio de precio en Uniswap) afecta tus piezas directamente.

Entonces, respondiendo a la pregunta inicial: No hay un número. Si un contrato tiene 20 funciones y puede interactuar con otros 10 protocolos, las combinaciones de estados posibles superan por mucho a los átomos del universo conocido.

¿Son hackeables los contratos "perfectamente" auditados?

Sí. Rotundamente sí. Los reportes de auditoría suelen tener un disclaimer que dice:

"Esto no garantiza que el contrato sea 100% seguro".

El "Bug" que no es de código

Las mejores empresas revisan que el código sea seguro. Pero el hacker a veces no ataca el código, ataca el supuesto económico.

Caso real: Euler Finance ($200M)

Habían sido auditados por firmas top. El error fue una función que permitía a los usuarios "donar" sus fondos al protocolo, lo que accidentalmente permitía crear una posición de deuda insolvente. El código era legal, pero la lógica financiera era un suicidio.

¿Y los Smart Contracts de Stellar (Soroban)?

Stellar/Soroban usa Rust, que es como jugar al ajedrez con un árbitro que no te deja hacer movimientos ilegales (errores de memoria o tipos de datos mal puestos).

• Combinaciones en Soroban: Aunque Rust limita los errores "tontos", la lógica de negocio sigue teniendo infinitas combinaciones.

• La Ventaja de Stellar: Soroban está diseñado para ser más predecible. Ethereum es como un tablero donde las piezas pueden transformarse en otras en mitad de la partida. Stellar es más rígido, lo que reduce las "jugadas locas", pero el riesgo de un mal movimiento financiero sigue existiendo.

Y esta posibilidad de "mal movimiento financiero" pesa demasiado. Un error en la programación tradicional puede significar que una aplicación se cierre; en Web3, en cambio, un error es un "Jaque Mate" donde el premio son los fondos de tus usuarios. Esto nos lleva inevitablemente a la última pregunta:

¿Es realmente segura la descentralización o la Web3 es una mentira?

Sacando de lado las ballenas (tema que será para otra ocasion), la respuesta corta y directa es: la descentralización no es una mentira, pero tampoco es el mundo mágico que la promoción exagerada a veces vende. Es un paradigma diferente con un perfil de riesgo completamente distinto.

Para entender esto, bajaré a tierra los dos conceptos de los que veníamos hablando: la seguridad de la infraestructura y la seguridad de la lógica de negocio.

1. La Seguridad de la Infraestructura (Donde la descentralización brilla)

Aquí es donde la descentralización cumple su promesa. Al eliminar al intermediario centralizado (el banco), ganamos resistencia a la censura, inmutabilidad y transparencia. En este nivel, el "tablero" (la blockchain) es increíblemente robusto y objetivamente más seguro que los sistemas tradicionales de "caja negra".

2. La Seguridad de la Lógica de Negocio (El verdadero punto de fallo)

Aquí es donde reside la desilusión. La Web3 transfirió el riesgo de confiar en una institución a confiar en un código.

• De "Trust Me" a "Trust the Code": El problema es que el código es extremadamente difícil de verificar al 100%.

• La Inmutabilidad es un arma de doble filo: La misma característica que hace que la blockchain sea segura es lo que hace que los errores sean catastróficos. En el software tradicional publicas un parche; en Web3, si hay un error, los fondos ya se fueron y no hay "borrar".

Conclusión

La Web3 no es una mentira, pero sí es un paradigma tecnológico inmaduro que ha sido sobrecomercializado. Es como si en los albores de la aviación alguien vendiera pasajes a la Luna prometiendo que es tan seguro como un tren. La tecnología del vuelo efectivamente es real, pero la promesa de seguridad en cambio, es una fantasía para ese momento.

En la práctica, la promesa de una red "sin confianza" (trustless) es, por ahora, inalcanzable: terminamos confiando en auditores, desarrolladores de oráculos y equipos de seguridad. No hemos eliminado la confianza, solo la hemos redistribuido.

Aún así la Web3 es una revolución, con un riesgo muy alto y una curva de aprendizaje extremadamente empinada. La "mentira" no está en la tecnología, sino en la narrativa que la presenta como una solución simple, cuando en realidad exige un nivel de rigor técnico que apenas estamos empezando a comprender.