@BabylonLabs_io Sigo volviendo a cómo está escrita la condición de slashing de Babylon. Firma dos bloques en conflicto a la misma altura con tu clave EOTS, y la matemática misma revela tu clave privada. No lo revisa ningún comité, ninguna votación lo decide, la criptografía simplemente dispara.

Lo que hay debajo de eso es más interesante que el mecanismo en sí. Ahora existe un mercado de gestores de claves de terceros específicamente para evitar que esto se dispare, porque el protocolo no tiene forma de separar a un operador que hizo trampa de uno cuyo software de cliente falló. El discurso de “sin confianza, sin comité” es real a nivel de protocolo, pero la seguridad en el mundo real ahora depende en parte de si un proveedor específico de finality se molestó en adoptar uno de estos proveedores. Esa es una decisión de negocio privada, no algo escrito en la cadena.

Para cualquiera que asigne BTC a través de un proveedor de finality, es una variable que no puedes verificar actualmente. La adopción por parte del proveedor no se divulga, no está estandarizada y no forma parte de ninguna lista de verificación de diligencia debida que haya visto circular.

La “pureza” criptográfica se suponía que eliminaría la necesidad de confiar en el juicio de alguien. En cambio, solo movió ese juicio una capa más abajo, a la selección de proveedores que nadie publica.

Una condición de slashing sin comité todavía tiene un comité; solo que lo decide el mercado de proveedores sobre quién queda cubierto.

La brecha honesta aquí es que yo tampoco tengo números de adopción, así que es una observación estructural, no un riesgo medido.
#baby $BABY $BLESS $HOME
¿Tu proveedor de finality ejecuta protección de claves EOTS?