---
title: "Firme BLS"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Firme BLS
> 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
- [Hash crittografico](/it/crypto/cryptographic-hash/)
- [Proof of stake](/it/crypto/proof-of-stake/)
- [Firma a soglia](/it/crypto/threshold-signature/)
## Fonti
- [BLS Signatures](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force (consultato il: 2026-08-12)
- [RFC 9380: Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor (consultato il: 2026-08-12)
- [Short Signatures from the Weil Pairing](https://doi.org/10.1007/3-540-45682-1_30) - Springer (consultato il: 2026-08-12)
- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs) - Ethereum Foundation (consultato il: 2026-08-12)
- [Phase 0 Beacon Chain Specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consultato il: 2026-08-12)
- [Ethereum Annotated Specification: BLS Signatures](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation (consultato il: 2026-08-12)
- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [Consensus mechanisms](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (consultato il: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/bls-signature/index.mdx