Firmas Schnorr
Oradores: Andreas Antonopoulos
Fecha: October 7, 2018
Transcripción De: Michael Folkson
Traducción Por: Blue Moon
Tags: Schnorr signatures
Categoría: Podcast
LTB Episodio 378 - El Petro dentro de Venezuela y las firmas Schnorr
Actualmente utilizamos el algoritmo de firma digital de curva elíptica (ECDSA), que es una forma específica de realizar firmas digitales con curvas elípticas, pero no la única. Las firmas Schnorr tienen algunas características únicas que las hacen mejores en muchos aspectos que el algoritmo ECDSA que usamos actualmente en Bitcoin.
Las firmas Schnorr son mejores porque tienen ciertas peculiaridades en la forma en que se desarrollan las matemáticas. Las firmas digitales son números, sólo son números. La forma en que se calculan estos números es de tal manera que otra persona puede verificar que usted calculó este número con el conocimiento de la clave privada sin revelar realmente esta clave privada. Pueden verificar que tienes la clave privada cuando hiciste la firma. Un algoritmo de firma digital no es más que una función matemática que te da un número como resultado de aplicar la clave privada a un mensaje de tal manera que otra persona puede verificar que ese número revela que conocías la clave privada sin conocer ella misma la clave privada. Tiene dos aspectos: firmar y verificar.
Las firmas Schnorr presentan ciertas características que las hacen mejores. La primera de ellas es la capacidad de hacer agregación. Esto significa que si quieres firmar varios mensajes diferentes con varias claves privadas diferentes y producir varias firmas diferentes, con Schnorr lo que puedes hacer es producir una firma agregada que es el equivalente a si hubieras firmado el mensaje agregado con el agregado de todas las claves privadas. Piénsalo de esta manera. Es como si la suma de todas las firmas fuera lo mismo que si aplicaras una firma con la suma de todas las claves privadas sobre la suma de todos los mensajes. Estoy utilizando la suma en un sentido más amplio. No es la operación aritmética tradicional de la suma, pero es el equivalente en las curvas elípticas.
En Bitcoin una transacción puede tener varias entradas y cada una de ellas tiene su propia firma. Digamos que usted tiene una transacción que está gastando pequeños trozos de monedas de cuatro direcciones diferentes que su cartera controla, todo el cambio suelto que tenía y lo está pagando en algún lugar. En una transacción tradicional de Bitcoin usted tendría cuatro entradas en su transacción para agregar todo este cambio suelto que usted tenía. Tendrías que aplicar cuatro firmas con cuatro claves públicas diferentes contra el mismo mensaje de transacción para poder gastar esa transacción. Con las firmas Schnorr puede aplicar una firma agregada a las cuatro entradas, lo que significa que utiliza una cuarta parte del espacio de la transacción.
Ahora, ve un paso más allá y piensa que tienes un bloque que tiene mil transacciones firmadas por diferentes personas con diferentes claves privadas en diferentes transacciones. ¿Qué pasaría si pudieras agregar todas las firmas de todas las transacciones y sólo propagarlas como parte de la verificación del bloque? Alguien puede simplemente validar que la firma de todo el bloque es válida para todas las transacciones que están en ese bloque sumando todas las transacciones y todas las claves públicas y contando una vez. Si es válida, ya está hecho y saben que todas las firmas eran válidas. Si no lo es, tendrán que comprobar cada una de ellas de forma independiente, pero ese es un caso muy raro en Bitcoin. La mayoría de las veces lo que se puede hacer es agregar todas las firmas de una transacción en una sola firma y luego agregar todas las firmas de todas las transacciones de un bloque en una sola firma para todo el bloque.
Estás transmitiendo 1/25 de los datos en ese caso particular. Optimiza el ancho de banda, optimiza el almacenamiento en disco, optimiza la capacidad de la cadena de bloques. Optimiza la velocidad de verificación. Eso es sólo el comienzo. Aquí hay otro escenario. Digamos que estás tratando de hacer un multisig entre 5 participantes. Digamos un multisig de 5 de 5. Hoy en día, para hacer eso con un multisig tradicional tendrías que aplicar 5 firmas que corresponden a las 5 claves públicas que se conocen para el multisig y tendrías que verificar las 5 firmas para confirmar ese multisig. Con las firmas Schnorr y una construcción inventada por, creo, Andrew Poelstra, Greg Maxwell y Pieter Wuille, llamada musig, se puede hacer una multifirma compuesta, lo que significa básicamente que las 5 partes se reúnen y producen una firma que representa el conjunto de sus 5 claves públicas. Se valida como una sola firma en la multisig, que es el voto unánime si se quiere, el caso unánime de una multisig es un caso especial y se puede hacer con una firma que se construye conjuntamente por los 5 participantes. Así que la multisig se convierte en una operación de una sola firma. Ese es el primer paso. Ahora imagina que esto, desde la perspectiva pública, fuera indistinguible de un pago único en el que una sola parte firma con una sola clave pública y una sola firma, lo que significa que puedes convertir todos los multisig para que parezcan exactamente lo mismo que una operación de pago directa con una sola firma en Bitcoin.
Ahora imagina que puedes hacer eso no sólo para el caso unánime de una multifirma de 5 de 5, sino que puedes hacerlo para cualquier tipo de función booleana monótona, es decir, esta llave o estas dos y esta otra o estas tres más un bloqueo de tiempo de 30 minutos y estas otras dos o este bloqueo de tiempo y estas cinco llaves. Cualquier combinación de OR, AND, OR, AND, OR, AND de cualquier grupo de llaves puede ser representada ahora por una sola firma agregada que abrevia todo eso. Puedes hacer que todo eso parezca un simple pago. Su uso de los contratos inteligentes de manera efectiva y las soluciones de pago complejas son invisibles porque todo parece como si un solo pago se hiciera con una sola firma por una sola clave pública.
Requiere una bifurcación suave y el código de prueba ya ha sido escrito y presentado como un BIP.
En primer lugar, muchas de las investigaciones son muy, muy nuevas. El constructo musig, que es una optimización masiva de multisig para Schnorr, se inventó hace aproximadamente un año y se escribió sobre él. Los detalles de la implementación se han ido perfilando recientemente. Algunas de estas nuevas formulaciones, la ocultación de multisig y hacer que parezca un solo pago que se llama taproot y la propiedad equivalente llamada graftroot. Son dos inventos nuevos, apenas tienen unos meses desde que se habló de ellos. Ahora se trata de perfeccionar los detalles de la creación de una implementación que sea lo suficientemente flexible, genérica y eficiente como para abarcar todas estas mejoras de privacidad y verificación. La siguiente cuestión era el escollo o el punto de decisión principal era si estos se lanzan como una serie de cambios que son discretos entre sí y, si es así, lo que hacen es crear un desafío por el que las personas que tratan de utilizar los mecanismos de privacidad encantados son obvios, son visibles. O los haces todos en un lote de cambios para que puedas pasar inmediatamente al modelo en el que tu compleja multisig parece un pago con una sola firma, en cuyo caso las personas que usan estas características de privacidad mejoradas son indistinguibles de las que no lo hacen, lo que hace que la privacidad sea aún más poderosa. La decisión que parece haber salido de esto es desplegar todas estas características juntas para que la privacidad no sea algo que se pueda distinguir de los que no usan la privacidad. Esa es una gran idea en mi opinión. Ahora taproot, graftroot y Schnorr musig van a ser desplegados al mismo tiempo con un único soft fork.
Creo que no falta más de un año para que llegue ese momento. Cuando la tecnología se despliega a nivel de protocolo no significa que esté disponible en un monedero que se pueda utilizar con una bonita interfaz de usuario. Eso puede llevar otro año hasta que sea ampliamente utilizable, pero la función debería añadirse a Bitcoin y crear un aumento significativo de la privacidad, optimizaciones para la escalabilidad y un mejor multisig probablemente en el próximo año.
Se puede agregar un número infinito de firmas hasta llegar a una. Hay alguna relación entre esto y el enfoque de Mimblewimble para hacer la compresión de bloques que es bastante interesante. Las discusiones son desde una perspectiva práctica. ¿Cuánto espacio se ahorra si se hace esto dentro de una transacción? ¿Cuánto espacio se ahorra si se hace dentro de un bloque? ¿Se puede hacer entre bloques? Una de las cosas que hay que tener en cuenta es que hay que hacerlo de forma que no se rompa la compatibilidad con los clientes existentes o que permita que sea una característica opcional en lugar de una característica obligatoria que todo el mundo tenga que seguir.
Actualmente nos encontramos en la cuarta generación de multisig y las tres anteriores todavía están muy presentes. La primera generación de multisig es lo que se llama naked multisig que es multisig sin pay-to-script-hash. Es multisig sin una dirección ‘3’, pero donde se pone todo el script en el UTXO. Eso es muy raro hoy en día, probablemente no lo verás. Luego tienes el multisig envuelto en P2SH que es lo que la mayoría de nosotros usamos, donde la dirección del multisig comienza con un ‘3’. Ese es el que más conocemos. La mayoría de la gente no se ha dado cuenta de que ahora hay una nueva forma de multisig que es el multisig con una dirección SegWIt que es el multisig pay-to-witness-script-hash que es una dirección ‘bc1’ con una nueva dirección estilo SegWit. Esto no está muy extendido porque SegWit es tan nuevo que la gente todavía no ha hecho multisig de SegWit pero está empezando a aparecer ahora en algunas carteras. Schnorr multisig sería la cuarta iteración y todavía tienes las tres anteriores en funcionamiento. Es una ventana rodante.
Estoy seguro de que habrá reacciones en contra de esto, no hay tal cosa como una actualización no controvertida del protocolo de Bitcoin. Por supuesto, se trata de una actualización no obligatoria y compatible con el pasado, de modo que no hay que validar o utilizar esta función si no se quiere, pero eso no quita que sea controvertida. En un mundo en el que las vacunas son controvertidas, no creo que veamos nunca una mejora de Bitcoin que no lo sea.