En Ola, estamos totalmente de acuerdo con la afirmación de a16z en su artículo "  " acerca de web3:   Lograr la privacidad criptográfica y el cumplimiento normativo  “El desarrollo y regulación de  –una evolución de Internet impulsada por las criptomonedas– debe lograr dos objetivos que a menudo están en tensión. Objetivo 1:   . Objetivo 2: Reducir el riesgo de financiación ilícita en interés de la seguridad nacional”.   web3 Preservar la privacidad del consumidor, a pesar de la naturaleza transparente predeterminada de las cadenas de bloques  Esta visión se alinea con lo que Ola describió en el artículo "  ". Además, el énfasis en el alto rendimiento es una característica en la que Ola está trabajando arduamente para implementar.   Ola: da forma a tu propio viaje Web3  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, "  ," describe las diferencias entre estas tres soluciones.   Sin7y Tech Review (35): Paquete híbrido: la infraestructura de próxima generación - HackMD  En este artículo, nos centraremos más en explicar el diseño de Ola en términos de   . Como se describe en el artículo de a16z, la privacidad debe abarcar dos atributos simultáneamente: cumplimiento  Logre una protección de privacidad nativa para salvaguardar la información del usuario.  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 "  ", la pregunta fundamental es: "¿   "   Soluciones regulatorias que protegen la privacidad mediante pruebas de conocimiento cero: documento completo - a16z crypto 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 "  ", 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:   Sin7y Tech Review (33): Principios de transacciones privadas y cuestiones de cumplimiento normativo - HackMD    : Esto se logra mediante una firma única, como se detalla en la sección 4.1.7.1 de la  . Ocultar al iniciador de la transacción, o al remitente   protocolo zcash-retoño    : esto se divide en dos escenarios: Ocultar el destinatario de la transacción o el destinatario  ⅰ. 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  . 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  . El contenido de la transacción en sí no contiene ninguna información sobre el destinatario.   protocolo zcash-retoño   protocolo zcash-retoño  ⅱ. Ocultarse del mismo remitente se logra mediante una dirección pública única.    : el enfoque implica el uso de pruebas de conocimiento cero y esquemas secretos compartidos. Consulte las secciones 4.17 y 4.19 del  . Para ocultar información de transacciones   protocolo zcash-retoño    : 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: Para la implementación de no rastreable  ⅰ. 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:  Cada transacción permanece invisible para partes externas.  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?  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.  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.  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   Continuar ocultando el contenido de cada transacción, asegurando que la privacidad del usuario permanezca intacta.    . 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:  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.  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:   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  , las personas con una tarjeta Aadhaar pueden generar un zkDID.   Anon Aadhaar  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:    : 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. Implementación a nivel de plataforma  Este enfoque permite una protección de identidad y un control de privacidad consistentes en toda la plataforma.    : 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. Implementación a nivel de aplicación  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:    : 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. Trazabilidad    : La privacidad de cada transacción permanece intacta; La información sobre el remitente, el destinatario y otros aspectos permanece confidencial. Privacidad    : al mantener menos árboles, se reducen los gastos generales del sistema zk-proof. Eficiencia    : 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. Clave de vista actualizable    : 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: Respetuoso con el cumplimiento  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 "  " y "  "para incorporar mecanismos de lista negra y otras restricciones en las primeras etapas, refinando el diseño de todo el sistema de privacidad programable.   Lograr la privacidad de las criptomonedas y el cumplimiento normativo - a16z crypto   Privacidad de blockchain y cumplimiento normativo: hacia un equilibrio práctico   También publicado  aquí

2022 - HackerNoon Contributor of the Year - Algorithms

2022 - HackerNoon Contributor of the Year - Architecture

2022 - HackerNoon Contributor of the Year - Blockchain

2022 - HackerNoon Contributor of the Year - Optimization

2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Optimization

Nominated for 2022 - HackerNoon Contributor of the Year - Algorithms

Nominated for 2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Blockchain

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

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

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps