#baby $BABY
Enquanto eu estudava Babylon, uma pergunta ficou me incomodando: se o Bitcoin não consegue entender o que aconteceu em uma cadeia PoS, como ele pode punir um Finality Provider desonesto?
Minha primeira suposição foi que o Babylon, de alguma forma, envia uma prova de má conduta de volta ao Bitcoin e pede que o script dele julgue o caso. Isso pareceu pouco realista porque o Bitcoin Script não consegue executar a lógica complexa de slashing usada por redes PoS.
A Seção 7.2 do Litepaper de Bitcoin Staking da Babylon mudou a forma como eu entendi o design. O Babylon não pede ao Bitcoin para interpretar o ataque inteiro. Em vez disso, o seu gadget de finalidade EOTS transforma double-signing em uma armadilha criptográfica.
Um Finality Provider compromete a aleatoriedade de assinatura para futuras alturas de blocos. Se ele votar em dois blocos conflitantes na mesma altura, a mesma aleatoriedade privada é reutilizada. Essas duas assinaturas podem expor a chave privada EOTS do provider. A chave exposta então pode completar as transações de slashing pré-construídas conectadas às suas delegações em BTC.
Minha percepção foi simples: o Bitcoin não precisa entender o crime; ele só precisa impor a transação de punição uma vez que o segredo criptográfico seja revelado.
Isso é uma forma inteligente de permitir que o BTC nativo seja slasheadável sem envolvê-lo nem movê-lo para outra cadeia. Mas isso também cria um risco operacional. A documentação do Babylon observa que bugs de software ou falhas de hardware podem expor Finality Providers honestos a slashing, por isso a proteção anti-slashing importa.
Para mim, a verdadeira inovação do Babylon não é apenas fazer staking de BTC self-custodial. É traduzir a má conduta em PoS para uma consequência que o Bitcoin consegue impor com scripting limitado.
@BabylonLabs_io
#BTC
Enquanto eu estudava Babylon, uma pergunta ficou me incomodando: se o Bitcoin não consegue entender o que aconteceu em uma cadeia PoS, como ele pode punir um Finality Provider desonesto?
Minha primeira suposição foi que o Babylon, de alguma forma, envia uma prova de má conduta de volta ao Bitcoin e pede que o script dele julgue o caso. Isso pareceu pouco realista porque o Bitcoin Script não consegue executar a lógica complexa de slashing usada por redes PoS.
A Seção 7.2 do Litepaper de Bitcoin Staking da Babylon mudou a forma como eu entendi o design. O Babylon não pede ao Bitcoin para interpretar o ataque inteiro. Em vez disso, o seu gadget de finalidade EOTS transforma double-signing em uma armadilha criptográfica.
Um Finality Provider compromete a aleatoriedade de assinatura para futuras alturas de blocos. Se ele votar em dois blocos conflitantes na mesma altura, a mesma aleatoriedade privada é reutilizada. Essas duas assinaturas podem expor a chave privada EOTS do provider. A chave exposta então pode completar as transações de slashing pré-construídas conectadas às suas delegações em BTC.
Minha percepção foi simples: o Bitcoin não precisa entender o crime; ele só precisa impor a transação de punição uma vez que o segredo criptográfico seja revelado.
Isso é uma forma inteligente de permitir que o BTC nativo seja slasheadável sem envolvê-lo nem movê-lo para outra cadeia. Mas isso também cria um risco operacional. A documentação do Babylon observa que bugs de software ou falhas de hardware podem expor Finality Providers honestos a slashing, por isso a proteção anti-slashing importa.
Para mim, a verdadeira inovação do Babylon não é apenas fazer staking de BTC self-custodial. É traduzir a má conduta em PoS para uma consequência que o Bitcoin consegue impor com scripting limitado.
@BabylonLabs_io
#BTC