FROST significa Flexible Round-Optimized Schnorr Threshold. É um protocolo de assinatura de limiar em que participantes suficientes assinam sob uma chave pública comum sem reconstruir toda a chave secreta num único local durante a assinatura.
Num esquema 2 de 3 bastam duas parcelas autorizadas disponíveis; uma não consegue produzir uma assinatura. Um atacante que obtenha duas também atinge o limiar. Uma parcela duradoura de chave não é uma assinatura parcial de determinada mensagem: é necessário o protocolo conjunto com novos valores de uso único. [RFC 9591 — FROST]
Um distribuidor de confiança pode criar o segredo e repartir parcelas, conhecendo assim toda a chave e devendo tratá-la com segurança. DKG permite geração conjunta sem esse distribuidor único, mas acrescenta comunicação e verificação próprias. RFC 9591 especifica sobretudo a assinatura; o apêndice sobre o distribuidor não significa que toda a implementação use DKG automaticamente. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
Na primeira ronda, um participante cria dois nonces secretos e partilha os compromissos públicos. Na segunda, verifica a mensagem, a lista de participantes e os seus compromissos, e calcula a sua parcela de assinatura. Um coordenador agrega as parcelas. Fatores de ligação associam os nonces à mensagem e ao conjunto de compromissos específicos; as duas rondas excluem a geração prévia de chaves. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Reutilizar um nonce pode expor material secreto de chave. Depois do uso, os nonces secretos devem ser retirados com segurança mesmo numa tentativa abortada; restaurar uma cópia antiga não pode torná-los reutilizáveis. Aleatoriedade, sessões simultâneas e registo persistente do consumo fazem parte da segurança, não são apenas otimizações de velocidade. [RFC 9591 — FROST]
O coordenador recolhe compromissos e parcelas de assinatura; sem parcelas de chave suficientes não tem poder para assinar sozinho. Pode, contudo, reter mensagens ou provocar uma interrupção. Verificar uma parcela inválida pode identificar o autor, não garantir que a sessão termine. Continuam necessários transporte autenticado e participantes disponíveis em número suficiente. [RFC 9591 — FROST]
Para Bitcoin, o resultado deve cumprir a codificação, o hash e as regras exatas de BIP 340 e eventuais ajustes de chave Taproot. Escolher secp256k1 numa suite FROST genérica não basta. ZF fornece separadamente frost-secp256k1-tr para Taproot; verifica a suite concreta e os seus testes. Uma assinatura na cadeia não revela por si só o limiar interno. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Uma parcela precisa do identificador correto, dos dados públicos do grupo e de software compatível. Recuperar uma parcela perdida com os outros ou renovar parcelas são protocolos adicionais que a implementação deve realmente suportar. Copiar a mesma parcela não acrescenta um participante independente. As cópias devem preservar o limiar e impedir o regresso de nonces consumidos. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Cada signatário deve verificar destinatários, montantes, taxa e regras de aprovação, em vez de assinar cegamente um hash do coordenador. FROST resolve a assinatura conjunta, não a correção da intenção comercial. Antes de usar, verifica a versão da implementação, a recuperação e o comportamento perante falhas; um RFC informativo não certifica a carteira inteira. [RFC 9591 — FROST]
Para ter uma visão mais completa, leia este verbete junto com Schnorr signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.