#baby Eu vi recentemente o TBV de @BabylonLabs_io .
Comecei a não mais ficar de olho na página de depósito.
Em vez disso, foquei especificamente no que acontece depois que o Provider desaparece.
A resposta está escondida nos artifacts do par de chaves WOTS e do claimer.
Na criação do Vault.
O usuário recebe uma chave de assinatura única.
E também um conjunto completo de transações pré-assinadas e dados de desafio.
Essas coisas, no dia a dia, parecem anexos técnicos.
Mas, quando a situação realmente sai do controle, podem ser a única saída.
Vault Provider online.
Ele pode ajudar o usuário a concluir Claim, Assert e Payout.
Provider não responde.
Em teoria, o usuário ainda consegue executar as ferramentas de linha de comando, seguindo o caminho de transação pré-definido, para recuperar $BTC de volta para o endereço original.
Parece algo bem “não confiável”.
Mas eu imediatamente pensei em um cenário mais realista.
O Provider cai.
E o computador antigo do usuário também quebra.
Os arquivos WOTS existem apenas no dispositivo original.
Não há backup offline dos materiais de recuperação.
Nesse momento, o protocolo não faz confisco de ativos.
E o script também não impede a saída.
Mesmo assim, o usuário pode ainda estar diante da saída, porém sem encontrar a chave para abrir a porta.
Então “sem necessidade de aprovação do operador” é só o passo 1.
O próximo passo é fazer com que usuários comuns realmente tenham capacidade independente de recuperação.
Os dados que eu quero ver são bem simples.
Quantos usuários fizeram backup dos materiais.
Qual é a taxa de sucesso do Self-Claim.
Quanto tempo leva para uma recuperação completa.
Em que etapa a falha costuma ficar travada.
A narrativa da infraestrutura de $BABY pode ser bem ampla.
Mas se o TBV está maduro, não dá para avaliar apenas pelo quanto $BTC foi depositado com sucesso.
O verdadeiro teste de estresse é: quando todos os papéis de apoio não estão online, o usuário consegue levar os ativos completamente embora apenas com os arquivos que ele mesmo salvou.
#baby
Comecei a não mais ficar de olho na página de depósito.
Em vez disso, foquei especificamente no que acontece depois que o Provider desaparece.
A resposta está escondida nos artifacts do par de chaves WOTS e do claimer.
Na criação do Vault.
O usuário recebe uma chave de assinatura única.
E também um conjunto completo de transações pré-assinadas e dados de desafio.
Essas coisas, no dia a dia, parecem anexos técnicos.
Mas, quando a situação realmente sai do controle, podem ser a única saída.
Vault Provider online.
Ele pode ajudar o usuário a concluir Claim, Assert e Payout.
Provider não responde.
Em teoria, o usuário ainda consegue executar as ferramentas de linha de comando, seguindo o caminho de transação pré-definido, para recuperar $BTC de volta para o endereço original.
Parece algo bem “não confiável”.
Mas eu imediatamente pensei em um cenário mais realista.
O Provider cai.
E o computador antigo do usuário também quebra.
Os arquivos WOTS existem apenas no dispositivo original.
Não há backup offline dos materiais de recuperação.
Nesse momento, o protocolo não faz confisco de ativos.
E o script também não impede a saída.
Mesmo assim, o usuário pode ainda estar diante da saída, porém sem encontrar a chave para abrir a porta.
Então “sem necessidade de aprovação do operador” é só o passo 1.
O próximo passo é fazer com que usuários comuns realmente tenham capacidade independente de recuperação.
Os dados que eu quero ver são bem simples.
Quantos usuários fizeram backup dos materiais.
Qual é a taxa de sucesso do Self-Claim.
Quanto tempo leva para uma recuperação completa.
Em que etapa a falha costuma ficar travada.
A narrativa da infraestrutura de $BABY pode ser bem ampla.
Mas se o TBV está maduro, não dá para avaliar apenas pelo quanto $BTC foi depositado com sucesso.
O verdadeiro teste de estresse é: quando todos os papéis de apoio não estão online, o usuário consegue levar os ativos completamente embora apenas com os arquivos que ele mesmo salvou.
#baby