Viendo un montón de contratos en Ethereum, es fácil pensar que TBV finalmente acabará cediendo el control de BTC a otra cadena. Pero al desarmarlo de verdad, se descubre que @BabylonLabs_io divide el sistema en tres capas, con un propósito: que ninguna capa pueda reescribir el resultado por sí sola.
La primera capa está en Bitcoin. BTC se bloquea en salidas Taproot; los retiros normales, los retiros por liquidación y las respuestas ante disputas se escriben en diagramas de transacciones prefirmadas al construir el conjunto. Antes de la activación, aún hay HTLC de Pre-PegIn; como Ethereum no completó la activación, los usuarios pueden solicitar un reembolso unilateral después de que venza el tiempo de bloqueo. Bitcoin no entiende de préstamos: solo se encarga de custodiar “qué transacciones tienen permiso para gastar este UTXO”.
La segunda capa está en Ethereum. El contrato principal registra el ciclo de vida del Vault, el compromiso Hashlock y la promesa WOTS; gestiona los time locks, los participantes, el acceso a la aplicación y los límites de exposición. Luego, el Adapter traduce los préstamos, los reembolsos y las retiradas en operaciones del protocolo. En la actualidad, el adaptador registrado en la red de pruebas pública sigue siendo únicamente Aave v4 Adapter.
La tercera capa es el software fuera de cadena. El Vault Provider coordina la construcción del conjunto y las prefirmas. Roles como Application Vault Keeper y Universal Challenger escuchan ambas cadenas, guardan los materiales, generan o desafían pruebas de retiro y las envían en la siguiente transacción.
Lo importante no es solo la “colaboración en tres capas”, sino que cuando fallan, las consecuencias son distintas: si el contrato de Ethereum falla, afecta el registro contable y el negocio; si los roles fuera de cadena quedan sin conexión, se retrasa la salida. Pero aun así, ninguno de ellos puede crear por sí solo una salida de Bitcoin que no estuviera prefirmada. Al revés, incluso si los scripts de Bitcoin fueran más seguros, no pueden sustituir oráculos, la gestión de riesgos de la aplicación ni los retadores en línea.
Por eso TBV no elimina la confianza: separa el control de los activos, el estado del negocio y la actividad de ejecución, de modo que el fallo de una sola capa no se convierta directamente en la pérdida de la propiedad de BTC. Antes del lanzamiento en mainnet, auditaré estas tres capas por separado, en lugar de limitarme a comprobar una frase como “BTC se queda en la cadena original”.
#baby $BABY
La primera capa está en Bitcoin. BTC se bloquea en salidas Taproot; los retiros normales, los retiros por liquidación y las respuestas ante disputas se escriben en diagramas de transacciones prefirmadas al construir el conjunto. Antes de la activación, aún hay HTLC de Pre-PegIn; como Ethereum no completó la activación, los usuarios pueden solicitar un reembolso unilateral después de que venza el tiempo de bloqueo. Bitcoin no entiende de préstamos: solo se encarga de custodiar “qué transacciones tienen permiso para gastar este UTXO”.
La segunda capa está en Ethereum. El contrato principal registra el ciclo de vida del Vault, el compromiso Hashlock y la promesa WOTS; gestiona los time locks, los participantes, el acceso a la aplicación y los límites de exposición. Luego, el Adapter traduce los préstamos, los reembolsos y las retiradas en operaciones del protocolo. En la actualidad, el adaptador registrado en la red de pruebas pública sigue siendo únicamente Aave v4 Adapter.
La tercera capa es el software fuera de cadena. El Vault Provider coordina la construcción del conjunto y las prefirmas. Roles como Application Vault Keeper y Universal Challenger escuchan ambas cadenas, guardan los materiales, generan o desafían pruebas de retiro y las envían en la siguiente transacción.
Lo importante no es solo la “colaboración en tres capas”, sino que cuando fallan, las consecuencias son distintas: si el contrato de Ethereum falla, afecta el registro contable y el negocio; si los roles fuera de cadena quedan sin conexión, se retrasa la salida. Pero aun así, ninguno de ellos puede crear por sí solo una salida de Bitcoin que no estuviera prefirmada. Al revés, incluso si los scripts de Bitcoin fueran más seguros, no pueden sustituir oráculos, la gestión de riesgos de la aplicación ni los retadores en línea.
Por eso TBV no elimina la confianza: separa el control de los activos, el estado del negocio y la actividad de ejecución, de modo que el fallo de una sola capa no se convierta directamente en la pérdida de la propiedad de BTC. Antes del lanzamiento en mainnet, auditaré estas tres capas por separado, en lugar de limitarme a comprobar una frase como “BTC se queda en la cadena original”.
#baby $BABY