Estos días he estado investigando cómo Babylon “vende seguridad”. Hoy paso a la perspectiva del comprador: si yo fuera un desarrollador de una cadena nueva, ¿qué tendría que hacer para integrar Babylon?
IBC es la entrada. Babylon se comunica con la cadena de consumidores mediante IBC (protocolo de comunicación entre cadenas). Esto significa que tu cadena debe ser compatible con IBC para poder recibir los derechos de seguridad de Bitcoin de Babylon. Para las cadenas del ecosistema Cosmos, esto no es un obstáculo: IBC es la configuración estándar. Pero para cadenas de Solana o del ecosistema EVM, necesitas un puente adicional.
Pero hay un detalle importante que hay que aclarar: IBC solo se encarga de transmitir mensajes, no de verificar si el contenido del mensaje es verdadero o falso. Solo puede decirte “el otro emitió un mensaje”, pero no garantiza que ese mensaje corresponda a un estado honesto de la cadena. Por eso Babylon hace doble verificación: la información viaja por el canal de IBC, pero el ancla de seguridad final está en los checkpoints de la cadena de Bitcoin. Después de recibir el mensaje vía IBC, puedes verificar en la cadena de Bitcoin el checkpoint correspondiente a ese momento para ver si el mensaje coincide con el estado en cadena. Esa es la doble validación de IBC + timestamp de Bitcoin.
@BabylonLabs_io $BABY #baby
Fragmentación de la seguridad. Varias cadenas comparten el mismo pool de Bitcoin en garantía, lo que suena a ahorro, pero hay un problema: si un validador malicioso en una cadena es sancionado, ¿podría eso afectar a las demás cadenas?
La forma de actuar de Babylon es aislar el contexto de la sanción (slashing). En términos simples, cada cadena de consumidores tiene sus propias reglas de slashing y condiciones de desgarantía. Si el validador de la cadena A comete malas acciones y su clave EOTS se expone, solo se sanciona la parte de fondos que está en garantía en la cadena A. Si el mismo validador también proporciona seguridad a la cadena B, esa parte en B no se ve afectada. Las reglas de slashing de cada cadena son independientes, como “bancos de pruebas de seguridad” diferentes.
¿Quién controla tus operaciones de garantía? Tu Bitcoin bloqueado está dentro de un UTXO; ¿quién tiene permiso para moverlo? Babylon no depende de una wallet multisig: eso sería demasiado centralizado. En su lugar, utiliza un comité de firma por umbral (Covenant Signers): aproximadamente una docena de entidades independientes, y se necesita la firma de más de dos tercios para iniciar una operación de desgarantía. Técnicamente utiliza TSS (un esquema de firma por umbral), que es la misma base que una wallet MPC. La diferencia es que los permisos de estos Covenant Signers están estrictamente limitados: solo pueden operar con UTXOs cuyo tiempo de bloqueo ya haya vencido, pero no pueden mover los fondos que aún están en garantía.
IBC es la entrada. Babylon se comunica con la cadena de consumidores mediante IBC (protocolo de comunicación entre cadenas). Esto significa que tu cadena debe ser compatible con IBC para poder recibir los derechos de seguridad de Bitcoin de Babylon. Para las cadenas del ecosistema Cosmos, esto no es un obstáculo: IBC es la configuración estándar. Pero para cadenas de Solana o del ecosistema EVM, necesitas un puente adicional.
Pero hay un detalle importante que hay que aclarar: IBC solo se encarga de transmitir mensajes, no de verificar si el contenido del mensaje es verdadero o falso. Solo puede decirte “el otro emitió un mensaje”, pero no garantiza que ese mensaje corresponda a un estado honesto de la cadena. Por eso Babylon hace doble verificación: la información viaja por el canal de IBC, pero el ancla de seguridad final está en los checkpoints de la cadena de Bitcoin. Después de recibir el mensaje vía IBC, puedes verificar en la cadena de Bitcoin el checkpoint correspondiente a ese momento para ver si el mensaje coincide con el estado en cadena. Esa es la doble validación de IBC + timestamp de Bitcoin.
@BabylonLabs_io $BABY #baby
Fragmentación de la seguridad. Varias cadenas comparten el mismo pool de Bitcoin en garantía, lo que suena a ahorro, pero hay un problema: si un validador malicioso en una cadena es sancionado, ¿podría eso afectar a las demás cadenas?
La forma de actuar de Babylon es aislar el contexto de la sanción (slashing). En términos simples, cada cadena de consumidores tiene sus propias reglas de slashing y condiciones de desgarantía. Si el validador de la cadena A comete malas acciones y su clave EOTS se expone, solo se sanciona la parte de fondos que está en garantía en la cadena A. Si el mismo validador también proporciona seguridad a la cadena B, esa parte en B no se ve afectada. Las reglas de slashing de cada cadena son independientes, como “bancos de pruebas de seguridad” diferentes.
¿Quién controla tus operaciones de garantía? Tu Bitcoin bloqueado está dentro de un UTXO; ¿quién tiene permiso para moverlo? Babylon no depende de una wallet multisig: eso sería demasiado centralizado. En su lugar, utiliza un comité de firma por umbral (Covenant Signers): aproximadamente una docena de entidades independientes, y se necesita la firma de más de dos tercios para iniciar una operación de desgarantía. Técnicamente utiliza TSS (un esquema de firma por umbral), que es la misma base que una wallet MPC. La diferencia es que los permisos de estos Covenant Signers están estrictamente limitados: solo pueden operar con UTXOs cuyo tiempo de bloqueo ya haya vencido, pero no pueden mover los fondos que aún están en garantía.