Babylon permite que os detentores de BTC garantam a segurança das cadeias PoS por meio da delegação a um Finality Provider (FP). A narrativa faz sentido. Mas a maior parte das discussões pula um papel-chave no meio: o próprio FP.$EUL
Os detentores de BTC delegam as moedas ao FP, e o FP é responsável por assinar com finalidade (finalidade) para a cadeia PoS alvo. Se o FP assinar duas vezes, o mecanismo EOTS expõe a chave privada e o BTC é confiscado (punido). Portanto, o risco dos detentores depende do comportamento do FP — escolhendo um FP confiável, o modelo de segurança se sustenta; escolhendo um FP não confiável, o BTC pode ser punido por erros do FP.
O problema é: como os detentores escolhem o FP? Atualmente, a interface de Staking da Babylon mostra informações do FP como: nome, taxa de comissão e total de stake. Porém, ela não mostra o histórico operacional do FP — ele já omitiu assinaturas antes? Já foi contestado? As cadeias PoS que ele atende estão rodando normalmente? A versão do software do FP é a mais recente? Essas informações não são visíveis no Staking.
Mais sutil ainda é a concentração do conjunto de FPs. Se muitos BTC forem delegados ao mesmo FP, o comportamento desse FP determina o estado de segurança de uma grande quantidade de fundos. A documentação da Babylon também menciona a necessidade de diversificar os FPs, mas nesta fase ainda é outra questão se a taxa de crescimento do conjunto de FPs consegue acompanhar a taxa de crescimento do volume de delegação de BTC.
@BabylonLabs_io verificou em testnet Phase-1 a viabilidade criptográfica do EOTS, e na Phase-2 foi implementado o fluxo real de delegação e punição/confisco. Mas viabilidade criptográfica e maturidade do ecossistema do FP são duas coisas diferentes. Ao delegar BTC, os detentores precisam avaliar não apenas se a cadeia PoS vale a pena ser protegida, mas também se o FP merece receber essa confiança. Se a transparência operacional do FP não for suficiente, o risco dos detentores não se limita aos riscos de protocolo da cadeia PoS — ele também vem dos riscos operacionais do FP.
Por isso, ao analisar o Staking de BTC da Babylon agora, eu não considero apenas quantos BTC foram travados; eu considero também a variação da concentração na lista de FPs e o histórico público de operação dos FPs. Se o BTC cresce rápido, mas o conjunto de FPs cresce devagar, a maior parte dos fundos fica concentrada em poucos FPs — e então a segurança do sistema depende de que esses FPs não cometam erros. Se o mecanismo de escolha dos FPs não for transparente, isso se torna outra forma de "confiar em poucas pessoas".#baby $BABY
Recentemente, a comunidade tem discutido os recursos de personalização dos parâmetros no teste de rede do TBV (@BabylonLabs_io ). Muita gente diz “finalmente não preciso ficar preso aos modelos fixos do protocolo”. Eu mesmo testei na prática as condições de restrição dos scripts multi-caminhos do Taproot e o processo de criação do vault — e vou compartilhar algumas visões diferentes.
O ponto mais marcante desta proposta é o nível de controle que o usuário tem sobre a garantia: as taxas de colateralização, o tempo de bloqueio e a linha de liquidação são definidos pelo próprio usuário e gravados diretamente no script do Taproot, sem passar por qualquer aprovação de administrador do protocolo. Para nós que já passamos por situações em que um protocolo DeFi força a liquidação e acaba fechando posições de forma inesperada, alinhar as condições de saída com nossa própria tolerância ao risco realmente é um grande avanço.$EUL
Mas, por mais livre que seja a brincadeira, a base ainda impõe um nível de exigência ao usuário que não pode ser ignorado. Como os parâmetros são definidos “de uma vez” ao criar o vault e ficam gravados no script do Bitcoin, eles não podem ser alterados de forma alguma depois — o que significa que, se você definir a taxa de colateralização errada, escolher um tempo de bloqueio inadequado ou subestimar a volatilidade do mercado em relação à linha de liquidação, o único caminho de correção é fechar o vault atual e recriá-lo. Isso envolve custos de duas transações no Bitcoin e uma rodada de sincronização de estado entre cadeias. Do lado do Aave, também não dá para ler a sua “intenção de mudar”; só se reconhece os valores já gravados no script. Esse tipo de cenário pode não ser comum, mas costuma ser justamente quando o usuário se dá mais mal: não é quando as operações são complexas, e sim quando a pessoa acha que já entendeu as regras e relaxa a vigilância.$DEXE
Nos últimos dias, configurei na testnet diferentes combinações de parâmetros e executei várias rodadas de validação. No geral, o fluxo de interação é extremamente suave, e dá para ver que o time fez um trabalho pesado no desenho dos caminhos do script. Mas, falando a verdade, a flexibilidade e a taxa de tolerância a falhas sempre entram em disputa; não existe nenhuma configuração que satisfaça, ao mesmo tempo, “deixar tudo à vontade” e “ter como corrigir facilmente quando errar”. Minha sugestão é que todos testem na testnet todas as combinações de parâmetros, mas ao criar o vault na mainnet não fixe de uma vez parâmetros de longo prazo: comece usando um curto tempo de bloqueio e um volume pequeno como teste. Só depois que estiver tudo bem é que vale aumentar. O pressuposto da liberdade de parâmetros é entender como cada parâmetro se comporta em condições extremas; manter três partes de sobriedade é o que permite usar bem as ferramentas de regras construídas por conta própria.#baby $BABY
O grupo recentemente deu um sinal de implementação ao conectar a Consumer Chain ao Babylon e tratá-la como uma camada compartilhada de segurança do BTC. Levei três dias para implantar todos os nós do Babylon Genesis testnet, sincronizar os dados de blocos e seguir, uma a uma, as etapas do processo de registro da Consumer Chain conforme a documentação oficial. Comparei trechos por trechos com a seção 7 do whitepaper, especificamente com a parte “BSN depende do Babylon para fornecer finalidade”, exportei vários conjuntos de logs de assinatura para validação cruzada. Eu tenho uma avaliação de longo prazo de que a segurança cross-chain só deve considerar a independência da fonte da finalidade final; não será afetada por dados operacionais nem pela quantidade de nós. Por isso, decomponho de maneira objetiva o desenho subjacente que sustenta a finalidade final da Consumer Chain @BabylonLabs_io .
Logo na abertura da seção 7 do whitepaper, aponta-se o principal dilema do modelo de segurança tradicional do IBC: duas cadeias usam seus próprios conjuntos de validadores para decidir a finalidade, e o nível de segurança das transações cross-chain depende do limite inferior de segurança de cada conjunto de validadores. A arquitetura do BSN mudou a abordagem — quando a Consumer Chain não produz blocos, a produção de blocos usa seus próprios validadores, mas a finalidade do bloco é confirmada pelos Finality Providers registrados on-chain na cadeia Babylon Genesis, por meio de assinaturas EOTS.
A própria Consumer Chain não precisa buscar outra camada de segurança; essencialmente, os problemas de segurança são delegados ao orçamento de segurança econômica do BTC do Babylon. $BABY , no ecossistema BSN, assume o consumo de gas para taxas de assinatura e validação de finalidade cross-chain. A operação da Consumer Chain precisa usar BABY para pagar as taxas de assinatura e recompensas para os FPs. Existe um vínculo direto entre token e mecanismo BSN; não há design de separação entre economia de tokens e camada de aplicação. $RIF
A taxa de produção de blocos da Consumer Chain precisa ser compatível com o ritmo de confirmação de finalidade do Babylon. O tempo de bloco na cadeia Babylon é de ~1 segundo; se a Consumer Chain produzir blocos rápido demais, acumulará uma grande fila de blocos aguardando a confirmação do Babylon. As assinaturas dos FPs dependem do status online dos EOTS Managers e da coordenação multisig do Covenant Committee; se o horizonte de manutenção de qualquer um dos lados for estendido, a confirmação de finalidade da Consumer Chain também será adiada.
As falhas de implementação na camada de integração do protocolo nascente não são uma exceção, e não se pode negar a direção de compartilhamento de segurança econômica do BTC apenas porque o caminho de registro da Consumer Chain não está fluindo bem no momento. Pessoalmente, apenas testei com um valor pequeno de BABY no testnet para ensaiar o fluxo de assinatura e validação cross-chain. Primeiro, familiarizei-me com o mecanismo de sincronização de finalidade entre a Consumer Chain e a cadeia Babylon; depois, fui aumentando gradualmente a participação em termos de volume. #baby
Sem perceber, já acompanhei a Binance por tanto tempo. Feliz 9º aniversário! Espero que a experiência continue melhorando cada vez mais, e que sigamos juntos explorando o mundo digital #BinanceTurns9