Construyendo un servicio de moneda privada usando Exonum

Las pruebas / argumentos de conocimiento cero son una tecnología criptográfica emergente que promete acercarnos al Santo Grial de blockchain: proporcionar privacidad y auditabilidad de los datos.

Las aplicaciones potenciales para conocimiento cero incluyen, pero no se limitan a:


Otra aplicación para pruebas de conocimiento cero es ayudar a las cadenas de bloques a escalar . Los ZKP permiten la "compresión" de los cálculos para las transacciones de blockchain sin sacrificar la seguridad.

En este artículo, describimos cómo se puede aplicar el conocimiento cero (específicamente, Bulletproofs ) para construir un servicio centrado en la privacidad utilizando la plataforma Exonum de Bitfury.



An√°lisis situacional


Es posible lograr cierto nivel de privacidad de datos en las aplicaciones blockchain utilizando el enfoque de "jard√≠n amurallado", donde los datos est√°n ocultos porque el acceso a ellos est√° restringido con la ayuda de firewalls, control de acceso basado en roles, fosos y otras medidas de seguridad perimetral . Los datos confidenciales en la cadena de bloques pueden encriptarse (quiz√°s, con un esquema de encriptaci√≥n de clave p√ļblica, con las claves p√ļblicas relevantes administradas por la misma cadena de bloques) y / o almacenarse fuera de la cadena de bloques (en este caso, la cadena de bloques solo almacena huellas digitales hash de los datos) Este enfoque se utiliza en muchos marcos contables distribuidos autorizados.

Sin embargo, las desventajas del enfoque de "jard√≠n amurallado" son cada vez m√°s evidentes. Para decirlo sin rodeos, el enfoque es antit√©tico a uno de los principales puntos de venta de blockchain: la auditabilidad. Si los datos en la cadena de bloques no se pueden auditar consultando la l√≥gica del contrato inteligente, la cadena de bloques se convierte en un servicio de marca de tiempo vinculado glorificado. El hecho de que haya algunos datos en la cadena de bloques ya no significa que estos datos sean v√°lidos seg√ļn las reglas del contrato inteligente. La segunda desventaja principal del enfoque de jard√≠n amurallado es que no se escala. El CTO de R3, Richard Brown, por ejemplo, compar√≥ acertadamente el modelo de privacidad de su soluci√≥n con los canales de Slack: es dif√≠cil agregar o eliminar de forma segura a los participantes del jard√≠n, a√ļn m√°s cuando no hay expectativas previas en cuanto al n√ļmero e identidades de estos participantes

Aqu√≠ es donde el conocimiento cero puede ser valioso. Por dise√Īo, las pruebas y argumentos de conocimiento cero prueban de manera convincente una declaraci√≥n sobre datos privados sin revelar nada sobre los datos, excepto la declaraci√≥n que se est√° probando. ¬°Es f√°cil hacer que las pruebas de conocimiento cero sean universalmente verificables, sin sacrificar la privacidad! ¬≤ Esta caracter√≠stica es exactamente lo que se necesita para construir un sistema que mantenga la privacidad y sea auditable al mismo tiempo.

Nuestra investigacion


Para demostrar el uso de pruebas de conocimiento cero, vamos a construir un servicio de criptomonedas con una funcionalidad similar a los servicios de tutor√≠a en la documentaci√≥n de Exonum . El servicio permite registrar usuarios y billeteras (proporcionando un saldo inicial de tokens como recompensa) y transferir tokens entre las partes registradas. Todas las transacciones se autentican con la ayuda de un criptosistema de firma digital, Ed25519, que est√° integrado en los servicios de Exonum. No ocultamos las identidades de las partes que realizan transacciones (es decir, sus claves p√ļblicas), pero ocultamos la cantidad de tokens que se realizan y el saldo de cada cuenta en el sistema. Tambi√©n discutimos c√≥mo podr√≠amos mejorar el servicio para ocultar las entidades de transacci√≥n al final del art√≠culo.

El servicio es de código abierto y se puede acceder aquí .

Fondo de criptografía


Para entender cómo funciona el servicio, primero debemos presentarnos a la primitiva criptográfica central que sustenta Bulletproofs, un concepto llamado compromisos de Pedersen . Un esquema de compromiso criptográfico es algo así como una función hash: alguien ingresa datos secretos (la apertura) y obtiene la salida que está codificada de manera irreconocible (el compromiso). Entonces se puede revelar la apertura para demostrar que el valor comprometido le corresponde.

