#baby $BABY Da primeira vez que vi o TBV escrito como “trustless”, minha compreensão foi bem simples: não depende de um custodiante e não exige tantos papéis operacionais. Só depois de ler a documentação dos papéis do protocolo de @BabylonLabs_io é que percebi que o que foi removido não foram todos os participantes, mas sim o controle do BTC por um único custodiante.
O documento divide o TBV em um papel de usuário e quatro grupos de papéis operacionais: o Vault Provider é responsável pelo ciclo de vida do cofre; o Application Vault Keeper coordena a liquidação da aplicação; o Universal Challenger cuida de desafios entre aplicações; e o Security Council é um apoio emergencial de transição. Elas podem coordenar configurações, fornecer provas e fazer liquidações, mas nenhuma delas pode custodiar diretamente o BTC do usuário.
Isso me levou a perguntar: então, onde o TBV coloca a confiança? A resposta não é “não precisa confiar em ninguém”, mas sim que o poder originalmente concentrado em um custodiante é decomposto em condições de script, mecanismos de prova e múltiplos papéis. O usuário não precisa confiar que algum operador devolverá o BTC, mas precisa entender o que cada papel pode e não pode fazer.
O custo também fica bem claro. É difícil explicar todo o sistema apenas com três botões “depositar—emprestar—resgatar”; se o usuário não souber quem coordena seu Vault e qual grupo de papéis responde pelos desafios, quando algo der errado será difícil decidir o próximo passo: esperar, solicitar ou tratar uma exceção.
Por isso, prefiro entender o TBV como “eliminar o custódio de ponto único”, e não como “remover todos os participantes”. Para o BABY, a questão é se a interface consegue fazer o usuário entender essa tabela de papéis. Quanto mais papéis existem, mais evidente fica que não dá para resumir tudo com uma única frase de trustless.