FROST

Imagine uma associação cujas poupanças são geridas por Anna, Jan e Eva. Escolhem a regra 2 de 3: Anna e Jan, Anna e Eva, ou Jan e Eva podem aprovar um pagamento. Cada pessoa guarda uma parte secreta diferente, uma parcela do material da chave comum construída criptograficamente. Uma parte não basta, mas também não são três cópias da mesma palavra-passe. Se Eva estiver indisponível, os outros dois podem colaborar. O mesmo limite vale para um atacante: se obtiver partes suficientes, também poderá assinar. Assim, distribuí-las só ajuda se comprometer um dispositivo ou uma conta não der acesso a todos os restantes. [1] [2]

Anna não deve confirmar uma operação apenas porque a aplicação anuncia uma assinatura pendente. Precisa de conhecer o destinatário, o montante e a comissão, e verificar se o eventual troco regressa à associação. Cada signatário precisa de uma forma fiável de verificar a transação real. Um hash, uma impressão digital criptográfica curta dos dados, não explica o seu conteúdo a uma pessoa. O FROST permite colaborar sobre a mesma mensagem; não avalia se uma fatura é autêntica ou se alguém compreendeu o que aprovou. Mesmo uma assinatura concluída não confirma o pagamento num bloco. Um bloco reúne transações registadas no histórico comum da rede Bitcoin. O RFC 9591 é uma especificação informativa do protocolo, não um certificado de segurança da aplicação inteira. [1] [2]

Taproot é uma melhoria do Bitcoin que permite gastar fundos com uma assinatura correspondente à chave prevista ou cumprindo condições definidas de antemão. Uma assinatura com limiar devidamente construída pode parecer uma assinatura normal de uma só chave ao gastar através da via de chave do Taproot. A assinatura, por si só, não revela o número interno de partes nem o limiar. Isso favorece a privacidade e reduz os dados de assinatura, mas não garante o anonimato de toda a transação nem da comunicação entre participantes. O Bitcoin exige as regras exatas do BIP 340; FROST genérico na curva secp256k1, a base matemática dos cálculos com chaves do Bitcoin, não basta. Por isso, a Zcash Foundation (ZF) disponibiliza frost-secp256k1-tr especificamente para Taproot. Os ajustes de chave usados pelo Taproot também têm de ser tratados corretamente. O mesmo nome de curva não prova compatibilidade, e a existência de uma biblioteca não significa que todas as carteiras a suportem. [3] [4]

Antes de assinar, a associação tem de criar as partes com segurança. Um distribuidor de confiança pode gerar a chave completa e dividi-la. Isso introduz um momento delicado: conhece toda a chave, e uma cópia guardada permitiria contornar a aprovação conjunta pretendida. A alternativa é DKG, a geração distribuída de chaves, em que a chave secreta completa não precisa de aparecer num único participante. Exige comunicação autenticada e protegida e uma execução correta do protocolo. Não basta enviar alguns ficheiros por correio eletrónico. O RFC 9591 centra-se na assinatura; não promete automaticamente DKG em todos os produtos. Uma parte da chave de longo prazo também é diferente de uma contribuição de assinatura para um pagamento específico. [1] [2]

A assinatura propriamente dita tem duas rondas, sem contar a geração prévia da chave. Primeiro, cada participante selecionado cria dois valores secretos de utilização única, chamados nonce, e envia os seus compromissos públicos: valores que o vinculam criptograficamente a esses nonce. Depois recebe a mensagem comum e a lista de compromissos, verifica os dados e calcula a sua contribuição de assinatura. O coordenador combina as contribuições. Os fatores de vinculação ligam os cálculos à mensagem específica, à chave pública do grupo e aos compromissos. Com uma regra 2 de 3, pode iniciar-se uma sessão com dois participantes. Se forem selecionados os três, todos têm de contribuir; não se pode simplesmente excluir quem deixou de responder. [1] [3]

Aqui, um nonce é um valor secreto para uma única tentativa de assinatura, não uma palavra-passe reutilizável. A sua reutilização pode revelar material secreto da chave. Se o computador de Jan falhar depois de enviar uma contribuição de assinatura, restaurar um estado antigo não pode marcar como novos os nonce já utilizados. Um pagamento inacabado também não autoriza a sua reutilização. Uma implementação segura exige boa aleatoriedade, separação das tentativas simultâneas e eliminação fiável dos valores consumidos. Esta é uma razão para não montar FROST por conta própria a partir de scripts avulsos. Matemática correta não protege, por si só, dados secretos mal geridos. [1]

O coordenador organiza as mensagens, mas essa função, por si só, não lhe permite assinar pela associação. Precisa das contribuições dos detentores selecionados. Pode, contudo, reter comunicações ou interromper uma sessão, tal como uma contribuição inválida pode fazê-la falhar. As verificações detetam uma contribuição de assinatura inválida; atribuir a falha a uma pessoa exige conhecer de forma fiável a origem das mensagens. Detetar o problema não garante a conclusão. Uma nova tentativa exige um grupo autorizado disponível e novos nonce. A associação precisa, portanto, de um plano para falhas e desacordos, não apenas de um limiar mostrado no ecrã inicial. [1] [2]

Se Eva perder o dispositivo, o nome FROST não recuperará os fundos por si só. A cópia de segurança deve preservar a sua parte, o identificador, os dados necessários do grupo e a possibilidade de os carregar num programa compatível. Não equivale automaticamente a uma Seed Phrase comum, a cópia de segurança de uma carteira em palavras. Recuperar uma parte com a ajuda dos outros e renovar as partes são procedimentos adicionais que o sistema concreto tem de suportar. Uma cópia da parte de Eva continua a ser a mesma parte; não acrescenta um voto independente. Renovar as partes mantendo a chave do grupo também não neutraliza um conjunto suficiente de partes roubadas anteriormente. Antes de usar poupanças reais, o ensaio deve abranger recuperação, falhas e a versão exata do programa, não apenas uma assinatura bem-sucedida. [2] [3]