¡Bienvenido! ¿Eres nuevo en Zcash?
La red de Zcash es joven, ¡pero evoluciona rápidamente! ¡Regístrate y nos pondremos en contacto con más información sobre cómo puedes comenzar con Zcash!

Idioma

Cultivando Sapling: Nuevos Cimientos Criptográficos

Sean Bowe | Jul 26, 2017

La próxima actualización del protocolo de Zcash, denominada Sapling, contará con una serie de mejoras en el rendimiento, la seguridad y la usabilidad de nuestras transacciones blindadas. Este es el primero de una serie de posts del blog que explorará el progreso realizado en el desarrollo de Sapling.

BLS12-381: una nueva curva zk-SNARK

Los zk-SNARK de Zcash se basan actualmente en una construcción de curva elíptica Barreto-Naehrig implementada dentro de libsnark, diseñada por nuestros científicos hace muchos años. En el tiempo transcurrido desde entonces, la optimización de Kim-Barbulescu al algoritmo de tamiz de campo numérico redujo el nivel de seguridad conjeturado de esta curva a alrededor de 110 bits, aunque la seguridad concreta de la curva según la investigación actual sigue siendo de alrededor de 128 bits, como era la intención originalmente.

Como precaución adicional, estamos aprovechando la oportunidad para actualizar nuestra curva elíptica en la actualización a Sapling. A principios de este año, presenté una nueva curva llamada BLS12-381. Esta curva apunta a 128 bits de seguridad utilizando recomendaciones más conservadoras sugeridas por varios trabajos recientes.

Ahora existe una implementación en lenguaje Rust de esta curva. Incluye fuertes garantías de seguridad de memoria, ya que no utiliza ninguna optimización de código o de ensamblaje unsafe{}. A pesar de ser una curva más grande, esta nueva implementación es más eficiente que la implementación de BN254 que usamos actualmente en Zcash.

Pairing crate benchmarks

Las aceleraciones son especialmente pronunciadas en los emparejamientos y la aritmética \(\mathbb{G}_2\), lo que aumenta el rendimiento de las pruebas y verificaciones de zk-SNARK.

Nuevo algoritmo de multi-exponenciación

La parte más costosa de crear una prueba zk-SNARK es la evaluación de grandes polinomios sobre los grupos de curvas elípticas \(\mathbb{G}_1\) y \(\mathbb{G}_2\). Esto se hace con un algoritmo llamado "multi-exponenciación" que calcula \(\prod_{i=0}^{n}{b_{i}^{s_i}}\) para un gran número de exponentes \(\vec{s}\) que residen en la memoria, y un gran número de bases \(\vec{b}\) que residen en el disco dentro de la clave de prueba zk-SNARK.

Actualmente, utilizamos la implementación de libsnark del algoritmo Bos-Coster. En el peor de los casos, este algoritmo utiliza tanta memoria como el número de bases en las que se está operando, por lo que la única vía para disminuir el uso de memoria es trabajar con subconjuntos más pequeños de las bases en cada ocasión. A modo de ejemplo, Ariel Gabizon implementó este tipo de optimización en un cambio a libsnark.

libsnark ha implementado recientemente una variante del algoritmo de Pippenger que divide la multi-exponenciación en regiones del exponente relativas a los bits, acumulando bases en conjuntos y realizando la suma por partes. Este algoritmo no sólo es más eficiente que Bos-Coster, sino que además es muy conveniente en el contexto de pruebas en stream. Con este algoritmo, podemos evitar cargar la clave de prueba en la memoria antes de construir una prueba, lo cual constituye una fuente primaria de uso de memoria en nuestro sistema.

Nuevo sistema de pruebas

Por supuesto, realizar menos multi-exponenciaciones también sería una buena manera de mejorar el rendimiento en tiempo de ejecución. Estamos considerando firmemente el uso de un nuevo sistema de pruebas zk-SNARK, descubierto por Jens Groth, para remplazar el PGHR (Pinocchio). Este sistema de pruebas realiza suposiciones criptográficas más fuertes, pero contiene pruebas más pequeñas y conjuntos de prueba/verificación más rápidos.

Lo que es más, el nuevo sistema de prueba de Groth nos permite diseñar cálculos multi-pares menos costosos y ofrece otras características realmente interesantes de las que hablaremos más en un post futuro del blog.

Próximos pasos

Aunque los esfuerzos anteriores combinados ofrecen mejoras sustanciales en el uso de la memoria y el tiempo de las pruebas, la reducción del tamaño de nuestro circuito zk-SNARK tendrá un efecto mucho más notable. Hemos construido una serie de nuevas primitivas criptográficas sobre la construcción BLS12-381 que nos permiten reducir el tamaño de nuestros circuitos aritméticos, reducir el tamaño de las direcciones Zcash y simplificar el protocolo.

En nuestro próximo artículo del blog, hablaremos más sobre estas primitivas y sobre cuánto ayudarán todas estas mejoras al rendimiento de nuestros zk-SNARKs.

Sapling, zkSNARKs, protocol | Ver todos los tags