Signatures BLS et schémas de signatures agrégées

Les signatures BLS reposent sur des appariements bilinéaires — une opération mathématique sur les courbes elliptiques. Un appariement e: G1 x G2 -> GT associe des paires de points de deux groupes (G1, G2) à un groupe cible GT. Sa propriété essentielle est la bilinéarité : e(aP, bQ) = e(P, Q)^(ab) pour les scalaires a et b et les points P et Q. Cela permet de vérifier les relations entre les éléments des groupes sans connaître les logarithmes discrets. La courbe d’appariement la plus utilisée en cryptographie est BLS12-381, choisie pour son niveau de sécurité de 128 bits, la petite taille de ses éléments de groupe (48 octets dans G1, 96 octets dans G2) et l’efficacité du calcul des appariements.

Une signature BLS (Boneh-Lynn-Shacham) fonctionne comme suit. Génération de clés : la clé privée x est un scalaire aléatoire ; la clé publique PK = x * G, où G est le générateur de G2. Signature : pour un message m, calculer H = hash-to-curve(m) dans G1, puis sigma = x * H. La signature sigma est un point unique de G1 (48 octets sur BLS12-381). Vérification : vérifier e(sigma, G) == e(H, PK). Par bilinéarité, e(x*H, G) = e(H, G)^x = e(H, x*G) = e(H, PK). La sécurité repose sur l’hypothèse co-CDH : calculer x*H à partir de H et de x*G est difficile sans connaître x.

Les signatures BLS permettent une agrégation non interactive : étant donné des signatures sigma_1, ..., sigma_n sur des messages m_1, ..., m_n provenant de clés publiques PK_1, ..., PK_n, un agrégateur calcule sigma_agg = sigma_1 + sigma_2 + ... + sigma_n (addition de points de courbe elliptique). La signature agrégée est une valeur unique de 48 octets, quel que soit n. La vérification exige n+1 opérations d’appariement : vérifier e(sigma_agg, G) == product(e(H_i, PK_i)). Dans le cas courant où tous les signataires signent le même message, la vérification se réduit à 2 appariements : e(sigma_agg, G) == e(H, sum(PK_i)).

L’agrégation BLS naïve est vulnérable à l’attaque par clé usurpée. Un adversaire enregistre PK_adv = x_adv*G - PK_honest. La clé agrégée PK_agg = PK_honest + PK_adv = x_adv*G, que l’adversaire contrôle entièrement. Options de défense : (1) preuve de possession : chaque signataire prouve qu’il connaît sa clé privée en signant sa propre clé publique lors de l’inscription ; (2) augmentation du message : inclure la clé publique de chaque signataire dans son message ; (3) délinéarisation (BGLS) : multiplier chaque clé publique par hash(PK_i, all_PKs) avant l’agrégation, ce qui brise la linéarité permettant l’attaque. Ethereum utilise la preuve de possession pour l’inscription des validateurs.

La couche de consensus d’Ethereum (la chaîne Beacon) utilise largement l’agrégation BLS12-381. À chaque créneau, plus de 400 000 validateurs actifs attestent la tête de la chaîne. Sans agrégation, le stockage de toutes les signatures nécessiterait environ 400 000 * 96 octets = 38 MB par créneau. Avec l’agrégation BLS par comité (généralement 512 validateurs), chaque comité produit une signature agrégée de 96 octets, ce qui réduit la quantité totale de données de signature à quelques kilo-octets par créneau. Le corps du bloc de la chaîne Beacon contient des attestations agrégées : un champ de bits indiquant quels validateurs ont participé, ainsi qu’une signature BLS agrégée pour chaque comité.

Les opérations de signature BLS présentent des caractéristiques de performance différentes de celles d’ECDSA. La signature BLS exige un hachage vers la courbe et une multiplication scalaire (environ 1 ms sur du matériel moderne). La vérification BLS exige deux opérations d’appariement (environ 3 à 5 ms chacune, soit environ 6 à 10 ms au total). La signature ECDSA exige une multiplication de point (environ 0,2 ms) ; sa vérification exige deux multiplications de point (environ 0,4 ms). La vérification BLS est plus lente pour une signature isolée, mais bien plus rapide en agrégation : vérifier 1 000 signatures BLS agrégées exige environ 10 ms au total, contre environ 400 ms pour 1 000 vérifications ECDSA individuelles. Le seuil de rentabilité se situe autour de 2 à 3 signatures.

