Privacidad programable: cómo podría ser más compatible con el cumplimiento al mundo Web3

En Ola, estamos totalmente de acuerdo con la afirmación de a16z en su artículo " Lograr la privacidad criptográfica y el cumplimiento normativo " acerca de web3:

“El desarrollo y regulación de web3 –una evolución de Internet impulsada por las criptomonedas– debe lograr dos objetivos que a menudo están en tensión. Objetivo 1: Preservar la privacidad del consumidor, a pesar de la naturaleza transparente predeterminada de las cadenas de bloques . Objetivo 2: Reducir el riesgo de financiación ilícita en interés de la seguridad nacional”.

Esta visión se alinea con lo que Ola describió en el artículo " Ola: da forma a tu propio viaje Web3 ". Además, el énfasis en el alto rendimiento es una característica en la que Ola está trabajando arduamente para implementar.

Ya sea que se trate de escenarios privados o no privados, la programabilidad es un atributo extremadamente importante. En el ámbito de la privacidad programable, además de Ola, tanto Aztec como Miden están trabajando para lograr el mismo objetivo.

El artículo de Ola, " Sin7y Tech Review (35): Paquete híbrido: la infraestructura de próxima generación - HackMD ," describe las diferencias entre estas tres soluciones.

En este artículo, nos centraremos más en explicar el diseño de Ola en términos de cumplimiento . Como se describe en el artículo de a16z, la privacidad debe abarcar dos atributos simultáneamente:

1. Logre una protección de privacidad nativa para salvaguardar la información del usuario.

   
   

2. Garantizar el cumplimiento normativo para rastrear actividades ilícitas.

El primer punto es relativamente sencillo de lograr. En cuanto al segundo, cada proyecto tiene sus propias consideraciones y compensaciones. Principalmente profundizaremos en el proceso de pensamiento y diseño de Ola con respecto al cumplimiento normativo.

Al abordar esto desde la perspectiva de resolver problemas del mundo real, examinemos primero los desafíos que enfrentan varios proyectos de privacidad en términos de cumplimiento normativo. Como se describe en el capítulo "Desanonimización selectiva involuntaria" del artículo " Soluciones regulatorias que protegen la privacidad mediante pruebas de conocimiento cero: documento completo - a16z crypto ", la pregunta fundamental es: "¿ Quién mantiene la clave privada para desbloquear la trazabilidad? "

¿Por qué necesitamos una clave privada para desbloquear la trazabilidad?

La necesidad de una clave privada para lograr la trazabilidad está relacionada con los diseños de privacidad actuales.

Dado que casi todas las soluciones de privacidad basadas actualmente en la tecnología zk (conocimiento cero) se han inspirado en Zcash, analizaremos directamente el diseño de Zcash, como se muestra a continuación:

En el artículo " Sin7y Tech Review (33): Principios de transacciones privadas y cuestiones de cumplimiento normativo - HackMD ", puede encontrar los principios de diseño detrás de las transacciones privadas. Explicaremos brevemente cómo se mantiene la privacidad bajo este diseño y cómo aborda las preocupaciones regulatorias:

1. Ocultar al iniciador de la transacción, o al remitente : Esto se logra mediante una firma única, como se detalla en la sección 4.1.7.1 de la protocolo zcash-retoño .

   
   

2. Ocultar el destinatario de la transacción o el destinatario : esto se divide en dos escenarios:

   
   

ⅰ. La ocultación de terceros se logra cifrando la información de la transacción utilizando la dirección pública del destinatario. Ver sección 4.19.1 del protocolo zcash-retoño . Luego, el receptor examina las transacciones utilizando una clave privada (conocida como clave de vista entrante) para descifrar y filtrar las transacciones que se les envían, como se describe en la sección 4.19.2 del protocolo zcash-retoño . El contenido de la transacción en sí no contiene ninguna información sobre el destinatario.

ⅱ. Ocultarse del mismo remitente se logra mediante una dirección pública única.

3. Para ocultar información de transacciones : el enfoque implica el uso de pruebas de conocimiento cero y esquemas secretos compartidos. Consulte las secciones 4.17 y 4.19 del protocolo zcash-retoño .

   
   

