Design central da Babylon: Separando Custódia, Consenso, Finalidade e Governança
Estava lendo o Babylon Genesis como se fosse um único sistema de segurança e então percebi que o design, na verdade, são quatro permissões que parecem agrupadas de longe.
A custódia fica no Bitcoin.
O consenso fica com os validadores do CometBFT.
A finalização vem dos Finality Providers.
a governança pertence aos titulares <$BABY > e seus delegados.
Essa separação mudou o diagrama para mim.
Quando o BTC é apostado por meio de @BabylonLabs_io, ele é bloqueado em um script nativo do Bitcoin, com autocustódia. O Finality Provider selecionado recebe poder de voto, não as moedas. Enviar votos de finalidade não faz dele o custodiante do Bitcoin.
Os apostadores de BABY delegam aos validadores do CometBFT, e esses validadores cuidam da produção de blocos e do consenso. Os Finality Providers ficam por cima, adicionando uma rodada separada de finalidade sustentada por BTC delegado.
Mesmo encadeamento.
Funções diferentes.
A parte que eu precisei reler foi a governança. Os apostadores de BTC podem fornecer segurança e ganhar recompensas de BABY, mas essa delegação de BTC não lhes dá automaticamente um voto de governança. As propostas passam pelo módulo de governança do Cosmos, onde os titulares de BABY e seus delegados votam.
O café estava esfriando enquanto eu voltava, repetidas vezes, à ideia de que cada função é incompleta por design.
Um Finality Provider pode votar na finalidade sem produzir o bloco ou manter o BTC. Um validador pode produzir blocos sem controlar a custódia do Bitcoin. Um eleitor de BABY pode influenciar regras de rede sem finalizar o encadeamento.
No começo, eu achava que a Babylon estava adicionando segurança do Bitcoin sobre um único sistema de validadores.
Uma leitura mais atenta fez parecer mais checks e limites: scripts do Bitcoin mantêm as condições de custódia, validadores rodam o consenso, Finality Providers adicionam finalidade apoiada por BTC, e a governança do BABY muda as regras.
Nenhuma função única deveria virar as quatro.
Essa separação torna a Babylon mais difícil de capturar, ou apenas dá aos usuários quatro centros de poder diferentes para monitorar?
#baby $BEAT @BabylonLabs_io $BABY
Estava lendo o Babylon Genesis como se fosse um único sistema de segurança e então percebi que o design, na verdade, são quatro permissões que parecem agrupadas de longe.
A custódia fica no Bitcoin.
O consenso fica com os validadores do CometBFT.
A finalização vem dos Finality Providers.
a governança pertence aos titulares <$BABY > e seus delegados.
Essa separação mudou o diagrama para mim.
Quando o BTC é apostado por meio de @BabylonLabs_io, ele é bloqueado em um script nativo do Bitcoin, com autocustódia. O Finality Provider selecionado recebe poder de voto, não as moedas. Enviar votos de finalidade não faz dele o custodiante do Bitcoin.
Os apostadores de BABY delegam aos validadores do CometBFT, e esses validadores cuidam da produção de blocos e do consenso. Os Finality Providers ficam por cima, adicionando uma rodada separada de finalidade sustentada por BTC delegado.
Mesmo encadeamento.
Funções diferentes.
A parte que eu precisei reler foi a governança. Os apostadores de BTC podem fornecer segurança e ganhar recompensas de BABY, mas essa delegação de BTC não lhes dá automaticamente um voto de governança. As propostas passam pelo módulo de governança do Cosmos, onde os titulares de BABY e seus delegados votam.
O café estava esfriando enquanto eu voltava, repetidas vezes, à ideia de que cada função é incompleta por design.
Um Finality Provider pode votar na finalidade sem produzir o bloco ou manter o BTC. Um validador pode produzir blocos sem controlar a custódia do Bitcoin. Um eleitor de BABY pode influenciar regras de rede sem finalizar o encadeamento.
No começo, eu achava que a Babylon estava adicionando segurança do Bitcoin sobre um único sistema de validadores.
Uma leitura mais atenta fez parecer mais checks e limites: scripts do Bitcoin mantêm as condições de custódia, validadores rodam o consenso, Finality Providers adicionam finalidade apoiada por BTC, e a governança do BABY muda as regras.
Nenhuma função única deveria virar as quatro.
Essa separação torna a Babylon mais difícil de capturar, ou apenas dá aos usuários quatro centros de poder diferentes para monitorar?
#baby $BEAT @BabylonLabs_io $BABY