---
title: "Firmas BLS"
description: "Una guía centrada en la verificación de firmas Boneh-Lynn-Shacham, modalidades de agregación, suites criptográficas, defensas contra claves maliciosas, uso en el consenso de Ethereum y riesgos de implementación."
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.
# Firmas BLS
> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
## Respuesta directa
Una firma Boneh-Lynn-Shacham es una firma digital basada en emparejamientos bilineales. En una orientación habitual, la clave secreta `sk` genera la clave pública `PK = sk * G1`; el mensaje `m` se transforma en `H(m)` dentro de `G2`; y la firma `sig = sk * H(m)` se verifica mediante `e(PK, H(m)) = e(G1, sig)`. Los grupos exactos, las codificaciones, la suite hash-to-curve y la separación de dominios son elecciones de la suite criptográfica, no notaciones intercambiables.
BLS ofrece una ventaja operativa singular: las firmas válidas pueden sumarse en un único elemento de grupo de tamaño constante. Esto comprime las firmas, pero no la lista de firmantes, ni demuestra quorum, identifica validadores autorizados, impide equivocaciones o hace definitivo el consenso. Esas propiedades proceden del protocolo que la rodea.
## Cómo funciona
1. Fija protocolo, suite criptográfica y versión: curva, grupos de claves públicas y firmas, serialización, función hash-to-curve, etiqueta de separación de dominio y construcción de la raíz del mensaje. Nunca deduzcas compatibilidad solo por la etiqueta BLS.
2. Genera `sk` con el procedimiento de generación de claves especificado y deriva `PK`. Rechaza codificaciones cero, infinito, malformadas, no canónicas o del subgrupo incorrecto aplicando exactamente `KeyValidate` y las reglas de deserialización.
3. Construye los bytes exactos del mensaje y el dominio de firma. En el consenso de Ethereum, la raíz de firma vincula la raíz SSZ del objeto con un dominio derivado del tipo de operación y los datos del fork; el texto mostrado no es el objeto firmado.
4. Firma y verifica individualmente con el esquema elegido. Las variantes Basic, de aumento del mensaje y proof of possession emplean defensas distintas contra claves maliciosas y no deben mezclarse sin cuidado.
5. Elige el verificador agregado según el patrón de mensajes. Usa `FastAggregateVerify` solo para varias claves públicas validadas que firman el mismo mensaje bajo los supuestos requeridos de proof of possession; usa `AggregateVerify` para la lista de claves públicas y mensajes permitida por el esquema.
6. Reconstruye independientemente el conjunto de firmantes a partir de los datos del comité o de un bitlist de participantes, rechaza índices duplicados o no autorizados, aplica pesos de stake o umbral y después verifica la firma agregada. Un agregado válido autentica el conjunto aportado; no determina si este cumple la política.
7. Concilia el resultado con fork choice, condiciones de slashing, quorum, disponibilidad, tiempos y finalidad. Conserva bytes de entrada, dominios, índices de firmantes, versión de implementación y vectores de prueba, y compara bibliotecas independientes antes del despliegue.
## Ejemplos desarrollados
- **La compresión no elimina los datos de pertenencia.** El consenso de Ethereum codifica cada clave pública BLS en `48 bytes` y cada firma en `96 bytes`. Para `512` firmas sobre el mismo mensaje, las firmas separadas ocupan `512 * 96 = 49,152 bytes`. Una firma agregada más un bitlist de participantes de `512-bit = 64-byte` ocupa `96 + 64 = 160 bytes`, una reducción de `49,152 - 160 = 48,992 bytes`, o `99.6744791667%`. Las claves públicas de los validadores y el mapeo del comité deben seguir disponibles en otro lugar.
- **Agregación sobre el mismo mensaje.** Supón que los validadores registrados `17`, `24` y `91` firman la misma raíz de firma `R`. Sus firmas se agregan como `sigAgg = sig17 + sig24 + sig91`. La verificación utiliza el conjunto ordenado de claves públicas validadas `[PK17, PK24, PK91]`, la misma `R` y `FastAggregateVerify`. Un resultado válido demuestra que esas claves firmaron `R` bajo el esquema; otra regla decide su peso y si tres firmantes forman quorum.
- **Mensajes distintos requieren la API correcta.** Las claves `PK1`, `PK2` y `PK3` firman los mensajes distintos `m1`, `m2` y `m3`. El verificador debe conservar los pares `[PK1, m1]`, `[PK2, m2]` y `[PK3, m3]`, y llamar al `AggregateVerify` aplicable; sustituir esas entradas por un único mensaje y `FastAggregateVerify` verifica una afirmación diferente. Bajo el esquema Basic, los mensajes también deben ser distintos.
- **Agregación no es firma umbral.** En un grupo de `8` miembros, agregar de forma ordinaria las firmas de los miembros `[1, 2, 4, 6, 8]` genera una firma y una lista de cinco firmantes. No se convierte en una firma umbral `5-of-8` bajo una sola clave pública de grupo. Un diseño BLS umbral real requiere generación distribuida de claves o un dealer de confianza, índices de participaciones y reglas de interpolación; sus supuestos de confianza y fallo deben auditarse por separado.
## Riesgos
- Usar una curva, orientación de grupos o suite criptográfica distinta de la del protocolo.
- Firmar bytes serializados distintos pese a mostrar el mismo mensaje legible.
- Omitir el dominio del fork, operación o aplicación y permitir replay entre contextos.
- Tratar un Internet-Draft caducado como un estándar final e inmutable.
- Aceptar codificaciones de puntos malformadas, no canónicas o en el infinito.
- Omitir comprobaciones de subgrupo y admitir entradas de curva no válida o subgrupo pequeño.
- Usar código hash-to-curve improvisado en vez de la suite y los vectores de prueba especificados.
- Generar claves secretas sesgadas, nulas, duplicadas, filtradas o derivadas de forma predecible.
- Reutilizar una clave entre protocolos cuyos supuestos de proof of possession y dominio difieren.
- Agregar claves públicas no registradas sin la defensa contra claves maliciosas exigida por el esquema.
- Invocar la verificación rápida de mismo mensaje para mensajes distintos o raíces incoherentes.
- Permutar, duplicar u omitir la asociación entre clave pública y mensaje.
- Confiar en un bitlist de participantes sin comprobar pertenencia al comité e índices únicos.
- Contar firmas en vez del stake, peso o umbral definido por el protocolo.
- Suponer que un agregado revela qué firma individual era inválida.
- Confundir agregación ordinaria, multifirmas y firmas umbral.
- Tratar la validez de la firma como prueba de disponibilidad de datos, corrección de ejecución o finalidad.
- Ignorar equivocaciones, mensajes sancionables, ventanas temporales o el contexto de fork choice.
- Depender de una sola biblioteca, función de CPU u optimización de verificación por lotes no comprobada.
- Subestimar el coste del emparejamiento, entradas de denegación de servicio, canales laterales, custodia de claves, actualizaciones y ausencia de seguridad poscuántica.
## Errores comunes
- Una firma agregada demuestra que participaron todos los validadores.
- Cualquier combinación de claves públicas y firmas BLS es segura sin reglas de proof of possession.
- La agregación de tamaño constante elimina la necesidad de transmitir o reconstruir la pertenencia de los firmantes.
- La agregación BLS y BLS umbral son la misma construcción.
- Una firma BLS válida hace que el bloque, mensaje de bridge o protocolo firmado sea económicamente seguro y definitivo.
## Temas relacionados
- [Hash criptográfico](/es/crypto/cryptographic-hash/)
- [Proof of stake](/es/crypto/proof-of-stake/)
- [Firma umbral](/es/crypto/threshold-signature/)
## Fuentes
- [BLS Signatures](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force (consultado: 2026-08-12)
- [RFC 9380: Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor (consultado: 2026-08-12)
- [Short Signatures from the Weil Pairing](https://doi.org/10.1007/3-540-45682-1_30) - Springer (consultado: 2026-08-12)
- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs) - Ethereum Foundation (consultado: 2026-08-12)
- [Phase 0 Beacon Chain Specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consultado: 2026-08-12)
- [Ethereum Annotated Specification: BLS Signatures](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation (consultado: 2026-08-12)
- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals (consultado: 2026-08-12)
- [Consensus mechanisms](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (consultado: 2026-08-12)
Source: https://wiki.fcontext.com/es/crypto/bls-signature/index.mdx