Zum Inhalt springen
Financial Context Wiki

BLS-Signaturen

Ein verifikationsorientierter Leitfaden zu Boneh-Lynn-Shacham-Signaturen, Aggregationsmodi, Cipher Suites, Schutz vor Rogue-Key-Angriffen, der Nutzung im Ethereum-Konsens und Implementierungsrisiken.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Eine Boneh-Lynn-Shacham-Signatur ist eine auf bilinearen Paarungen basierende digitale Signatur. In einer üblichen Orientierung erzeugt der geheime Schlüssel sk den öffentlichen Schlüssel PK = sk * G1; die Nachricht m wird auf H(m) in G2 abgebildet; und die Signatur sig = sk * H(m) wird über e(PK, H(m)) = e(G1, sig) verifiziert. Exakte Gruppen, Codierungen, Hash-to-Curve-Suite und Domain-Separation sind Festlegungen der Cipher Suite und keine austauschbare Notation.

BLS bietet einen ungewöhnlichen betrieblichen Vorteil: Gültige Signaturen lassen sich zu einem einzigen Gruppenelement konstanter Größe addieren. Dies komprimiert die Signaturen, aber weder die Unterzeichnerliste noch beweist es ein Quorum, identifiziert autorisierte Validatoren, verhindert Equivocation oder macht den Konsens final. Diese Eigenschaften stammen aus dem umgebenden Protokoll.

Funktionsweise

  1. Legen Sie Protokoll, Cipher Suite und Version fest: Kurve, Gruppen für öffentliche Schlüssel und Signaturen, Serialisierung, Hash-to-Curve-Funktion, Domain-Separation-Tag und Konstruktion der Nachrichtenwurzel. Leiten Sie Kompatibilität niemals allein aus der Bezeichnung BLS ab.
  2. Erzeugen Sie sk mit dem vorgeschriebenen Schlüsselerzeugungsverfahren und leiten Sie PK ab. Verwerfen Sie Null-, Unendlichkeits-, fehlerhafte, nicht kanonische und falschen Untergruppen zugehörige Codierungen gemäß den exakten KeyValidate- und Deserialisierungsregeln.
  3. Konstruieren Sie die exakten Nachrichtenbytes und die Signaturdomäne. Im Ethereum-Konsens bindet die Signing Root eine SSZ-Objektwurzel an eine aus Operationstyp und Fork-Daten abgeleitete Domäne; der angezeigte Text ist nicht das signierte Objekt.
  4. Signieren und prüfen Sie einzeln mit dem gewählten Schema. Basic, Message Augmentation und Proof of Possession besitzen unterschiedliche Schutzmechanismen gegen Rogue Keys und dürfen nicht unbedacht vermischt werden.
  5. Wählen Sie den Aggregatverifizierer anhand des Nachrichtenmusters. Verwenden Sie FastAggregateVerify nur für mehrere validierte öffentliche Schlüssel, die unter den erforderlichen Proof-of-Possession-Annahmen dieselbe Nachricht signieren; verwenden Sie AggregateVerify für die vom Schema zugelassene Liste aus öffentlichen Schlüsseln und Nachrichten.
  6. Rekonstruieren Sie den Unterzeichnerkreis unabhängig aus Komiteedaten oder einer Teilnehmer-Bitlist, verwerfen Sie doppelte oder unberechtigte Indizes, wenden Sie Stake- oder Schwellengewichte an und prüfen Sie erst dann die aggregierte Signatur. Ein gültiges Aggregat authentifiziert den vorgelegten Kreis; es entscheidet nicht, ob dieser die Richtlinie erfüllt.
  7. Stimmen Sie das Ergebnis mit Fork Choice, Slashing-Bedingungen, Quorum, Verfügbarkeit, Zeitvorgaben und Finalität ab. Bewahren Sie Eingabebytes, Domänen, Unterzeichnerindizes, Implementierungsversion und Testvektoren auf und vergleichen Sie vor dem Einsatz unabhängige Bibliotheken.

