Reviendo aquela semana em que eu tirei do arquivo e releí alguns casos típicos de falhas ao executar slashing no segmento de BTC Staking, quanto mais eu olho, mais sinto que o design do caminho de slashing do Babylon (EOTS) precisa ficar atento a um detalhe fácil de negligenciar. Do ponto de vista de participantes altamente envolvidos, depois que a chave privada do EOTS do FP é exposta, o Monitor consegue enviar a Slashing Tx para a rede Bitcoin a tempo? Isso é ainda mais digno de atenção do que a taxa de retorno anualizada que o protocolo declara.
Na comunidade, já houve muitas rodadas do modelo de usar tokens com inflação para pagar o orçamento de segurança. A rentabilidade, quando exibida, parece não tão baixa. Mas para um detentor que apostou BTC, o retorno real depende em grande parte da trajetória da taxa de câmbio do BABY em relação ao BTC. Em termos de ativos Bitcoin, por quanto tempo essa relação de liquidação conseguirá se manter depende de o BABY ter uma demanda contínua para absorver a saída da inflação.@BabylonLabs_io O que realmente precisa ser verificado é se ele consegue garantir a execução em tempo real da Slashing Tx sob os mais diversos cenários de taxas.
Para isso, o design da taxa de slashing não pode ser um parâmetro estático. Quando o Staker pré-assina a Slashing Tx em janeiro de 2024, a rede Bitcoin prevê Gas de 30 sats/vB. Seis meses depois, com a rede congestionada, o Gas dispara para 300 sats/vB; a Slashing Tx previamente assinada pode levar muito tempo para ser empacotada pelos mineradores.$BANK
Falando de forma objetiva: exigir que um Gas pré-estipulado escrito em um script de UTXO se adapte automaticamente ao congestionamento da rede está, de fato, um pouco além das capacidades atuais dos scripts do Bitcoin. Buscar demais adaptabilidade de taxas aumentaria a complexidade da construção da Slashing Tx pré-assinada e também tornaria mais pesado o fluxo de coordenação do Covenant Committee. Moeda sempre tem duas faces: taxas estáticas reduzem a complexidade do design, mas aumentam o risco de execução.$RIF
Mas, pessoalmente, minha posição é bem clara: nesse mecanismo final de segurança que é a execução de slashing, eu prefiro que o fluxo de construção da Slashing Tx do protocolo seja um pouco mais “torto/complexo”, do que permitir que o Gas pré-estipulado vire um espaço de evasão que o FP possa explorar. O Babylon, de fato, já está fazendo bem completo no design de EOTS e Covenant — isso é só a base. Quando a rede Bitcoin passar por um ciclo completo de alta e baixa, com flutuações de taxas, e as execuções da Slashing Tx em todos os ambientes de taxas puderem ser consultadas na cadeia, então é que essa engrenagem de slashing realmente mostrará do que é capaz.#baby $BABY
Na comunidade, já houve muitas rodadas do modelo de usar tokens com inflação para pagar o orçamento de segurança. A rentabilidade, quando exibida, parece não tão baixa. Mas para um detentor que apostou BTC, o retorno real depende em grande parte da trajetória da taxa de câmbio do BABY em relação ao BTC. Em termos de ativos Bitcoin, por quanto tempo essa relação de liquidação conseguirá se manter depende de o BABY ter uma demanda contínua para absorver a saída da inflação.@BabylonLabs_io O que realmente precisa ser verificado é se ele consegue garantir a execução em tempo real da Slashing Tx sob os mais diversos cenários de taxas.
Para isso, o design da taxa de slashing não pode ser um parâmetro estático. Quando o Staker pré-assina a Slashing Tx em janeiro de 2024, a rede Bitcoin prevê Gas de 30 sats/vB. Seis meses depois, com a rede congestionada, o Gas dispara para 300 sats/vB; a Slashing Tx previamente assinada pode levar muito tempo para ser empacotada pelos mineradores.$BANK
Falando de forma objetiva: exigir que um Gas pré-estipulado escrito em um script de UTXO se adapte automaticamente ao congestionamento da rede está, de fato, um pouco além das capacidades atuais dos scripts do Bitcoin. Buscar demais adaptabilidade de taxas aumentaria a complexidade da construção da Slashing Tx pré-assinada e também tornaria mais pesado o fluxo de coordenação do Covenant Committee. Moeda sempre tem duas faces: taxas estáticas reduzem a complexidade do design, mas aumentam o risco de execução.$RIF
Mas, pessoalmente, minha posição é bem clara: nesse mecanismo final de segurança que é a execução de slashing, eu prefiro que o fluxo de construção da Slashing Tx do protocolo seja um pouco mais “torto/complexo”, do que permitir que o Gas pré-estipulado vire um espaço de evasão que o FP possa explorar. O Babylon, de fato, já está fazendo bem completo no design de EOTS e Covenant — isso é só a base. Quando a rede Bitcoin passar por um ciclo completo de alta e baixa, com flutuações de taxas, e as execuções da Slashing Tx em todos os ambientes de taxas puderem ser consultadas na cadeia, então é que essa engrenagem de slashing realmente mostrará do que é capaz.#baby $BABY