Ao ver o TBV no whitepaper da @BabylonLabs_io , o que mais facilmente é ignorado não é a fórmula, mas uma frase bem discreta: Antes de criar o Vault, é necessário pré-assinar um conjunto de transações do Bitcoin, e talvez seja preciso que outras partes também assinem.

Essa frase parece comum, mas quanto mais penso, mais percebo que é crucial. A lógica do cofre do TBV foi feita para permitir que partes que não confiam uma na outra cooperem: os caminhos de gasto já são definidos com antecedência, as transações pré-assinadas “congelam” as regras futuras, e ninguém consegue alterar as condições de forma improvisada. Só que, assim que entra a ideia de “outras partes”, as coisas deixam de ser tão simples.

Por exemplo, em cenários de empréstimo, o liquidante pode precisar entrar no fluxo de assinatura; no ecossistema de stablecoins, um grande detentor de capital também pode precisar participar com antecedência. A cada signatário a mais, tecnicamente é “só mais uma chave”, mas na prática surgem vários problemas de coordenação: quem assina primeiro? quem assina depois? o que acontece se alguém ficar offline? o tempo excedido conta como falha ou como uma tentativa de novo? Isso não é ataque de hacker; são exatamente os pontos mais fáceis de travar em processos do dia a dia.#baby

Por isso, acho que a dificuldade do TBV não está apenas no Bitcoin Script, mas também na coordenação entre participantes. Dois indivíduos ainda conseguem fazer tudo fluir bem apenas com base em regras; quanto mais participantes entram, mais o fluxo de pré-assinatura deixa de ser apenas um problema criptográfico e vira um problema organizacional.$BTC

$BABY Se houver governança, de fato é possível padronizar processos como ordem de assinatura, tratamento de timeouts e rollback de exceções. Mas isso também traz uma contradição sutil: quanto mais se tenta reduzir a confiança manual, mais é preciso deixar as regras de colaboração claramente definidas; quanto mais regras, maior também o custo da governança.$ETH