Impede o Payout, mas não significa que consegue reescrever o destino do BTC
Nos Trustless Bitcoin Vaults (TBV), o Security Council pode facilmente ser interpretado de forma errada como se detivesse uma multisig com controle sobre o BTC. A testnet pública atual usa 5 chaves públicas do Bitcoin e 3-de-5 de quorum legal: as chaves públicas são gravadas em parâmetros off-chain do protocolo versionado, para assinar conjuntamente o CouncilNoPayout. Ele consegue bloquear o Payout de um Vault específico, mas não consegue direcionar o BTC para um novo endereço indicado pelo Council.
A limitação vem do diagrama de saídas do Bitcoin já fixado no momento da criação do Vault. Os depositantes pré-assinam o Payout e determinam o destino legal: uma saída normal ou o self-claim, nas condições já existentes, retornam ao endereço do depositante, sem necessidade de aprovação do Council; já o caminho de liquidação segue para o endereço autorizado do Application Vault Keeper. As chaves do Council não estão entre esses destinos de recebimento, portanto, mesmo ao atingir o quorum, há apenas poder de bloqueio, não poder de redirecionar ativos.
Isso é diferente do No-Payout que o challenger transmite no fluxo normal de disputas: aquele é baseado no fato de que um Claim inválido é contestado e não pode ser refutado; o CouncilNoPayout é usado para falhas extremas ou recuperações especiais que o mecanismo padrão não consegue tratar. O pause do lado do Ethereum é outra camada: ele consegue pausar ações da aplicação, mas não consegue reescrever os caminhos já existentes de Pre-PegIn refund e WOTS self-claim.
O CouncilNoPayout mudou meus critérios de avaliação: eu deixei de perguntar apenas se o sistema tem um comitê, e passei a perguntar o que ele consegue fazer o Bitcoin aceitar como resultado. Se ele consegue impedir saídas, ainda traz riscos de disponibilidade e de atraso na saída; se ele não consegue criar novos destinos, então o pior cenário fica limitado ao bloqueio, e não ao redirecionamento de ativos. Se as permissões do Council forem abusadas, um Payout legítimo ainda pode ser travado; se o Council ficar indisponível, também diminui a capacidade de recuperação de emergência, então não dá para escrever esse design como isento de risco.
@BabylonLabs_io define o Security Council como uma rede de segurança transitória, com o objetivo de desativar gradualmente seu poder conforme o protocolo amadureça. O que realmente vale observar não é apenas se a multisig existe, mas em qual etapa as permissões emergenciais ficam limitadas pelo caminho de gasto do Bitcoin.$BTC $ETH
$BABY
#baby
Nos Trustless Bitcoin Vaults (TBV), o Security Council pode facilmente ser interpretado de forma errada como se detivesse uma multisig com controle sobre o BTC. A testnet pública atual usa 5 chaves públicas do Bitcoin e 3-de-5 de quorum legal: as chaves públicas são gravadas em parâmetros off-chain do protocolo versionado, para assinar conjuntamente o CouncilNoPayout. Ele consegue bloquear o Payout de um Vault específico, mas não consegue direcionar o BTC para um novo endereço indicado pelo Council.
A limitação vem do diagrama de saídas do Bitcoin já fixado no momento da criação do Vault. Os depositantes pré-assinam o Payout e determinam o destino legal: uma saída normal ou o self-claim, nas condições já existentes, retornam ao endereço do depositante, sem necessidade de aprovação do Council; já o caminho de liquidação segue para o endereço autorizado do Application Vault Keeper. As chaves do Council não estão entre esses destinos de recebimento, portanto, mesmo ao atingir o quorum, há apenas poder de bloqueio, não poder de redirecionar ativos.
Isso é diferente do No-Payout que o challenger transmite no fluxo normal de disputas: aquele é baseado no fato de que um Claim inválido é contestado e não pode ser refutado; o CouncilNoPayout é usado para falhas extremas ou recuperações especiais que o mecanismo padrão não consegue tratar. O pause do lado do Ethereum é outra camada: ele consegue pausar ações da aplicação, mas não consegue reescrever os caminhos já existentes de Pre-PegIn refund e WOTS self-claim.
O CouncilNoPayout mudou meus critérios de avaliação: eu deixei de perguntar apenas se o sistema tem um comitê, e passei a perguntar o que ele consegue fazer o Bitcoin aceitar como resultado. Se ele consegue impedir saídas, ainda traz riscos de disponibilidade e de atraso na saída; se ele não consegue criar novos destinos, então o pior cenário fica limitado ao bloqueio, e não ao redirecionamento de ativos. Se as permissões do Council forem abusadas, um Payout legítimo ainda pode ser travado; se o Council ficar indisponível, também diminui a capacidade de recuperação de emergência, então não dá para escrever esse design como isento de risco.
@BabylonLabs_io define o Security Council como uma rede de segurança transitória, com o objetivo de desativar gradualmente seu poder conforme o protocolo amadureça. O que realmente vale observar não é apenas se a multisig existe, mas em qual etapa as permissões emergenciais ficam limitadas pelo caminho de gasto do Bitcoin.$BTC $ETH
$BABY
#baby