Supondo que a chave emergencial tenha sido comprometida, qual é o pior cenário: será que o BTC é redirecionado para outro destinatário, ou que um pagamento normal fica travado? Ao fazer modelagem de ameaças para o Trustless Bitcoin Vaults (TBV), é possível registrar os resultados em um formulário de três campos para ação manual.
No campo de perda de ativos, primeiro observe o script de recebimento. O destino de um Vault existente já é determinado no momento da criação: ele contém apenas o endereço do Depositor ou o endereço do liquidation arbitrageur, e a chave do Security Council não faz parte do conjunto de destinatários. Controlar o Council não cria, de forma alguma, um novo destinatário; além disso, não é possível substituir o endereço original pelo endereço de um atacante.
No entanto, o campo de interrupção de serviço não pode ser preenchido com “não”. O Council tem capacidade de impedir o payout, então um problema com a chave emergencial causa um impacto real de liveness: o fato de as moedas não terem sido recolhidas por ele não significa que os usuários possam concluir a saída conforme o plano original. Esse tipo de dano deve ser tratado como um evento de disponibilidade, e não ser ocultado pelo fato de os ativos não terem sido redirecionados.
No campo de exposição de condições, também é necessário listar as demais dependências. Embora o TBV reduza os riscos de custódia e de bridge, ainda utiliza contratos Ethereum, oráculos, ZK/BABE e pipelines de provas cross-chain; além disso, existem exigências de governança e de disponibilidade por parte dos operadores. Nem todas essas exigências pertencem ao Council, mas todas afetam “se é possível cumprir as condições”.
Portanto, a sequência temporal é: verificar o conjunto de destinos na criação; quando ocorrer uma anomalia, avaliar se o payout foi bloqueado; e, ao continuar a disposição, checar as provas, os contratos e as condições operacionais. Os três campos correspondem a três tipos de consequências e não devem ser fundidos na frase “como há multisig, então é custódia”.
No fim, esta ficha apresenta apenas conclusões limitadas: poderes emergenciais podem causar interrupção de serviço, mas não permitem inferir um direito de saque via redirecionamento; a direção dos ativos é restrita, mas isso também não permite afirmar que o sistema não é afetado pela governança. Ao categorizar o pior resultado, fica claro o que deve ser prevenido — roubo ou inatividade.
@BabylonLabs_io $BABY #baby
No campo de perda de ativos, primeiro observe o script de recebimento. O destino de um Vault existente já é determinado no momento da criação: ele contém apenas o endereço do Depositor ou o endereço do liquidation arbitrageur, e a chave do Security Council não faz parte do conjunto de destinatários. Controlar o Council não cria, de forma alguma, um novo destinatário; além disso, não é possível substituir o endereço original pelo endereço de um atacante.
No entanto, o campo de interrupção de serviço não pode ser preenchido com “não”. O Council tem capacidade de impedir o payout, então um problema com a chave emergencial causa um impacto real de liveness: o fato de as moedas não terem sido recolhidas por ele não significa que os usuários possam concluir a saída conforme o plano original. Esse tipo de dano deve ser tratado como um evento de disponibilidade, e não ser ocultado pelo fato de os ativos não terem sido redirecionados.
No campo de exposição de condições, também é necessário listar as demais dependências. Embora o TBV reduza os riscos de custódia e de bridge, ainda utiliza contratos Ethereum, oráculos, ZK/BABE e pipelines de provas cross-chain; além disso, existem exigências de governança e de disponibilidade por parte dos operadores. Nem todas essas exigências pertencem ao Council, mas todas afetam “se é possível cumprir as condições”.
Portanto, a sequência temporal é: verificar o conjunto de destinos na criação; quando ocorrer uma anomalia, avaliar se o payout foi bloqueado; e, ao continuar a disposição, checar as provas, os contratos e as condições operacionais. Os três campos correspondem a três tipos de consequências e não devem ser fundidos na frase “como há multisig, então é custódia”.
No fim, esta ficha apresenta apenas conclusões limitadas: poderes emergenciais podem causar interrupção de serviço, mas não permitem inferir um direito de saque via redirecionamento; a direção dos ativos é restrita, mas isso também não permite afirmar que o sistema não é afetado pela governança. Ao categorizar o pior resultado, fica claro o que deve ser prevenido — roubo ou inatividade.
@BabylonLabs_io $BABY #baby