¿Cuáles son las ventajas de Schnorr vs ECDSA?

Entiendo que las firmas Schnorr proporcionan una mejora en ECDSA en el sentido de que son 64 bytes fijos en lugar del formato de firma ECDSA más largo, sin embargo, no veo cómo esto es una ventaja sobre ECDSA en cualquier situación excepto multisig.

Con ECDSA, las transacciones se pueden firmar y verificar sin necesidad de incluir la clave pública del firmante en el mensaje. Sin embargo, Schnorr (como se describe en el BIP reciente) no tiene esa ventaja, lo que significa que para cualquier transacción que no sea desde una dirección multisig, el espacio necesario para almacenar todos los datos necesarios para la verificación sería 26 bytes más barato bajo ECDSA (suponiendo un 64 byte Schnorr sig con una clave pública comprimida de 33 bytes frente a una firma ECDSA de ~71 bytes sin una clave pública).

Con respecto a eso, ¿por qué Schnorr recibe tanta atención? ¿Las transacciones multisig constituyen suficiente carga de Bitcoin para que Schnorr sea tan importante? ¿Y por qué ha habido poco o ningún enfoque en la implementación de transacciones sin almacenar claves públicas (lo que Ethereum ha estado haciendo todo el tiempo)?

Respuestas (1)

Su pregunta parece asumir que el único objetivo es minimizar el tamaño de la transacción en cadena. La reducción del tamaño y los costos relacionados es ciertamente algo que se puede mejorar, pero está lejos de ser lo único. Las principales ventajas de la propuesta de Schnorr son:

  • Mejor privacidad , al hacer que las diferentes políticas de gasto multigrado sean indistinguibles en la cadena. Cuando se combina con Taproot, esto se extiende a casi todas las ejecuciones cooperativas de contratos (que se convierten en una sola firma en cadena, independientemente de la complejidad o la cantidad de participantes)
  • Habilitación de protocolos de nivel superior más simples , como intercambios atómicos que no se pueden distinguir de los pagos normales. Estos pueden usarse para construir construcciones de canales de pago más eficientes.
  • Mejora de la velocidad de verificación , al admitir la validación por lotes de todas las firmas en un bloque a la vez (por una fracción de la velocidad de la validación individual).
  • Cambiar a una construcción comprobablemente segura , tal vez previniendo un exploit contra ECDSA en el futuro.

En cuanto a su sugerencia específica de usar la recuperación de clave pública para evitar publicar la clave pública en un gasto, hay algunos argumentos en contra:

  • La recuperación de clave pública es incompatible con la validación por lotes y, al ignorar la validación por lotes, es (ligeramente) más lenta que la validación normal en sí misma.
  • Puede haber patentes que se apliquen a la recuperación de claves públicas.
  • El mismo tamaño de ahorro se puede lograr de manera más simple usando pay-to-pubkey en lugar de pay-to-pubkeyhash (nuevamente, cuando se combina con Taproot, esta ventaja se extiende a los scripts, así como a las construcciones de una sola clave).
  • La agregación de firmas de entrada cruzada a más largo plazo tiene un ahorro de tamaño potencial mucho mejor al reducir el número total de firmas por transacción (no solo la entrada de transacción) a 1. La agregación de entrada cruzada también es incompatible con la recuperación de clave pública, aunque esto no está incluido actualmente. en la propuesta de Schnorr.

También tenga en cuenta que la falta de recuperación de clave pública no es inherente a Schnorr: es el resultado de elegir Schnorr con prefijo de clave. Es mejor verlo como una compensación entre 3 propiedades:

  1. Linealidad : la capacidad de producir conjuntamente una firma por la suma de claves públicas (la base para todas las construcciones de firmas múltiples de Schnorr).
  2. Falta de maleabilidad de clave : con maleabilidad de clave es posible tomar una firma para una clave pública existente y convertirla en una firma para una clave relacionada (por ejemplo, una en el mismo árbol BIP32)
  3. Recuperación de clave pública : la capacidad de reconstruir una clave pública a partir de una firma y un mensaje.

Schnorr con prefijo de clave carece de recuperación de clave pública. Schnorr sin clave prefijada sufre de maleabilidad clave. ECDSA carece de linealidad. No parece posible construir un esquema de firma que tenga los tres.

¿Podría explicar qué significa linealidad en el contexto de ECDSA?
ECDSA no es lineal. Schnorr es: la ecuación de verificación de la firma es sG = R + H(R,P,m)*P. Dos personas pueden crear su propio R1 y R2, y si luego producen las firmas s1 y s2 que satisfacen la ecuación s1G = R1 + H(R1+R2,P,m)*P1, y luego suman s = s1 + s2, el resultado satisface sG = R + H(R,P,M)(P1+P2); es decir, es una firma válida para la suma de las claves. Tal construcción solo es posible debido a que la ecuación es lineal en todas las variables del firmante: s = k + H(R,P,m)x (con k = nonce, x = clave privada). Para ECDSA es sk = m + rx. La multiplicación s*k rompe la linealidad.
@PieterWuille ¿Sabe qué tan rápido es Schnorr vs ECDSA en términos de verificaciones por segundo? Albert Casademont dice ( blog.cloudflare.com/… ) que: rsa 2048 bits 34423.4 verifique/s y 256 bit ecdsa (nistp256) 4500.6 verifique/s. ¿Qué podemos esperar de Schnorr aquí (más o menos)?
@Martin Single (no por lotes) La verificación de Schnorr tiene un rendimiento muy similar al de ECDSA. En hardware razonablemente reciente, libsecp256k1 puede verificar más de 10000 firmas/s.
@PieterWuille ¿Qué tan rápido es validar por lotes un bloque con solo Schnorr sobre un bloque con solo ECDSA?
La validación de firmas probablemente sea alrededor de un factor 2 veces más rápido, pero la validación de bloques no son solo firmas, y los detalles dependen mucho de la implementación. La relación entre la validación individual y por lotes solía ser mayor en libsecp256k1, pero las mejoras generales en el rendimiento han reducido ligeramente el beneficio (al beneficiar más a la validación individual que a la por lotes).
¿Cuáles son las ventajas de Schnorr vs ECDSA?
RespuestasAquíPolítica de privacidad1y, 0v