Ontem à noite li o whitepaper de TBV da BabylonLabs e fiquei parado ao ver a parte de verificação com provas de conhecimento zero para withdrawal. Refiz o caminho de verificação e percebi que antes eu tinha simplificado demais o problema.@BabylonLabs_io
Eu sempre me perguntei: por que não permitir que a main chain do Bitcoin entenda diretamente as mudanças de estado de um protocolo externo? A resposta está nos limites de verificação. O design de scripts do Bitcoin, na essência, não foi feito para lidar com estados externos; se for forçado a fazê-lo, a lógica original de verificação muda. Por isso, o TBV seguiu um caminho mais contido. O protocolo externo produz um resultado; via mecanismo de prova, esse resultado é convertido em condições de gasto que o Bitcoin consegue verificar de forma independente. O Bitcoin só precisa checar se as condições enviadas estão de acordo com as regras.
No whitepaper oficial, eles repetem “Translation”. Pelo meu entendimento, isso significa traduzir o estado externo em condições de confiança verificáveis pelo Bitcoin. O protocolo externo produz um resultado de computação submetido a restrições de prova; o Bitcoin fica responsável por verificar. Os dois são conectados por provas criptográficas, e desde o início até o fim eles não compartilham a mesma fonte de confiança. Esse é o cerne da lógica de design do TBV.
Mas minimizar a confiança não significa ausência de risco. O light client da Babylon sincroniza cabeçalhos de blocos e verifica provas de Merkle; quando a rede Bitcoin sofre reorganização (reorg), transações de depósito em blocos isolados podem ser revertidas, enquanto os ativos na cadeia de contratos ainda podem já ter sido cunhados antecipadamente. Uma instituição de auditoria de segurança simulou uma situação: após a cadeia Babylon reiniciar com um crash, o light client ainda reconhece a altura antiga; um pool de mineração malicioso submete uma cadeia de bifurcação forjada e consegue passar na verificação. Essas são limitações decorrentes das características físicas do modo light client, não uma vulnerabilidade no nível do código. Para mitigar isso, foi introduzida a governança $BABY : detentores de tokens votam para confirmar o número de blocos. Na prática, isso é uma escolha de preferência por risco, e não um hardcoding técnico.
No fim das contas, o verdadeiro destaque do TBV não está em quantos cenários ele conecta, mas em permitir que o BTC participe de lógicas financeiras ainda mais complexas sem alterar o modelo de segurança do Bitcoin. O que vale atenção no BABY talvez não seja quantas aplicações ele conecta, e sim se essa forma de colaboração entre regras de verificação e computação externa consegue, de fato, abrir possibilidades novas.#baby
Eu sempre me perguntei: por que não permitir que a main chain do Bitcoin entenda diretamente as mudanças de estado de um protocolo externo? A resposta está nos limites de verificação. O design de scripts do Bitcoin, na essência, não foi feito para lidar com estados externos; se for forçado a fazê-lo, a lógica original de verificação muda. Por isso, o TBV seguiu um caminho mais contido. O protocolo externo produz um resultado; via mecanismo de prova, esse resultado é convertido em condições de gasto que o Bitcoin consegue verificar de forma independente. O Bitcoin só precisa checar se as condições enviadas estão de acordo com as regras.
No whitepaper oficial, eles repetem “Translation”. Pelo meu entendimento, isso significa traduzir o estado externo em condições de confiança verificáveis pelo Bitcoin. O protocolo externo produz um resultado de computação submetido a restrições de prova; o Bitcoin fica responsável por verificar. Os dois são conectados por provas criptográficas, e desde o início até o fim eles não compartilham a mesma fonte de confiança. Esse é o cerne da lógica de design do TBV.
Mas minimizar a confiança não significa ausência de risco. O light client da Babylon sincroniza cabeçalhos de blocos e verifica provas de Merkle; quando a rede Bitcoin sofre reorganização (reorg), transações de depósito em blocos isolados podem ser revertidas, enquanto os ativos na cadeia de contratos ainda podem já ter sido cunhados antecipadamente. Uma instituição de auditoria de segurança simulou uma situação: após a cadeia Babylon reiniciar com um crash, o light client ainda reconhece a altura antiga; um pool de mineração malicioso submete uma cadeia de bifurcação forjada e consegue passar na verificação. Essas são limitações decorrentes das características físicas do modo light client, não uma vulnerabilidade no nível do código. Para mitigar isso, foi introduzida a governança $BABY : detentores de tokens votam para confirmar o número de blocos. Na prática, isso é uma escolha de preferência por risco, e não um hardcoding técnico.
No fim das contas, o verdadeiro destaque do TBV não está em quantos cenários ele conecta, mas em permitir que o BTC participe de lógicas financeiras ainda mais complexas sem alterar o modelo de segurança do Bitcoin. O que vale atenção no BABY talvez não seja quantas aplicações ele conecta, e sim se essa forma de colaboração entre regras de verificação e computação externa consegue, de fato, abrir possibilidades novas.#baby