Para ser honesto, a arquitetura do Babylon é, sim, bonita em termos de ideia — “um protocolo nativo de staking do Bitcoin, projetado para estender a segurança do Bitcoin para outras redes”. Que o detentor de $BTC não faça ponte, não envolva empacotamento, não utilize custódia: faça staking direto do BTC. Mas, entre “bonito” e “seguro”, existe uma sequência de buracos ainda não preenchidos.
O Babylon roda apenas um light client de BTC e depende de intermediários externos para atualizar os cabeçalhos dos blocos do Bitcoin. O cenário divulgado pela Zellic me deixou apreensivo: durante a indisponibilidade (queda) do Babylon, a rede Bitcoin continua gerando blocos. Ao reiniciar, o light client ainda acredita que a altura mais recente é a mesma do momento anterior à queda. Um pool de mineração malicioso pode enviar antecipadamente uma cadeia bifurcada; o nó do Babylon pode temporariamente confundir a cadeia principal. O atacante não precisa vencer em poder de hash a rede principal do Bitcoin; basta rodar mais rápido que o intermediário (relay) honesto após o reinício.
A assinatura EOTS de uso único também não me deixou mais tranquilo. A Zellic descobriu que todos os esquemas de assinatura do Babylon baseados em Secp256k1 usam multiplicação escalar de tempo variável, o que abre uma vulnerabilidade de canal lateral de tempo, potencialmente permitindo vazamento de nonce e, com isso, recuperação da chave privada. Um aviso de segurança no GitHub também divulgou uma falha de replay de assinatura — o atacante pode injetar compromissos PubRand inválidos.
Os limites de travamento (locking) dos scripts do Bitcoin também são frágeis. A vulnerabilidade exposta pela GHSA-4rmq-mc2c-r495 mostra: quando um FP sai do conjunto ativo na mesma altura de bloco, os delegadores que já foram totalmente desvinculados do BTC ainda mantêm ActiveSatoshis não nulos — ou seja, continuam a receber recompensas com staking de 0 BTC.
A velocidade de geração de blocos das duas cadeias é completamente diferente, e há uma defasagem de alguns minutos no estado de staking. O módulo zoneconcierge do Babylon, ao processar pacotes IBC, usa a iteração não determinística de um map do Go; nós diferentes produzem ordens de travessia diferentes, o que faz toda a cadeia parar (halt).
Por fim, vem uma reação em cadeia causada pela congestão da rede BTC. No estágio Cap-1 de agosto de 2024, a taxa (Gas) do Bitcoin disparou de US$ 0,5 para US$ 132. Com um limite de staking de 1000 BTC, foram necessárias cerca de 21.000 transações para preencher 6 blocos e concluir o processo. O script de desempacotamento (unbonding) tem a taxa codificada (hard-coded) — por um tempo, o custo de desempacotamento chegou a representar 45% das taxas da rede Bitcoin.
Um protocolo em que a sobrevivência ou morte é determinada pelas condições de congestionamento da rede BTC — você tem certeza de que ele aguenta a próxima “guerra de Gas”?
#baby $BABY @BabylonLabs_io
O Babylon roda apenas um light client de BTC e depende de intermediários externos para atualizar os cabeçalhos dos blocos do Bitcoin. O cenário divulgado pela Zellic me deixou apreensivo: durante a indisponibilidade (queda) do Babylon, a rede Bitcoin continua gerando blocos. Ao reiniciar, o light client ainda acredita que a altura mais recente é a mesma do momento anterior à queda. Um pool de mineração malicioso pode enviar antecipadamente uma cadeia bifurcada; o nó do Babylon pode temporariamente confundir a cadeia principal. O atacante não precisa vencer em poder de hash a rede principal do Bitcoin; basta rodar mais rápido que o intermediário (relay) honesto após o reinício.
A assinatura EOTS de uso único também não me deixou mais tranquilo. A Zellic descobriu que todos os esquemas de assinatura do Babylon baseados em Secp256k1 usam multiplicação escalar de tempo variável, o que abre uma vulnerabilidade de canal lateral de tempo, potencialmente permitindo vazamento de nonce e, com isso, recuperação da chave privada. Um aviso de segurança no GitHub também divulgou uma falha de replay de assinatura — o atacante pode injetar compromissos PubRand inválidos.
Os limites de travamento (locking) dos scripts do Bitcoin também são frágeis. A vulnerabilidade exposta pela GHSA-4rmq-mc2c-r495 mostra: quando um FP sai do conjunto ativo na mesma altura de bloco, os delegadores que já foram totalmente desvinculados do BTC ainda mantêm ActiveSatoshis não nulos — ou seja, continuam a receber recompensas com staking de 0 BTC.
A velocidade de geração de blocos das duas cadeias é completamente diferente, e há uma defasagem de alguns minutos no estado de staking. O módulo zoneconcierge do Babylon, ao processar pacotes IBC, usa a iteração não determinística de um map do Go; nós diferentes produzem ordens de travessia diferentes, o que faz toda a cadeia parar (halt).
Por fim, vem uma reação em cadeia causada pela congestão da rede BTC. No estágio Cap-1 de agosto de 2024, a taxa (Gas) do Bitcoin disparou de US$ 0,5 para US$ 132. Com um limite de staking de 1000 BTC, foram necessárias cerca de 21.000 transações para preencher 6 blocos e concluir o processo. O script de desempacotamento (unbonding) tem a taxa codificada (hard-coded) — por um tempo, o custo de desempacotamento chegou a representar 45% das taxas da rede Bitcoin.
Um protocolo em que a sobrevivência ou morte é determinada pelas condições de congestionamento da rede BTC — você tem certeza de que ele aguenta a próxima “guerra de Gas”?
#baby $BABY @BabylonLabs_io