4. Para la implementación de no rastreable : el enfoque se basa en el diseño del árbol de compromiso (en adelante denominado "CM") y el árbol anulador (en adelante denominado "NF"). Este diseño tiene los siguientes propósitos:

   
   

ⅰ. Cada UTXO (salida de transacción no gastada) corresponde a un CM y un NF, pero no existe un vínculo directo entre los dos.

ⅱ. Tanto el árbol CM como el árbol NF son árboles de sólo anexos.

ⅲ. El árbol CM se utiliza para demostrar la validez de UTXO, mientras que el árbol NF evita el doble gasto de UTXO.

Según el diseño de privacidad anterior, los usuarios pueden beneficiarse de las siguientes funciones de protección de la privacidad:

1. Cada transacción permanece invisible para partes externas.

   
   

2. Las conexiones entre transacciones son imposibles de rastrear.

   
   

Parece un diseño impecable de protección de la privacidad para los usuarios. Sin embargo, cuando se basa en la realidad, no todos los usuarios operan con intenciones genuinas y legales. Deben existir mecanismos para revelar parte o la totalidad de los detalles de la transacción privada para lograr la trazabilidad cuando sea necesario.

Esto ayuda a los organismos reguladores a tomar medidas contra usuarios malintencionados. De lo contrario, esta forma de privacidad podría convertirse en una herramienta para que actores maliciosos perjudiquen a los usuarios comunes.

¿El diseño de privacidad antes mencionado permite a las autoridades reguladoras rastrear cómodamente las transacciones y hacer cumplir las regulaciones? La respuesta es no. Como se ilustra en el diagrama proporcionado (al que se hace referencia pero no se muestra), el diseño de privacidad actual requiere una clave de visualización para desbloquear la trazabilidad de las transacciones.

Sin embargo, esta clave de vista la posee el usuario, lo que la hace inaccesible directamente a los reguladores. Esto se relaciona con las cuestiones descritas en las secciones 13/14 tituladas "Desanonimización selectiva voluntaria" y "Desanonimización selectiva no voluntaria" del artículo " Soluciones regulatorias que protegen la privacidad mediante pruebas de conocimiento cero: documento completo: criptografía a16z. "

Profundicemos más. ¿Por qué la clave de vista es tan sensible que los usuarios dudan en proporcionársela a los reguladores?

1. En primer lugar, es fundamental aclarar que la clave de vista no es la clave privada utilizada para las firmas de transacciones; no se puede utilizar para firmar transacciones directamente y, por lo tanto, no se puede utilizar para robar activos del usuario.

   
   

2. Una vez que se expone la clave de visualización, los reguladores pueden ver todas las transacciones privadas iniciadas por un usuario en texto sin formato. Los usuarios deben confiar en que los reguladores: (1) la clave de visualización no se filtrará; y (2) los detalles de la transacción no serán revelados.

   
   

3. Los usuarios con propósitos viciosos, por supuesto, no estarán dispuestos a proporcionar su clave de visión, lo que dejará a los reguladores impotentes.

   
   

Según el análisis anterior, la solución de privacidad ideal debería :

1. Continuar ocultando el contenido de cada transacción, asegurando que la privacidad del usuario permanezca intacta.

   
   

2. Lograr una trazabilidad sin permiso entre transacciones, lo que significa que la trazabilidad se puede realizar sin el suministro obligatorio de información adicional .

Esta es la visión que Ola se esfuerza por lograr: ¡privacidad programable que incorpora trazabilidad de forma nativa!

¿Cómo introduce Ola la trazabilidad nativa en la privacidad programable?

Para abordar los desafíos regulatorios que enfrentan las soluciones de privacidad mencionadas anteriormente, Ola se ha atrevido a intentarlo y ha esbozado un diseño específico. Los puntos tecnológicos centrales se pueden resumir en:

1. Ya no se introduce el árbol anulador para lograr la imposibilidad de rastrear las transacciones. En el diseño de Ola, las transacciones son rastreables, pero esto se hace mediante cifrado sin comprometer los atributos de privacidad de las transacciones mismas.

   
   

