Al rediseñar Babylon Genesis hoy, he estado mirando una cuestión en particular: si todo el protocolo gira en torno a la seguridad de BTC, ¿por qué la entidad oficial emite BABY por separado en lugar de dejar que BTC asuma todas las funciones?
Al seguir leyendo, descubrí que desde el principio la entidad oficial no tenía la intención de convertir a BTC en un “activo todoterreno” dentro de la red.
En Babylon, BTC es más bien una especie de garantía de seguridad. Se encarga de proporcionar seguridad económica para que las redes PoS que se conectan puedan respaldarse en el valor de Bitcoin. Pero lo que realmente hace que la red funcione se basa en otra lógica. El pago de gas, las votaciones de gobernanza y los incentivos del ecosistema: estas acciones de alta frecuencia se asignan a BABY.
Más tarde me di cuenta de que esto, en esencia, busca evitar una contradicción: hacer que un activo con una naturaleza más orientada a la reserva de valor asuma, al mismo tiempo, tareas de ejecución de alta frecuencia.
Si todas las operaciones dependieran de BTC, cada interacción de la red se vincularía directamente con el propio activo de Bitcoin, y tanto la experiencia de usuario como el diseño de incentivos quedarían limitados. Babylon decide entregar la capa de ejecución a BABY y dejar la capa de seguridad a BTC. En esencia, esto permite que dos activos hagan lo que mejor saben, en vez de sustituirse entre sí.
Por supuesto, este diseño también tiene un costo. El protocolo debe mantener dos sistemas económicos, el umbral de comprensión para los usuarios aumenta y el desarrollo del ecosistema debe tener en cuenta tanto a quienes sostienen BTC como a quienes usan BABY. Pero, en comparación con concentrar toda la responsabilidad en un solo activo, esta división de tareas deja más espacio para futuras expansiones.
Antes yo pensaba que la innovación de Babylon solo era que “BTC puede ser apostado de forma nativa”. Ahora, al verlo de nuevo, entiendo que lo que realmente quiere construir es una arquitectura donde la capa de seguridad y la capa de ejecución se separan, y la existencia de BABY es una pieza importante para que esta división de responsabilidades pueda funcionar a largo plazo.
Si en el futuro más protocolos del ecosistema de Bitcoin adoptan un modelo similar, ¿te resultaría más convincente la idea de “un activo se encarga de la seguridad y otro activo se encarga de la ejecución”, o prefieres que todas las funciones se concentren en BTC?
#baby $BABY
Al seguir leyendo, descubrí que desde el principio la entidad oficial no tenía la intención de convertir a BTC en un “activo todoterreno” dentro de la red.
En Babylon, BTC es más bien una especie de garantía de seguridad. Se encarga de proporcionar seguridad económica para que las redes PoS que se conectan puedan respaldarse en el valor de Bitcoin. Pero lo que realmente hace que la red funcione se basa en otra lógica. El pago de gas, las votaciones de gobernanza y los incentivos del ecosistema: estas acciones de alta frecuencia se asignan a BABY.
Más tarde me di cuenta de que esto, en esencia, busca evitar una contradicción: hacer que un activo con una naturaleza más orientada a la reserva de valor asuma, al mismo tiempo, tareas de ejecución de alta frecuencia.
Si todas las operaciones dependieran de BTC, cada interacción de la red se vincularía directamente con el propio activo de Bitcoin, y tanto la experiencia de usuario como el diseño de incentivos quedarían limitados. Babylon decide entregar la capa de ejecución a BABY y dejar la capa de seguridad a BTC. En esencia, esto permite que dos activos hagan lo que mejor saben, en vez de sustituirse entre sí.
Por supuesto, este diseño también tiene un costo. El protocolo debe mantener dos sistemas económicos, el umbral de comprensión para los usuarios aumenta y el desarrollo del ecosistema debe tener en cuenta tanto a quienes sostienen BTC como a quienes usan BABY. Pero, en comparación con concentrar toda la responsabilidad en un solo activo, esta división de tareas deja más espacio para futuras expansiones.
Antes yo pensaba que la innovación de Babylon solo era que “BTC puede ser apostado de forma nativa”. Ahora, al verlo de nuevo, entiendo que lo que realmente quiere construir es una arquitectura donde la capa de seguridad y la capa de ejecución se separan, y la existencia de BABY es una pieza importante para que esta división de responsabilidades pueda funcionar a largo plazo.
Si en el futuro más protocolos del ecosistema de Bitcoin adoptan un modelo similar, ¿te resultaría más convincente la idea de “un activo se encarga de la seguridad y otro activo se encarga de la ejecución”, o prefieres que todas las funciones se concentren en BTC?
#baby $BABY