Quando a “autocustódia nativa” lota a tela e domina as conversas, eu fico encarando o whitepaper da Babylon — mas o que não sai da minha cabeça é o multisig 6-out-of-9 do Covenant Committee。
Para entender esse “descompasso”, primeiro é preciso descascar a cebola da Babylon. O modelo Taproot do Bitcoin garante propriedade, mas quando a lógica de slashing fica complexa, o Script nativo ainda fica aquém. Por isso, a Babylon introduziu o Covenant Committee. Isso não é um aumento deliberado de centralização, e sim uma concessão de engenharia dentro das limitações atuais de script. Esses nove nós se parecem mais com “executores de regras”, usando o mecanismo de multisig para garantir que o BTC flua apenas pelos caminhos definidos pelo protocolo.
Daí surge a elegância — e a crueldade — do EOTS. O design das chaves para dupla assinatura (FP) que revela automaticamente a chave privada é quase uma obra de arte; uma dupla assinatura maliciosa queimaria diretamente 33,33% do principal. Mas a elegância no nível de engenharia muitas vezes convive com a realidade dura: uma dupla assinatura acidental causada por bifurcação extrema ou bug de nó pode, na prática on-chain, parecer idêntica a uma dupla assinatura maliciosa. Se acontecer um incidente operacional com FP, um único erro pode fazer o principal virar pó. Nesse modelo, escolher FP em vez de um Staking tradicional para validar praticamente não é diferente; a Babylon apenas colocou uma “roupagem narrativa” de “autocustódia”.
Indo mais a fundo, o mecanismo TBV tenta resolver o problema final: permitir que o BTC seja usado como colateral na Ethereum, sem virar uma forma de “encapsular” BTC. O TBV não move o BTC: o BTC do depositante permanece sempre travado no script Taproot do Bitcoin, e o contrato na Ethereum só rastreia o estado do cofre. Isso é mais como um número interno gerado pelo banco ao dar um imóvel em garantia — a “certidão original” continua no livro-razão do Bitcoin.
Ainda assim, “Trustless” não é de jeito nenhum “Riskless”. A espinha dorsal do TBV é o BitVM3, e esse modelo tem um calcanhar de Aquiles: alguém precisa estar disposto a gastar Gas durante o período de challenge para acompanhar e submeter o desafio. Na prática, muito provavelmente o equilíbrio de jogo depende de instituições sustentarem o jogo. E, além disso, o período de challenge se sobrepõe ao Unbonding Period: em condições de mercado extremas, o risco de atraso na liquidação é real.
No fim das contas, a Babylon brincou o script com criatividade — mas quanto maior a complexidade, mais “casos de borda” aparecem. O que realmente devemos observar não é quantos BTC ela consegue atrair, e sim se o Covenant Committee conseguirá se enfraquecer à medida que as capacidades nativas do Bitcoin evoluam. Se no futuro o Script conseguir expressar mais lógica, o comitê de hoje será apenas uma transição; se não conseguir, isso se tornará um custo estrutural de longo prazo que o BTC passa a carregar ao entrar no mundo PoS.
#baby $BABY @BabylonLabs_io
Para entender esse “descompasso”, primeiro é preciso descascar a cebola da Babylon. O modelo Taproot do Bitcoin garante propriedade, mas quando a lógica de slashing fica complexa, o Script nativo ainda fica aquém. Por isso, a Babylon introduziu o Covenant Committee. Isso não é um aumento deliberado de centralização, e sim uma concessão de engenharia dentro das limitações atuais de script. Esses nove nós se parecem mais com “executores de regras”, usando o mecanismo de multisig para garantir que o BTC flua apenas pelos caminhos definidos pelo protocolo.
Daí surge a elegância — e a crueldade — do EOTS. O design das chaves para dupla assinatura (FP) que revela automaticamente a chave privada é quase uma obra de arte; uma dupla assinatura maliciosa queimaria diretamente 33,33% do principal. Mas a elegância no nível de engenharia muitas vezes convive com a realidade dura: uma dupla assinatura acidental causada por bifurcação extrema ou bug de nó pode, na prática on-chain, parecer idêntica a uma dupla assinatura maliciosa. Se acontecer um incidente operacional com FP, um único erro pode fazer o principal virar pó. Nesse modelo, escolher FP em vez de um Staking tradicional para validar praticamente não é diferente; a Babylon apenas colocou uma “roupagem narrativa” de “autocustódia”.
Indo mais a fundo, o mecanismo TBV tenta resolver o problema final: permitir que o BTC seja usado como colateral na Ethereum, sem virar uma forma de “encapsular” BTC. O TBV não move o BTC: o BTC do depositante permanece sempre travado no script Taproot do Bitcoin, e o contrato na Ethereum só rastreia o estado do cofre. Isso é mais como um número interno gerado pelo banco ao dar um imóvel em garantia — a “certidão original” continua no livro-razão do Bitcoin.
Ainda assim, “Trustless” não é de jeito nenhum “Riskless”. A espinha dorsal do TBV é o BitVM3, e esse modelo tem um calcanhar de Aquiles: alguém precisa estar disposto a gastar Gas durante o período de challenge para acompanhar e submeter o desafio. Na prática, muito provavelmente o equilíbrio de jogo depende de instituições sustentarem o jogo. E, além disso, o período de challenge se sobrepõe ao Unbonding Period: em condições de mercado extremas, o risco de atraso na liquidação é real.
No fim das contas, a Babylon brincou o script com criatividade — mas quanto maior a complexidade, mais “casos de borda” aparecem. O que realmente devemos observar não é quantos BTC ela consegue atrair, e sim se o Covenant Committee conseguirá se enfraquecer à medida que as capacidades nativas do Bitcoin evoluam. Se no futuro o Script conseguir expressar mais lógica, o comitê de hoje será apenas uma transição; se não conseguir, isso se tornará um custo estrutural de longo prazo que o BTC passa a carregar ao entrar no mundo PoS.
#baby $BABY @BabylonLabs_io