🇪🇸 Zk-SNARKs: configuraciones actualizables en la blockchain

Los Zk-SNARKs han demostrado ser una “navaja suiza” para blockchain y libros de contabilidad distribuidos, con aplicaciones en privacidad, interoperabilidad y escalabilidad

Desde su introducción, las pruebas de conocimiento cero (ZKP) se han utilizado para respaldar aplicaciones potenciales que van desde la computación verificable externalizada hasta las credenciales anónimas, dentro de una multitud de entornos que requieren un equilibrio entre privacidad e integridad. Las ZKP permiten a una parte demostrar a otra que una determinada declaración o afirmación es verdadera, sin revelar el contenido de dicha declaración. La aplicación de las ZKP en una variedad de casos de uso en la cadena contribuye a resolver problemas de privacidad, interoperabilidad y escalabilidad.

En este post, echamos un vistazo a los diferentes tipos de ZKP y a sus casos de uso específicos. También hablamos de los zk-SNARKs, de algunos problemas conocidos en su aplicación, y proponemos un mecanismo de blockchain con características seguras en condiciones comparables al protocolo blockchain. El artículo se basa en el libro "Mining for Privacy: How to Bootstrap a Snarky Blockchain”, escrito por Thomas Kerber, Aggelos Kiayias y Markulf Kohlweiss.

Diferentes tipos de ZKP

En el entorno blockchain, es habitual que los clientes descarguen y verifiquen cada transacción publicada en la red. Esto significa que un tamaño de prueba pequeño y un tiempo de verificación rápido son importantes para el despliegue práctico de los protocolos de conocimiento cero. Hay varios esquemas prácticos entre los que elegir, con un amplio espacio de compensaciones en cuanto a rendimiento y supuestos criptográficos:

  • Argumentos de conocimiento cero no interactivos (NIZK): es el concepto más general. Los NIZK pueden ser no sucintos pero, como ventaja, pueden basarse en supuestos criptográficos estándar y a menudo satisfacen fuertes garantías de seguridad.
  • Argumentos de conocimiento cero no interactivos sucintos (SNARG): consiguen ser sucintos a costa de supuestos criptográficos más fuertes y, a menudo, de garantías de seguridad más débiles.
  • Argumentos sucintos de conocimiento cero no interactivos (SNARKs o a veces zk-SNARKs): son SNARGs que también son pruebas de conocimiento y conocimiento cero. El nombre también es popular por el poema sin sentido de Lewis Carrol “The Hunting of the Snark”.
  • Argumentos de conocimiento sucintos y transparentes (STARKs): aquí la transparencia se refiere a que la configuración sólo requiere una función hash de confianza. Esto es beneficioso, pero puede conllevar una sobrecarga de rendimiento.

En la actualidad, el sistema de demostración más atractivo desde la perspectiva del verificador es un argumento de conocimiento sucinto no interactivo (preprocesado), o zk-SNARK para abreviar, que tiene un tamaño de prueba pequeño y constante y costes de verificación en tiempo constante incluso para relaciones arbitrariamente grandes. Los Zk-SNARKs han demostrado ser una “navaja suiza” para blockchain y libros de contabilidad distribuidos, con aplicaciones en privacidad, interoperabilidad y escalabilidad.

Casos de uso

Los casos de uso de los zk-SNARKs son muy diversos. A veces, los SNARKs se emplean para mejorar el rendimiento y las propiedades de succión del sistema. Otros casos de uso emplean zk-SNARKs para mejorar la privacidad. Algunos casos son mixtos, donde ambos aspectos juegan un papel.

En el entorno blockchain, teniendo en cuenta el rendimiento y la concisión, los zk-SNARKs pueden contribuir en gran medida a casos de uso como

  • Clientes ligeros: para mejorar la eficiencia de los parámetros y la estructura general de las aplicaciones. Los sistemas de prueba eficientes (sin requisito de conocimiento cero) desempeñan un papel importante en el arranque de clientes ligeros. Los sistemas de pruebas recursivas también son un buen complemento para este caso de uso, ya que garantizan la seguridad de la recursión no limitada, así como el uso de funciones externas (por ejemplo, funciones hash) en las pruebas recursivas.

  • Contratos inteligentes: para descargar la posible congestión del libro mayor debido a la ejecución de contratos inteligentes públicos. La compilación de código en la cadena a SNARKs, con tiempo de verificación constante o logarítmico, puede permitir validadores más complejos.

  • Prueba de trabajo útil (PoUW): Los SNARKs pueden ser la clave para verificar los “cálculos útiles” realizados por los mineros, que de otro modo serían costosos de validar en la cadena.