Durchgerechnete Beispiele

  • Komprimierung beseitigt keine Mitgliedschaftsdaten. Der Ethereum-Konsens codiert jeden öffentlichen BLS-Schlüssel als 48 bytes und jede Signatur als 96 bytes. Bei 512 Signaturen derselben Nachricht belegen einzelne Signaturen 512 * 96 = 49,152 bytes. Eine aggregierte Signatur zusammen mit einer Teilnehmer-Bitlist von 512-bit = 64-byte belegt 96 + 64 = 160 bytes; das entspricht einer Reduktion um 49,152 - 160 = 48,992 bytes beziehungsweise 99.6744791667%. Die öffentlichen Validatorenschlüssel und Komitee-Zuordnung müssen weiterhin anderweitig verfügbar sein.
  • Aggregation derselben Nachricht. Angenommen, die registrierten Validatoren 17, 24 und 91 signieren dieselbe Signing Root R. Ihre Signaturen werden als sigAgg = sig17 + sig24 + sig91 aggregiert. Die Prüfung nutzt den geordneten, validierten Satz öffentlicher Schlüssel [PK17, PK24, PK91], dasselbe R und FastAggregateVerify. Ein gültiges Ergebnis beweist, dass diese Schlüssel R im Rahmen des Schemas signiert haben; eine separate Regel bestimmt ihre Gewichte und ob drei Unterzeichner ein Quorum bilden.
  • Unterschiedliche Nachrichten verlangen die richtige API. Die Schlüssel PK1, PK2 und PK3 signieren die verschiedenen Nachrichten m1, m2 und m3. Der Verifizierer muss die Zuordnungen [PK1, m1], [PK2, m2], [PK3, m3] erhalten und das anwendbare AggregateVerify aufrufen. Werden diese Eingaben durch eine Nachricht und FastAggregateVerify ersetzt, wird eine andere Aussage geprüft. Beim Basic-Schema müssen auch die Nachrichten verschieden sein.
  • Aggregation ist keine Schwellensignatur. In einer Gruppe mit 8 Mitgliedern erzeugt die gewöhnliche Aggregation der Signaturen von [1, 2, 4, 6, 8] eine Signatur samt Liste von fünf Unterzeichnern. Sie wird dadurch nicht zu einer 5-of-8-Schwellensignatur unter einem einzigen öffentlichen Gruppenschlüssel. Ein echtes Threshold-BLS-Design erfordert verteilte Schlüsselerzeugung oder einen vertrauenswürdigen Dealer, Share-Indizes und Interpolationsregeln; seine Vertrauens- und Ausfallannahmen müssen separat geprüft werden.

Risiken

  • Verwendung einer Kurve, Gruppenorientierung oder Cipher Suite, die vom Protokoll abweicht.
  • Signieren unterschiedlicher serialisierter Bytes trotz derselben menschenlesbaren Anzeige.
  • Auslassen der Fork-, Operations- oder Anwendungsdomäne und dadurch möglicher kontextübergreifender Replay.
  • Behandlung eines abgelaufenen Internet-Drafts als unveränderlichen endgültigen Standard.
  • Annahme fehlerhafter, nicht kanonischer oder auf unendlich liegender Punktcodierungen.
  • Überspringen von Untergruppenprüfungen und Zulassen von Invalid-Curve- oder Small-Subgroup-Eingaben.
  • Verwendung eigener Hash-to-Curve-Logik statt der vorgeschriebenen Suite und Testvektoren.
  • Erzeugung verzerrter, nullwertiger, duplizierter, offengelegter oder vorhersehbar abgeleiteter geheimer Schlüssel.
  • Wiederverwendung eines Schlüssels in Protokollen mit unterschiedlichen Proof-of-Possession- und Domänenannahmen.
  • Aggregation nicht registrierter öffentlicher Schlüssel ohne den vom Schema verlangten Rogue-Key-Schutz.
  • Aufruf der schnellen Gleichnachrichtenprüfung für verschiedene Nachrichten oder inkonsistente Wurzeln.
  • Vertauschen, Duplizieren oder Auslassen der Zuordnung zwischen öffentlichem Schlüssel und Nachricht.
  • Vertrauen auf eine Teilnehmer-Bitlist ohne Prüfung der Komiteemitgliedschaft und eindeutiger Indizes.
  • Zählen von Signaturen statt protokolldefiniertem Stake, Gewicht oder Schwellenwert.
  • Annahme, ein Aggregat zeige, welche Einzelsignatur ungültig war.
  • Verwechslung gewöhnlicher Aggregation, Multisignaturen und Schwellensignaturen.
  • Gleichsetzung von Signaturgültigkeit mit Datenverfügbarkeit, korrekter Ausführung oder Finalität.
  • Nichtbeachtung von Equivocation, slashbaren Nachrichten, Zeitfenstern oder Fork-Choice-Kontext.
  • Abhängigkeit von einer einzigen Bibliothek, CPU-Funktion oder ungeprüften Batch-Verifizierungsoptimierung.
  • Unterschätzung von Pairing-Kosten, Denial-of-Service-Eingaben, Seitenkanälen, Schlüsselverwahrung, Upgrades und fehlender Post-Quanten-Sicherheit.

Häufige Fehlannahmen

  • Eine aggregierte Signatur beweist, dass jeder Validator teilgenommen hat.
  • Beliebige öffentliche BLS-Schlüssel und Signaturen können ohne Proof-of-Possession-Regeln sicher kombiniert werden.
  • Aggregation konstanter Größe beseitigt die Notwendigkeit, die Unterzeichnerzugehörigkeit zu übertragen oder zu rekonstruieren.
  • BLS-Aggregation und Threshold BLS sind dieselbe Konstruktion.
  • Eine gültige BLS-Signatur macht den signierten Block, die Bridge-Nachricht oder das Protokoll wirtschaftlich sicher und final.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...