Trois schémas de signature se disputent aujourd’hui le cœur des infrastructures numériques critiques : ECDSA, le vétéran qui sécurise encore la majorité des transactions Bitcoin et des connexions TLS, Schnorr, arrivé sur Bitcoin avec Taproot en 2021 et déjà utilisé sur une bonne partie du réseau, et BLS, la signature à base de couplages qui fait tourner le consensus d’Ethereum avec près de 892 000 validateurs actifs recensés en avril 2026. Chacun répond à un problème différent : la compatibilité, la compacité, ou l’agrégation massive. Le choix entre les trois ne se résume pas à une question de vitesse brute, il dépend du contexte de déploiement, du coût de vérification sur une chaîne compatible EVM, et de la disponibilité dans les outils de gestion de clés professionnels comme AWS KMS ou Google Cloud KMS.
Cet article compare les trois schémas sur leurs spécifications techniques, leurs performances mesurées par la bibliothèque noble-curves, leur coût réel en gas sur Ethereum, leur disponibilité chez les fournisseurs cloud, et leurs usages dans des protocoles en production comme Bitcoin, Ethereum, Chia et Filecoin. L’objectif est de donner une base de décision concrète pour les équipes qui doivent choisir un schéma de signature en 2026, sans prétendre qu’un seul gagnant existe pour tous les cas.
BLS, Schnorr et ECDSA : trois mathématiques différentes
ECDSA (Elliptic Curve Digital Signature Algorithm) repose sur la difficulté du logarithme discret sur une courbe elliptique classique, le plus souvent secp256k1 pour Bitcoin et Ethereum, ou P-256 pour le TLS et les certificats d’entreprise. C’est le schéma le plus ancien des trois, normalisé depuis les années 1990 et implémenté dans quasiment toutes les bibliothèques cryptographiques existantes. Sa principale faiblesse opérationnelle vient du nonce aléatoire : s’il est réutilisé ou mal généré, la clé privée peut être retrouvée par calcul, un défaut qui a déjà coûté cher à plusieurs portefeuilles matériels mal implémentés.
Schnorr utilise la même courbe secp256k1 que Bitcoin, mais une construction mathématique plus simple et linéaire. Cette linéarité est ce qui permet d’additionner plusieurs clés publiques et plusieurs signatures avant de vérifier, ce que Bitcoin exploite depuis l’activation de Taproot en novembre 2021 via la BIP-340. La signature résultante tient sur exactement 64 octets, sans encodage variable, contre un format DER de longueur changeante pour ECDSA.
BLS (Boneh-Lynn-Shacham) change complètement de terrain mathématique : il repose sur des couplages bilinéaires sur une courbe comme BLS12-381, une construction plus lourde en calcul mais qui permet d’agréger un nombre arbitraire de signatures émises par un nombre arbitraire de signataires différents en une seule signature finale. C’est exactement ce dont Ethereum a besoin pour faire tenir les votes de centaines de milliers de validateurs dans chaque bloc. La documentation officielle d’Ethereum le formule clairement : BLS a été retenu parce qu’il “permet une agrégation très efficace des signatures”, un point que Schnorr ne couvre que partiellement puisque son agrégation reste limitée à un sous-ensemble de signataires coordonnés (via des protocoles comme MuSig2), alors que BLS agrège sans coordination préalable entre les parties.
Tableau comparatif : BLS vs Schnorr vs ECDSA
Le tableau suivant réunit les spécifications techniques vérifiables des trois schémas, avec les sources primaires utilisées pour chaque ligne.
| Caractéristique | BLS12-381 | Schnorr (BIP-340) | ECDSA (secp256k1) |
|---|---|---|---|
| Fondement mathématique | Couplages bilinéaires | Logarithme discret elliptique | Logarithme discret elliptique |
| Courbe utilisée | BLS12-381 | secp256k1 | secp256k1 ou P-256 |
| Taille de signature | 96 octets (format G2, utilisé par Ethereum) ou 48 octets (format G1) | 64 octets fixes | 64 octets compacts ou 70-73 octets en DER |
| Agrégation native | Oui, sans coordination préalable | Partielle, via MuSig2 avec coordination | Non |
| Déterminisme | Oui | Oui (avec nonce dérivé du message) | Non par défaut (RFC 6979 recommandé en pratique) |
| Vitesse de signature (noble-curves, Apple M4) | 417 op/s (G1) ou 112 op/s (G2) | Proche d’ECDSA sur la même courbe | 4 217 op/s |
| Vitesse de vérification (noble-curves, Apple M4) | 100 op/s (G1) ou 77 op/s (G2) | Proche d’ECDSA sur la même courbe | 1 352 op/s |
| Précompilé natif sur Ethereum | Oui, EIP-2537 depuis Pectra | Non | Oui, ecrecover (adresse 0x01) |
| Coût de vérification sur Ethereum | ~70 300 à 102 900 gas (selon le nombre de paires) | ~40 000 à 1 000 000 gas (implémentation non native) | 3 000 gas |
| Support AWS KMS | Non | Non (secp256k1 brut disponible, pas de signature Schnorr) | Oui (ECC_SECG_P256K1) |
| Adoption principale | Ethereum (consensus), Chia, Filecoin | Bitcoin (Taproot) | Bitcoin (legacy), Ethereum (comptes), TLS, SSH |
| Résistance post-quantique | Aucune | Aucune | Aucune |
Un point mérite d’être souligné dans ce tableau : aucune bibliothèque publique ne fournit aujourd’hui de référentiel officiel séparant la vitesse pure de Schnorr de celle d’ECDSA sur secp256k1. Les deux schémas partagent la même courbe et une opération de vérification du même ordre de grandeur (une multiplication scalaire), ce qui rend l’écart de performance brute marginal entre les deux. La vraie différence entre Schnorr et ECDSA n’est donc pas la vitesse, mais la taille fixe de la signature et la capacité d’agrégation linéaire.
Benchmarks de performance : ce que mesurent trois sources différentes
Pour éviter d’avancer des chiffres non vérifiables, cette section s’appuie sur trois sources distinctes. La première est le dépôt officiel de la bibliothèque noble-curves, maintenue par Paul Miller et largement utilisée dans l’écosystème JavaScript pour secp256k1, Ed25519 et BLS12-381. Sur un processeur Apple M4, cette bibliothèque mesure une signature ECDSA secp256k1 à 4 217 opérations par seconde (237 microsecondes par opération) et une vérification à 1 352 opérations par seconde (739 microsecondes). Pour BLS12-381, la signature courte au format G1 atteint 417 opérations par seconde tandis que le format long G2, celui qu’utilise le consensus Ethereum, plafonne à 112 opérations par seconde. La vérification est plus coûteuse encore : 100 opérations par seconde en G1 et seulement 77 en G2.
La deuxième source est la documentation technique de BLS12-381 rédigée par Ben Edgington, ingénieur chez ConsenSys, qui explique pourquoi BLS reste plus lent : chaque vérification nécessite une boucle de Miller suivie d’une exponentiation finale, deux opérations réputées coûteuses, optimisées en pratique en combinant les calculs pour éviter de les dupliquer intégralement. Cette lourdeur de calcul est le prix à payer pour la propriété qui rend BLS unique : vérifier n signatures agrégées ne demande que n+1 couplages, contre 2n pour une vérification individuelle de chaque signature prise séparément.
La troisième source est le relevé d’usage des précompilés Ethereum publié par ethPandaOps, qui a observé le trafic mainnet entre le 29 décembre 2025 et le 26 février 2026. Sur cette fenêtre de 59 jours, le précompilé BLS12-381 introduit par la mise à jour Pectra n’a été appelé que 63 fois au total, l’opération g2multiexp représentant la majorité de ces appels. À titre de comparaison, le précompilé ecPairing historique (sur la courbe BN254, différente de BLS12-381) coûte environ 129 000 gas par appel, l’ecMul environ 6 000 gas, et l’ecAdd seulement 150 gas. Ces chiffres confirment que la vitesse brute de BLS n’est pas le facteur qui freine son adoption sur les contrats intelligents : c’est plutôt le manque de cas d’usage on-chain qui justifierait son coût.
Le coût réel en gas sur Ethereum
C’est sur ce terrain que les trois schémas se distinguent le plus nettement pour un développeur de contrats intelligents. ECDSA bénéficie d’un précompilé natif depuis les origines d’Ethereum : l’opération ecrecover, à l’adresse 0x01, coûte un montant fixe de 3 000 gas, quel que soit le contenu du message signé. C’est ce qui explique que la quasi-totalité des portefeuilles et des contrats de vérification de signature sur Ethereum s’appuient encore sur ECDSA, même quand un schéma plus moderne existe.
BLS a obtenu son propre précompilé avec l’EIP-2537, passé au statut final et activé sur le mainnet via la mise à jour Pectra. La formule de coût est publique : 32 600 fois le nombre de paires de points à vérifier, plus 37 700 gas fixes. Une vérification de signature BLS classique nécessite deux paires, ce qui donne environ 102 900 gas, soit plus de trente fois le coût d’un ecrecover. Pour une transaction isolée, ce surcoût est pénalisant. Pour vérifier l’agrégation de centaines de signatures en une seule opération, comme le fait le consensus Ethereum hors chaîne, le calcul s’inverse complètement en faveur de BLS.
Schnorr est le cas le plus inconfortable sur Ethereum : il n’existe aucun précompilé natif pour la courbe secp256k1 utilisée par BIP-340. Les précompilés 0x06, 0x07 et 0x08 accélèrent une courbe différente, BN254, et ne servent donc à rien pour vérifier une signature Schnorr Bitcoin. Le dépôt GitHub zerodao-finance/bip340-solidity documente deux implémentations concrètes : une vérification Schnorr “naïve” en Solidity coûte environ 1 000 000 gas, tandis qu’une version optimisée qui détourne astucieusement le précompilé ecrecover ramène ce coût à environ 40 000 gas. Cette seconde version reste treize fois plus chère qu’une vérification ECDSA native, ce qui explique pourquoi Schnorr progresse sur Bitcoin mais reste quasiment absent des contrats Ethereum.
// Coût approximatif de vérification d'une signature, par schéma, sur l'EVM
// ECDSA : ecrecover natif -> 3 000 gas
// BLS : EIP-2537, 2 paires -> 32 600*2 + 37 700 = 102 900 gas
// Schnorr: implémentation optimisée -> ~40 000 gas (non native)
// Schnorr: implémentation naïve -> ~1 000 000 gas (non native)Tableau tarifaire : disponibilité et coût chez les fournisseurs cloud
Pour les équipes qui gèrent des clés de signature en entreprise plutôt que directement sur une chaîne, la question change de nature : quel service de gestion de clés (KMS) prend en charge quel schéma, et à quel prix. Le tableau suivant compare les offres principales disponibles pour un usage en Europe.
| Fournisseur | ECDSA secp256k1 | ECDSA P-256/P-384 | Schnorr natif | BLS natif | Tarif indicatif |
|---|---|---|---|---|---|
| AWS KMS | Oui (ECC_SECG_P256K1) | Oui | Non | Non | 1 $ par clé-mois + 0,15 $ les 10 000 signatures |
| Google Cloud KMS | Oui | Oui | Non | Non | environ 0,000082 $ par heure et par version de clé active |
| Azure Key Vault | Partiel selon la région | Oui | Non | Non | Variable selon le niveau Premium/HSM |
| HSM dédié (Thales, YubiHSM) | Selon le modèle | Oui | Non en natif | Non en natif | Coût matériel fixe, pas de facturation à l’opération |
| Bibliothèque logicielle (noble-curves, blst, libsecp256k1) | Oui | Oui | Oui | Oui | Gratuit, open source |
Le constat est net : aucun des grands fournisseurs de KMS cloud ne propose de signature Schnorr ou BLS en natif dans son API standard. AWS KMS prend en charge la courbe secp256k1 utilisée par Bitcoin et Ethereum, mais uniquement pour générer des signatures ECDSA classiques, pas des signatures Schnorr. La documentation AWS KMS ne liste d’ailleurs pas non plus Ed25519 parmi les spécifications de clé asymétrique disponibles. Une équipe qui veut utiliser Schnorr ou BLS en production doit donc gérer ses clés elle-même via une bibliothèque logicielle ou un HSM spécialisé, ce qui déplace la responsabilité de la sécurité opérationnelle vers l’équipe interne plutôt que vers le fournisseur cloud.
Cinq cas d’usage réels en production
La théorie se vérifie dans les choix effectifs des plus grands protocoles. Voici cinq déploiements concrets qui illustrent pourquoi chaque schéma trouve sa place.
- Ethereum, consensus (Beacon Chain) : environ 892 000 validateurs actifs recensés en avril 2026 signent des attestations avec BLS12-381. La documentation officielle d’Ethereum précise que BLS a été retenu précisément pour son agrégation, qui compresse des milliers de signatures individuelles en une seule signature de 96 octets plus un champ de participation, évitant ainsi de faire circuler des mégaoctets de données à chaque créneau.
- Ethereum, comptes utilisateurs : à l’inverse du consensus, les transactions envoyées par les utilisateurs restent signées en ECDSA secp256k1 et vérifiées via ecrecover. Un même réseau utilise donc deux schémas différents selon la couche concernée, ce qui illustre bien qu’il n’existe pas de réponse unique.
- Bitcoin, Taproot : depuis l’activation de novembre 2021, les sorties au format P2TR utilisent Schnorr (BIP-340). Le rapport sur l’état de l’ensemble des UTXO publié par mempool.space situait la part des sorties Taproot à 34,2 % de l’ensemble des UTXO au 18 mai 2025, un chiffre qui continue de progresser mais dont la mesure exacte varie selon qu’on compte les transactions, les entrées ou les sorties.
- Chia : le projet revendique avoir construit “la première bibliothèque de signatures BLS pensée pour la production”, bls-signatures, directement fondée sur le standard BLS12-381 de l’IETF. Chia l’utilise pour signer les blocs et les transactions de sa chaîne fondée sur la preuve d’espace.
- Filecoin : le réseau de stockage décentralisé utilise les deux schémas pour des usages différents. La spécification officielle précise qu’ECDSA sur secp256k1 authentifie les messages pour rester compatible avec les outils externes, tandis que BLS sur BLS12-381 sert à signer les tickets de mineurs et d’autres objets où l’agrégation réduit l’espace de stockage sur la chaîne.
Sécurité : nonce, clés malhonnêtes et vérification par lot
Les trois schémas partagent la même famille de risques classiques liés aux courbes elliptiques (mauvaise génération aléatoire, bibliothèque vulnérable, canal auxiliaire), mais chacun porte aussi un risque spécifique. ECDSA reste exposé au problème du nonce : s’il est réutilisé entre deux signatures différentes avec la même clé, ou s’il est généré par un générateur aléatoire faible, un attaquant peut reconstruire la clé privée par un calcul simple. C’est pour cette raison que la plupart des implémentations modernes appliquent la génération déterministe du nonce décrite par la RFC 6979, qui élimine la dépendance à un générateur aléatoire externe à chaque signature.
Schnorr, grâce à sa construction linéaire, supprime une partie de la malléabilité qui touchait ECDSA (une même transaction pouvait historiquement avoir plusieurs signatures valides légèrement différentes), mais cette même linéarité impose une discipline stricte sur la génération du nonce lors de constructions multi-signatures comme MuSig2 : une mauvaise implémentation de l’agrégation peut permettre à un participant malhonnête de forcer une signature invalide ou de récupérer des informations sur la clé d’un autre participant.
BLS porte un risque distinct, documenté depuis les premières publications sur le schéma : l’attaque dite de la “clé renégate” (rogue key attack). Dans un protocole d’agrégation multi-signataire naïf, un participant peut choisir sa clé publique en fonction des clés des autres pour forger une signature agrégée valide sans connaître réellement la clé privée correspondante. Les implémentations sérieuses, dont celle utilisée par le consensus Ethereum, neutralisent ce risque en exigeant une preuve de possession de la clé privée (proof of possession) au moment de l’enregistrement du validateur, avant d’accepter sa clé publique dans le processus d’agrégation.
La vérification par lot illustre bien ces différences d’architecture. ECDSA ne propose pas de mode d’agrégation natif, donc vérifier cent signatures ECDSA demande cent vérifications indépendantes, chacune coûtant son propre temps de calcul. Schnorr permet un gain modeste via la vérification par lot (batch verification), qui combine plusieurs vérifications en une seule opération mathématique plus rapide que la somme des opérations séparées, sans toutefois réduire la taille des données transmises. BLS va plus loin puisque l’agrégation se produit avant même la vérification : les cent signatures deviennent une seule signature de 96 octets, et la vérification de cette signature agrégée ne coûte que légèrement plus qu’une vérification individuelle, ce qui explique pourquoi Ethereum a pu faire croître son nombre de validateurs sans que le coût de vérification du consensus explose de façon proportionnelle.
Aucun des trois schémas ne résiste à un ordinateur quantique
Un point que les équipes de sécurité européennes ne cessent de répéter mérite d’être rappelé clairement ici : BLS, Schnorr et ECDSA reposent tous les trois sur la difficulté du logarithme discret dans un groupe fondé sur une courbe elliptique, qu’il s’agisse d’un couplage bilinéaire pour BLS ou d’une opération de point classique pour les deux autres. L’algorithme de Shor casse cette famille de problèmes dès qu’un ordinateur quantique suffisamment stable et suffisamment grand existe. Un projet de document du groupe de certification cybersécurité de l’ENISA, daté du 7 mai 2026, rappelle qu’une primitive fondée uniquement sur le logarithme discret elliptique ne doit pas être utilisée seule lorsqu’une résistance aux attaques quantiques est exigée par le contexte réglementaire ou le niveau de risque du système.
Concrètement, cela signifie qu’aucun des trois schémas comparés dans cet article ne doit être choisi comme protection de long terme pour des données ou des actifs dont la confidentialité ou l’intégrité doit durer plusieurs décennies. Pour ces cas, la bascule progressive s’oriente vers des schémas normalisés par le NIST comme ML-DSA (ex-Dilithium) ou SLH-DSA (ex-SPHINCS+), que nous avons déjà comparés en détail dans notre analyse ML-DSA vs SLH-DSA vs FN-DSA. BLS, Schnorr et ECDSA restent pertinents pour tout ce qui ne requiert pas cette garantie de long terme, ce qui couvre encore la quasi-totalité des usages actuels en blockchain et en TLS.
Avantages et inconvénients de chaque schéma
Avant de passer au guide de migration, voici une synthèse directe des forces et des limites de chaque option.
ECDSA
- Avantage : compatibilité maximale, disponible nativement dans AWS KMS, Google Cloud KMS, tous les HSM, tous les navigateurs et toutes les bibliothèques TLS.
- Avantage : vérification la plus rapide des trois (1 352 op/s mesurées sur noble-curves) et la moins coûteuse sur Ethereum (3 000 gas via ecrecover).
- Inconvénient : signature de taille variable en encodage DER, pas d’agrégation native, et un historique de failles liées à la génération du nonce.
Schnorr
- Avantage : signature fixe de 64 octets, agrégation linéaire possible via MuSig2, déjà actif sur Bitcoin depuis 2021.
- Avantage : performance brute très proche d’ECDSA puisqu’il utilise la même courbe secp256k1.
- Inconvénient : aucun précompilé natif sur Ethereum, ce qui rend sa vérification on-chain 13 à 330 fois plus coûteuse en gas qu’ECDSA selon l’implémentation.
BLS
- Avantage : seul schéma des trois capable d’agréger un nombre arbitraire de signatures de signataires non coordonnés en une seule signature, ce qui a rendu possible le consensus Ethereum à grande échelle.
- Avantage : précompilé natif disponible depuis Pectra via l’EIP-2537.
- Inconvénient : le plus lent des trois en signature comme en vérification (jusqu’à 17 fois plus lent qu’ECDSA en vérification selon noble-curves), et le plus coûteux en gas pour une vérification isolée.
- Inconvénient : exposé à l’attaque de la clé renégate si l’implémentation n’impose pas de preuve de possession de la clé.
Guide de migration : passer d’ECDSA vers Schnorr ou BLS
Une migration réussie suit rarement un remplacement direct d’un schéma par un autre. Voici les étapes concrètes recommandées pour une équipe qui envisage de faire évoluer son infrastructure de signature.
- Étape 1, cartographier l’usage réel : identifier si la signature sert à authentifier un utilisateur unique (ECDSA suffit souvent), à coordonner un petit groupe de signataires connus (Schnorr via MuSig2 devient pertinent), ou à agréger un très grand nombre de signataires indépendants (BLS s’impose).
- Étape 2, vérifier la disponibilité dans l’outillage existant : si l’équipe dépend d’AWS KMS, de Google Cloud KMS ou d’un HSM d’entreprise classique, ni Schnorr ni BLS ne sont disponibles nativement aujourd’hui, ce qui implique de gérer les clés en dehors du KMS géré, avec les contraintes de sécurité opérationnelle que cela ajoute.
- Étape 3, chiffrer le coût on-chain avant de s’engager : pour tout usage impliquant un contrat Ethereum, comparer précisément le coût d’ecrecover (3 000 gas) face à une vérification Schnorr non native (40 000 à 1 000 000 gas) ou une vérification BLS via EIP-2537 (à partir de 70 300 gas pour une paire).
- Étape 4, auditer la génération de nonce et la preuve de possession : pour ECDSA, confirmer l’usage de RFC 6979 ou d’un générateur aléatoire certifié. Pour BLS, confirmer qu’une preuve de possession de clé est exigée avant toute agrégation.
- Étape 5, tester la double signature en parallèle : faire cohabiter l’ancien et le nouveau schéma pendant une période de transition, à l’image de ce qu’Ethereum fait déjà en utilisant ECDSA pour les comptes et BLS pour le consensus au sein du même réseau.
- Étape 6, documenter la dépendance à la cryptographie classique : consigner dans le registre de risques que le schéma choisi, quel qu’il soit parmi les trois, ne résiste pas à un ordinateur quantique, afin d’anticiper une future bascule hybride.
Quel schéma choisir selon votre cas d’usage
Au-delà de la théorie, voici des recommandations concrètes selon le contexte de déploiement.
- Portefeuille individuel ou service web classique : ECDSA via un KMS géré comme AWS KMS ou Google Cloud KMS reste le choix le plus simple et le moins risqué, avec un support natif complet et un coût prévisible.
- Portefeuille multi-signataire Bitcoin : Schnorr avec MuSig2 réduit la taille des transactions et améliore la confidentialité des configurations multi-signatures par rapport à un multisig ECDSA classique, pour un coût de calcul comparable.
- Réseau avec des milliers de validateurs indépendants : BLS est la seule option réaliste, comme le démontre le choix d’Ethereum pour gérer près de 892 000 validateurs sans saturer la bande passante du réseau.
- Contrat intelligent Ethereum avec vérification fréquente : éviter Schnorr non natif et privilégier ECDSA via ecrecover, sauf si le volume de signatures agrégées justifie le coût fixe plus élevé de l’EIP-2537 pour BLS.
- Chaîne de stockage ou de calcul décentralisé type Filecoin : le modèle hybride qui réserve ECDSA à l’authentification externe et BLS à l’agrégation interne, comme le fait Filecoin, permet de ne pas sacrifier la compatibilité pour obtenir les gains d’agrégation.
- Système devant durer plus de quinze ans : aucun des trois ne convient seul. Prévoir une migration vers un schéma post-quantique normalisé en complément, quel que soit le choix retenu aujourd’hui parmi BLS, Schnorr et ECDSA.
Bibliothèques et outils pour implémenter chaque schéma
Le choix de la bibliothèque compte presque autant que le choix du schéma. Pour ECDSA, l’écosystème est le plus mature des trois : OpenSSL, libsecp256k1 côté Bitcoin, et les modules natifs de Node.js couvrent la quasi-totalité des besoins, et notre comparatif ECDSA vs RSA détaille déjà les écarts de performance avec l’alternative historique RSA. Pour Schnorr, libsecp256k1 reste la référence côté Bitcoin depuis que le module Schnorr a été fusionné dans la bibliothèque principale, ce qui garantit un alignement direct avec les règles de consensus du réseau. Pour BLS, deux bibliothèques dominent selon le langage : blst, écrite en C et maintenue par Supranational, qui équipe la plupart des clients Ethereum pour des raisons de performance brute en production, et noble-curves pour les équipes qui préfèrent un code TypeScript audité sans dépendance native.
Pour les équipes qui démarrent un projet de signature de zéro sans contrainte de compatibilité blockchain, il reste utile de revoir les bases du sujet : notre article sur les signatures numériques explique comment le hachage et les clés garantissent l’authenticité d’un message, et notre comparatif HMAC vs signature numérique détaille la différence entre authentification symétrique partagée et signature asymétrique vérifiable publiquement, une distinction qui conditionne souvent le choix entre les trois schémas de cet article avant même de parler de courbe elliptique.
Le verdict chiffré
Il n’existe pas de vainqueur universel entre BLS, Schnorr et ECDSA, et les chiffres rassemblés dans cet article expliquent pourquoi. ECDSA reste le choix par défaut pour tout ce qui touche à la compatibilité : il est le seul des trois disponible nativement dans AWS KMS et Google Cloud KMS, le seul avec un précompilé Ethereum coûtant seulement 3 000 gas, et le seul mesuré à plus de 1 300 vérifications par seconde sur un matériel grand public. Schnorr gagne sur la compacité et l’agrégation légère : 64 octets fixes contre un format DER variable, et une adoption déjà mesurée à 34,2 % des UTXO Bitcoin en mai 2025, mais il paie cette élégance par l’absence de précompilé sur Ethereum, où sa vérification coûte jusqu’à treize fois plus cher qu’ECDSA même dans sa version optimisée.
BLS, enfin, perd sur tous les critères de vitesse brute, de 112 à 417 signatures par seconde contre plus de 4 000 pour ECDSA selon les mêmes mesures noble-curves, mais c’est le seul des trois capable de faire tenir les signatures de 892 000 validateurs dans une seule chaîne de blocs sans effondrer le réseau. Le choix dépend donc entièrement de l’échelle du problème à résoudre : la compatibilité immédiate pour ECDSA, la compacité pour Schnorr, l’agrégation massive pour BLS. Et dans les trois cas, la prochaine échéance à surveiller n’est pas une bataille entre eux, mais l’arrivée progressive de la cryptographie post-quantique qui, à terme, les concernera tous les trois de la même manière.
Questions fréquentes
BLS est-il plus sûr qu’ECDSA ?
Pas intrinsèquement. Les deux schémas offrent un niveau de sécurité classique comparable quand ils sont correctement implémentés. BLS ajoute un risque spécifique, l’attaque de la clé renégate lors de l’agrégation, qui ne concerne pas ECDSA utilisé seul. ECDSA, de son côté, reste exposé au risque de réutilisation de nonce si l’implémentation ne suit pas la RFC 6979.
Pourquoi Ethereum utilise-t-il deux schémas de signature différents ?
Parce que les deux couches du réseau ont des besoins opposés. Les comptes utilisateurs signent des transactions individuelles où la compatibilité avec ecrecover et l’écosystème existant compte le plus, d’où ECDSA. Le consensus doit agréger les votes de centaines de milliers de validateurs à chaque créneau, d’où BLS, choisi explicitement par la documentation officielle d’Ethereum pour sa capacité d’agrégation.
Peut-on utiliser Schnorr avec AWS KMS ou Google Cloud KMS ?
Non, pas directement. Les deux services prennent en charge la courbe secp256k1 pour générer des signatures ECDSA, mais aucun des deux ne propose de mode de signature Schnorr (BIP-340) dans son API standard au moment de la rédaction de cet article. Une équipe qui veut du Schnorr géré doit passer par une bibliothèque logicielle ou un module matériel spécialisé.
Pourquoi vérifier une signature BLS coûte-t-il si cher sur Ethereum ?
Parce que la vérification BLS repose sur un couplage bilinéaire, une opération mathématiquement plus lourde qu’une simple multiplication scalaire. La formule officielle de l’EIP-2537 facture 32 600 gas par paire de points plus 37 700 gas fixes, ce qui donne environ 102 900 gas pour une vérification classique à deux paires, contre 3 000 gas pour un ecrecover ECDSA.
Taproot a-t-il remplacé ECDSA sur Bitcoin ?
Non, les deux coexistent. Taproot a ajouté Schnorr comme option depuis novembre 2021, mais n’a pas supprimé la prise en charge d’ECDSA pour les anciens formats d’adresse. Le rapport mempool.space sur l’état des UTXO mesurait la part Taproot à 34,2 % de l’ensemble des UTXO au 18 mai 2025, ce qui laisse encore une majorité de valeur sécurisée par les anciens formats ECDSA et SegWit.
Faut-il déjà prévoir une migration post-quantique pour ces trois schémas ?
Pour les systèmes dont la durée de vie dépasse une décennie, oui. Le projet de document de l’ENISA daté du 7 mai 2026 rappelle qu’une primitive fondée uniquement sur le logarithme discret elliptique ne doit pas constituer l’unique protection quand la résistance aux attaques quantiques est exigée. BLS, Schnorr et ECDSA appartiennent tous à cette famille de primitives classiques et devront, à terme, être complétés ou remplacés par des schémas comme ML-DSA ou SLH-DSA.
Quelle est la différence entre Ed25519 et Schnorr sur secp256k1 ?
Les deux sont des constructions de type Schnorr, mais sur des courbes différentes : Ed25519 utilise Curve25519 avec un encodage et des conventions propres au standard RFC 8032, tandis que le Schnorr de Bitcoin (BIP-340) utilise secp256k1 avec des conventions adaptées au script Bitcoin. Nous détaillons cette distinction dans notre comparatif Ed25519 vs ECDSA P-256.
Un HSM d’entreprise classique peut-il générer des signatures BLS ?
La plupart des HSM commerciaux comme ceux de Thales ou les YubiHSM ne proposent pas BLS12-381 en natif dans leur firmware standard. Les projets qui ont besoin de BLS en production, comme Ethereum, Chia ou Filecoin, gèrent généralement leurs clés via des bibliothèques logicielles dédiées plutôt que via un HSM généraliste, ce qui déplace une partie de la charge de sécurité opérationnelle vers l’équipe d’ingénierie du projet.