Desde el punto de vista de la privacidad, muchas aplicaciones emplean pruebas de conocimiento cero para desplegar soluciones de pago seguras, intercambiar opciones, gestionar identidades, votar, subastas, estadísticas verificables (una forma de oráculo de blockchain) o comunicación anónima incentivada. Los casos de uso pueden incluir:

  • Contratos inteligentes privados: Los SNARKs son parte integral del diseño actual de los contratos inteligentes privados. Dos cosas son primordiales: la universalidad, para apoyar los contratos inteligentes desplegados por el usuario, y la facilidad de compilación. La expresividad de los contratos inteligentes puede eliminarse para reducir el espacio del problema, por ejemplo, desestimando los bucles no limitados y la recursividad, de modo que la composición recursiva de los SNARK no sea necesaria. Fundamentalmente, algún subconjunto de un lenguaje contractual de alto nivel puede compilarse en un circuito SNARK.

  • Pagos privados: los activos pueden verse como una forma particular de reclamación de identidad que incluye la modelización de la escasez. Una propuesta de pagos privados también puede admitir tokens multiactivos y no fungibles, y conectar estos tokens a los contratos inteligentes.

  • Gestión de la identidad: En el contexto de las credenciales verificables, los emisores pueden afirmar afirmaciones sobre los sujetos generando objetos criptográficos (credenciales). Los sujetos presentan posteriormente sus credenciales a otros usuarios que actúan como verificadores. Los verificadores son entonces capaces de validar que un emisor afirmó afirmaciones sobre el sujeto que presenta la credencial.

  • Votación y tesorería: Las pruebas ZK pueden utilizarse en la votación de la tesorería. Un sistema de tesorería para el protocolo de criptomonedas, por ejemplo, proporciona un esquema de votación que preserva la privacidad, en el que las papeletas de los votantes se encriptan y posteriormente se cuentan utilizando cálculos homomórficos. Las pruebas ZK en la tesorería son protocolos Sigma no interactivos basados en DLP que se utilizan para demostrar la corrección de los mensajes cifrados en varias etapas del protocolo (por ejemplo, que la papeleta del votante cifrada contiene una papeleta correctamente compuesta).

Los casos de uso mixto incluyen

  • Oráculos de la blockchain: Los SNARKs pueden reducir el coste de verificación cuando se agregan datos de múltiples fuentes, y pueden reducir el tamaño de los datos publicados en la cadena al incluir sólo el valor agregado y la prueba, en lugar de todos los puntos de datos. Para conseguir estas dos propiedades, las partes deben ser capaces de demostrar de forma sucinta el conocimiento de las firmas sobre un número de puntos de datos, así como la media/mediana/varianza respectiva.

  • Cadenas Laterales: una cadena en una configuración de pegging de cadena puede actuar como un cliente ligero hacia la otra cadena, verificando las transacciones entre cadenas en la otra cadena sin tener que verificar la totalidad de esa cadena. La diferencia es que este pegging se suele mantener a largo plazo, por lo que las pruebas se pueden proporcionar regularmente y de forma “actualizable”. Ver Proof of stake Sidechains para más información.

Problemas conocidos

El conocimiento cero no interactivo requiere cierta aleatoriedad compartida, o una cadena de referencia común. Para muchos sistemas sucintos, es necesaria una propiedad más fuerte:

No sólo se necesita un valor aleatorio compartido, sino que debe adherirse a una estructura específica. Una cadena de referencia estructurada (SRS) suele estar formada por elementos de grupo relacionados, es decir: gxi para todo i∈𝕫n.

La forma obvia de muestrear tal cadena de referencia a partir de la aleatoriedad pública revela los exponentes utilizados - y el conocimiento de estos valores rompe la solidez del propio sistema de pruebas. Para empeorar las cosas, la seguridad de estos sistemas se basa típicamente (entre otras cosas) en el conocimiento de las suposiciones de los exponentes, que establecen que para crear elementos de grupo relacionados de tal manera se requiere conocer los exponentes subyacentes, y por lo tanto cualquier muestreador de SRS tendrá que “conocer” los exponentes utilizados y ser de confianza para borrarlos, convirtiéndose, en efecto, en un único punto de fallo para el sistema subyacente.

