#baby $BABY
Mientras estudiaba Babylon, una pregunta no me dejaba en paz: si Bitcoin no puede entender lo que ocurrió en una cadena PoS, ¿cómo puede castigar a un Proveedor de Finalidad deshonesto?
Mi primera suposición fue que Babylon, de alguna manera, envía a Bitcoin una prueba de mala conducta y le pide a su script que juzgue el caso. Eso me pareció poco realista porque Bitcoin Script no puede ejecutar la lógica compleja de slashing usada por las redes PoS.
La Sección 7.2 del Litepaper de Staking en Bitcoin de Babylon cambió la forma en que entendí el diseño. Babylon no le pide a Bitcoin que interprete todo el ataque. En su lugar, su gadget de finality EOTS convierte el doble firmado en una trampa criptográfica.
Un Proveedor de Finalidad se compromete a la aleatoriedad de firma para alturas futuras de bloques. Si vota por dos bloques en conflicto en la misma altura, se reutiliza la misma aleatoriedad privada. Esas dos firmas pueden revelar la clave privada EOTS del proveedor. Esa clave expuesta puede luego completar las transacciones de slashing preconstruidas conectadas a sus delegaciones en BTC.
Mi conclusión fue sencilla: Bitcoin no necesita entender el delito; solo necesita hacer cumplir la transacción de castigo una vez que se revela el secreto criptográfico.
Es una forma ingeniosa de permitir que el BTC nativo pueda slashearse sin envolverlo ni moverlo a otra cadena. Pero también crea un riesgo operativo. La documentación de Babylon señala que errores de software o fallos de hardware pueden exponer a Proveedores de Finalidad honestos al slashing, por lo que la protección anti-slashing es importante.
Para mí, la verdadera innovación de Babylon no es solo el staking de BTC sin custodia. Es traducir la mala conducta en PoS a una consecuencia que Bitcoin puede imponer con un scripting limitado.
@BabylonLabs_io
#BTC
Mientras estudiaba Babylon, una pregunta no me dejaba en paz: si Bitcoin no puede entender lo que ocurrió en una cadena PoS, ¿cómo puede castigar a un Proveedor de Finalidad deshonesto?
Mi primera suposición fue que Babylon, de alguna manera, envía a Bitcoin una prueba de mala conducta y le pide a su script que juzgue el caso. Eso me pareció poco realista porque Bitcoin Script no puede ejecutar la lógica compleja de slashing usada por las redes PoS.
La Sección 7.2 del Litepaper de Staking en Bitcoin de Babylon cambió la forma en que entendí el diseño. Babylon no le pide a Bitcoin que interprete todo el ataque. En su lugar, su gadget de finality EOTS convierte el doble firmado en una trampa criptográfica.
Un Proveedor de Finalidad se compromete a la aleatoriedad de firma para alturas futuras de bloques. Si vota por dos bloques en conflicto en la misma altura, se reutiliza la misma aleatoriedad privada. Esas dos firmas pueden revelar la clave privada EOTS del proveedor. Esa clave expuesta puede luego completar las transacciones de slashing preconstruidas conectadas a sus delegaciones en BTC.
Mi conclusión fue sencilla: Bitcoin no necesita entender el delito; solo necesita hacer cumplir la transacción de castigo una vez que se revela el secreto criptográfico.
Es una forma ingeniosa de permitir que el BTC nativo pueda slashearse sin envolverlo ni moverlo a otra cadena. Pero también crea un riesgo operativo. La documentación de Babylon señala que errores de software o fallos de hardware pueden exponer a Proveedores de Finalidad honestos al slashing, por lo que la protección anti-slashing es importante.
Para mí, la verdadera innovación de Babylon no es solo el staking de BTC sin custodia. Es traducir la mala conducta en PoS a una consecuencia que Bitcoin puede imponer con un scripting limitado.
@BabylonLabs_io
#BTC