BLS-handtekeningen en geaggregeerde handtekeningschema's

BLS-handtekeningen zijn gebaseerd op bilineaire pairings — een wiskundige bewerking op elliptische krommen. Een pairing e: G1 x G2 -> GT beeldt paren punten uit twee groepen (G1, G2) af op een doelgroep GT. De cruciale eigenschap is bilineariteit: e(aP, bQ) = e(P, Q)^(ab) voor scalaire waarden a en b en punten P en Q. Hierdoor kunnen relaties tussen groepselementen worden gecontroleerd zonder de discrete logaritmen te kennen. De meest gebruikte pairingkromme voor cryptografie is BLS12-381, gekozen vanwege het beveiligingsniveau van 128 bits, de kleine groepselementen (48 bytes in G1, 96 bytes in G2) en de efficiënte berekening van pairings.

Een BLS-handtekening (Boneh-Lynn-Shacham) werkt als volgt. Sleutelgeneratie: de privésleutel x is een willekeurige scalaire waarde; de openbare sleutel PK = x * G, waarbij G de generator van G2 is. Ondertekening: bereken voor bericht m H = hash-to-curve(m) in G1 en vervolgens sigma = x * H. De handtekening sigma is één punt in G1 (48 bytes op BLS12-381). Verificatie: controleer e(sigma, G) == e(H, PK). Door bilineariteit geldt e(x*H, G) = e(H, G)^x = e(H, x*G) = e(H, PK). De beveiliging berust op de co-CDH-aanname: het berekenen van x*H met H en x*G is moeilijk zonder x te kennen.

BLS-handtekeningen ondersteunen niet-interactieve aggregatie: gegeven handtekeningen sigma_1, ..., sigma_n voor berichten m_1, ..., m_n van openbare sleutels PK_1, ..., PK_n berekent een aggregeerder sigma_agg = sigma_1 + sigma_2 + ... + sigma_n (optelling van punten op elliptische krommen). De geaggregeerde handtekening is ongeacht n één waarde van 48 bytes. Voor verificatie zijn n+1 pairingbewerkingen nodig: controleer e(sigma_agg, G) == product(e(H_i, PK_i)). In het veelvoorkomende geval waarin alle ondertekenaars hetzelfde bericht ondertekenen, wordt verificatie teruggebracht tot 2 pairings: e(sigma_agg, G) == e(H, sum(PK_i)).

Naïeve BLS-aggregatie is kwetsbaar voor de aanval met een malafide sleutel. Een aanvaller registreert PK_adv = x_adv*G - PK_honest. De geaggregeerde sleutel PK_agg = PK_honest + PK_adv = x_adv*G, waarover de aanvaller volledige controle heeft. Mogelijke verdedigingen zijn: (1) Proof of Possession (PoP): elke ondertekenaar bewijst kennis van diens privésleutel door bij registratie de eigen openbare sleutel te ondertekenen. (2) Berichtuitbreiding: neem de openbare sleutel van elke ondertekenaar op in diens bericht. (3) Delinearizatie (BGLS): vermenigvuldig elke openbare sleutel vóór aggregatie met hash(PK_i, all_PKs), waardoor de lineariteit die de aanval mogelijk maakt, wordt doorbroken. Ethereum gebruikt PoP voor de registratie van validators.

De consensuslaag van Ethereum (Beacon Chain) maakt uitgebreid gebruik van BLS12-381-aggregatie. In elk slot brengen ongeveer 400.000+ actieve validators een attest uit over de ketentop. Zonder aggregatie zou het opslaan van alle handtekeningen ongeveer ~400,000 * 96 bytes = 38 MB per slot vereisen. Met BLS-aggregatie per commissie (doorgaans 512 validators) produceert elke commissie één geaggregeerde handtekening van 96 bytes, waardoor de totale hoeveelheid handtekeninggegevens wordt teruggebracht tot kilobytes per slot. Het bloklichaam van de Beacon Chain bevat geaggregeerde attesten: een bitveld dat aangeeft welke validators hebben deelgenomen, plus één geaggregeerde BLS-handtekening voor elke commissie.

BLS-handtekeningbewerkingen hebben andere prestatiekenmerken dan ECDSA. Ondertekenen met BLS vereist één hash-to-curve-bewerking en één scalaire vermenigvuldiging (~1 ms op moderne hardware). Voor BLS-verificatie zijn twee pairingbewerkingen nodig (~3-5 ms per bewerking = ~6-10 ms in totaal). Ondertekenen met ECDSA vereist één puntvermenigvuldiging (~0,2 ms); voor verificatie zijn twee puntvermenigvuldigingen nodig (~0,4 ms). BLS-verificatie is per handtekening langzamer, maar bij aggregatie veel sneller: voor verificatie van 1000 geaggregeerde BLS-handtekeningen is in totaal ongeveer ~10 ms nodig, tegenover ~400 ms voor 1000 afzonderlijke ECDSA-verificaties. Het omslagpunt ligt rond 2-3 handtekeningen.

