FROST significa Flexible Round-Optimized Schnorr Threshold. Es un protocolo de firma de umbral en el que suficientes participantes firman con una clave pública común sin reconstruir toda la clave secreta en un lugar durante la firma.
En un esquema 2 de 3 bastan dos participaciones autorizadas disponibles; una no puede producir una firma. Un atacante que consiga dos también alcanza el umbral. Una participación de clave duradera no es una firma parcial de un mensaje concreto: hace falta el protocolo conjunto con valores nuevos de un solo uso. [RFC 9591 — FROST]
Un distribuidor de confianza puede crear el secreto y repartir participaciones, por lo que conoce toda la clave y debe manejarla de forma segura. DKG permite generarla conjuntamente sin ese distribuidor único, pero añade comunicación y verificación propias. RFC 9591 define principalmente la firma; su apéndice de distribuidor no significa que todos los despliegues usen DKG automáticamente. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
En la primera ronda un participante crea dos nonces secretos y comparte sus compromisos públicos. En la segunda verifica el mensaje, la lista de participantes y sus propios compromisos, y calcula su participación de firma. El coordinador agrega las participaciones. Los factores de vinculación unen los nonces al mensaje y conjunto de compromisos concretos; las dos rondas no incluyen la generación previa de claves. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Reutilizar un nonce puede exponer material secreto de clave. Tras usarse, los nonces secretos deben retirarse de forma segura incluso si el intento se aborta; restaurar una copia antigua no debe hacerlos reutilizables. Aleatoriedad, sesiones simultáneas y registro persistente del consumo son aspectos de seguridad, no simples optimizaciones de velocidad. [RFC 9591 — FROST]
El coordinador reúne compromisos y participaciones de firma; sin suficientes participaciones de clave no puede firmar por sí solo. Sin embargo, puede retener mensajes o provocar un aborto. Comprobar una participación defectuosa puede identificar a su autor, no garantizar que termine la sesión. Siguen siendo necesarios el transporte autenticado y suficientes participantes disponibles. [RFC 9591 — FROST]
Para Bitcoin, el resultado debe cumplir la codificación, el hash y las reglas exactas de BIP 340 y los posibles ajustes de clave Taproot. Elegir secp256k1 en una suite FROST genérica no basta. ZF ofrece por separado frost-secp256k1-tr para Taproot; verifica la suite concreta y sus pruebas. Una firma en cadena no revela por sí sola el umbral interno. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Una participación necesita su identificador correcto, datos públicos del grupo y software compatible. Recuperar una participación perdida con ayuda de otros o renovar participaciones requiere protocolos adicionales que el despliegue debe admitir realmente. Copiar la misma participación no añade un participante independiente. Las copias deben conservar el umbral e impedir que vuelvan nonces ya consumidos. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Cada firmante debe comprobar destinatarios, importes, comisión y reglas de aprobación, en lugar de firmar ciegamente un hash del coordinador. FROST resuelve la firma conjunta, no la corrección de la intención comercial. Antes de usarlo verifica la versión de implementación, la recuperación y el comportamiento ante fallos; un RFC informativo no certifica toda la cartera. [RFC 9591 — FROST]
Para obtener la imagen más completa, lee esta entrada junto con Firma Schnorr, MuSig2, Multisig, Taproot, Shamir Secret Sharing.