Firme BLS e schemi di firma aggregata

Le firme BLS si basano sui pairing bilineari — un'operazione matematica sulle curve ellittiche. Un pairing e: G1 x G2 -> GT associa coppie di punti appartenenti a due gruppi (G1, G2) a un gruppo di destinazione GT. La proprietà fondamentale è la bilinearità: e(aP, bQ) = e(P, Q)^(ab) per scalari a, b e punti P, Q. Questo consente di verificare le relazioni tra elementi dei gruppi senza conoscere i logaritmi discreti. La curva di pairing più utilizzata in crittografia è BLS12-381, scelta per il suo livello di sicurezza di 128 bit, per le ridotte dimensioni degli elementi dei gruppi (48 byte in G1, 96 byte in G2) e per l'efficienza del calcolo del pairing.

Una firma BLS (Boneh-Lynn-Shacham) funziona come segue. Generazione delle chiavi: la chiave privata x è uno scalare casuale; la chiave pubblica PK = x * G, dove G è il generatore di G2. Firma: dato il messaggio m, si calcola H = hash-to-curve(m) in G1, quindi sigma = x * H. La firma sigma è un singolo punto di G1 (48 byte su BLS12-381). Verifica: si controlla e(sigma, G) == e(H, PK). Per la bilinearità, e(x*H, G) = e(H, G)^x = e(H, x*G) = e(H, PK). La sicurezza si basa sull'assunzione co-CDH: calcolare x*H dati H e x*G è difficile senza conoscere x.

Le firme BLS supportano l'aggregazione non interattiva: date le firme sigma_1, ..., sigma_n sui messaggi m_1, ..., m_n associate alle chiavi pubbliche PK_1, ..., PK_n, un aggregatore calcola sigma_agg = sigma_1 + sigma_2 + ... + sigma_n (somma di punti della curva ellittica). La firma aggregata è un singolo valore di 48 byte indipendentemente da n. La verifica richiede n+1 operazioni di pairing: si controlla e(sigma_agg, G) == product(e(H_i, PK_i)). Nel caso comune in cui tutti i firmatari firmino lo stesso messaggio, la verifica si riduce a 2 pairing: e(sigma_agg, G) == e(H, sum(PK_i)).

L'aggregazione BLS ingenua è vulnerabile all'attacco della rogue key. L'avversario registra PK_adv = x_adv*G - PK_honest. La chiave aggregata PK_agg = PK_honest + PK_adv = x_adv*G, che l'avversario controlla interamente. Opzioni di difesa: (1) Proof of Possession (PoP): ogni firmatario dimostra di conoscere la propria chiave privata firmando la propria chiave pubblica durante la registrazione. (2) Message augmentation: includere la chiave pubblica di ogni firmatario nel relativo messaggio. (3) Delinearization (BGLS): moltiplicare ogni chiave pubblica per hash(PK_i, all_PKs) prima dell'aggregazione, interrompendo la linearità che rende possibile l'attacco. Ethereum usa PoP per la registrazione dei validatori.

Il livello di consenso di Ethereum (Beacon Chain) fa ampio uso dell'aggregazione BLS12-381. A ogni slot, circa 400,000+ validatori attivi attestano la testa della catena. Senza aggregazione, memorizzare tutte le firme richiederebbe ~400,000 * 96 byte = 38 MB per slot. Con l'aggregazione BLS per comitato (in genere 512 validatori), ogni comitato produce una firma aggregata di 96 byte, riducendo la quantità totale di dati relativi alle firme a pochi kilobyte per slot. Il corpo del blocco della beacon chain contiene attestazioni aggregate: un bitfield che indica quali validatori hanno partecipato, più una firma BLS aggregata di 96 byte per ogni comitato.

Le operazioni sulle firme BLS hanno caratteristiche prestazionali diverse da quelle di ECDSA. La firma BLS richiede un hash-to-curve e una moltiplicazione scalare (~1 ms su hardware moderno). La verifica BLS richiede due operazioni di pairing (~3-5 ms ciascuna = ~6-10 ms in totale). La firma ECDSA richiede una moltiplicazione di punti (~0.2 ms); la verifica richiede due moltiplicazioni di punti (~0.4 ms). La verifica BLS è più lenta per singola firma, ma molto più veloce in forma aggregata: verificare 1000 firme BLS aggregate richiede ~10 ms in totale, rispetto a ~400 ms per 1000 verifiche ECDSA individuali. Il punto di pareggio è intorno a 2-3 firme.

