Vai al contenuto
Financial Context Wiki

Firme BLS

Una guida incentrata sulla verifica delle firme Boneh-Lynn-Shacham, le modalità di aggregazione, le suite crittografiche, le difese contro le rogue key, l'impiego nel consenso di Ethereum e i rischi di implementazione.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Una firma Boneh-Lynn-Shacham è una firma digitale basata su pairing bilineari. In un orientamento comune, la chiave segreta sk produce la chiave pubblica PK = sk * G1; il messaggio m viene mappato in H(m) in G2; e la firma sig = sk * H(m) viene verificata tramite e(PK, H(m)) = e(G1, sig). Gruppi esatti, codifiche, suite hash-to-curve e separazione del dominio sono scelte della suite crittografica, non notazioni intercambiabili.

BLS offre un vantaggio operativo insolito: le firme valide possono essere sommate in un unico elemento del gruppo di dimensione costante. Ciò comprime le firme, ma non l’elenco dei firmatari, né dimostra il quorum, identifica i validatori autorizzati, impedisce l’equivocazione o rende definitivo il consenso. Queste proprietà provengono dal protocollo circostante.

Come funziona

  1. Fissa protocollo, suite crittografica e versione: curva, gruppi delle chiavi pubbliche e delle firme, serializzazione, funzione hash-to-curve, tag di separazione del dominio e costruzione della radice del messaggio. Non dedurre mai la compatibilità dalla sola etichetta BLS.
  2. Genera sk con la procedura specificata e deriva PK. Rifiuta codifiche zero, infinito, malformate, non canoniche o appartenenti al sottogruppo errato applicando esattamente KeyValidate e le regole di deserializzazione.
  3. Costruisci i byte esatti del messaggio e il dominio di firma. Nel consenso di Ethereum, la signing root lega la radice SSZ di un oggetto a un dominio derivato dal tipo di operazione e dai dati del fork; il testo visualizzato non è l’oggetto firmato.
  4. Firma e verifica individualmente con lo schema selezionato. Le varianti Basic, message augmentation e proof of possession adottano difese diverse contro le rogue key e non devono essere mescolate con leggerezza.
  5. Scegli il verificatore aggregato in base allo schema dei messaggi. Usa FastAggregateVerify solo per più chiavi pubbliche convalidate che firmano lo stesso messaggio nel rispetto delle ipotesi richieste di proof of possession; usa AggregateVerify per l’elenco di chiavi pubbliche e messaggi consentito dallo schema.
  6. Ricostruisci indipendentemente l’insieme dei firmatari dai dati del comitato o da una bitlist dei partecipanti, rifiuta indici duplicati o non autorizzati, applica i pesi di stake o di soglia e poi verifica la firma aggregata. Un aggregato valido autentica l’insieme fornito; non decide se esso soddisfa le regole.
  7. Riconcilia il risultato con fork choice, condizioni di slashing, quorum, disponibilità, tempistiche e finalità. Conserva byte di input, domini, indici dei firmatari, versione dell’implementazione e vettori di test, e confronta librerie indipendenti prima del deployment.

