Ir para o conteúdo
Financial Context Wiki

Assinaturas BLS

Um guia centrado na verificação de assinaturas Boneh-Lynn-Shacham, modos de agregação, suítes criptográficas, defesas contra chaves maliciosas, uso no consenso do Ethereum e riscos de implementação.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Uma assinatura Boneh-Lynn-Shacham é uma assinatura digital baseada em emparelhamentos bilineares. Em uma orientação comum, a chave secreta sk produz a chave pública PK = sk * G1; a mensagem m é mapeada para H(m) em G2; e a assinatura sig = sk * H(m) é verificada por e(PK, H(m)) = e(G1, sig). Os grupos exatos, codificações, suíte hash-to-curve e separação de domínio são escolhas da suíte criptográfica, não notações intercambiáveis.

BLS tem uma vantagem operacional incomum: assinaturas válidas podem ser somadas em um único elemento de grupo de tamanho constante. Isso comprime as assinaturas, mas não a lista de signatários, nem prova quorum, identifica validadores autorizados, impede equivocação ou torna o consenso final. Essas propriedades vêm do protocolo que a envolve.

Como funciona

  1. Fixe protocolo, suíte criptográfica e versão: curva, grupos de chave pública e assinatura, serialização, função hash-to-curve, tag de separação de domínio e construção da raiz da mensagem. Nunca deduza compatibilidade apenas do rótulo BLS.
  2. Gere sk pelo procedimento de geração de chaves especificado e derive PK. Rejeite codificações zero, infinito, malformadas, não canônicas ou no subgrupo errado aplicando exatamente KeyValidate e as regras de desserialização.
  3. Construa os bytes exatos da mensagem e o domínio de assinatura. No consenso do Ethereum, a raiz de assinatura vincula a raiz SSZ do objeto a um domínio derivado do tipo de operação e dos dados do fork; o texto exibido não é o objeto assinado.
  4. Assine e verifique individualmente com o esquema selecionado. As variantes Basic, de aumento de mensagem e proof of possession têm defesas diferentes contra chaves maliciosas e não devem ser misturadas casualmente.
  5. Escolha o verificador agregado conforme o padrão das mensagens. Use FastAggregateVerify apenas para várias chaves públicas validadas que assinam a mesma mensagem sob as premissas exigidas de proof of possession; use AggregateVerify para a lista de chaves públicas e mensagens permitida pelo esquema.
  6. Reconstrua independentemente o conjunto de signatários a partir dos dados do comitê ou de um bitlist de participantes, rejeite índices duplicados ou não autorizados, aplique pesos de stake ou limiar e então verifique a assinatura agregada. Um agregado válido autentica o conjunto fornecido; não decide se ele satisfaz a política.
  7. Reconcilie o resultado com fork choice, condições de slashing, quorum, disponibilidade, temporização e finalidade. Preserve bytes de entrada, domínios, índices dos signatários, versão da implementação e vetores de teste, e compare bibliotecas independentes antes da implantação.

Exemplos resolvidos

  • A compressão não elimina os dados de participação. O consenso do Ethereum codifica cada chave pública BLS em 48 bytes e cada assinatura em 96 bytes. Para 512 assinaturas da mesma mensagem, assinaturas separadas ocupam 512 * 96 = 49,152 bytes. Uma assinatura agregada mais um bitlist de participantes de 512-bit = 64-byte ocupa 96 + 64 = 160 bytes, redução de 49,152 - 160 = 48,992 bytes, ou 99.6744791667%. As chaves públicas dos validadores e o mapeamento do comitê ainda precisam estar disponíveis em outro lugar.
  • Agregação da mesma mensagem. Suponha que os validadores registrados 17, 24 e 91 assinem a mesma raiz de assinatura R. Suas assinaturas são agregadas como sigAgg = sig17 + sig24 + sig91. A verificação usa o conjunto ordenado de chaves públicas validadas [PK17, PK24, PK91], o mesmo R e FastAggregateVerify. Um resultado válido prova que essas chaves assinaram R sob o esquema; uma regra separada determina seus pesos e se três signatários formam quorum.
  • Mensagens distintas exigem a API correta. As chaves PK1, PK2 e PK3 assinam as mensagens distintas m1, m2 e m3. O verificador precisa preservar os pares [PK1, m1], [PK2, m2], [PK3, m3] e chamar o AggregateVerify aplicável; substituir essas entradas por uma única mensagem e FastAggregateVerify verifica uma afirmação diferente. No esquema Basic, as mensagens também precisam ser distintas.
  • Agregação não é assinatura limiar. Em um grupo de 8 membros, a agregação comum das assinaturas dos membros [1, 2, 4, 6, 8] produz uma assinatura e uma lista de cinco signatários. Ela não se transforma em uma assinatura limiar 5-of-8 sob uma única chave pública de grupo. Um projeto BLS limiar verdadeiro precisa de geração distribuída de chaves ou modelo com dealer confiável, índices de participações e regras de interpolação; suas premissas de confiança e falha devem ser auditadas separadamente.

Riscos

  • Usar curva, orientação de grupos ou suíte criptográfica diferente da definida pelo protocolo.
  • Assinar bytes serializados diferentes apesar de exibir a mesma mensagem legível.
  • Omitir o domínio de fork, operação ou aplicação e permitir replay entre contextos.
  • Tratar um Internet-Draft expirado como padrão final e imutável.
  • Aceitar codificações de pontos malformadas, não canônicas ou no infinito.
  • Ignorar verificações de subgrupo e admitir entradas de curva inválida ou subgrupo pequeno.
  • Usar código hash-to-curve improvisado em vez da suíte e dos vetores de teste especificados.
  • Gerar chaves secretas enviesadas, zero, duplicadas, vazadas ou derivadas de forma previsível.
  • Reutilizar uma chave entre protocolos cujas premissas de proof of possession e domínio sejam diferentes.
  • Agregar chaves públicas não registradas sem a defesa contra chaves maliciosas exigida pelo esquema.
  • Chamar a verificação rápida de mesma mensagem para mensagens distintas ou raízes inconsistentes.
  • Permutar, duplicar ou omitir a associação entre chave pública e mensagem.
  • Confiar em bitlist de participantes sem verificar participação no comitê e unicidade dos índices.
  • Contar assinaturas em vez do stake, peso ou limiar definido pelo protocolo.
  • Presumir que um agregado revela qual assinatura individual era inválida.
  • Confundir agregação comum, multisignatures e assinaturas limiares.
  • Tratar a validade da assinatura como prova de disponibilidade de dados, correção da execução ou finalidade.
  • Ignorar equivocação, mensagens sujeitas a slashing, janelas temporais ou contexto de fork choice.
  • Depender de uma biblioteca, recurso de CPU ou otimização de verificação em lote não verificada.
  • Subestimar custo de emparelhamento, entradas de negação de serviço, canais laterais, custódia de chaves, atualizações e ausência de segurança pós-quântica.

Equívocos comuns

  • Uma assinatura agregada prova que todos os validadores participaram.
  • Quaisquer chaves públicas e assinaturas BLS podem ser combinadas com segurança sem regras de proof of possession.
  • A agregação de tamanho constante elimina a necessidade de transmitir ou reconstruir a participação dos signatários.
  • Agregação BLS e BLS limiar são a mesma construção.
  • Uma assinatura BLS válida torna o bloco, a mensagem de bridge ou o protocolo assinado economicamente seguro e final.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...