-
Cube permitiría al usuario retirar sus fondos incluso si están dentro de un contrato.
-
Cube opera sobre una máquina virtual propia llamada CubeVM.
Un sistema que permitiría ejecutar contratos inteligentes sobre Bitcoin sin que el usuario entregue la custodia de sus fondos a ningún operador fue propuesto el 27 de mayo por Burak Keceli, el desarrollador conocido en la comunidad bitcoiner por haber expuesto en 2022 vulnerabilidades críticas en la Lightning Network (LN) que obligaron a una actualización de emergencia.
El nuevo proyecto se llama Cube y su objetivo es llevar finanzas programables a Bitcoin para que, cuando un usuario deposite sus fondos en un contrato inteligente no pierda temporalmente la capacidad de retirarlos por su cuenta.
Keceli describe a Cube como una plataforma sobre la que podrían construirse intercambios de activos sin intermediarios, sistemas de préstamos colateralizados y stablecoins respaldadas por bitcoin (BTC), entre otras aplicaciones financieras.
Cube elimina intermediarios y depende de su tecnología
Mientras muchas L2 actuales requieren algún grado de confianza en operadores o comités (como los Proveedores de Servicios de la L2 Ark del propio Keceli o la federación multisig en Liquid Network de Blockstream), Cube promete que el usuario nunca pierda la capacidad de retirar sus fondos unilateralmente en la capa base de Bitcoin.
En contrapartida, Cube sí requeriría de una capa técnica llamada Engine, que actuaría como su coordinador interno. Su rol sería ordenar las transacciones de los usuarios, registrar periódicamente el estado del sistema en Bitcoin y coordinar la ejecución fuera de la red.
En ese sentido, Keceli sostiene que el Engine «nunca es el custodio», ya que, según el desarrollador, los fondos permanecerían bajo un acuerdo entre el usuario y el Engine que requiere la firma de ambos para moverse (multisig 2 de 2). Además, explica Keceli, el usuario podría forzar su salida sin la colaboración del Engine si este actuara de forma maliciosa o dejara de funcionar.
Aunque los usuarios conserven la opción teórica de salida unilateral en caso de que el Engine dejara de funcionar o actuara maliciosamente, esto convierte al Engine en un punto potencial de fricción operativa, incluso si no compromete la custodia de los fondos.
Si bien Keceli no profundiza en cómo podría fallar el Engine, un error en esta estructura podría potencialmente deberse a un fallo técnico del sistema o a una actuación deliberada, incluyendo la posibilidad de que el Engine sea comprometido por un tercero.
¿Cómo funcionaría Cube en Bitcoin? Tres piezas combinadas
Cube combinaría tres mecanismos para lograr contratos inteligentes con salida unilateral:
Timeout trees (árboles de tiempo de espera)
El primero son los timeout trees (árboles de tiempo de espera), que son la estructura que organiza y registra los fondos de todos los usuarios dentro de Cube. Funcionan como un árbol de transacciones prefirmadas: cada rama corresponde a un usuario y tiene grabado, desde el inicio, el derecho de ese usuario a reclamar sus fondos directamente en Bitcoin si algo falla. Todo el árbol comparte un único punto de registro periódico en la red base.
Esa arquitectura permite dos modos de operación. Mientras el Engine funciona correctamente, las transacciones entre usuarios ocurren dentro de Cube sin necesidad de escribir cada movimiento en Bitcoin, lo que reduciría tiempos y costos. Pero si el Engine dejara de operar o intentara retener fondos, el usuario no necesitaría su autorización para salir: podría activar su rama del árbol directamente en Bitcoin y recuperar lo suyo de forma autónoma, una vez vencido el plazo predefinido que quedó grabado cuando depositó. Ese plazo es la única condición; no hay intermediario que pueda bloquearlo. Esta tecnología proviene del protocolo Ark.
BitVM3
El segundo mecanismo es BitVM3, la versión más reciente de BitVM (máquina virtual de Bitcoin), una propuesta del desarrollador Robin Linus. BitVM3, que aún no está operativa, apunta a resolver en Cube cómo un usuario podría demostrar que el Engine funcionó incorrectamente, si toda la ejecución ocurre fuera de Bitcoin.
La respuesta de Cube es que cada operación del Engine viene acompañada de una afirmación verificable sobre su resultado. Si el usuario detecta que esa afirmación es falsa, puede presentar la prueba del error directamente en Bitcoin. Bitcoin la evalúa y, si confirma el fraude, activaría una penalización contra el Engine, que haría liberar los fondos bloqueados como garantía expuestos ante una disputa resuelta a favor del usuario. El mecanismo busca que el costo de actuar incorrectamente sea mayor que cualquier beneficio posible.
CubeVM
El tercero es CubeVM, una máquina virtual (entorno de ejecución de programas) construida como extensión de Bitcoin Script, el lenguaje nativo de programación de Bitcoin.
CubeVM añadiría soporte para contratos inteligentes complejos, que son los programas que podrían ejecutar lógica financiera avanzada, como intercambios de activos o stablecoins colateralizadas, algo que Bitcoin Script nativo no permite.
El problema que Cube quiere resolver en Bitcoin
Usar contratos inteligentes en Bitcoin implica que cuando un usuario deposita sus fondos en un contrato, esos fondos pasan a estar bajo control de la lógica del programa, no de la clave privada del usuario.
En ese estado intermedio, Bitcoin no tiene forma nativa de reconocer que esos fondos le pertenecen al usuario, ya que el protocolo entiende claves, no lógica de programas. El usuario queda, en la práctica, dependiente de que el sistema que esté utilizando funcione correctamente para recuperar lo suyo.
El mecanismo que Keceli propone para resolver esto se llama Shadowing (proyección de sombra). Esta herramienta mantendría en todo momento un registro interno de cuánto BTC le correspondería a cada usuario dentro de cada contrato.
Ese registro (llamado shadow space, o espacio de sombra) no representaría la custodia directa de los fondos, sino la deuda que el contrato tendría con cada participante. Esa deuda se reflejaría continuamente en los timeout trees, de forma que el usuario siempre tendría disponible una salida hacia la red Bitcoin equivalente al monto que el contrato le debe, incluso mientras sus fondos están bajo control del programa.
Para que el mecanismo funcione correctamente, Keceli describe una regla interna de la máquina virtual de Cube: la suma de todos los montos registrados en el espacio de sombra nunca podría superar el Bitcoin que el contrato efectivamente custodia. Si esa condición se viola, la operación que haga en Cube sería rechazada automáticamente. Esto buscaría garantizar que siempre haya fondos reales respaldando cada salida unilateral posible.
En ese contexto, mientras el debate sobre las L2 de Bitcoin con programabilidad oscila entre los sistemas que logran contratos complejos cediendo algún grado de custodia, y los que preservan la soberanía del usuario pero con funcionalidad limitada, Cube, una de las más recientes de esas propuestas, intenta no ceder en ninguno de los dos frentes. Sin embargo, si el diseño resiste el escrutinio técnico y llega a implementarse es, todavía, una pregunta abierta.
