---
title: "Signatures BLS"
description: "Un guide axé sur la vérification des signatures Boneh-Lynn-Shacham, les modes d'agrégation, les suites cryptographiques, les protections contre les clés malveillantes, leur emploi dans le consensus Ethereum et les risques d'implémentation."
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.
# Signatures BLS
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Une signature Boneh-Lynn-Shacham est une signature numérique fondée sur des couplages bilinéaires. Dans une orientation courante, la clé secrète `sk` produit la clé publique `PK = sk * G1` ; le message `m` est projeté sur `H(m)` dans `G2` ; et la signature `sig = sk * H(m)` se vérifie par `e(PK, H(m)) = e(G1, sig)`. Les groupes précis, les encodages, la suite hash-to-curve et la séparation de domaines relèvent de la suite cryptographique et ne sont pas des notations interchangeables.
BLS présente un avantage opérationnel inhabituel : les signatures valides peuvent être additionnées en un seul élément de groupe de taille constante. Cette propriété compresse les signatures, mais pas la liste des signataires ; elle ne prouve pas davantage un quorum, n'identifie pas les validateurs autorisés, n'empêche pas l'équivoque et ne rend pas le consensus définitif. Ces garanties proviennent du protocole environnant.
## Fonctionnement
1. Fixez le protocole, la suite cryptographique et la version : courbe, groupes des clés publiques et des signatures, sérialisation, fonction hash-to-curve, étiquette de séparation de domaine et construction de la racine du message. Ne déduisez jamais la compatibilité du seul sigle BLS.
2. Générez `sk` avec la procédure de génération de clés prescrite et dérivez `PK`. Rejetez les encodages nuls, à l'infini, mal formés, non canoniques ou dans le mauvais sous-groupe en appliquant exactement `KeyValidate` et les règles de désérialisation.
3. Construisez les octets exacts du message et le domaine de signature. Dans le consensus Ethereum, la racine de signature lie la racine SSZ d'un objet à un domaine dérivé du type d'opération et des données du fork ; le texte affiché n'est pas l'objet signé.
4. Signez et vérifiez individuellement avec le schéma retenu. Les variantes Basic, augmentation du message et proof of possession emploient des défenses différentes contre les clés malveillantes et ne doivent pas être mélangées sans précaution.
5. Choisissez le vérificateur agrégé selon le schéma des messages. Utilisez `FastAggregateVerify` uniquement pour plusieurs clés publiques validées signant le même message sous les hypothèses requises de proof of possession ; utilisez `AggregateVerify` pour la liste de clés publiques et de messages permise par le schéma.
6. Reconstituez indépendamment l'ensemble des signataires à partir des données du comité ou d'une bitlist de participants, rejetez les indices en double ou non autorisés, appliquez les pondérations de stake ou de seuil, puis vérifiez la signature agrégée. Un agrégat valide authentifie l'ensemble fourni ; il ne décide pas si cet ensemble respecte la politique.
7. Rapprochez le résultat du fork choice, des conditions de slashing, du quorum, de la disponibilité, des délais et de la finalité. Conservez les octets d'entrée, domaines, indices des signataires, version de l'implémentation et vecteurs de test, puis comparez des bibliothèques indépendantes avant tout déploiement.
## Exemples détaillés
- **La compression ne supprime pas les données d'appartenance.** Le consensus Ethereum encode chaque clé publique BLS sur `48 bytes` et chaque signature sur `96 bytes`. Pour `512` signatures du même message, les signatures séparées occupent `512 * 96 = 49,152 bytes`. Une signature agrégée accompagnée d'une bitlist de participants de `512-bit = 64-byte` occupe `96 + 64 = 160 bytes`, soit une réduction de `49,152 - 160 = 48,992 bytes`, ou `99.6744791667%`. Les clés publiques des validateurs et la correspondance avec le comité doivent toujours être disponibles ailleurs.
- **Agrégation d'un même message.** Supposons que les validateurs enregistrés `17`, `24` et `91` signent tous la même racine de signature `R`. Leurs signatures s'agrègent selon `sigAgg = sig17 + sig24 + sig91`. La vérification emploie l'ensemble ordonné et validé des clés publiques `[PK17, PK24, PK91]`, la même `R` et `FastAggregateVerify`. Un résultat valide prouve que ces clés ont signé `R` selon le schéma ; une règle distincte détermine leur poids et si trois signataires constituent un quorum.
- **Des messages distincts exigent la bonne API.** Les clés `PK1`, `PK2` et `PK3` signent les messages distincts `m1`, `m2` et `m3`. Le vérificateur doit préserver les couples `[PK1, m1]`, `[PK2, m2]`, `[PK3, m3]` et appeler l'`AggregateVerify` applicable ; remplacer ces entrées par un seul message et `FastAggregateVerify` vérifie une autre affirmation. Avec le schéma Basic, les messages doivent aussi être distincts.
- **L'agrégation n'est pas une signature à seuil.** Dans un groupe de `8` membres, l'agrégation ordinaire des signatures des membres `[1, 2, 4, 6, 8]` produit une signature et une liste de cinq signataires. Elle ne devient pas une signature à seuil `5-of-8` sous une seule clé publique de groupe. Un véritable système threshold BLS requiert une génération distribuée de clés ou un dealer de confiance, des indices de parts et des règles d'interpolation ; ses hypothèses de confiance et de défaillance doivent être auditées séparément.
## Risques
- Utiliser une courbe, une orientation de groupes ou une suite cryptographique différente de celle du protocole.
- Signer des octets sérialisés différents malgré l'affichage du même message lisible.
- Omettre le domaine du fork, de l'opération ou de l'application et permettre un replay entre contextes.
- Considérer un Internet-Draft expiré comme une norme définitive et immuable.
- Accepter des encodages de points mal formés, non canoniques ou à l'infini.
- Omettre les contrôles de sous-groupe et accepter des entrées invalid-curve ou small-subgroup.
- Employer un code hash-to-curve improvisé plutôt que la suite et les vecteurs de test prescrits.
- Générer des clés secrètes biaisées, nulles, dupliquées, divulguées ou dérivées de manière prévisible.
- Réutiliser une clé entre des protocoles dont les hypothèses de proof of possession et de domaine diffèrent.
- Agréger des clés publiques non enregistrées sans la défense contre les clés malveillantes requise par le schéma.
- Appeler la vérification rapide d'un même message pour des messages distincts ou des racines incohérentes.
- Permuter, dupliquer ou omettre l'association entre clé publique et message.
- Faire confiance à une bitlist de participants sans vérifier l'appartenance au comité et l'unicité des indices.
- Compter les signatures plutôt que le stake, le poids ou le seuil défini par le protocole.
- Supposer qu'un agrégat révèle quelle signature individuelle était invalide.
- Confondre agrégation ordinaire, multisignatures et signatures à seuil.
- Assimiler la validité d'une signature à une preuve de disponibilité des données, de correction de l'exécution ou de finalité.
- Ignorer l'équivoque, les messages passibles de slashing, les fenêtres temporelles ou le contexte du fork choice.
- Dépendre d'une seule bibliothèque, fonctionnalité du processeur ou optimisation non vérifiée de validation par lots.
- Sous-estimer le coût des couplages, les entrées de déni de service, les canaux auxiliaires, la garde des clés, les mises à niveau et l'absence de sécurité post-quantique.
## Idées reçues
- Une signature agrégée prouve que tous les validateurs ont participé.
- N'importe quelles clés publiques et signatures BLS peuvent être combinées sans risque en l'absence de règles de proof of possession.
- L'agrégation de taille constante supprime la nécessité de transmettre ou de reconstituer l'appartenance des signataires.
- L'agrégation BLS et threshold BLS sont une même construction.
- Une signature BLS valide rend le bloc, le message de bridge ou le protocole signé économiquement sûr et définitif.
## Sujets connexes
- [Hachage cryptographique](/fr/crypto/cryptographic-hash/)
- [Proof of stake](/fr/crypto/proof-of-stake/)
- [Signature à seuil](/fr/crypto/threshold-signature/)
## Sources
- [BLS Signatures](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force (consulté le : 2026-08-12)
- [RFC 9380: Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor (consulté le : 2026-08-12)
- [Short Signatures from the Weil Pairing](https://doi.org/10.1007/3-540-45682-1_30) - Springer (consulté le : 2026-08-12)
- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs) - Ethereum Foundation (consulté le : 2026-08-12)
- [Phase 0 Beacon Chain Specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consulté le : 2026-08-12)
- [Ethereum Annotated Specification: BLS Signatures](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation (consulté le : 2026-08-12)
- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals (consulté le : 2026-08-12)
- [Consensus mechanisms](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (consulté le : 2026-08-12)
Source: https://wiki.fcontext.com/fr/crypto/bls-signature/index.mdx