La computación multipartita segura (MPC) puede utilizarse, y se ha utilizado, para reducir la confianza depositada en dicho proceso de configuración. Sin embargo, la selección de los participantes en el cómputo seguro y la verificación de la generación del SRS por el protocolo MPC conservan un elemento de centralización. El uso del MPC sigue siendo un elemento controvertido en la configuración de un sistema descentralizado que requiere SNARKs.

Resolver los problemas de privacidad con la generación segura de SRS

Una cadena de referencia estructurada actualizable (uSRS) puede ser inicializada de forma segura utilizando un libro mayor distribuido requiriendo a los creadores de bloques que realicen actualizaciones en una uSRS en evolución durante un período de configuración inicial. Después de esperar a que se llegue a un acuerdo sobre la uSRS final, ésta puede utilizarse de forma segura.

La prueba de esto se basa en los medios básicos de funcionamiento de los libros contables de estilo Nakamoto: diferentes usuarios pueden ampliar una blockchain si pueden satisfacer alguna condición, estando esta condición asociada a un tipo de dureza que garantiza que los atacantes tienen limitado el número de extensiones que pueden realizar. Dada esta estructura, asociamos una actualización uSRS a cada bloque antes de un tiempo 𝛿1. Este tiempo se selecciona de forma que las propiedades de seguridad del libro mayor garanticen que al menos uno de los bloques es honesto en cada cadena competitiva en este punto.

Esto puede construirse a partir de una funcionalidad del libro contable con un estado de liderazgo adicional, que se deriva de la información que los mineros incrustan en sus bloques para codificar las actualizaciones de uSRS. Esto se deja lo suficientemente general para permitir también otros usos. La idea básica es mostrar que un libro contable que realiza actualizaciones uSRS en su estado de liderazgo es equivalente al que no lo hace, pero va acompañado de un uSRS seguro. Después de un tiempo 𝛿1, los usuarios esperan otro período de tiempo 𝛿2 hasta que el prefijo común garantice que todas las partes están de acuerdo con la cadena de referencia.

Propuesta de abstracción del libro mayor

Nuestra construcción de la funcionalidad de la cadena de referencia estructurada actualizable se basa en las propiedades del prefijo común, la calidad de la cadena y el crecimiento de la cadena definidos en el análisis de la columna vertebral de Bitcoin por Garay et al., para los algoritmos de consenso de estilo Nakamoto:

  • Prefijo común. Dadas las cadenas actuales 𝛱1 y 𝛱2 de dos partes, y eliminando k bloques de la primera, es un prefijo de la segunda: 𝛱1⌊k ≺𝛱2.
  • Calidad de la cadena existencial. Para la cadena actual de cualquier parte 𝛱, cualquier l bloque consecutivo en esta cadena incluirá al menos un bloque creado por una parte honesta.
  • Crecimiento de la cadena. Si la cadena de una parte tiene una longitud c, entonces s ranuras de tiempo más tarde, tendrá al menos una longitud c+𝛾.

Construcción descentralizada de uSRS

Nuestra propuesta de construcción, detallada en el artículo Mining for Privacy, es sencilla: cada cadena está asociada a un uSRS específico, y cuando un minero extiende una cadena, realiza adicionalmente una actualización del uSRS. En la génesis de la cadena, se puede utilizar una aleatoriedad conocida (o incluso ninguna aleatoriedad). El principio que subyace a este diseño es sencillo: la capacidad de actualización de los uSRS garantiza que si se realiza una única actualización de forma honesta (tanto utilizando aleatoriedad verdadera como borrando esta aleatoriedad después de realizar la actualización), el uSRS resultante puede utilizarse de forma segura. Nos basamos en la propiedad de calidad existencial de la cadena para garantizar esto - una vez que se han generado l bloques, al menos uno de ellos debe ser creado por un minero honesto, y por lo tanto después de l bloques, el uSRS de una cadena es seguro.