La diferencia con las funciones hash es que adem√°s de ser vinculante (nadie puede idear dos aperturas diferentes que produzcan el mismo compromiso), tambi√©n se espera que se oculte un esquema de compromiso (es imposible revertir el esquema y producir una apertura dado un compromiso). Una funci√≥n hash se oculta si su entrada se distribuye uniformemente sobre todo el espacio de entrada, pero esta suposici√≥n con frecuencia no se cumple para los compromisos (de hecho, debe ser posible comprometerse con un valor de un conjunto muy peque√Īo, como Boolean). Como tal, la abertura contiene, adem√°s de la carga √ļtil, el factor de cegamiento que hace (al menos estad√≠sticamente) improbable adivinar la carga √ļtil dado el compromiso.

El esquema de compromiso de Pedersen utiliza un grupo de primer orden , en el que se cree que el problema de logaritmo discreto (DLP) es difícil, junto con dos generadores, G y H. G y H deben elegirse de tal manera que se desconozca la relación de registro discreta entre ellos; en otras palabras, nadie sabe k tal que H = kG .³ La apertura es un par (x, r) , donde x es el valor comprometido y r es el factor de cegamiento; ambos son escalares grupales (esencialmente, enteros con "desbordamiento" similar a los tipos enteros finitos utilizados en la mayoría de los lenguajes de programación). El compromiso se calcula como Comm (x; r) = xG + rH . Se puede demostrar que si DLP en el grupo es difícil, el compromiso de Pedersen es computacionalmente vinculante y perfectamente oculto.

La propiedad crucial para los compromisos de Pedersen es que son aditivos: la suma (o diferencia) de 2 compromisos es un compromiso con la suma (o diferencia) de los valores comprometidos. De hecho,

C1 = x1 G + r1 H; C2 = x2 G + r2 H => C1 + C2 = (x1 + x2) G + (r1 + r2) H = Comm(x1 + x2; r1 + r2). 

No incluimos los detalles aquí sobre cómo se construyen y verifican las balas, pero se puede encontrar más información en los siguientes recursos: [ 1 ] y [ 2 ]. Es suficiente tener en cuenta que se supone que el límite superior del límite M tiene la forma 2 ^ (2 ^ n) , lo que conduce a la construcción de prueba más eficiente.

Construyendo un servicio


Con nuestro conocimiento, podemos ocultar de forma segura los saldos de las cuentas y transferir cantidades con la ayuda de los compromisos de Pedersen. Usando pruebas de rango, podemos probar / verificar que una transferencia es correcta:

  • El monto transferido es positivo
  • El remitente tiene saldo suficiente en su cuenta.

Para la primera prueba, asumimos el compromiso con el monto de la transferencia, C_a (está directamente presente en la transacción de transferencia), y verificamos que el valor comprometido en C_a-Comm (1; 0) se encuentra en el rango [0, M) . De hecho, esto es equivalente a probar que C_a corresponde a un valor en el rango [1, M] . El remitente puede presentar esta prueba, ya que conoce la cantidad transferida a .

Para la segunda prueba, debemos asumir el compromiso del saldo actual del remitente, C_s , y verificar que el valor comprometido en C_s-C_a se encuentre en el rango [0, M) . Nuevamente, el remitente puede producir esta prueba ya que él / ella conoce la apertura a C_s y C_a .

Para aplicar la transferencia al estado blockchain, restamos el compromiso de cantidad C_a del compromiso de saldo del remitente (como hemos verificado, no puede conducir a un saldo negativo o al aumento del saldo del remitente), y luego sumamos C_a al receptor equilibrio compromiso

Detalles clave


Es importante tener en cuenta que hay algunas condiciones que pueden hacer que el servicio implementado sea m√°s complejo.

