Nos últimos dias estive pesquisando como o Babylon “vende segurança”. Hoje mudo para a perspectiva do comprador — suponha que eu seja um desenvolvedor de uma nova rede: o que exatamente preciso fazer para integrar o Babylon?
O IBC é o ingresso. O Babylon se comunica com as cadeias consumidoras via IBC (protocolo de comunicação entre cadeias). Isso significa que a sua rede precisa suportar IBC para receber os direitos de segurança do Bitcoin. Para cadeias no ecossistema Cosmos, isso não é um obstáculo — o IBC é padrão. Mas para cadeias Solana ou baseadas em EVM, é necessário uma ponte extra.
Mas há uma armadilha para deixar claro: o IBC só transmite mensagens, não verifica se a mensagem é verdadeira ou não. Ele só consegue te dizer “o outro enviou uma mensagem”, sem garantir que essa mensagem corresponda ao estado honesto da cadeia. Por isso, o Babylon faz uma dupla garantia — a informação passa pelo canal IBC, mas o ponto final de ancoragem de segurança é o checkpoint na cadeia do Bitcoin. Depois de receber a mensagem via IBC, você pode verificar na cadeia do Bitcoin o checkpoint correspondente ao tempo, e checar se a mensagem está de acordo com o estado on-chain. Essa é a dupla validação: IBC + time stamp do Bitcoin.
@BabylonLabs_io $BABY #baby
Fragmentação de segurança. Várias cadeias compartilham o mesmo pool de Bitcoin colateral — parece economizar, mas surge um problema: se um validador malicioso em uma cadeia sofrer slashing, isso vai afetar as outras cadeias?
A abordagem do Babylon é isolar o contexto de slashing. Em termos simples: cada cadeia consumidora tem suas próprias regras de slashing e condições de descolateralização. Se o validador da cadeia A praticar má conduta, sua chave EOTS é exposta, mas apenas a parcela do capital que está colateralizada na cadeia A será penalizada. Se o mesmo validador também fornecer segurança para a cadeia B, a parte dele na cadeia B não é afetada. As relações de slashing de cada cadeia são independentes, como se fossem “sandbox de segurança” diferentes.
Quem controla as operações do seu colateral? O seu Bitcoin fica travado em um UTXO — quem tem permissão para movê-lo? O Babylon não depende de uma carteira multisig — isso seria centralizador demais. Ele utiliza um comitê de assinatura por limiar (Covenant Signers): algo em torno de uma dúzia de entidades independentes, e é necessário que mais de dois terços assinem para iniciar uma operação de descolateralização. Tecnologicamente, usa TSS (esquema de assinatura por limiar), o mesmo tipo de coisa que carteiras MPC. A diferença é que as permissões desse grupo de Covenant Signers são estritamente limitadas: só podem operar UTXOs cujo time lock já tenha expirado, e não conseguem mexer em fundos ainda em colateralização.
O IBC é o ingresso. O Babylon se comunica com as cadeias consumidoras via IBC (protocolo de comunicação entre cadeias). Isso significa que a sua rede precisa suportar IBC para receber os direitos de segurança do Bitcoin. Para cadeias no ecossistema Cosmos, isso não é um obstáculo — o IBC é padrão. Mas para cadeias Solana ou baseadas em EVM, é necessário uma ponte extra.
Mas há uma armadilha para deixar claro: o IBC só transmite mensagens, não verifica se a mensagem é verdadeira ou não. Ele só consegue te dizer “o outro enviou uma mensagem”, sem garantir que essa mensagem corresponda ao estado honesto da cadeia. Por isso, o Babylon faz uma dupla garantia — a informação passa pelo canal IBC, mas o ponto final de ancoragem de segurança é o checkpoint na cadeia do Bitcoin. Depois de receber a mensagem via IBC, você pode verificar na cadeia do Bitcoin o checkpoint correspondente ao tempo, e checar se a mensagem está de acordo com o estado on-chain. Essa é a dupla validação: IBC + time stamp do Bitcoin.
@BabylonLabs_io $BABY #baby
Fragmentação de segurança. Várias cadeias compartilham o mesmo pool de Bitcoin colateral — parece economizar, mas surge um problema: se um validador malicioso em uma cadeia sofrer slashing, isso vai afetar as outras cadeias?
A abordagem do Babylon é isolar o contexto de slashing. Em termos simples: cada cadeia consumidora tem suas próprias regras de slashing e condições de descolateralização. Se o validador da cadeia A praticar má conduta, sua chave EOTS é exposta, mas apenas a parcela do capital que está colateralizada na cadeia A será penalizada. Se o mesmo validador também fornecer segurança para a cadeia B, a parte dele na cadeia B não é afetada. As relações de slashing de cada cadeia são independentes, como se fossem “sandbox de segurança” diferentes.
Quem controla as operações do seu colateral? O seu Bitcoin fica travado em um UTXO — quem tem permissão para movê-lo? O Babylon não depende de uma carteira multisig — isso seria centralizador demais. Ele utiliza um comitê de assinatura por limiar (Covenant Signers): algo em torno de uma dúzia de entidades independentes, e é necessário que mais de dois terços assinem para iniciar uma operação de descolateralização. Tecnologicamente, usa TSS (esquema de assinatura por limiar), o mesmo tipo de coisa que carteiras MPC. A diferença é que as permissões desse grupo de Covenant Signers são estritamente limitadas: só podem operar UTXOs cujo time lock já tenha expirado, e não conseguem mexer em fundos ainda em colateralização.