Esempi svolti

  • La compressione non elimina i dati di appartenenza. Il consenso di Ethereum codifica ogni chiave pubblica BLS in 48 bytes e ogni firma in 96 bytes. Per 512 firme dello stesso messaggio, le firme separate occupano 512 * 96 = 49,152 bytes. Una firma aggregata più una bitlist dei partecipanti di 512-bit = 64-byte occupa 96 + 64 = 160 bytes, con una riduzione di 49,152 - 160 = 48,992 bytes, ossia 99.6744791667%. Le chiavi pubbliche dei validatori e la mappatura del comitato devono comunque essere disponibili altrove.
  • Aggregazione dello stesso messaggio. Supponiamo che i validatori registrati 17, 24 e 91 firmino la stessa signing root R. Le loro firme vengono aggregate come sigAgg = sig17 + sig24 + sig91. La verifica usa l’insieme ordinato e convalidato di chiavi pubbliche [PK17, PK24, PK91], la stessa R e FastAggregateVerify. Un risultato valido dimostra che tali chiavi hanno firmato R nell’ambito dello schema; una regola distinta decide il loro peso e se tre firmatari costituiscono un quorum.
  • Messaggi distinti richiedono l’API corretta. Le chiavi PK1, PK2 e PK3 firmano i messaggi distinti m1, m2 e m3. Il verificatore deve conservare gli abbinamenti [PK1, m1], [PK2, m2], [PK3, m3] e chiamare l’AggregateVerify applicabile; sostituire tali input con un solo messaggio e FastAggregateVerify verifica un’affermazione diversa. Nello schema Basic, anche i messaggi devono essere distinti.
  • L’aggregazione non è una firma a soglia. In un gruppo di 8 membri, l’aggregazione ordinaria delle firme dei membri [1, 2, 4, 6, 8] produce una firma e un elenco di cinque firmatari. Non diventa una firma a soglia 5-of-8 sotto un’unica chiave pubblica di gruppo. Un vero sistema threshold BLS richiede la generazione distribuita delle chiavi o un dealer fidato, indici delle quote e regole di interpolazione; le sue ipotesi di fiducia e di guasto devono essere verificate separatamente.

Rischi

  • Usare una curva, un orientamento dei gruppi o una suite crittografica diversi da quelli del protocollo.
  • Firmare byte serializzati diversi pur mostrando lo stesso messaggio leggibile.
  • Omettere il dominio del fork, dell’operazione o dell’applicazione, consentendo replay tra contesti.
  • Trattare un Internet-Draft scaduto come uno standard definitivo e immutabile.
  • Accettare codifiche di punti malformate, non canoniche o all’infinito.
  • Saltare i controlli del sottogruppo e ammettere input invalid-curve o small-subgroup.
  • Usare codice hash-to-curve ad hoc invece della suite e dei vettori di test specificati.
  • Generare chiavi segrete distorte, nulle, duplicate, esposte o derivate in modo prevedibile.
  • Riutilizzare una chiave tra protocolli con ipotesi diverse di proof of possession e dominio.
  • Aggregare chiavi pubbliche non registrate senza la difesa dalle rogue key richiesta dallo schema.
  • Chiamare la verifica rapida dello stesso messaggio per messaggi distinti o radici incoerenti.
  • Permutare, duplicare o omettere l’associazione tra chiave pubblica e messaggio.
  • Fidarsi di una bitlist dei partecipanti senza verificare appartenenza al comitato e unicità degli indici.
  • Contare le firme anziché lo stake, il peso o la soglia definiti dal protocollo.
  • Presumere che un aggregato riveli quale singola firma fosse invalida.
  • Confondere aggregazione ordinaria, multifirme e firme a soglia.
  • Considerare la validità della firma una prova di disponibilità dei dati, correttezza dell’esecuzione o finalità.
  • Ignorare equivocazione, messaggi soggetti a slashing, finestre temporali o contesto della fork choice.
  • Affidarsi a una sola libreria, funzione CPU o ottimizzazione non verificata della validazione in batch.
  • Sottovalutare il costo dei pairing, gli input denial-of-service, i canali laterali, la custodia delle chiavi, gli upgrade e l’assenza di sicurezza post-quantistica.

Idee errate comuni

  • Una firma aggregata dimostra che ogni validatore ha partecipato.
  • Qualsiasi combinazione di chiavi pubbliche e firme BLS è sicura senza regole di proof of possession.
  • L’aggregazione di dimensione costante elimina la necessità di trasmettere o ricostruire l’appartenenza dei firmatari.
  • L’aggregazione BLS e threshold BLS sono la stessa costruzione.
  • Una firma BLS valida rende il blocco, il messaggio di bridge o il protocollo firmato economicamente sicuro e definitivo.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...