Conheça o desenvolvimento mais recente da Babylon e descubra que a versão otimizada do Bitcoin Script do TBV já foi levada para 0.4. Esta versão não tem como foco novas funcionalidades; o objetivo é mover a lógica de verificação de um estado da carteira que antes ficava na cadeia para um pré-cálculo fora da cadeia e, então, confirmá-la com uma assinatura única para enviar a transação. As mudanças ficam bem claras: a expectativa de espera de uma operação comum de peg-in caiu para cerca de 2,5 horas, uma nova compressão em relação ao início de junho. No design do TBV, o ponto que mais gerava hesitação, originalmente, era justamente a questão do tempo. Como o Bitcoin mainnet produz blocos mais devagar e a multisig também adiciona etapas extras, muitos ficavam travados na fase de testnet na etapa “a carteira precisa ficar online o tempo todo”. Agora, depois dessas alterações, os parâmetros de controle de risco do período de disputa de saques também começaram a ficar modularizados: é possível escolher ciclos de segurança diferentes conforme o tamanho do cofre. Coferes menores não precisam mais ser forçados a usar atrasos no nível institucional. $BTC
Há ainda um detalhe ignorado: as transições de estado do BTC dentro do cofre não passam mais pela validação completa de uma árvore de Merkle; em vez disso, elas recortam apenas um caminho de UTXO. Em outras palavras, sem sacrificar a confiabilidade, o gasto de gas é reduzido mais pela metade. Embora a Babylon em si não dependa de uma cadeia de smart contracts, essa etapa melhora indiretamente os custos de cross-chain quando, no futuro, houver integração com outros DeFi compatíveis com EVM. Afinal, ninguém quer depositar apenas uma BTC e acabar consumindo dias de lucro só em taxas.
$BABY , por outro lado, embora não esteja diretamente vinculado à distribuição de rendimentos do TBV, dá para ver no roadmap de atualizações de governança que, posteriormente, caso o TBV ative o “liquidity guidance” (orientação de liquidez) dentro do cofre, haverá votação por meio de sinal de Snapshot que contará com a participação de depositantes/holders que fizeram lock de BABY. Este ponto ainda não foi implementado, mas a direção já está bem clara: o TBV não é uma ilha, e o BABY está sendo inserido no circuito central de decisões. Em vez de ficar olhando para o preço no curto prazo, faz mais sentido entender primeiro essa lógica de cofre com minimização de confiança.
#baby @BabylonLabs_io $BABY
Há ainda um detalhe ignorado: as transições de estado do BTC dentro do cofre não passam mais pela validação completa de uma árvore de Merkle; em vez disso, elas recortam apenas um caminho de UTXO. Em outras palavras, sem sacrificar a confiabilidade, o gasto de gas é reduzido mais pela metade. Embora a Babylon em si não dependa de uma cadeia de smart contracts, essa etapa melhora indiretamente os custos de cross-chain quando, no futuro, houver integração com outros DeFi compatíveis com EVM. Afinal, ninguém quer depositar apenas uma BTC e acabar consumindo dias de lucro só em taxas.
$BABY , por outro lado, embora não esteja diretamente vinculado à distribuição de rendimentos do TBV, dá para ver no roadmap de atualizações de governança que, posteriormente, caso o TBV ative o “liquidity guidance” (orientação de liquidez) dentro do cofre, haverá votação por meio de sinal de Snapshot que contará com a participação de depositantes/holders que fizeram lock de BABY. Este ponto ainda não foi implementado, mas a direção já está bem clara: o TBV não é uma ilha, e o BABY está sendo inserido no circuito central de decisões. Em vez de ficar olhando para o preço no curto prazo, faz mais sentido entender primeiro essa lógica de cofre com minimização de confiança.
#baby @BabylonLabs_io $BABY
搞懂链下预计算怎么做到的
100%
2.5小时等待是真实测的吗
0%
1 Votos • Votação encerrada