BLS-signaturer og aggregerte signatursystemer

BLS-signaturer bygger på bilineære paringer – en matematisk operasjon på elliptiske kurver. En paring e: G1 x G2 -> GT avbilder par av punkter fra to grupper (G1, G2) til en målgruppe GT. Den kritiske egenskapen er bilinearitet: e(aP, bQ) = e(P, Q)^(ab) for skalarene a, b og punktene P, Q. Dette gjør det mulig å kontrollere sammenhenger mellom gruppeelementer uten å kjenne de diskrete logaritmene. Den mest brukte paringskurven i kryptografi er BLS12-381, som er valgt på grunn av sikkerhetsnivået på 128 bit, små gruppeelementer (48 byte i G1, 96 byte i G2) og effektiv beregning av paringer.

En BLS-signatur (Boneh-Lynn-Shacham) fungerer slik. Nøkkelgenerering: privatnøkkelen x er en tilfeldig skalar, og den offentlige nøkkelen er PK = x * G, der G er G2-generatoren. Signering: gitt meldingen m beregnes H = hash-to-curve(m) i G1, og deretter sigma = x * H. Signaturen sigma er ett enkelt G1-punkt (48 byte på BLS12-381). Verifisering: kontroller at e(sigma, G) == e(H, PK). På grunn av bilineariteten er e(x*H, G) = e(H, G)^x = e(H, x*G) = e(H, PK). Sikkerheten bygger på co-CDH-antakelsen: det er vanskelig å beregne x*H når H og x*G er gitt, uten å kjenne x.

BLS-signaturer støtter ikke-interaktiv aggregering: gitt signaturene sigma_1, ..., sigma_n på meldingene m_1, ..., m_n fra de offentlige nøklene PK_1, ..., PK_n beregner en aggregator sigma_agg = sigma_1 + sigma_2 + ... + sigma_n (punktaddisjon på elliptisk kurve). Den aggregerte signaturen er én enkelt verdi på 48 byte, uavhengig av n. Verifisering krever n+1 paringsoperasjoner: kontroller e(sigma_agg, G) == product(e(H_i, PK_i)). Når alle signerer den samme meldingen, reduseres verifiseringen til 2 paringer: e(sigma_agg, G) == e(H, sum(PK_i)).

Naiv BLS-aggregering er sårbar for rogue key-angrep. En angriper registrerer PK_adv = x_adv*G - PK_honest. Den aggregerte nøkkelen PK_agg = PK_honest + PK_adv = x_adv*G, som angriperen har full kontroll over. Mulige mottiltak er: (1) Proof of Possession (PoP): hver signerer beviser at vedkommende kjenner privatnøkkelen sin ved å signere sin egen offentlige nøkkel under registreringen. (2) Message augmentation: inkluder hver signers offentlige nøkkel i meldingen. (3) Delinearization (BGLS): multipliser hver offentlige nøkkel med hash(PK_i, all_PKs) før aggregering, slik at lineariteten som muliggjør angrepet brytes. Ethereum bruker PoP ved validatorregistrering.

Ethereums konsensuslag (Beacon Chain) bruker BLS12-381-aggregering i stor utstrekning. For hver slot attesterer omtrent 400 000+ aktive validatorer på kjedetoppen. Uten aggregering ville lagring av alle signaturene kreve ~400,000 * 96 bytes = 38 MB per slot. Med BLS-aggregering per komité (vanligvis 512 validatorer) produserer hver komité én aggregert signatur på 96 byte, noe som reduserer den totale signaturmengden til kilobyte per slot. Beacon Chain-blokkens innhold har aggregerte attesteringer: et bitfelt som viser hvilke validatorer som deltok, samt én aggregert BLS-signatur for hver komité.

BLS-signaturoperasjoner har andre ytelsesegenskaper enn ECDSA. BLS-signering krever én hash-to-curve-operasjon og én skalarmultiplikasjon (~1 ms på moderne maskinvare). BLS-verifisering krever to paringsoperasjoner (~3-5 ms hver = ~6-10 ms totalt). ECDSA-signering krever én punktmultiplikasjon (~0.2 ms), mens verifisering krever to punktmultiplikasjoner (~0.4 ms). BLS-verifisering er langsommere per signatur, men langt raskere samlet: verifisering av 1000 aggregerte BLS-signaturer krever ~10 ms totalt, mot ~400 ms for 1000 individuelle ECDSA-verifiseringer. Skjæringspunktet ligger rundt 2-3 signaturer.

