Saltar al contenido
Financial Context Wiki

Firmas BLS

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.

Actualizado

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

Fuentes

Navegación

Buscar en la wiki...