Diseño central de Babylon: Separar custodia, consenso, finalidad y gobernanza
Leía Babylon Genesis como si fuera un solo sistema de seguridad y luego me di cuenta de que el diseño en realidad son cuatro permisos que, vistos a distancia, parecen estar empaquetados.
la custodia permanece en Bitcoin.
el consenso recae en validadores de CometBFT.
la finalidad proviene de los Finality Providers.
gobernanza pertenece a los holders $BABY y a sus delegados.
esa separación cambió el diagrama para mí.
Cuando BTC se pone en staking a través de @BabylonLabs_io, queda bloqueado en un script autocustodiado nativo de Bitcoin. El Finality Provider seleccionado recibe poder de voto, no las monedas. Enviar votos de finalidad no lo convierte en el custodio de Bitcoin.
Los stakers de BABY delegan a validadores de CometBFT, y esos validadores se encargan de la producción de bloques y del consenso. Los Finality Providers están por encima, añadiendo una ronda de finalidad separada respaldada por el BTC delegado.
La misma cadena.
Roles distintos.
La parte que tuve que releer fue la gobernanza. Los stakers de BTC pueden aportar seguridad y ganar recompensas en BABY, pero esa delegación de BTC no les da automáticamente un voto de gobernanza. Las propuestas se ejecutan a través del módulo de gobernanza de Cosmos, donde los holders de BABY y sus delegados votan.
El café se estaba enfriando mientras volvía una y otra vez a lo incompleta que es, por diseño, cada función.
Un Finality Provider puede votar sobre la finalidad sin producir el bloque ni mantener el BTC. Un validador puede producir bloques sin controlar la custodia de Bitcoin. Un votante BABY puede influir en las reglas de la red sin finalizar la cadena.
Al principio pensé que Babylon estaba superponiendo la seguridad de Bitcoin sobre un único sistema de validadores.
Una lectura más detenida hizo que pareciera más bien un sistema de comprobaciones y límites: los scripts de Bitcoin mantienen las condiciones de custodia, los validadores ejecutan el consenso, los Finality Providers añaden una finalidad respaldada por BTC y la gobernanza de BABY cambia las reglas.
No se supone que ningún rol llegue a convertirse en los cuatro.
¿Esa separación hace que Babylon sea más difícil de capturar, o solo le da a los usuarios cuatro centros de poder diferentes para monitorear?
#baby $BEAT @BabylonLabs_io $BABY
Leía Babylon Genesis como si fuera un solo sistema de seguridad y luego me di cuenta de que el diseño en realidad son cuatro permisos que, vistos a distancia, parecen estar empaquetados.
la custodia permanece en Bitcoin.
el consenso recae en validadores de CometBFT.
la finalidad proviene de los Finality Providers.
gobernanza pertenece a los holders $BABY y a sus delegados.
esa separación cambió el diagrama para mí.
Cuando BTC se pone en staking a través de @BabylonLabs_io, queda bloqueado en un script autocustodiado nativo de Bitcoin. El Finality Provider seleccionado recibe poder de voto, no las monedas. Enviar votos de finalidad no lo convierte en el custodio de Bitcoin.
Los stakers de BABY delegan a validadores de CometBFT, y esos validadores se encargan de la producción de bloques y del consenso. Los Finality Providers están por encima, añadiendo una ronda de finalidad separada respaldada por el BTC delegado.
La misma cadena.
Roles distintos.
La parte que tuve que releer fue la gobernanza. Los stakers de BTC pueden aportar seguridad y ganar recompensas en BABY, pero esa delegación de BTC no les da automáticamente un voto de gobernanza. Las propuestas se ejecutan a través del módulo de gobernanza de Cosmos, donde los holders de BABY y sus delegados votan.
El café se estaba enfriando mientras volvía una y otra vez a lo incompleta que es, por diseño, cada función.
Un Finality Provider puede votar sobre la finalidad sin producir el bloque ni mantener el BTC. Un validador puede producir bloques sin controlar la custodia de Bitcoin. Un votante BABY puede influir en las reglas de la red sin finalizar la cadena.
Al principio pensé que Babylon estaba superponiendo la seguridad de Bitcoin sobre un único sistema de validadores.
Una lectura más detenida hizo que pareciera más bien un sistema de comprobaciones y límites: los scripts de Bitcoin mantienen las condiciones de custodia, los validadores ejecutan el consenso, los Finality Providers añaden una finalidad respaldada por BTC y la gobernanza de BABY cambia las reglas.
No se supone que ningún rol llegue a convertirse en los cuatro.
¿Esa separación hace que Babylon sea más difícil de capturar, o solo le da a los usuarios cuatro centros de poder diferentes para monitorear?
#baby $BEAT @BabylonLabs_io $BABY