BLS à seuil étend l’agrégation au partage de secrets. Dans un schéma à seuil (t, n), la clé privée est divisée en n parts au moyen du partage de secret de Shamir sur le champ des scalaires de BLS. Chaque détenteur i produit une signature partielle sigma_i = sk_i * H(m). Toute combinaison de t signatures partielles peut être calculée à l’aide des coefficients d’interpolation de Lagrange : sigma = sum(lambda_i * sigma_i). Le résultat est identique à la signature produite par la clé originale, mais aucune partie ne détient jamais la clé complète. BLS à seuil est utilisé dans la technologie de validateurs distribués (DVT), les portefeuilles MPC et les services de signature à seuil tels que Fireblocks et Web3Auth.

Filecoin utilise les signatures BLS pour son système de preuves de stockage et la signature des transactions. Les mineurs de stockage agrègent plusieurs preuves au moyen de l’agrégation BLS, ce qui réduit les coûts de vérification sur la chaîne. Le pool de messages de Filecoin agrège également plusieurs signatures de transaction en une seule signature agrégée, réduisant ainsi la taille des blocs. L’implémentation de Filecoin utilise le projet de norme BLS de l’IETF (hachage vers la courbe conforme à la RFC 9380, courbe BLS12-381), avec la variante à taille minimale de clé publique où les clés publiques sont dans G1 (48 octets) et les signatures dans G2 (96 octets) — l’inverse de la convention d’Ethereum.

Bien que Zcash utilise principalement des preuves zk-SNARK Groth16, les appariements BLS sont au fondement de nombreuses constructions de connaissance nulle fondées sur les appariements. L’équation de vérification de Groth16 est une vérification par appariement : e(A, B) = e(alpha, beta) * e(vk, C), où A, B et C sont des éléments de preuve. Les engagements polynomiaux KZG (utilisés dans les transactions de données blob d’Ethereum conformes à l’EIP-4844 et dans divers systèmes de regroupement ZK) reposent également sur les appariements BLS12-381 : un engagement envers le polynôme f(x) est C = f(tau)*G, et les preuves d’évaluation sont vérifiées par appariement. BLS12-381 a été choisie spécifiquement pour l’efficacité de ses opérations d’appariement et son niveau de sécurité de 128 bits.

BLS n’est pas le seul schéma de signature agrégable. Les signatures Schnorr permettent l’agrégation de clés (MuSig2, utilisée dans Taproot de Bitcoin), grâce à laquelle plusieurs signataires produisent une seule signature Schnorr indiscernable d’une signature produite par un seul signataire. FROST (signature de Schnorr à seuil, flexible et optimisée pour les tours) fournit des signatures Schnorr à seuil en deux tours. Cependant, l’agrégation Schnorr exige une interaction entre les signataires, contrairement à l’agrégation BLS non interactive, ce qui la rend moins adaptée aux grands ensembles de validateurs. BLS reste privilégiée pour le consensus sur chaîne de blocs en raison de son agrégation non interactive et de sa vérification par lots efficace.

Les signatures BLS reposent sur des appariements de courbes elliptiques, qui sont vulnérables aux ordinateurs quantiques exécutant l’algorithme de Shor. Un ordinateur quantique suffisamment puissant pourrait calculer les logarithmes discrets sur BLS12-381, compromettant toutes les signatures BLS existantes et la sécurité du consensus d’Ethereum. Le calendrier reste incertain, mais NIST estime à 15 à 20 ans le délai avant l’apparition d’ordinateurs quantiques pertinents pour la cryptographie. Ethereum et les autres chaînes dépendant de BLS devront migrer vers des schémas de signature postquantiques (CRYSTALS-Dilithium/ML-DSA ou SPHINCS+/SLH-DSA) avant que cette menace ne se concrétise. Cette migration nécessite des modifications au niveau du protocole pour l’enregistrement des validateurs, les formats d’attestation et la vérification des agrégats.

Quel est le principal avantage de l’agrégation des signatures BLS dans la couche de consensus d’Ethereum ?

Les signatures BLS utilisent des appariements bilinéaires sur les courbes BLS12-381. Les signatures sont des points G1 de 48 octets  et les clés publiques, des points G2 de 96 octets selon la convention d’Ethereum. L’agrégation non interactive combine n signatures en une seule valeur de 48 octets, vérifiée au moyen de n+1 appariements. L’attaque par clé malveillante est atténuée par la preuve de possession lors de l’enregistrement des validateurs. Ethereum utilise BLS pour compresser plus de 400 000 attestations de validateurs par créneau en quelques kilo-octets. BLS à seuil permet de répartir les validateurs sans détenteur unique de la clé. BLS repose sur des appariements et n’offre pas de sécurité postquantique, ce qui impose une migration future.