BLS-Signaturen und aggregierte Signaturschemata

BLS-Signaturen beruhen auf bilinearen Paarungen — einer mathematischen Operation auf elliptischen Kurven. Eine Paarung e: G1 x G2 -> GT bildet Punktpaare aus zwei Gruppen (G1, G2) auf eine Zielgruppe GT ab. Die entscheidende Eigenschaft ist die Bilinearität: e(aP, bQ) = e(P, Q)^(ab) für Skalare a, b und Punkte P, Q. Dadurch lassen sich Beziehungen zwischen Gruppenelementen überprüfen, ohne die diskreten Logarithmen zu kennen. Die am häufigsten verwendete Paarungskurve für die Kryptografie ist BLS12-381. Sie wurde wegen ihres 128-Bit-Sicherheitsniveaus, der kleinen Gruppenelemente (48 Byte in G1, 96 Byte in G2) und der effizienten Berechnung der Paarung ausgewählt.

Eine BLS-(Boneh-Lynn-Shacham-)Signatur funktioniert wie folgt. Schlüsselerzeugung: Der private Schlüssel x ist ein zufälliger Skalar; der öffentliche Schlüssel PK = x * G, wobei G der G2-Generator ist. Signieren: Für die Nachricht m wird H = hash-to-curve(m) in G1 berechnet; anschließend sigma = x * H. Die Signatur sigma ist ein einzelner G1-Punkt (48 Byte auf BLS12-381). Verifikation: Prüfe e(sigma, G) == e(H, PK). Aufgrund der Bilinearität gilt e(x*H, G) = e(H, G)^x = e(H, x*G) = e(H, PK). Die Sicherheit beruht auf der co-CDH-Annahme: x*H aus H und x*G zu berechnen, ist ohne Kenntnis von x schwierig.

BLS-Signaturen unterstützen die nichtinteraktive Aggregation: Für Signaturen sigma_1, ..., sigma_n auf Nachrichten m_1, ..., m_n von öffentlichen Schlüsseln PK_1, ..., PK_n berechnet ein Aggregator sigma_agg = sigma_1 + sigma_2 + ... + sigma_n (Addition elliptischer Kurvenpunkte). Die aggregierte Signatur ist unabhängig von n ein einzelner Wert mit 48 Byte. Für die Verifikation sind n+1 Paarungsoperationen erforderlich: Prüfe e(sigma_agg, G) == product(e(H_i, PK_i)). Im häufigen Fall, dass alle Signer dieselbe Nachricht signieren, reduziert sich die Verifikation auf 2 Paarungen: e(sigma_agg, G) == e(H, sum(PK_i)).

Die naive BLS-Aggregation ist anfällig für den Rogue-Key-Angriff. Ein Angreifer registriert PK_adv = x_adv*G - PK_honest. Der aggregierte Schlüssel PK_agg = PK_honest + PK_adv = x_adv*G wird vollständig vom Angreifer kontrolliert. Abwehrmöglichkeiten: (1) Proof of Possession (PoP): Jeder Signer weist bei der Registrierung durch eine Signatur seines eigenen öffentlichen Schlüssels nach, dass er seinen privaten Schlüssel kennt. (2) Message Augmentation: Den Nachrichten jedes Signers wird dessen öffentlicher Schlüssel hinzugefügt. (3) Delinearization (BGLS): Vor der Aggregation wird jeder öffentliche Schlüssel mit hash(PK_i, all_PKs) multipliziert, wodurch die für den Angriff erforderliche Linearität aufgehoben wird. Ethereum verwendet PoP bei der Validator-Registrierung.

Die Konsensschicht von Ethereum (Beacon Chain) nutzt die Aggregation von BLS12-381 in großem Umfang. In jedem Slot attestieren etwa 400,000+ aktive Validatoren den Chain-Head. Ohne Aggregation würde die Speicherung aller Signaturen etwa ~400,000 * 96 bytes = 38 MB pro Slot erfordern. Durch die BLS-Aggregation pro Komitee (typischerweise 512 Validatoren) erzeugt jedes Komitee eine 96-Byte-Aggregatsignatur, wodurch die gesamten Signaturdaten auf wenige Kilobyte pro Slot sinken. Der Block-Body der Beacon Chain enthält aggregierte Attestierungen: ein Bitfeld, das angibt, welche Validatoren teilgenommen haben, sowie eine aggregierte BLS-Signatur pro Komitee.

BLS-Signaturoperationen weisen andere Leistungsmerkmale als ECDSA auf. Für das Signieren mit BLS sind ein Hash-to-Curve und eine Skalarmultiplikation erforderlich (~1 ms auf moderner Hardware). Die BLS-Verifikation erfordert zwei Paarungsoperationen (~3-5 ms pro Operation = insgesamt ~6-10 ms). Beim Signieren mit ECDSA ist eine Punktmultiplikation erforderlich (~0.2 ms); für die Verifikation sind zwei Punktmultiplikationen erforderlich (~0.4 ms). Die BLS-Verifikation ist pro Signatur langsamer, aber aggregiert deutlich schneller: Die Verifikation von 1000 aggregierten BLS-Signaturen erfordert insgesamt ~10 ms gegenüber ~400 ms für 1000 einzelne ECDSA-Verifikationen. Der Umschlagpunkt liegt bei etwa 2-3 Signaturen.