Terskel-BLS utvider aggregering til hemmelighetsdeling. I et terskelskjema (t, n) deles privatnøkkelen i n andeler ved hjelp av Shamir-hemmelighetsdeling over BLS-skalarfeltet. Hver deltaker i produserer en delsignatur sigma_i = sk_i * H(m). Hvilke som helst t delsignaturer kan kombineres ved hjelp av Lagrange-interpolasjonskoeffisienter: sigma = sum(lambda_i * sigma_i). Resultatet er identisk med signaturen som den opprinnelige nøkkelen ville produsert, men ingen enkeltpart har noen gang hele nøkkelen. Terskel-BLS brukes i distribuert validatorteknologi (DVT), MPC-lommebøker og tjenester for terskelsignering, som Fireblocks og Web3Auth.

Filecoin bruker BLS-signaturer i systemet for lagringsbevis og til transaksjonssignering. Lagringsminere aggregerer flere bevis ved hjelp av BLS-aggregering, noe som reduserer kostnadene for verifisering på kjeden. Filecoins meldingspool aggregerer også flere transaksjonssignaturer til én enkelt aggregert signatur, noe som reduserer blokkstørrelsene. Filecoin-implementasjonen bruker IETF-utkaststandarden for BLS (hash-to-curve i henhold til RFC 9380, BLS12-381-kurven) med varianten minimum-pubkey-size, der offentlige nøkler ligger i G1 (48 byte) og signaturer i G2 (96 byte) – det motsatte av Ethereums konvensjon.

Selv om Zcash hovedsakelig bruker Groth16 zk-SNARK-bevis, danner BLS-paringer grunnlaget for mange paringsbaserte nullkunnskapskonstruksjoner. Verifiseringslikningen for Groth16 er en paringskontroll: e(A, B) = e(alpha, beta) * e(vk, C), der A, B, C er beviselementer. KZG-polynomforpliktelser (brukt i Ethereums EIP-4844 blob-transaksjoner og ulike ZK-rollupsystemer) bygger også på BLS12-381-paringer: en forpliktelse til polynomet f(x) er C = f(tau)*G, og evalueringsbevis verifiseres med paringer. BLS12-381 ble valgt spesielt på grunn av effektive paringsoperasjoner og sikkerhet på 128 bit.

BLS er ikke det eneste aggregerbare signaturskjemaet. Schnorr-signaturer støtter nøkkelaggregering (MuSig2, brukt i Bitcoin Taproot), der flere signerere produserer én Schnorr-signatur som ikke kan skilles fra en signatur fra én enkelt signerer. FROST (Flexible Round-Optimized Schnorr Threshold) tilbyr terskel-Schnorr-signaturer i to runder. Schnorr-aggregering krever imidlertid samhandling mellom signererne (i motsetning til ikke-interaktiv BLS-aggregering), noe som gjør den mindre egnet for store validatorsett. BLS er fortsatt foretrukket for blokkjede-konsensus på grunn av ikke-interaktiv aggregering og effektiv batchverifisering.

BLS-signaturer er basert på paringer på elliptiske kurver, som er sårbare for kvantedatamaskiner som kjører Shors algoritme. En tilstrekkelig kraftig kvantedatamaskin kan beregne diskrete logaritmer i BLS12-381, slik at alle eksisterende BLS-signaturer brytes og Ethereums konsensussikkerhet undergraves. Tidslinjen er usikker, men NIST anslår at det vil ta 15–20 år før kvantedatamaskiner som er relevante for kryptografi, blir tilgjengelige. Ethereum og andre kjeder som er avhengige av BLS, må migrere til postkvantesignaturskjemaer (CRYSTALS-Dilithium/ML-DSA eller SPHINCS+/SLH-DSA) før denne trusselen blir reell. Migreringen krever endringer på protokollnivå i validatorregistrering, attestasjonsformater og aggregert verifisering.

BLS-signaturer bruker bilineære paringer på BLS12-381-kurver. Signaturer er 48-bytes G1-punkter, mens offentlige nøkler er 96-bytes G2-punkter etter Ethereums konvensjon. Ikke-interaktiv aggregering kombinerer n signaturer til én verdi på 48 byte, som verifiseres med n+1 paringer. Rogue key-angrepet motvirkes av Proof of Possession under validatorregistreringen. Ethereum bruker BLS til å komprimere attestasjoner fra over 400 000 validatorer per slot til noen få kilobyte. Threshold BLS muliggjør distribuerte validatorer uten én enkelt nøkkelinnehaver. BLS er paringsbasert og ikke postkvantesikkert, så det vil kreve en fremtidig migrering.