Lendo a especificação técnica de @BabylonLabs_io , o script de staking do Bitcoin usa OP_CHECKMULTISIGVERIFY para impor o requisito de quórum dos validadores. Mas aqui está a sutileza: o próprio script não codifica condições de slashing — ele apenas verifica se o número exigido de validadores assinou.
Isso significa que o bloqueio em Bitcoin é estruturalmente simples: ou o usuário faz o saque após o unbonding, hmm.. ou o conjunto de validadores assina para aplicar o slashing. A lógica real de slashing — o que constitui mau comportamento, quanto é cortado, quais validadores assinam — é inteiramente off-chain, aplicada pela cadeia Babylon Genesis, não pelo script do Bitcoin.
Então a camada Bitcoin fornece finalidade criptográfica para o bloqueio, mas as condições desse bloqueio são determinadas pelo estado da cadeia Babylon. Se a cadeia Babylon disser "o validador X se comportou mal, corte seus delegadores", o quórum de validadores assina a transação de slashing, e o Bitcoin a executa. Mas o Bitcoin não tem como verificar independentemente se o slashing foi justificado.
Isso inverte o modelo de confiança: o Bitcoin garante que o UTXO não possa ser gasto sem a assinatura do quórum, hmm.. mas não garante que o quórum use essa assinatura de forma honesta. A segurança migra do proof-of-work do Bitcoin para o consenso dos validadores da Babylon. A parte "nativa" é real, mas a parte "sem confiança" depende das mesmas suposições de qualquer chain PoS: que o conjunto de validadores seja honesto e economicamente alinhado.
Em comparação com uma bridge puramente baseada em Ethereum, a Babylon reduz a superfície de ataque para explorações — sem token embrulhado, sem risco de minting — mas não elimina a dependência dos validadores. O script de bloqueio é apenas uma ferramenta; a cadeia Babylon é o juiz.
Se o conjunto de validadores for comprometido, o script do Bitcoin oferece alguma defesa além de um bloqueio cuja chave os atacantes já controlam?
#baby $BABY
Isso significa que o bloqueio em Bitcoin é estruturalmente simples: ou o usuário faz o saque após o unbonding, hmm.. ou o conjunto de validadores assina para aplicar o slashing. A lógica real de slashing — o que constitui mau comportamento, quanto é cortado, quais validadores assinam — é inteiramente off-chain, aplicada pela cadeia Babylon Genesis, não pelo script do Bitcoin.
Então a camada Bitcoin fornece finalidade criptográfica para o bloqueio, mas as condições desse bloqueio são determinadas pelo estado da cadeia Babylon. Se a cadeia Babylon disser "o validador X se comportou mal, corte seus delegadores", o quórum de validadores assina a transação de slashing, e o Bitcoin a executa. Mas o Bitcoin não tem como verificar independentemente se o slashing foi justificado.
Isso inverte o modelo de confiança: o Bitcoin garante que o UTXO não possa ser gasto sem a assinatura do quórum, hmm.. mas não garante que o quórum use essa assinatura de forma honesta. A segurança migra do proof-of-work do Bitcoin para o consenso dos validadores da Babylon. A parte "nativa" é real, mas a parte "sem confiança" depende das mesmas suposições de qualquer chain PoS: que o conjunto de validadores seja honesto e economicamente alinhado.
Em comparação com uma bridge puramente baseada em Ethereum, a Babylon reduz a superfície de ataque para explorações — sem token embrulhado, sem risco de minting — mas não elimina a dependência dos validadores. O script de bloqueio é apenas uma ferramenta; a cadeia Babylon é o juiz.
Se o conjunto de validadores for comprometido, o script do Bitcoin oferece alguma defesa além de um bloqueio cuja chave os atacantes já controlam?
#baby $BABY