El receptor de una transferencia debe encontrar la apertura a C_a desde alg√ļn lugar; de lo contrario, deja de conocer la apertura de su equilibrio y ya no puede hacer nada con su billetera. La apertura no est√° presente en el texto sin formato de la transacci√≥n de transferencia (que es el punto completo). Podr√≠amos suponer que el receptor obtiene de manera confiable la apertura a trav√©s de un canal fuera de la cadena (por ejemplo, enviado por el remitente a trav√©s de Telegram), pero ese no es un escenario ilustrativo. Entonces, en cambio, encriptamos la apertura usando encriptaci√≥n de clave p√ļblica de dos partes basada en el intercambio de claves Diffie-Hellman (libsodium llama a este tipo de caja de encriptaci√≥n). Para el beneficio adicional, las claves Curve25519 requeridas para la rutina box se pueden convertir de las claves Ed25519, por lo que podemos continuar usando un solo par de claves para cada usuario en lugar de introducir claves de cifrado separadas.



Una vez que introducimos el cifrado, ya no podemos aplicar la transferencia atómicamente. De hecho, el remitente puede proporcionar basura de forma maliciosa o involuntaria en lugar del cifrado de apertura, y la lógica de la cadena de bloques no podrá decir que este es el caso. Por lo tanto, solicitamos al receptor que acepte explícitamente la transferencia a través de una transacción separada.



Antes de que se acepte una transferencia, modifica el compromiso de saldo del remitente (de lo contrario, permitiríamos el doble gasto), pero no el del receptor.



Una vez que la red blockchain confirma la transacción de aceptación, se actualiza el saldo del receptor y se completa la transferencia.



Para evitar puntos muertos, una transferencia especifica un retraso de bloqueo de tiempo (en la altura relativa de la cadena de bloques, como el CSV de Bitcoin) para que el receptor indique la aceptación. Si el bloqueo de tiempo ha expirado, la transferencia se reembolsará automáticamente al remitente (Exonum lo permite a través de Service :: beforeCommit () hook).

Otro problema es más complejo. Para producir la prueba de un saldo suficiente, el remitente debe conocer su saldo actual, lo que puede no ser siempre el caso. Una transacción de aceptación perdida o un reembolso pueden aumentar el saldo del remitente sin saberlo; en este caso, la transferencia fallará en la verificación y el remitente se sentirá razonablemente frustrado.

Para aliviar este problema, permitimos que las transferencias hagan referencia a lo que el remitente cree que es su estado actual de billetera (m√°s precisamente, la referencia toma la forma del n√ļmero de eventos que cambian el saldo de la cuenta: transferencias y reembolsos). Al verificar la prueba de un saldo suficiente, utilizamos el estado de referencia para obtener el compromiso de saldo del remitente. Adem√°s, verificamos que no se hayan producido transferencias salientes desde el estado de referencia. Si este es el caso, podemos estar seguros de que si restamos el monto de la transferencia del saldo actual del remitente, terminaremos con un valor no negativo. De hecho, ¬°los eventos en el historial de la cuenta despu√©s del punto de referencia (transferencias entrantes y reembolsos) solo pueden aumentar el saldo! ‚Ā∑

Con los puntos de referencia en su lugar, el remitente sigue estando algo limitado; No debe tener transferencias pendientes al crear una nueva transferencia. A√ļn as√≠, esta restricci√≥n es mucho menos limitante que el requisito de conocer el estado de la cuenta en el momento de la transferencia; fundamentalmente, hacemos que el remitente dependa de lo que hizo anteriormente, pero no de las acciones de los dem√°s.

Implementación


Utilizamos una biblioteca a prueba de balas escrita en Rust puro, que recientemente ha alcanzado la etapa de prelanzamiento . Dado que la plataforma Exonum está escrita en Rust, se integra perfectamente con la biblioteca. Como beneficio adicional, a diferencia de la versión de prueba de balas descrita en el documento técnico original (que se está desarrollando en C y utiliza la curva elíptica secp256k1 de Bitcoin), la biblioteca que utilizamos se basa en Curve25519, que ya se usa en Exonum como el componente principal del Ed25519 criptosistema de firma digital.

Implementar el servicio basado en la descripción anterior es bastante sencillo. La parte más difícil fue construir pruebas de Merkle que autentiquen la información devuelta al usuario para que no tenga que confiar ciegamente en los nodos Exonum con los que se comunica. Mejorar la experiencia de los desarrolladores de servicios a este respecto es uno de los principales objetivos de la versión Exonum 1.0 .

Próximos pasos


