Hoy justo me topé en el documento TBV con el capítulo de “principio de funcionamiento” sobre el @BabylonLabs_io . Al principio creí que el depósito y la hipoteca eran dos operaciones separadas: primero, bloquear el BTC en un script de Bitcoin, y luego esperar a que del lado de Ethereum se vaya confirmando y haciendo efectivo poco a poco. Al terminar, me di cuenta de que esa comprensión era incorrecta; el término oficial que usan es “atomicamente binds” (atomically binds). Significa que estas dos cosas ni siquiera tienen un orden previo: son dos caras del mismo acto.
En concreto: el paso de activar el colateral enlaza “la efectividad del colateral de BTC en el lado de Ethereum” con “el BTC quedando bloqueado dentro del script de Taproot” como un todo inseparable. Es decir, o ambas partes se cumplen simultáneamente, o ninguna se cumple; no existe un estado intermedio en el que “el BTC ya está bloqueado, pero Ethereum todavía no ha reaccionado”, y tampoco existe el caso inverso. Del lado del reembolso se sigue otra lógica: con base en el procedimiento de desafío de BABE, el script de Bitcoin solo utiliza los primitivos existentes de Bitcoin Script para verificar la prueba del evento de reembolso ocurrido en Ethereum; no hace falta que Bitcoin haga ningún hard fork.#baby
Creo que la restricción específica a la que apunta este diseño es la siguiente: si los estados de ambos lados pudieran confirmarse por separado, necesariamente aparecería una “brecha de regateo” (game-theoretic gap). Por ejemplo, que el BTC ya esté bloqueado, pero la otra parte no confirme durante mucho tiempo del lado de Ethereum: esto es una variante del “problema de la opción gratuita” mencionado una y otra vez en el whitepaper. La vinculación atómica borra esa brecha de juego directamente a nivel físico.
Lo comparo con otro ejemplo: esto no es un flujo secuencial como “primero se firma el contrato y luego se pasa por notaría”, sino una liquidación simultánea en el mismo segundo entre comprador y vendedor. El dinero y la mercancía deben transferirse al mismo tiempo; no existe un estado intermedio en el que “se pagó el dinero pero no llegó la mercancía”, o “llegó la mercancía pero no se entregó el dinero”. Ese estado intermedio en sí es la raíz de que durante el pasado se necesitaran intermediarios que fueran dignos de confianza.
En cuanto al lado del reembolso, qué ventana de desafío específica sigue “verificar un evento de Ethereum usando primitivos existentes de Bitcoin Script” y qué ocurriría si falla: el documento de definición TBV solo menciona que está basado en BABE, pero no entra en los detalles de los parámetros. Esta parte aún hay que vigilar actualizaciones del documento.
Ahora, en la red de pruebas se está ejecutando Signet BTC contra activos simulados de Sepolia, sin riesgo real de fondos. Pero este diseño en dos fases —el bloqueo y la efectividad ocurren a la vez, y el reembolso por su cuenta recorre la verificación mediante desafío— es, por lo que he visto, la división de trabajo técnica más central en la capa de protocolo TBV.#baby $BABY
En concreto: el paso de activar el colateral enlaza “la efectividad del colateral de BTC en el lado de Ethereum” con “el BTC quedando bloqueado dentro del script de Taproot” como un todo inseparable. Es decir, o ambas partes se cumplen simultáneamente, o ninguna se cumple; no existe un estado intermedio en el que “el BTC ya está bloqueado, pero Ethereum todavía no ha reaccionado”, y tampoco existe el caso inverso. Del lado del reembolso se sigue otra lógica: con base en el procedimiento de desafío de BABE, el script de Bitcoin solo utiliza los primitivos existentes de Bitcoin Script para verificar la prueba del evento de reembolso ocurrido en Ethereum; no hace falta que Bitcoin haga ningún hard fork.#baby
Creo que la restricción específica a la que apunta este diseño es la siguiente: si los estados de ambos lados pudieran confirmarse por separado, necesariamente aparecería una “brecha de regateo” (game-theoretic gap). Por ejemplo, que el BTC ya esté bloqueado, pero la otra parte no confirme durante mucho tiempo del lado de Ethereum: esto es una variante del “problema de la opción gratuita” mencionado una y otra vez en el whitepaper. La vinculación atómica borra esa brecha de juego directamente a nivel físico.
Lo comparo con otro ejemplo: esto no es un flujo secuencial como “primero se firma el contrato y luego se pasa por notaría”, sino una liquidación simultánea en el mismo segundo entre comprador y vendedor. El dinero y la mercancía deben transferirse al mismo tiempo; no existe un estado intermedio en el que “se pagó el dinero pero no llegó la mercancía”, o “llegó la mercancía pero no se entregó el dinero”. Ese estado intermedio en sí es la raíz de que durante el pasado se necesitaran intermediarios que fueran dignos de confianza.
En cuanto al lado del reembolso, qué ventana de desafío específica sigue “verificar un evento de Ethereum usando primitivos existentes de Bitcoin Script” y qué ocurriría si falla: el documento de definición TBV solo menciona que está basado en BABE, pero no entra en los detalles de los parámetros. Esta parte aún hay que vigilar actualizaciones del documento.
Ahora, en la red de pruebas se está ejecutando Signet BTC contra activos simulados de Sepolia, sin riesgo real de fondos. Pero este diseño en dos fases —el bloqueo y la efectividad ocurren a la vez, y el reembolso por su cuenta recorre la verificación mediante desafío— es, por lo que he visto, la división de trabajo técnica más central en la capa de protocolo TBV.#baby $BABY