BLS-drempelhandtekeningen breiden aggregatie uit met geheimdeling. In een (t, n)-drempelschema wordt de privésleutel met Shamir-geheimdeling over het scalaire veld van BLS verdeeld in n delen. Elke deelnemer i produceert een gedeeltelijke handtekening sigma_i = sk_i * H(m). Elke t gedeeltelijke handtekeningen kunnen worden gecombineerd met coëfficiënten voor Lagrange-interpolatie: sigma = sum(lambda_i * sigma_i). Het resultaat is identiek aan de handtekening die door de oorspronkelijke sleutel zou zijn geproduceerd, maar geen enkele partij beschikt ooit over de volledige sleutel. BLS-drempelhandtekeningen worden gebruikt in gedistribueerde validatortechnologie (DVT), MPC-portefeuilles en diensten voor drempelondertekening zoals Fireblocks en Web3Auth.

Filecoin gebruikt BLS-handtekeningen voor zijn systeem voor opslagbewijzen en voor het ondertekenen van transacties. Opslagminers aggregeren meerdere bewijzen met BLS-aggregatie, waardoor de verificatiekosten op de blockchain dalen. De berichtenpool van Filecoin aggregeert ook meerdere transactiehandtekeningen tot één aggregaat, waardoor blokken kleiner worden. De implementatie van Filecoin gebruikt de conceptstandaard van IETF voor BLS (hash-to-curve volgens RFC 9380, BLS12-381-kromme) met de variant met minimale openbare-sleutelgrootte, waarbij openbare sleutels in G1 staan (48 bytes) en handtekeningen in G2 (96 bytes) — het tegenovergestelde van de conventie van Ethereum.

Hoewel Zcash voornamelijk Groth16 zk-SNARK-bewijzen gebruikt, vormen BLS-pairings de basis van veel op pairings gebaseerde nulkennisconstructies. De verificatievergelijking van Groth16 is een pairingcontrole: e(A, B) = e(alpha, beta) * e(vk, C), waarbij A, B en C bewijscomponenten zijn. KZG-polynoomcommitments (gebruikt in blobtransacties van Ethereum's EIP-4844 en in verschillende ZK-rollupsystemen) zijn ook gebaseerd op BLS12-381-pairings: een commitment aan polynoom f(x) is C = f(tau)*G en evaluatiebewijzen worden via pairings geverifieerd. BLS12-381 is specifiek gekozen vanwege de efficiënte pairingbewerkingen en de beveiliging van 128 bits.

BLS is niet het enige schema voor agregeerbare handtekeningen. Schnorr-handtekeningen ondersteunen sleutelaggregatie (MuSig2, gebruikt in Bitcoin Taproot), waarbij meerdere ondertekenaars één Schnorr-handtekening produceren die niet te onderscheiden is van een handtekening van één ondertekenaar. FROST (Flexible Round-Optimized Schnorr Threshold) biedt drempelhandtekeningen op basis van Schnorr in twee rondes. Voor Schnorr-aggregatie is echter interactie tussen ondertekenaars nodig (in tegenstelling tot niet-interactieve BLS-aggregatie), waardoor deze minder geschikt is voor grote validatorsets. BLS blijft de voorkeur houden voor blockchainconsensus vanwege de niet-interactieve aggregatie en efficiënte batchverificatie.

BLS-handtekeningen zijn gebaseerd op pairings op elliptische krommen, die kwetsbaar zijn voor kwantumcomputers die het algoritme van Shor uitvoeren. Een voldoende krachtige kwantumcomputer zou discrete logaritmen in BLS12-381 kunnen berekenen, waardoor alle bestaande BLS-handtekeningen worden gebroken en de consensusbeveiliging van Ethereum teniet wordt gedaan. De tijdlijn is onzeker, maar NIST schat dat cryptografisch relevante kwantumcomputers over 15–20 jaar beschikbaar kunnen zijn. Ethereum en andere ketens die afhankelijk zijn van BLS zullen moeten overstappen op post-kwantumveilige handtekeningschema's (CRYSTALS-Dilithium/ML-DSA of SPHINCS+/SLH-DSA) voordat deze dreiging werkelijkheid wordt. De migratie vereist wijzigingen op protocolniveau in de registratie van validators, attestatie-indelingen en verificatie van aggregaten.

BLS-handtekeningen gebruiken bilineaire pairings op krommen van BLS12-381. Handtekeningen zijn G1-punten van 48 bytes; openbare sleutels zijn G2-punten van 96 bytes volgens de conventie van Ethereum. Niet-interactieve aggregatie combineert n handtekeningen tot één waarde van 48 bytes, die met n+1 pairings wordt geverifieerd. De aanval met een frauduleuze sleutel wordt beperkt door het bewijs van bezit tijdens de registratie van validators. Ethereum gebruikt BLS om meer dan 400.000 validatorattestaties per slot te comprimeren tot kilobytes. BLS met een drempelwaarde maakt gedistribueerde validators zonder één enkele sleutelhouder mogelijk. BLS is gebaseerd op pairings en niet post-kwantumveilig, waardoor toekomstige migratie nodig is.