#baby $BABY ¿Cómo se “slashea” a un validador en Bitcoin cuando Bitcoin no tiene una lógica de slashing incorporada?
Me tomó más tiempo de lo esperado entender este caso en particular, porque la respuesta no es un contrato inteligente: es un esquema de firmas que hace algo ingenioso con matemáticas en lugar de código.
@BabylonLabs_io usa lo que se llama una Firma Extraíble de Un Solo Uso (EOTS, por sus siglas en inglés), basada en las firmas nativas Schnorr de Bitcoin. Aquí está el truco central: un proveedor de finalización genera un par único de claves para cada altura de bloque sobre la que vota. Mientras firme solo un bloque por cada altura, la firma permanece completamente segura y no se filtra nada. Pero si firma dos bloques en conflicto en la misma altura, las matemáticas se desmoronan. Reutilizar esa clave por altura para firmar dos mensajes distintos expone su clave privada directamente, debido a cómo funcionan las matemáticas de las firmas Schnorr cuando se reutiliza un nonce.
La ronda de finalización en sí requiere firmas de más de dos tercios del peso de BTC en stake para que un bloque se finalice realmente; por lo tanto, cualquier violación de seguridad, por definición, requiere que haya más de un tercio del stake que haya firmado doble. Eso es lo que hace que la garantía de “completamente slasheaple” esté impuesta matemáticamente en lugar de ser una promesa de política: una vez que la clave se filtra, cualquiera puede construir y transmitir la transacción de slashing, no solo Babylon, no solo un validador. En esa etapa no se requiere una votación de comité, no hay proceso de apelaciones: solo matemáticas expuestas.
Lo que no he visto respondido claramente es esto: ¿la generación de claves para cada altura de bloque crea una carga operativa significativa para los proveedores de finalización que ejecutan múltiples BSNs simultáneamente, y podría esa carga convertirse en una superficie de ataque, por ejemplo, si un proveedor bajo carga reutiliza aleatoriedad por error en lugar de por mala intención?
¿La seguridad de EOTS es puramente una garantía matemática, o depende en silencio de que los proveedores de finalización también tengan una infraestructura sólida de gestión de claves?
$BABY
Me tomó más tiempo de lo esperado entender este caso en particular, porque la respuesta no es un contrato inteligente: es un esquema de firmas que hace algo ingenioso con matemáticas en lugar de código.
@BabylonLabs_io usa lo que se llama una Firma Extraíble de Un Solo Uso (EOTS, por sus siglas en inglés), basada en las firmas nativas Schnorr de Bitcoin. Aquí está el truco central: un proveedor de finalización genera un par único de claves para cada altura de bloque sobre la que vota. Mientras firme solo un bloque por cada altura, la firma permanece completamente segura y no se filtra nada. Pero si firma dos bloques en conflicto en la misma altura, las matemáticas se desmoronan. Reutilizar esa clave por altura para firmar dos mensajes distintos expone su clave privada directamente, debido a cómo funcionan las matemáticas de las firmas Schnorr cuando se reutiliza un nonce.
La ronda de finalización en sí requiere firmas de más de dos tercios del peso de BTC en stake para que un bloque se finalice realmente; por lo tanto, cualquier violación de seguridad, por definición, requiere que haya más de un tercio del stake que haya firmado doble. Eso es lo que hace que la garantía de “completamente slasheaple” esté impuesta matemáticamente en lugar de ser una promesa de política: una vez que la clave se filtra, cualquiera puede construir y transmitir la transacción de slashing, no solo Babylon, no solo un validador. En esa etapa no se requiere una votación de comité, no hay proceso de apelaciones: solo matemáticas expuestas.
Lo que no he visto respondido claramente es esto: ¿la generación de claves para cada altura de bloque crea una carga operativa significativa para los proveedores de finalización que ejecutan múltiples BSNs simultáneamente, y podría esa carga convertirse en una superficie de ataque, por ejemplo, si un proveedor bajo carga reutiliza aleatoriedad por error en lugar de por mala intención?
¿La seguridad de EOTS es puramente una garantía matemática, o depende en silencio de que los proveedores de finalización también tengan una infraestructura sólida de gestión de claves?
$BABY