Sin embargo, no es suficiente saber que la cadena de referencia de una cadena en particular es segura; para la mayoría de las aplicaciones prácticas, queremos que todos los usuarios estén de acuerdo con la cadena de referencia. Esto lo proporciona la propiedad de prefijo común, que garantiza que para cualquier cadena de l+k bloques, todos los demás usuarios tendrán la misma cadena de referencia que la generada por esta cadena - ¡siempre que los usuarios dejen de actualizar después de l bloques!

Por último, el crecimiento de la cadena garantiza que el acontecimiento que nos interesa -cuando todo el mundo está de acuerdo con la cadena de referencia- acabará ocurriendo. Garantiza que los usuarios acabarán teniendo una cadena de longitud l+k. En concreto, como cada s unidades de tiempo se generan bloques, el evento ocurrirá como muy tarde en el momento ⌈(l+k)/s⌉.

Todo esto está muy bien en abstracto, pero deja cuestiones de orden práctico: estos análisis abstractos suponen que las actualizaciones pueden crearse con poco o ningún coste, y que no afectan al procedimiento estándar de extracción. Sin embargo, esto no es del todo cierto para la minería de pruebas de trabajo:

1 Las actualizaciones son relativamente costosas, tardando entre 5 y 10 minutos en calcularse, dependiendo del tamaño del uSRS objetivo.

2 Es posible engañar a las actualizaciones, realizándolas más rápido pero sin añadir la seguridad de la cadena de referencia.

Estos factores combinados suponen un reto, especialmente en el entorno de la prueba de trabajo, donde la actualización debe realizarse antes de que un minero pueda empezar a minar un bloque. Esto retrasa a los mineros que no hacen trampas, mientras que sus homólogos que hacen trampas ya están minando. En consecuencia, la dificultad de minado (correspondiente al tiempo previsto entre bloques) no debería ser demasiado baja, ya que cuanto más baja sea, más se beneficia un minero tramposo. Por otro lado, una dificultad alta conduce naturalmente a un mayor tiempo para alcanzar el consenso. En la figura 1 se muestra este equilibrio.

Siempre que la dificultad se calibre adecuadamente, un análisis de simulación muestra que este efecto no perjudica la seguridad general. Dependiendo de la probabilidad de fallo (є) que estemos dispuestos a tolerar, y de la fracción del poder de extracción de un atacante (а) de la que queramos protegernos, el uSRS puede generarse de forma segura con el procedimiento bien en unas horas, o bien en varios meses en un escenario más pesimista, como se muestra en la Figura 1.

Figura 1. El tiempo necesario hasta que se garantiza al menos una actualización honesta, en función del tiempo del bloque objetivo

Fuente: artículo de investigación "Mining for Privacy: How to Bootstrap a Snarky Blockchain’

Un problema similar ocurre cuando se considera el comportamiento racional: los mineros que sólo buscan beneficios también intentarán engañar en sus actualizaciones, no por maldad, sino simplemente porque pueden producir bloques más rápido si lo hacen. Esto puede evitarse recompensando adicionalmente el buen comportamiento: se puede pedir a un muestreo de mineros, a posteriori, que proporcionen la aleatoriedad de sus actualizaciones y que demuestren que se ha muestreado de forma adecuada (por ejemplo, utilizando una función hash). Si son capaces de hacerlo, pueden ganar una recompensa adicional, compensando cualquier pérdida que pudieran tener por no hacer trampa.

En resumen, la aplicabilidad de zk-SNARKs beneficia en gran medida a diferentes casos de uso en la cadena, resolviendo problemas de privacidad, interoperabilidad y escalabilidad. Aunque la configuración de confianza, necesaria para muchos zk-SNARKs, parece estar en desacuerdo con la naturaleza descentralizada de los libros de contabilidad distribuidos, puede realizarse de forma totalmente descentralizada para los SNARKs con cadenas de referencia actualizables. Aunque en principio también es posible utilizar SNARKs transparentes como Halo, las técnicas descritas anteriormente permiten que SNARKs como Plonk (que pueden ser más eficientes dependiendo de las circunstancias), que dependen de cadenas de referencia actualizables, también se utilicen de forma segura para aplicaciones en la cadena - ya no es el caso de que las configuraciones de SNARK sean demasiado opacas para confiar, si es que alguna vez lo fueron.


:es: Traducción al español de “Zk-SNARKs: updatable setups on the blockchain”, publicado por Thomas Kerber en el blog IOG el 31 de Agosto de 2022