---
title: "Assinaturas BLS"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Assinaturas BLS
> 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
- [Hash criptográfico](/pt-br/crypto/cryptographic-hash/)
- [Proof of stake](/pt-br/crypto/proof-of-stake/)
- [Assinatura limiar](/pt-br/crypto/threshold-signature/)
## Fontes
- [BLS Signatures](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force (acessado em: 2026-08-12)
- [RFC 9380: Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor (acessado em: 2026-08-12)
- [Short Signatures from the Weil Pairing](https://doi.org/10.1007/3-540-45682-1_30) - Springer (acessado em: 2026-08-12)
- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs) - Ethereum Foundation (acessado em: 2026-08-12)
- [Phase 0 Beacon Chain Specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (acessado em: 2026-08-12)
- [Ethereum Annotated Specification: BLS Signatures](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation (acessado em: 2026-08-12)
- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [Consensus mechanisms](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (acessado em: 2026-08-12)
Source: https://wiki.fcontext.com/pt-br/crypto/bls-signature/index.mdx