Al principio pensé que el mecanismo de slashing de Babylon era como el de otras cadenas PoS: dependía de votaciones de gobernanza en cadena o de que los relayers presentaran pruebas, hasta que volví a leer el whitepaper @BabylonLabs_io en la sección 4.2.
Mi comprensión inicial fue muy simple. Que el validador comete una mala conducta (por ejemplo, doble firma), que otros recopilan pruebas, las presentan a un contrato inteligente y entonces el contrato deduce el depósito. Por eso me quedaba una curiosidad enorme: si Bitcoin mainnet no tiene contratos inteligentes, ¿cómo identifica y ejecuta ese tipo de mala conducta fuera de la cadena?
Hasta que en la sección 4.2 del whitepaper apareció una palabra que me detuvo: “Extractable One-Time Signature (EOTS) enables the automatic private key leakage upon double signing.” La leí varias veces más y entonces lo entendí de golpe.
Volví a dibujar un diagrama de transición del estado criptográfico para comprenderlo: Babylon no intenta que Bitcoin “entienda” la mala conducta, sino que usa el primitive criptográfico EOTS para traducirla directamente en “fuga de la clave privada”. Cuando un validador firma dos bloques distintos en el mismo altura, matemáticamente estas dos firmas chocan y hacen que la clave privada de los fondos custodiados por el validador en Bitcoin mainnet se filtre. Cualquiera que obtenga esa clave privada puede enviar de inmediato los bitcoins del monedero a una dirección de destrucción (Burn Address).
Así que la proposición central no es “cómo ejecuta Bitcoin un castigo”, sino “cómo lograr que el propio perpetrador se vea obligado a entregar la clave privada con sus propias manos”. Babylon no construye una lógica de supervisión compleja sobre Bitcoin, sino que usa criptografía para crear un “cadalso de cero confianza”: en cuanto activas el doble firmado, el código despoja físicamente la propiedad de tus activos; no hace falta que ningún intermediario arbitre.
Por supuesto, este mecanismo de “fuga automática de claves privadas” exige requisitos extremadamente altos para la gestión de claves de firma (KMS) en los nodos locales de los validadores. Todavía estoy observando de forma continua si, en condiciones extremas como una congestión extrema de red o retrasos maliciosos, EOTS podría provocar, por un error ocasional del nodo, una “matanza” injusta de alguien inocente.
¿Babylon fuerza la fuga de la clave privada mediante criptografía como un desenlace final seguro de cero confianza, o como una pesadilla operativa?

#baby $BABY