BLS-Signaturen sind überall, von Ethereums Konsens bis zu EigenLayer. Aber es ist einfach, sie falsch zu verwenden. Was sind BLS-Signaturen? Lassen Sie uns über die richtige und die falsche Art sprechen, sie zu verwenden:

Aber zuerst, was sind BLS-Signaturen? BLS-Signaturen sind ein kryptografisches Element, das zum Signieren von Nachrichten verwendet wird, ähnlich wie ECDSA. So funktioniert die Mathematik. Es basiert auf elliptischen Kurvenpaarungen. Aber was macht sie so besonders? Warum diese ausgeklügelten Paarungen verwenden?

Die Killerfunktion von BLS: Signaturaggregation. Sie können viele BLS-Signaturen zu einer einzigen Signatur kombinieren. Dies ermöglicht es Ihnen, N Signaturen auf einmal zu übertragen und zu überprüfen, was platz- und zeiteffizienter ist! Und on-chain sind Optimierungen enorm wichtig für Gasersparnisse.

Für einen detaillierten Einblick, wie BLS-Signaturen funktionieren, sowie den Prozess des Aufbaus von Aggregationen und Multi-Signaturen, schaut euch den vollständigen Blogbeitrag an, der am Ende dieses Threads verlinkt ist! Jetzt sehen wir uns an, wie BLS-Signaturen schiefgehen können und wie EigenLayer sie (richtig, um diese Fallstricke zu vermeiden) verwendet!

EigenLayer ist eine Restaking-Schicht für Ethereum. In EigenLayer AVSes signieren Validatoren die Ergebnisse ihrer Validierungsberechnungen. Der Aggregator sammelt all diese Signaturen und bringt sie on-chain. Die aggregierten Signaturen werden on-chain verifiziert.

Die Aufgabe enthält die Blocknummer, als die Aufgabe erstellt wurde, und einen Schwellenwert, der den Prozentsatz der Operatorvalidierung angibt, der erforderlich ist, um die Aufgabe zu validieren. Die Operatoren, die sich für das AVS entschieden haben, können diese Aufgaben erhalten, um die Aufgabenantwort zu berechnen, und dann kann der Operator die Antwort mit seiner BLS-Unterschrift der Aufgabe an den Aggregator senden. Sobald der Schwellenwert identischer Antworten erreicht ist, fasst der Aggregator alle BLS-Unterschriften zu einer einzigartigen aggregierten Unterschrift zusammen und sendet sie an den AVS-Vertrag zurück. Der Vertrag überprüft, ob die Unterschrift korrekt ist, und öffnet eine Herausforderungsperiode, in der ein Herausforderer beweisen kann, dass die Validierung falsch war, und falls ja, werden die sich falsch verhaltenden Operatoren bestraft.

Im Vertrag erfolgt die Überprüfung in der Funktion `trySignatureAndApkVerification`:

Multi-Signaturen können jedoch, wenn sie falsch verwendet werden, mit einem ernsthaften Problem namens Rogue-Key-Angriffe einhergehen. Angenommen, ein ehrlicher Benutzer hat einen öffentlichen Schlüssel, `pk_0`. Ein Angreifer, der `pk_0` zuvor gesehen hat, kann seinen öffentlichen Schlüssel als pk_1 = sk_1⋅G_1—pk_0 wählen. Der Angreifer würde den privaten Schlüssel, der mit dem öffentlichen Schlüssel verbunden ist, nicht kennen. Die Multi-Signatur-Überprüfung würde jedoch Folgendes ergeben:

Nur `sk_1` ist erforderlich, um eine Nachricht zu signieren, die zu einer gültigen Multi-Signatur führt, auch wenn der erste Benutzer sie möglicherweise nicht signiert hat. Dies lässt sich leicht auf jede Anzahl `r` ehrlicher Benutzer verallgemeinern, indem der betrügerische Schlüssel gewählt wird, und zwar:

Dies ist eine gefährliche Bedrohung, da ein bösartiger Aggregator, der in unserem vorherigen AVS-Beispiel zuvor einen betrügerischen Schlüssel registriert hätte, aggregierte Signaturen senden könnte, die nicht von den Validierern signiert wurden, aber dennoch vom Vertrag akzeptiert werden. Dies würde dazu führen, dass Validierer bestraft werden, selbst wenn sie sich nicht falsch verhalten haben.

Um einen Rogue-Key-Angriff zu verhindern, ist die gängige Methode, die Benutzer zu bitten, nachzuweisen, dass sie den privaten Schlüssel kennen, der mit ihrem öffentlichen Schlüssel übereinstimmt, bekannt als Besitznachweis. Daher wird der Benutzer im ersten Registrierungsschritt aufgefordert, seinen öffentlichen Schlüssel zusammen mit dem Besitznachweis π zu registrieren, sodass:

Im Grunde wird der Benutzer aufgefordert, seinen öffentlichen Schlüssel oder eine andere Identifikationsnachricht zu signieren. In AVS ist die Nachricht die Betreiberadresse. Im EigenLayer-Vertrag wird der Besitznachweis durch die Funktion `registerBLSPublicKey` überprüft:

Die Funktion `pubkeyRegistrationMessageHash` wird verwendet, um den benutzerdefinierten Domänentrenner `PUBKEY_REGISTRATION_TYPEHASH` und die Betreiberadresse zu hashen.

Nach der Registrierung wird der öffentliche Schlüssel dem Vertrag hinzugefügt. Wir können seinen Wert überprüfen, indem wir die Funktion `getRegisteredPubkey` aufrufen. Hier ist ein Beispiel für einen BLS-öffentlichen Schlüssel, der für EigenDA AVS registriert ist:

Der Nachweis des Besitzes ist im Grunde eine BLS-Unterschrift. Es ist jedoch auch nicht ratsam, Multi-Signaturen während des Nachweis-des-Besitzes-Schrittes zu verwenden, um beispielsweise mehrere öffentliche Schlüssel für einen einzelnen Teilnehmer zu registrieren. In diesem Fall würde der Teilnehmer einen Splitting-Zero-Angriff erreichen. Der Teilnehmer könnte Schlüssel registrieren, die sich bei der Addition gegenseitig aufheben und so den Nachweis des Besitzes umgehen.

Wir haben gesehen, dass BLS-Multi-Signaturen eine bedeutende Optimierungsmöglichkeit bieten. Die Implementierung von EigenLayer zeigt die Leistungsfähigkeit von BLS-Signaturen und hebt auch die Komplexitäten hervor, die mit ihrer praktischen Bereitstellung verbunden sind. Multi-Signaturen bringen jedoch Sicherheitsrisiken wie Rogue-Key-Angriffe mit sich, die Schutzmaßnahmen wie den Nachweis des Besitzes erforderlich machen. Mit dem Pectra-Upgrade, das BLS12-381 unterstützt, könnten wir jedoch weitere Implementierungen und Verbesserungen in Solidity sehen, und wir hoffen, dass dieser Beitrag hilft, bekannte Implementierungsfehler und Sicherheitsanfälligkeiten zu vermeiden.

Für einen tieferen Einblick in BLS-Signaturen, Aggregationsaufbau und Multi-Signaturen, schauen Sie sich unseren kürzlich veröffentlichten Blogbeitrag unten an: