Assinaturas Schnorr
A substituição do algoritmo de assinatura digital do Bitcoin (ECDSA) pelo algoritmo Schnorr, mais eficiente, está há muito tempo no topo da lista de desejos de muitos desenvolvedores de Bitcoin. Um algoritmo simples que aproveita a criptografia de curva elíptica, Schnorr permite diversas melhorias em relação ao esquema existente, ao mesmo tempo que preserva todos os seus recursos e premissas de segurança.
Notavelmente, as assinaturas Schnorr suportam “multisig nativo” que permite a agregação de múltiplas assinaturas em uma única válida para a soma das chaves de suas respectivas entradas. Esta funcionalidade oferece três benefícios importantes:
-
Assinaturas de tamanho constante, independentemente do número de participantes na configuração multisig. Uma transação 50 de 50 é efetivamente do mesmo tamanho daquela que usa uma única chave pública e assinatura. Por esta razão, o desempenho de tais esquemas é significativamente melhorado, eliminando o requisito original de validação individual de cada assinatura. Além disso, a verificação das assinaturas Schnorr é ligeiramente mais rápida que a do ECDSA.
-
A diminuição do tamanho dos dados a serem validados e transmitidos através da rede também se traduz em ganhos de capacidade interessantes. Considerando o crescimento histórico no número de transações multisig exibido abaixo, o potencial para reduzir o tamanho dessas transações é uma adição atraente aos esforços de expansão existentes. Devemos esperar que esta tendência continue com o surgimento e maior adoção de canais de pagamento.
-
Do ponto de vista da privacidade, Schnorr permite que toda a política do multisig seja obscurecida e indistinguível de uma única chave pública convencional. Numa configuração de limite, também se torna impossível para os participantes revelarem quais deles autorizaram ou não uma transação.
Distribuição de saídas P2SH não gastas de acordo com sua configuração multisig. Fonte: p2sh.info
Infelizmente, ao contrário do ECDSA, o algoritmo de Schnorr não foi padronizado desde a sua invenção, provavelmente devido à patente original que lhe foi aplicada (que já expirou). Embora as linhas gerais do sistema sejam matematicamente sólidas, a falta de documentação e especificações torna a sua implementação mais difícil. Especificamente, sua aplicação ao design de pares de chaves efêmeros do Bitcoin envolve considerações de segurança que requerem otimização adicional.
O principal desafio é definido por Pieter Wuille em sua apresentação Scaling Bitcoin Milan das assinaturas Schnorr como o problema de “cancelamento”. A possibilidade de um grupo de usuários criar uma assinatura válida para a soma de suas chaves abre a porta para um participante adversário subtrair do todo a chave de outro usuário. Basicamente funciona assim:
Suponha um esquema multisig 2 de 2 usando as chaves públicas de entrada Q1 e Q2. Em vez de anunciar sua chave como Q2 para ser combinada com Q1, um participante mal-intencionado poderia fornecer, durante a fase de interação, Q2-Q1 e cancelar efetivamente a chave do outro usuário. Qualquer fundo enviado para a chave pública conjunta agora só pode ser gasto pelo proprietário da chave Q2, sem que o proprietário do Q1 sequer esteja ciente do que está acontecendo.
Felizmente, agora está disponível uma solução que envolve a multiplicação de cada chave usada durante a configuração por um hash baseado nela mesma e em todas as outras chaves envolvidas antes da assinatura. Este processo é chamado de delinearização. Uma prova da segurança deste esquema está atualmente em fase de revisão por pares e será formalmente descrita num próximo documento técnico.
No curto prazo, as assinaturas Schnorr estão sendo consideradas um substituto viável para duas funções importantes do protocolo Bitcoin: OP_CHECKSIG e OP_CHECKMULTISIG.
O primeiro é atualmente usado para verificar assinaturas ECDSA em relação à sua respectiva chave pública de acordo com a mensagem de uma transação. Ao mudar para um equivalente que verifica assinaturas Schnorr em vez de ECDSA, o opcode pode ser usado para autorizar um gasto que requer múltiplas assinaturas, o que normalmente exigiria a chamada de OP_CHECKMULTISIG. Utilizando interação a priori não observável pela rede, a coleção de signatários calcula uma chave pública combinada juntamente com uma assinatura comum que é verificada pelo novo OP_CHECKSIG com os benefícios de maior privacidade e redução de custos.
Este último envolve cenários de limite em que apenas n-de-m assinaturas são necessárias para autorizar uma transação. A implementação atual do OP_CHECKMULTISIG valida todas as chaves públicas e assinaturas associadas exigidas pela política de limite. Como a computação é dimensionada linearmente com o número de participantes, Schnorr propõe um esquema muito mais eficiente que substitui a lista de assinaturas por uma única lista combinada, juntamente com um subconjunto das chaves públicas necessárias.
Até que seja realizada uma avaliação mais detalhada do esquema de delinearização que protege os signatários de atores mal-intencionados, outras aplicações de assinaturas Schnorr podem ser prematuras, mas espera-se que a implementação dos recursos acima possa abrir caminho para uma melhor compreensão do esquema em produção. Dependendo de uma revisão adicional por pares, um BIP para a implementação das Assinaturas Schnorr poderá ser proposto até o final do ano.
Agregação de assinatura
As propriedades de Schnorr que permitem a combinação de múltiplas assinaturas em uma única entrada também são aplicáveis à agregação de múltiplas entradas para todas as transações. O desenvolvedor de Bitcoin Gregory Maxwell foi o primeiro a apresentar a ideia usando insights de uma proposta anterior baseada em assinaturas BLS.
Para compreender bem a diferença entre esta aplicação e as descritas acima é necessário considerar como as assinaturas são agregadas em cada respectivo caso. Na configuração multisig nativa, os signatários colaboram entre si para calcular uma chave pública comum e sua assinatura associada. Esta interação acontece fora do protocolo e diz respeito apenas às partes envolvidas. A ideia por trás da agregação de assinaturas é habilitar validadores de sistema, ou seja. Nós Bitcoin para calcular uma única chave e assinatura para cada entrada de todas as transações no nível do protocolo.
Dado que este esquema expande o âmbito de agregação para fora do conjunto determinístico de participantes, introduz um novo vetor de ataque para atores maliciosos aproveitarem o bug de “cancelamento”. Por esta razão, a correção de delinearização destacada na seção anterior é crítica para a solidez deste método.
Em termos de implementação, a proposta é bastante simples: OP_CHECKSIG e OP_CHECKMULTISIG são modificados para que possam empilhar chaves públicas, delinearizá-las e, uma vez validadas todas as entradas associadas, produzir uma assinatura combinada para suas respectivas transações.
É bastante simples avaliar o tipo de poupança de recursos que teria sido possível se a agregação de assinaturas tivesse sido implementada desde o bloco génese. Supondo que cada assinatura histórica seria reduzida a 1 byte, exceto uma por transação, a análise sugere que o método resultaria em uma redução de pelo menos 25% em termos de armazenamento e largura de banda. O aumento da utilização de limiares n-de-n provavelmente se traduzirá em mais poupanças, embora não tenham sido contabilizados nesta análise.
