Glosario / Protocolo y actualizaciones
Verificación por lotes
- ¿Qué es la verificación por lotes?
- La verificación por lotes verifica muchas firmas Schnorr en una sola ecuación de curva elíptica en lugar de una a una, y devuelve un único resultado de éxito o fallo para todo el conjunto.
Se especifica en el BIP-340.
Un verificador reúne u firmas, multiplica todas menos la primera por un escalar aleatorio y resuelve el conjunto con una sola ecuación en lugar de u. BIP-340 se diseñó para ello y estableció un tamaño fijo de 64 bytes para las firmas, mientras que el ECDSA estandarizado no puede verificarse por lotes en absoluto salvo que se añadan datos de testigo adicionales. El procesamiento por lotes es una decisión de cada verificador, así que cambia la rapidez con que un nodo verifica el historial y nada de sus monedas.
Cómo funciona
La verificación por lotes se especifica en BIP-340 como BatchVerify, que toma u claves públicas de 32 bytes, u mensajes y u firmas de 64 bytes y da una sola respuesta para todas ellas.
Primero vienen los coeficientes. El verificador genera u-1 enteros en el rango de 1 a n-1, donde n es el orden de la curva, de forma determinista a partir de un generador cuya semilla es un hash de todos los valores de entrada del lote: claves, mensajes y firmas por igual. BIP-340 considera SHA256 un hash seguro para la semilla y ChaCha20 una forma segura de expandirla en enteros de 256 bits, descartando los que queden fuera del rango.
El lote se reduce entonces a una sola comprobación: la suma ponderada de los valores s, multiplicada por el punto generador, tiene que ser igual al resultado de aplicar los mismos coeficientes a los puntos R y al desafío de cada firma multiplicado por su propia clave pública. Esas u verificaciones separadas se convierten en una sola comparación, a la que BIP-340 atribuye aceleraciones significativas.
Ese ahorro se paga con un costo por firma. BatchVerify vuelve a llevar cada valor r a la curva, algo que la verificación individual nunca hace: Verify recalcula R a partir de s y del desafío, y luego solo comprueba que su coordenada x sea igual a r.
La garantía es deliberadamente asimétrica. Si todas las firmas del lote son válidas, BatchVerify siempre tiene éxito; si aunque sea una no lo es, tiene éxito como mucho con una probabilidad despreciable. Lo que no hará es identificar a la culpable, así que un verificador que necesite saber qué firma falló las verifica una a una.
Dónde aparece
La verificación por lotes vive por completo del lado del verificador en la red, y por eso nunca aparece en la interfaz de una billetera ni en una estimación de comisión.
Donde compensa es en un nodo que procesa de una vez años de gastos Taproot, no en una billetera que envía un pago. BIP-340 no obliga a procesar por lotes en ningún punto: la verificación de una sola firma es la definición, y un lote es algo que un verificador puede elegir. El BIP exige un algoritmo especificado a nivel de byte, la exactitud que le faltó al análisis sintáctico de DER hasta BIP-66, para que nadie pueda construir una firma válida para unos verificadores y no para otros. Como el verificador elige sus propios lotes, esa propiedad es la que hace que la verificación por lotes y la individual solo puedan diferir con una probabilidad despreciable, incluso frente a un atacante que intente hacerlas discrepar.
El procesamiento por lotes también explica decisiones de BIP-340 que, por sí solas, parecen arbitrarias. Las firmas podrían haber adoptado una forma más corta, en la que un hash de 16 bytes basta para el objetivo de seguridad de 128 bits, y el BIP la rechazó: los hash cortos son frágiles cuando trabajan juntos firmantes que desconfían entre sí, y la forma más larga, que lleva R, es la que admite el procesamiento por lotes. Las claves públicas ocupan 32 bytes en lugar de los 33 bytes de la codificación comprimida habitual de bitcoin, una elección por compacidad, y la coordenada y que así queda fuera se restringe a la par en lugar de dejarse ambigua, porque tanto la verificación eficiente como el procesamiento por lotes necesitan que no lo sea.
ECDSA no obtiene nada de esto. BIP-340 lo da como uno de los motivos para cambiar el esquema de firma: la formulación estandarizada no puede verificarse por lotes de forma más eficiente que individualmente salvo que se añadan datos de testigo adicionales.
Verificación por lotes frente a MuSig2
Tanto la verificación por lotes como MuSig2 abaratan un gran número de firmas, pero solo MuSig2 cambia lo que se difunde.
MuSig2 agrega varios firmantes en una sola clave y una firma ordinaria de 64 bytes antes de que la transacción llegue a la red, así que su ahorro está en privacidad y espacio de bloque, y es n de n: todos los firmantes tienen que participar. La verificación por lotes deja cada firma donde estaba y solo reordena la aritmética que realiza un validador, sin la cooperación de nadie y sin que nadie lo sepa siquiera: un nodo puede agrupar por lotes firmas hechas por desconocidos con años de diferencia, en transacciones sin relación entre sí.