BLS a soglia estende l'aggregazione alla condivisione segreta. In uno schema a soglia (t, n), la chiave privata viene suddivisa in n quote usando la condivisione segreta di Shamir sul campo degli scalari BLS. Ogni partecipante i produce una firma parziale sigma_i = sk_i * H(m). Qualsiasi t firme parziali può essere combinata usando coefficienti di interpolazione di Lagrange: sigma = sum(lambda_i * sigma_i). Il risultato è identico alla firma prodotta dalla chiave originale, ma nessuna singola parte possiede mai la chiave completa. BLS a soglia viene utilizzato nella distributed validator technology (DVT), nei portafogli MPC e nei servizi di firma a soglia come Fireblocks e Web3Auth.

Filecoin usa le firme BLS per il proprio sistema di prove di archiviazione e per la firma delle transazioni. I miner di storage aggregano più prove usando l'aggregazione BLS, riducendo i costi di verifica on-chain. Il message pool di Filecoin aggrega anche più firme di transazioni in un'unica firma aggregata, riducendo le dimensioni dei blocchi. L'implementazione di Filecoin usa la bozza dello standard BLS dell'IETF (hash-to-curve secondo RFC 9380, curva BLS12-381) con la variante minimum-pubkey-size, in cui le chiavi pubbliche sono in G1 (48 byte) e le firme in G2 (96 byte) — l'opposto della convenzione di Ethereum.

Sebbene Zcash utilizzi principalmente le prove zk-SNARK Groth16, i pairing BLS sono alla base di molte costruzioni zero-knowledge basate su pairing. L'equazione di verifica di Groth16 è un controllo di pairing: e(A, B) = e(alpha, beta) * e(vk, C), dove A, B, C sono elementi della prova. Anche gli impegni polinomiali KZG (utilizzati nelle transazioni blob EIP-4844 di Ethereum e in vari sistemi di ZK rollup) si basano sui pairing BLS12-381: un impegno al polinomio f(x) è C = f(tau)*G e le prove di valutazione vengono verificate tramite pairing. BLS12-381 è stata scelta specificamente per l'efficienza delle operazioni di pairing e per la sicurezza a 128 bit.

BLS non è l'unico schema di firme aggregabili. Le firme Schnorr supportano l'aggregazione delle chiavi (MuSig2, usato in Bitcoin Taproot), in cui più firmatari producono una singola firma Schnorr indistinguibile da quella di un singolo firmatario. FROST (Flexible Round-Optimized Schnorr Threshold) fornisce firme Schnorr a soglia in due round. Tuttavia, l'aggregazione Schnorr richiede interazione tra i firmatari (a differenza dell'aggregazione BLS non interattiva), rendendola meno adatta a grandi insiemi di validatori. BLS rimane la scelta preferita per il consenso blockchain grazie alla sua aggregazione non interattiva e alla sua efficiente verifica batch.

Le firme BLS si basano su pairing su curve ellittiche, vulnerabili ai computer quantistici che eseguono l'algoritmo di Shor. Un computer quantistico sufficientemente potente potrebbe calcolare i logaritmi discreti in BLS12-381, invalidando tutte le firme BLS esistenti e compromettendo la sicurezza del consenso di Ethereum. La tempistica non è certa, ma NIST stima 15-20 anni prima della disponibilità di computer quantistici rilevanti per la crittografia. Ethereum e le altre chain che dipendono da BLS dovranno migrare a schemi di firma post-quantistici (CRYSTALS-Dilithium/ML-DSA o SPHINCS+/SLH-DSA) prima che questa minaccia si concretizzi. La migrazione richiede modifiche a livello di protocollo per la registrazione dei validatori, i formati delle attestazioni e la verifica aggregata.

Qual è il principale vantaggio dell'aggregazione delle firme BLS nel livello di consenso di Ethereum?

Le firme BLS utilizzano pairing bilineari sulle curve BLS12-381. Le firme sono punti G1 di 48 byte; le chiavi pubbliche sono punti G2 di 96 byte secondo la convenzione di Ethereum. L'aggregazione non interattiva combina n firme in un unico valore di 48 byte, verificato con n+1 pairing. L'attacco della rogue key è mitigato dal Proof of Possession durante la registrazione dei validatori. Ethereum utilizza BLS per comprimere in pochi kilobyte le attestazioni di oltre 400.000 validatori per slot. BLS threshold consente di gestire validatori distribuiti senza un unico detentore della chiave. BLS si basa sui pairing e non offre sicurezza post-quantistica, quindi sarà necessario effettuare una migrazione in futuro.