Les signatures BLS sont partout, du consensus d'Ethereum à EigenLayer. Mais il est facile de les utiliser de manière incorrecte. Qu'est-ce que les signatures BLS ? Parlons de la bonne et de la mauvaise façon de les utiliser :

Mais d'abord, qu'est-ce que les signatures BLS ? Les signatures BLS sont un primitive cryptographique utilisée pour signer des messages, comme l'ECDSA. Voici comment fonctionne le calcul. C'est basé sur des appariements de courbes elliptiques. Mais qu'est-ce qui les rend si spéciales ? Pourquoi utiliser ces appariements sophistiqués ?

La fonctionnalité phare de BLS : l'agrégation de signatures. Vous pouvez combiner plusieurs signatures BLS en une seule signature. Cela vous permet de transmettre et de vérifier N signatures en une seule fois, ce qui est plus efficace en termes d'espace et de temps ! Et sur la chaîne, les optimisations sont extrêmement importantes pour économiser du gaz.

Pour un aperçu approfondi du fonctionnement des signatures BLS, ainsi que du processus de construction d'agrégation et de multi-signatures, consultez l'article de blog complet lié à la fin de ce fil ! Maintenant, voyons comment les signatures BLS peuvent mal tourner et comment EigenLayer les utilise (correctement, en évitant ces pièges) !

EigenLayer est une couche de restaking pour Ethereum. Dans EigenLayer AVSes, les validateurs signent les résultats de leurs calculs de validation. L'agrégateur collecte toutes ces signatures et les pousse sur la chaîne. Les signatures agrégées sont vérifiées sur la chaîne.

La tâche contient le numéro de bloc lorsque la tâche a été créée et un seuil indiquant le pourcentage de validation des opérateurs, qui est nécessaire pour valider la tâche. Les opérateurs qui ont choisi d'opter pour l'AVS peuvent obtenir ces tâches pour calculer la réponse à la tâche, puis l'opérateur peut envoyer la réponse avec sa signature BLS de la tâche à l'agrégateur. Dès que le seuil de réponses identiques est atteint, l'agrégateur fusionne toutes les signatures BLS en une unique signature agrégée et la renvoie au contrat AVS. Le contrat vérifie que la signature est correcte et ouvre une période de contestation pendant laquelle un contestataire peut prouver que la validation était incorrecte, et si c'est le cas, les opérateurs malveillants sont sanctionnés.

Dans le contrat, la vérification se fait dans la fonction `trySignatureAndApkVerification` :

Cependant, les signatures multiples, si elles sont mal utilisées, présentent un problème sérieux appelé attaques par clé malveillante. Disons qu'un utilisateur honnête a une clé publique, `pk_0`. Un attaquant qui a déjà vu `pk_0` peut choisir sa clé publique comme pk_1 = sk_1⋅G_1—pk_0. L'attaquant ne connaîtrait pas la clé privée associée à la clé publique. Cependant, la vérification de la multi-signature donnerait ce qui suit :

Seul `sk_1` est nécessaire pour signer un message, ce qui entraîne une multi-signature valide, même si le premier utilisateur ne l'a pas signé. Cela se généralise facilement à tout nombre `r` d'utilisateurs honnêtes en choisissant la clé malveillante, à savoir :

C'est une menace dangereuse puisque, dans notre précédent exemple AVS, un agrégateur malveillant qui aurait précédemment enregistré une clé frauduleuse pourrait envoyer des signatures agrégées non signées par les validateurs mais qui seraient tout de même acceptées par le contrat. Cela entraînerait des sanctions pour les validateurs même s'ils n'ont pas mal agi.

Ainsi, pour prévenir une attaque par clé malveillante, la méthode courante consiste à demander aux utilisateurs de prouver qu'ils connaissent la clé privée qui correspond à leur clé publique, connue sous le nom de preuve de possession. Ainsi, lors de la première étape d'enregistrement, l'utilisateur est invité à enregistrer sa clé publique accompagnée de la preuve de possession π telle que :

En gros, l'utilisateur est invité à signer sa clé publique ou tout autre message d'identification. Dans AVS, le message est l'adresse de l'opérateur. Dans le contrat EigenLayer, la preuve de possession est vérifiée par la fonction `registerBLSPublicKey` :

La fonction `pubkeyRegistrationMessageHash` est utilisée pour hacher le séparateur de domaine personnalisé `PUBKEY_REGISTRATION_TYPEHASH` et l'adresse de l'opérateur.

Après l'enregistrement, la clé publique est ajoutée au contrat. Nous pouvons vérifier sa valeur en appelant la fonction `getRegisteredPubkey`. Voici un exemple d'une clé publique BLS enregistrée pour EigenDA AVS :

La preuve de possession est essentiellement une signature BLS. Cependant, il n'est également pas conseillé d'utiliser des signatures multiples lors de l'étape de preuve de possession, par exemple, pour enregistrer plusieurs clés publiques pour un seul participant. Dans ce cas, le participant pourrait réaliser une attaque de zéro fractionné. Dans ce cas, le participant pourrait enregistrer des clés qui s'annuleraient lorsqu'elles sont additionnées et pourraient contourner la preuve de possession.

Nous avons constaté que les multi-signatures BLS offrent une opportunité d'optimisation significative. L'implémentation d'EigenLayer démontre la puissance des signatures BLS et met également en évidence les complexités impliquées dans leur déploiement pratique. Cependant, les multi-signatures introduisent des risques de sécurité tels que les attaques par clé malveillante, ce qui nécessite des mesures de protection comme la preuve de possession. Mais avec la mise à niveau Pectra prenant en charge BLS12-381, nous pourrions voir de nouvelles implémentations et améliorations dans Solidity, et nous espérons donc que cet article aidera à éviter les bogues d'implémentation connus et les vulnérabilités.

Pour une plongée plus approfondie dans les signatures BLS, l'agrégation de constructions et les multi-signatures, consultez notre article de blog récemment publié ci-dessous :