El servicio que hemos construido no oculta las identidades del remitente y el receptor de las transferencias, lo cual es una limitación importante para las aplicaciones del mundo real. Afortunadamente, hay formas de resolver este problema.

La t√©cnica gen√©rica utilizada en zCash (pero aplicable principalmente a otros casos de uso, como Ethereum ) se basa en la creaci√≥n de un √°rbol Merkle del estado del sistema. Por ejemplo, zCash construye el √°rbol de compromiso de notas , que es m√°s o menos equivalente a las salidas de transacciones creadas en Bitcoin. Las pruebas de conocimiento cero luego abarcan rutas de autenticaci√≥n (tambi√©n conocidas como ramas de Merkle) en este √°rbol, revelan algo sobre un elemento del √°rbol sin revelar a qu√© elemento se hace referencia. La desventaja de este enfoque es que las funciones hash criptogr√°ficas utilizadas para construir √°rboles Merkle son dif√≠ciles de transferir al √°mbito de conocimiento cero; las pruebas resultantes se vuelven computacionalmente caras: una sola prueba puede tardar segundos o incluso minutos en crearse. La b√ļsqueda de m√°s funciones hash criptogr√°ficas ‚Äúcompatibles con ZKP‚ÄĚ es el √°rea de investigaci√≥n activa.

Si admitimos restricciones adicionales, puede haber una soluci√≥n m√°s f√°cil. Por ejemplo, un art√≠culo reciente de Narula et al . describe un sistema con un n√ļmero limitado y a priori conocido de participantes, que puede realizar transacciones entre ellos sin revelar participantes o cantidades transferidas para cualquier transacci√≥n. (Piense en una red blockchain centrada en la privacidad para las transferencias interbancarias).

En una nota más prosaica, probablemente haya muchas mejoras técnicas que el servicio desarrollado puede disfrutar: más cobertura de prueba, separación de claves de firma y cifrado, evaluación comparativa, etc. Una mejora importante para el servicio UX sería permitir el ordenamiento determinista de transacciones que se originan en el mismo usuario, que planeamos resolver no mucho después de lanzar Exonum 1.0.

Conclusión


Hemos descrito cómo construir un cryptotoken basado en cuentas con una fuerte privacidad habilitada por pruebas de conocimiento cero (específicamente, a prueba de balas). La lógica del token se implementó como un servicio Exonum. Aunque actualmente el servicio es solo una prueba de concepto, muestra cómo la plataforma Exonum se puede utilizar para construir sobre primitivas criptográficas complejas con una sobrecarga muy baja impuesta por el entorno de ejecución.



  1. Existe una distinción intrincada entre pruebas y argumentos, que no abordaremos aquí. En aras de la simplicidad, nos referiremos a todas las construcciones de conocimiento cero en este artículo como pruebas de conocimiento cero, incluso si esto no siempre es correcto desde el punto de vista teórico.
  2. Esto se puede lograr a través de una técnica muy general conocida como transformación Fiat - Shamir , que convierte un protocolo de prueba interactivo en uno no interactivo, universalmente verificable. Sacrificando el rigor científico una vez más, no aclararemos explícitamente que las pruebas de conocimiento cero que utilizamos no son interactivas.
  3. Los generadores generalmente se eligen con el m√©todo "nada bajo la manga". Por ejemplo, G puede ser parte de la especificaci√≥n del grupo para su uso en criptograf√≠a de clave p√ļblica, y H se deriva de G a trav√©s de una funci√≥n hash: H ~ hash (G) .
  4. Esto √ļltimo significa que incluso un adversario con potencia inform√°tica infinita no puede deducir a qu√© se compromete el compromiso; de hecho, si DLP en el grupo se rompe, cada compromiso puede abrirse a cualquier valor posible.
  5. Esto es parcialmente una decisión de prueba de concepto; en general, reutilizar claves para diferentes propósitos es una mala idea.
  6. Es teóricamente posible proporcionar una prueba de conocimiento cero para que el valor cifrado sea equivalente al saldo comprometido; sin embargo, aumentaría prohibitivamente la complejidad del sistema.
  7. Vale la pena mencionar que algunas transferencias que rompen la regla "no hay transferencias salientes desde el estado referenciado" a√ļn pueden ser correctas; simplemente no tenemos forma de verificar esto.





Source: https://habr.com/ru/post/440274/


All Articles