2. El árbol de compromiso restante pasa del modo original de solo agregar a uno actualizable mediante la introducción de declaraciones de prueba adicionales para evitar ataques de doble gasto en el mismo compromiso. Esto se ilustra en la Figura 2:

   
   

3. Incorporar un mecanismo de clave de vista actualizable. Esto significa que cuando se expone una clave de vista, los usuarios pueden actualizar la clave de vista para garantizar que las transacciones privadas posteriores creadas después de la actualización de la clave no se puedan descifrar. Como se ilustra en la Figura 3:

   
   

zkDID/zkKYC equilibra eficazmente la privacidad y la regulación

Los identificadores descentralizados de conocimiento cero (zkDID) desempeñan un papel crucial en las plataformas de privacidad. Tienen la capacidad de transformar la identidad legal de un usuario (ID legal) en un zkDID. Por ejemplo, en el proyecto PSE Anon Aadhaar , las personas con una tarjeta Aadhaar pueden generar un zkDID.

Para otros, un zkDID es anónimo y no revela la información de identidad real del usuario. Esta doble característica proporciona una poderosa herramienta para la protección de la privacidad.

En cuanto a los niveles de implementación de zkDID, puede ocurrir en varios niveles, dependiendo del diseño y requisitos de la plataforma:

1. Implementación a nivel de plataforma : si una plataforma necesita administrar y verificar la identidad de todos los usuarios para garantizar la seguridad y el cumplimiento, implementar zkDID a nivel de plataforma podría ser la opción más adecuada. De esta manera, la plataforma puede integrar directamente zkDID como parte de su sistema de gestión de identidad, permitiendo la verificación y autorización de la identidad del usuario.

   
   

   Este enfoque permite una protección de identidad y un control de privacidad consistentes en toda la plataforma.

   
   

2. Implementación a nivel de aplicación : si una plataforma prioriza el control y la flexibilidad del usuario, entonces podría ser preferible implementar zkDID en una aplicación de capa superior en la plataforma. Este método permite a los usuarios elegir si desean utilizar zkDID y administrar su identidad según sea necesario.

   
   

   Los usuarios pueden decidir cuándo utilizar zkDID para equilibrar la privacidad y la comodidad. Este enfoque puede ser más adecuado para usuarios que desean tener un control más activo sobre su identidad. (no nativo).

Dado el diseño anterior, la solución de privacidad de Ola cuenta con las siguientes ventajas:

1. Trazabilidad : basándose en la información del CM dentro de una transacción, cualquier tercero puede rastrear la ruta del flujo del CM, como se ilustra en la Figura 2.

   
   

2. Privacidad : La privacidad de cada transacción permanece intacta; La información sobre el remitente, el destinatario y otros aspectos permanece confidencial.

   
   

3. Eficiencia : al mantener menos árboles, se reducen los gastos generales del sistema zk-proof.

   
   

4. Clave de vista actualizable : admite actualizaciones de la clave de vista, lo que garantiza que la privacidad de las transacciones no se vea comprometida si la clave de vista queda expuesta.

   
   

5. Respetuoso con el cumplimiento : sin la necesidad de información no exigible, los reguladores pueden rastrear el linaje del objetivo, por ejemplo, dentro de qué colecciones de CM. Si bien es posible que los reguladores carezcan temporalmente de conocimiento sobre los propietarios de estos CM, tienen dos opciones:

   
   

6. a. Espere a que el CM se consuma y se transfiera a una dirección pública, lo cual es factible ya que, en el diseño de Ola, todos los estados privados deben realizar la transición a estados públicos antes de salir del ecosistema.

   
   b. Obtenga información clave para el descifrado, un método tradicional utilizado para la trazabilidad en soluciones de protección de la privacidad, como se ve en sistemas como Zcash, Aleo, Aztec, Miden y otros.

Más allá de estas ventajas técnicas, Ola aún puede integrarse con artículos como " Lograr la privacidad de las criptomonedas y el cumplimiento normativo - a16z crypto " y " Privacidad de blockchain y cumplimiento normativo: hacia un equilibrio práctico "para incorporar mecanismos de lista negra y otras restricciones en las primeras etapas, refinando el diseño de todo el sistema de privacidad programable.

También publicado aquí