Threshold-BLS erweitert die Aggregation um Secret Sharing. In einem (t, n)-Schwellenschema wird der private Schlüssel mithilfe von Shamir Secret Sharing über dem BLS-Skalarfeld in n Anteile aufgeteilt. Jeder Teilnehmer i erzeugt eine Teilsignatur sigma_i = sk_i * H(m). Beliebige t Teilsignaturen können mithilfe von Lagrange-Interpolationskoeffizienten kombiniert werden: sigma = sum(lambda_i * sigma_i). Das Ergebnis ist identisch mit der von dem ursprünglichen Schlüssel erzeugten Signatur, aber keine einzelne Partei besitzt jemals den vollständigen Schlüssel. Threshold-BLS wird in der Distributed-Validator-Technologie (DVT), MPC-Wallets und Threshold-Signaturdiensten wie Fireblocks und Web3Auth eingesetzt.

Filecoin verwendet BLS-Signaturen für sein System von Speicherbeweisen und zum Signieren von Transaktionen. Speicher-Miner aggregieren mehrere Beweise mithilfe der BLS-Aggregation, wodurch die Kosten der On-Chain-Verifikation sinken. Der Message Pool von Filecoin aggregiert außerdem mehrere Transaktionssignaturen zu einer einzigen aggregierten Signatur und reduziert dadurch die Blockgröße. Die Filecoin-Implementierung verwendet den IETF-BLS-Draftstandard (Hash-to-Curve gemäß RFC 9380, BLS12-381-Kurve) mit der Variante mit minimaler Public-Key-Größe, bei der öffentliche Schlüssel in G1 (48 Byte) und Signaturen in G2 (96 Byte) liegen — das Gegenteil der Konvention von Ethereum.

Obwohl Zcash hauptsächlich Groth16-ZK-SNARK-Beweise verwendet, bilden BLS-Paarungen die Grundlage vieler paarungsbasierter Zero-Knowledge-Konstruktionen. Die Groth16-Verifikationsgleichung ist eine Paarungsprüfung: e(A, B) = e(alpha, beta) * e(vk, C), wobei A, B, C Beweiselemente sind. Auch KZG-Polynom-Commitments (verwendet in den Blob-Transaktionen von Ethereums EIP-4844 und verschiedenen ZK-Rollup-Systemen) beruhen auf BLS12-381-Paarungen: Ein Commitment für das Polynom f(x) ist C = f(tau)*G, und Auswertungsbeweise werden per Paarung verifiziert. BLS12-381 wurde speziell wegen seiner effizienten Paarungsoperationen und seiner 128-Bit-Sicherheit ausgewählt.

BLS ist nicht das einzige aggregierbare Signaturschema. Schnorr-Signaturen unterstützen die Schlüsselaggregation (MuSig2, verwendet in Bitcoin Taproot), bei der mehrere Signer eine einzelne Schnorr-Signatur erzeugen, die nicht von einer Signatur eines einzelnen Signers zu unterscheiden ist. FROST (Flexible Round-Optimized Schnorr Threshold) stellt Threshold-Schnorr-Signaturen in zwei Runden bereit. Die Schnorr-Aggregation erfordert jedoch eine Interaktion zwischen den Signern (anders als die nichtinteraktive BLS-Aggregation) und eignet sich dadurch weniger für große Validator-Mengen. BLS bleibt wegen seiner nichtinteraktiven Aggregation und der effizienten Batch-Verifikation die bevorzugte Lösung für Blockchain-Konsens.

BLS-Signaturen basieren auf elliptischen Kurvenpaarungen, die für Quantencomputer mit Shors Algorithmus anfällig sind. Ein ausreichend leistungsfähiger Quantencomputer könnte diskrete Logarithmen in BLS12-381 berechnen, dadurch alle bestehenden BLS-Signaturen brechen und die Konsenssicherheit von Ethereum außer Kraft setzen. Der Zeitrahmen ist ungewiss, aber NIST schätzt, dass für die Kryptografie relevante Quantencomputer in 15 bis 20 Jahren verfügbar sein könnten. Ethereum und andere von BLS abhängige Chains müssen auf Post-Quanten-Signaturverfahren (CRYSTALS-Dilithium/ML-DSA oder SPHINCS+/SLH-DSA) migrieren, bevor diese Bedrohung Realität wird. Die Migration erfordert Änderungen auf Protokollebene an der Validator-Registrierung, den Attestierungsformaten und der Aggregatverifizierung.

Was ist der wichtigste Vorteil der BLS-Signaturaggregation in der Konsensschicht von Ethereum?

BLS-Signaturen verwenden bilineare Paarungen auf BLS12-381-Kurven. Signaturen sind 48 Byte große G1-Punkte; öffentliche Schlüssel sind nach der Konvention von Ethereum 96 Byte große G2-Punkte. Die nicht-interaktive Aggregation kombiniert n Signaturen zu einem einzigen 48 Byte großen Wert, der mit n+1 Paarungen verifiziert wird. Der Rogue-Key-Angriff wird bei der Validator-Registrierung durch einen Proof of Possession abgewehrt. Ethereum verwendet BLS, um die Attestierungen von mehr als 400.000 Validatoren pro Slot auf wenige Kilobyte zu komprimieren. Threshold BLS ermöglicht verteilte Validatoren ohne eine einzelne Person, die den Schlüssel hält. BLS basiert auf Paarungen und ist nicht post-quanten-sicher, weshalb künftig eine Migration erforderlich ist.