Vou ser honesto: quando mergulhei pela primeira vez nas documentações de corte (slashing) do Babylon, algo não parecia certo. O protocolo explicitamente só aplica slashing por equivocação (double-signing). Downtime? Votos perdidos? Zero penalidade. Não há slashing por falhar em assinar checkpoints de finalidade.
Eis a teoria dos jogos que quase ninguém discute. Um Finality Provider pode apostar 100 BTC, aceitar delegações, obter rendimento — e simplesmente parar de assinar as assinaturas de finalidade para um BSN. O BSN perde a finalidade respaldada por Bitcoin, mas o BTC do FP? Nunca fica em risco. Eles nunca fizeram equivocação; apenas ficaram em silêncio.
A rede Vigilante? Ela monitora equivocações maliciosas. Ela não consegue “slash” por silêncio porque o script do Bitcoin não suporta provas de downtime. O Babylon herda essa falha do próprio Bitcoin: ele consegue punir o que você assina, mas não quando você assina.
Isso cria uma estratégia de “Passthrough Parasite”: obter rendimento enquanto entrega zero saída de segurança. Espere a janela de desativação (unbonding) de 2 dias, saque limpo e repita. Um BSN garantido por 51% de FPs honestos poderia instantaneamente degradar para 0% de segurança se eles coordenarem um “ataque de liveness” — sem slashing, sem perdas, apenas um apagão temporário que poderia liquidar posições de DeFi que dependem dessa finalidade.
O protocolo até rastreia a liveness por meio de uma janela deslizante, com punição por encarceramento (jailing) ao perder votos demais. Mas um provedor pode sair do conjunto ativo perto do limite e redefinir o contador de faltas antes que isso acione o jailing.
Nenhum outro protocolo de staking tem essa mesma brecha, porque eles impõem penalidades de uptime via mecanismos de heartbeat em cadeia. O Babylon não consegue — ele depende da limitação de scripting do Bitcoin. Isso faz com que a camada de segurança do Babylon seja, inerentemente, uma liveness voluntária. Uma distinção sutil, porém devastadora..
@BabylonLabs_io $BABY #baby $BLESS $ELON
Eis a teoria dos jogos que quase ninguém discute. Um Finality Provider pode apostar 100 BTC, aceitar delegações, obter rendimento — e simplesmente parar de assinar as assinaturas de finalidade para um BSN. O BSN perde a finalidade respaldada por Bitcoin, mas o BTC do FP? Nunca fica em risco. Eles nunca fizeram equivocação; apenas ficaram em silêncio.
A rede Vigilante? Ela monitora equivocações maliciosas. Ela não consegue “slash” por silêncio porque o script do Bitcoin não suporta provas de downtime. O Babylon herda essa falha do próprio Bitcoin: ele consegue punir o que você assina, mas não quando você assina.
Isso cria uma estratégia de “Passthrough Parasite”: obter rendimento enquanto entrega zero saída de segurança. Espere a janela de desativação (unbonding) de 2 dias, saque limpo e repita. Um BSN garantido por 51% de FPs honestos poderia instantaneamente degradar para 0% de segurança se eles coordenarem um “ataque de liveness” — sem slashing, sem perdas, apenas um apagão temporário que poderia liquidar posições de DeFi que dependem dessa finalidade.
O protocolo até rastreia a liveness por meio de uma janela deslizante, com punição por encarceramento (jailing) ao perder votos demais. Mas um provedor pode sair do conjunto ativo perto do limite e redefinir o contador de faltas antes que isso acione o jailing.
Nenhum outro protocolo de staking tem essa mesma brecha, porque eles impõem penalidades de uptime via mecanismos de heartbeat em cadeia. O Babylon não consegue — ele depende da limitação de scripting do Bitcoin. Isso faz com que a camada de segurança do Babylon seja, inerentemente, uma liveness voluntária. Uma distinção sutil, porém devastadora..
@BabylonLabs_io $BABY #baby $BLESS $ELON