Leyendo la especificación técnica de @BabylonLabs_io , el script de staking de Bitcoin utiliza OP_CHECKMULTISIGVERIFY para hacer cumplir el requisito de quorum del validador. Pero aquí está la sutileza: el propio script no codifica condiciones de slashing; solo verifica que el número requerido de validadores haya firmado.
Esto significa que el bloqueo de Bitcoin es estructuralmente simple: o el usuario se retira después del unbonding, hmm.. o el conjunto de validadores firma para ejecutar el slashing. La lógica real del slashing—qué constituye una mala conducta, cuánto se slashea, qué validadores firman—está completamente fuera de la cadena (off-chain), impuesta por la cadena Babylon Genesis, no por el script de Bitcoin.
Entonces la capa de Bitcoin proporciona finalidad criptográfica para el bloqueo, pero las condiciones de ese bloqueo las determina el estado de la cadena Babylon. Si la cadena Babylon dice "el validador X se comportó mal, slashea a sus delegadores", el quorum de validadores firma la transacción de slashing, y Bitcoin la ejecuta. Pero Bitcoin no tiene forma de verificar de manera independiente que el slashing estuviera justificado.
Esto invierte el modelo de confianza: Bitcoin asegura que el UTXO no pueda gastarse sin la firma del quorum, hmm.. pero no garantiza que el quorum use esa firma de manera honesta. La seguridad migra desde la prueba de trabajo (proof-of-work) de Bitcoin hacia el consenso de validadores de Babylon. La parte "nativa" es real, pero la parte "trustless" (sin confianza) depende de las mismas suposiciones que cualquier cadena PoS: que el conjunto de validadores es honesto y está alineado económicamente.
En comparación con un puente basado puramente en Ethereum, Babylon reduce la superficie de ataque para exploits—no hay token envuelto, no hay riesgo de acuñación—pero no elimina la dependencia del validador. El script de bloqueo es solo una herramienta; la cadena Babylon es el juez.
Si el conjunto de validadores se ve comprometido, ¿el script de Bitcoin ofrece alguna defensa más allá de un bloqueo sobre el que los atacantes ya controlan la clave para?
#baby $BABY
Esto significa que el bloqueo de Bitcoin es estructuralmente simple: o el usuario se retira después del unbonding, hmm.. o el conjunto de validadores firma para ejecutar el slashing. La lógica real del slashing—qué constituye una mala conducta, cuánto se slashea, qué validadores firman—está completamente fuera de la cadena (off-chain), impuesta por la cadena Babylon Genesis, no por el script de Bitcoin.
Entonces la capa de Bitcoin proporciona finalidad criptográfica para el bloqueo, pero las condiciones de ese bloqueo las determina el estado de la cadena Babylon. Si la cadena Babylon dice "el validador X se comportó mal, slashea a sus delegadores", el quorum de validadores firma la transacción de slashing, y Bitcoin la ejecuta. Pero Bitcoin no tiene forma de verificar de manera independiente que el slashing estuviera justificado.
Esto invierte el modelo de confianza: Bitcoin asegura que el UTXO no pueda gastarse sin la firma del quorum, hmm.. pero no garantiza que el quorum use esa firma de manera honesta. La seguridad migra desde la prueba de trabajo (proof-of-work) de Bitcoin hacia el consenso de validadores de Babylon. La parte "nativa" es real, pero la parte "trustless" (sin confianza) depende de las mismas suposiciones que cualquier cadena PoS: que el conjunto de validadores es honesto y está alineado económicamente.
En comparación con un puente basado puramente en Ethereum, Babylon reduce la superficie de ataque para exploits—no hay token envuelto, no hay riesgo de acuñación—pero no elimina la dependencia del validador. El script de bloqueo es solo una herramienta; la cadena Babylon es el juez.
Si el conjunto de validadores se ve comprometido, ¿el script de Bitcoin ofrece alguna defensa más allá de un bloqueo sobre el que los atacantes ya controlan la clave para?
#baby $BABY