V El último artículo de Dios: ¿Cómo protege el protocolo del grupo de privacidad la privacidad del usuario y cumple con los requisitos de cumplimiento?
原文：《Privacidad de Blockchain y cumplimiento normativo: hacia un equilibrio práctico》
De: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar y Ameen Soleimani
Compilado por: Odaily Planet Daily Husband How
Hoy, Buterin y otros escribieron conjuntamente un artículo de investigación sobre protocolos de privacidad, titulado "Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium".
El documento describe un nuevo protocolo de mejora de la privacidad basado en contratos inteligentes: grupo de privacidad, analiza sus ventajas y desventajas y muestra cómo equilibra a los usuarios honestos y los usuarios deshonestos. El protocolo está diseñado para utilizar pruebas de conocimiento cero para verificar la legitimidad de los fondos de los usuarios sin revelar su historial completo de transacciones, equilibrando los requisitos regulatorios y de privacidad al tiempo que filtra los fondos asociados con actividades delictivas.
Odaily Planet Daily ahora recopila la esencia del artículo de la siguiente manera.
I. Introducción
Las cadenas de bloques públicas son transparentes por diseño. La idea básica es que cualquiera puede elegir verificar las transacciones sin tener que depender de un tercero centralizado; al reducir las dependencias, proporciona una base neutral para una variedad de aplicaciones, incluidas, entre otras, las finanzas y la identidad soberana.
Sin embargo, desde el punto de vista de la privacidad, los conjuntos de datos públicos poseen cada transacción que contiene cada dirección de blockchain. Cada vez que alguien transfiere un activo a otra dirección o interactúa con un contrato inteligente, esa transacción siempre será visible en la cadena de bloques. Es evidente que esto no se ajusta a los requisitos de privacidad.
Ejemplo: Alice paga la cena en un restaurante con una billetera blockchain. El beneficiario ahora conoce la dirección de Alice y puede analizar toda la actividad pasada y futura en esa dirección. Del mismo modo, Alice ahora conoce la dirección de la billetera del restaurante y puede usar esta información para obtener las direcciones de la billetera de otros huéspedes o para verificar las ganancias del restaurante. O un tercero (como las redes sociales) que conoce el restaurante y la dirección de la billetera de Alice puede deducir fácilmente la dirección residencial real de Alice y estudiar sus transacciones pasadas y futuras.
**El auge de los protocolos de mejora de la privacidad tiene como objetivo resolver los problemas anteriores. Permite a los usuarios depositar fondos en el protocolo, utilizando una dirección, y retirar fondos del protocolo en un momento posterior, utilizando otra dirección. Todos los depósitos y retiros siguen siendo visibles en la cadena de bloques, pero la correspondencia entre transferencias específicas y transferencias ya no es pública. **
Uno de los protocolos de mejora de la privacidad más conocidos es Tornado Cash. Resuelve con éxito los problemas anteriores y permite a los usuarios conservar cierta privacidad. Sin embargo, además de los usuarios legítimos que intentan proteger sus datos, Tornado Cash también es utilizado por una variedad de malos actores. Los datos de depósito muestran que el grupo de piratas informáticos movió fondos a través de este protocolo. La evidencia sugiere que el grupo de piratería norcoreano también utilizó este protocolo de mejora de la privacidad, lo que culminó con la inclusión de las direcciones de contratos inteligentes del protocolo en la Lista de Nacionales Especialmente Designados y Personas Bloqueadas (comúnmente conocida como Lista SDN) mantenida por la Oficina de Activos Extranjeros de EE. UU. Control (OFAC). ).
**El problema clave con Tornado Cash es la línea borrosa entre usuarios legítimos y usuarios criminales. **Por lo tanto, Tornado Cash ofrece una función de cumplimiento que permite a los usuarios crear una prueba de de qué depósito provino un retiro determinado. Si bien este mecanismo permite a las personas demostrar su inocencia, lo hace a costa de tener que confiar en un intermediario centralizado y crear asimetrías de información. Al final, el mecanismo apenas fue utilizado por los usuarios.
Este artículo analiza una extensión de este enfoque que permite a los usuarios dar fe públicamente de información sobre de qué depósitos pueden provenir sus retiros, pero sin perder la privacidad. **Los pools de privacidad tienen un concepto general: permitir pruebas de membresía ("Certifico que mis retiros provienen de uno de estos depósitos") o pruebas de exclusión ("Certifico que mis retiros no provienen de ninguno de estos depósitos" ). **Este artículo analiza esta propuesta y explica cómo se puede utilizar para lograr un equilibrio entre usuarios honestos y deshonestos.
Tenga en cuenta que los grupos de privacidad brindan opciones adicionales al ampliar el conjunto de acciones del usuario. Aún pueden proporcionar pruebas más detalladas a una contraparte específica si es necesario. En algunos casos, sin embargo, puede ser suficiente una prueba de afiliación o exclusión. Además, la opción de hacer públicas estas pruebas tiene una serie de ventajas sobre la divulgación bilateral.
2. Antecedentes técnicos
En esta sección, proporcionamos una breve descripción técnica y analizamos la construcción técnica y los principios generales de protocolos como los grupos de privacidad.
1. Privacidad de blockchain antes de ZK-SNARK
Históricamente, los defensores de blockchain han argumentado que, si bien todas las transacciones son transparentes, las blockchains pueden preservar la privacidad porque brindan anonimato.
Con la llegada de las modernas herramientas de análisis y agrupación, esta protección de la privacidad se ha vuelto insuficiente. Para mejorar la privacidad de las cadenas de bloques públicas, se han introducido técnicas más sólidas, como uniones de tokens y Monero. Sin embargo, estas tecnologías aún conllevan el riesgo de fuga de datos. **
A esto le siguieron tecnologías de uso general a prueba de conocimiento cero, como Zcash y Tornado Cash, que pueden hacer que el conjunto de anonimato de cada transacción sea igual al conjunto completo de todas las transacciones anteriores. Esta técnica a menudo se denomina ZK-SNARK.
2、 ZK-SNARK
ZK-SNARKs es una técnica que permite a un demostrador demostrar una determinada afirmación matemática sobre datos públicos y privados, **al mismo tiempo que satisface dos propiedades clave: conocimiento cero y simplicidad. **
● Conocimiento-Cero: No revela ninguna información sobre los datos privados más que demostrar que dichos datos privados se ajustan a la declaración.
● **Simplicidad: **Las pruebas son breves y se pueden verificar rápidamente, incluso si las afirmaciones comprobadas requieren cálculos que requieren mucho tiempo.
Los ZK-SNARK han recibido una amplia atención por parte de la comunidad blockchain debido a su importancia en la escalabilidad, como los ZK-rollups. Para las aplicaciones de privacidad, la simplicidad no es particularmente importante, pero el conocimiento cero es esencial.
La "declaración" probada por ZK-SNARKs puede verse como un tipo de programa llamado "circuito", que calcula el resultado de una función f(x, w) con entradas públicas y privadas, y luego demuestra que para un público determinado ingrese x, hay una entrada privada w tal que el resultado de f(x, w) es Verdadero.
3. Aplicación de ZK-SNARK en sistemas como Zcash y Tornado Cash
Existen algunas diferencias menores entre las diferentes versiones de Zcash y los sistemas inspirados en él (como Tornado Cash). Sin embargo, la lógica básica en la que se basan es muy similar. Esta sección describe una versión simple que corresponde aproximadamente a cómo funcionan estos protocolos.
Los tokens consisten en secretos mantenidos por sus propietarios. Se pueden derivar dos valores de s:
● ID de token público L = hash(s + 1)
● anuladorU = hash(s + 2)
Entre ellos, hash se refiere a la función hash de contraseña, como SHA 256. Dado s, se pueden calcular el ID del token y el ceroizador. Sin embargo, dado un conjunto de anuladores y un ID de token público, el comportamiento pseudoaleatorio de la función hash garantiza que no pueda estar seguro de qué anulador está asociado con qué ID de token a menos que conozca los secretos que generaron ambos.
La cadena de bloques realiza un seguimiento de todos los ID de tokens que se han "creado" y de todos los anuladores que se han "gastado". Ambos conjuntos están en constante crecimiento (a menos que el protocolo quiera imponer cuándo se deben gastar los tokens).
Una colección de ID de token se almacena en una estructura de datos llamada árbol Merkle: si el árbol contiene N elementos, entonces cada elemento adyacente se procesa mediante hashes (lo que da como resultado ⌈ N/2 ⌉ hashes), y cada uno de estos hashes adyacentes se aplica hash nuevamente (lo que resulta en en ⌈ N/4 ⌉ hash), y así sucesivamente, hasta que todos los datos se confirmen en un único "hash raíz".
Dado un valor particular en un árbol y un hash de raíz, se puede proporcionar una rama de Merkle: un "valor hermano" que se une en cada paso del camino desde ese valor hasta la raíz. Esta rama de Merkle es útil porque es un pequeño dato (log 2(N) hashes) que se puede usar para demostrar que cualquier valor en particular está realmente en el árbol. La siguiente figura muestra un ejemplo de un árbol Merkle con una altura de 4.
Cuando los usuarios envían monedas a otras personas, proporcionan lo siguiente:
● El zerizer U que quieres gastar
● ID de token L' del nuevo token que se desea crear (se solicita al destinatario que lo proporcione)
● UN ZK-SNARK.
ZK-SNARK contiene las siguientes entradas privadas:
● Secretos de usuario
● Rama de Merkle en el árbol de ID del token, lo que demuestra que el token con ID de token L = hash(s + 1) en realidad se creó en algún momento en el pasado.
También contiene las siguientes aportaciones públicas:
● U, el valor cero del token que se está gastando.
● R, el hash raíz al que apunta la prueba de Merkle
ZK-SNARK demuestra dos propiedades:
● U = hash(s + 2)
● Las sucursales de Merkle son válidas.
Además de los ZK-SNARK, el protocolo también verifica lo siguiente:
● R es el hash raíz actual o histórico del árbol de ID del token.
● U no está en el conjunto de anuladores gastados.
Si la transacción es válida, agrega U al conjunto de nilificadores gastados y L' a la lista de ID de token. Mostrar U evita que una sola ficha se gaste dos veces. Sin embargo, no se revelará ninguna otra información. **El mundo exterior solo puede ver cuándo se envían las transacciones; no pueden obtener un patrón sobre quién envía o recibe estas transacciones y no pueden distinguir la fuente unificada de los tokens. **
Hay dos excepciones al modelo anterior: depósitos y retiros. En los depósitos, se pueden crear ID de token sin invalidar un determinado token anterior. Desde una perspectiva de preservación de la privacidad, los depósitos no son anónimos debido a que la asociación entre un L determinado y un evento externo que permite agregar L (en Tornado Cash, depositar ETH en el sistema; en Zcash, nueva minería ZEC) es pública.
En otras palabras, **los depósitos están vinculados a su historial de transacciones pasadas. **En los retiros, se consumirá un Zeroizer sin agregar una nueva ID de token. Esto puede desconectar los retiros de los depósitos correspondientes e indirectamente del historial de transacciones pasadas. Sin embargo, los retiros pueden vincularse a cualquier transacción futura que ocurra después del evento de retiro.
La primera versión de Tornado Cash no tenía concepto de transferencias internas, solo permitía depósitos y retiros. Las versiones posteriores, aún en etapa experimental, también permitieron transferencias internas y monedas de varias denominaciones, incluido el soporte para operaciones de "división" y "fusión". Discutiremos cómo extender el sistema básico de transferencia de monedas de privacidad y el fondo de privacidad a denominaciones arbitrarias en capítulos posteriores.
4. ZK-SNARK en grupo de privacidad
** La idea central del grupo de privacidad es que los usuarios no solo demuestren que el retiro está asociado con un depósito anterior mediante prueba de conocimiento cero, sino que también demuestren que pertenece a un conjunto de asociaciones más estricto. **La colección asociada puede ser un subconjunto de todos los depósitos realizados previamente, una colección que contenga solo los depósitos del usuario o cualquier cosa intermedia. Los usuarios especifican el conjunto proporcionando la raíz Merkle del conjunto asociado como entrada pública.
Como se muestra en la siguiente figura, en aras de la simplicidad, no probamos directamente que el conjunto asociado sea de hecho un subconjunto de los depósitos realizados anteriormente; en cambio, solo requerimos que el usuario use la misma ID de moneda que el nodo hoja para Demuestre las dos ramas de Merkle mediante conocimiento cero:
● Ingrese la rama Merkle de la raíz R del conjunto total de ID de monedas
● Ingrese la rama Merkle del conjunto de asociaciones raíz RA
La intención de esto es colocar el conjunto completo de asociaciones en algún lugar (podría ser en cadena). El concepto central es: en lugar de exigir a los usuarios que especifiquen exactamente de qué depósito provienen sus retiros o, en el otro extremo, no proporcionar ninguna otra información que no sea demostrar que no hubo gastos dobles, permitimos a los usuarios proporcionar un conjunto de opciones a partir de las cuales Los fondos pueden haber llegado, y esta colección puede ser tan amplia o reducida como deseen.
Fomentamos un ecosistema que facilite a los usuarios especificar un conjunto de asociaciones coherentes con sus preferencias. El resto de este artículo solo describirá la infraestructura basada en este mecanismo central simple y sus consecuencias.
3. Consideraciones prácticas y casos de uso
Desde el aspecto de la aplicación, analice cómo se utilizan en la práctica los protocolos de mejora de la privacidad.
1. Casos de uso para colecciones asociativas
Para ilustrar el valor de este programa en un entorno de aplicación de la ley, he aquí un ejemplo:
Supongamos que tenemos cinco usuarios: Alice, Bob, Carl, David, Eve. Los primeros cuatro usuarios son usuarios honestos, respetuosos de la ley pero conscientes de la privacidad, mientras que Eve es una ladrona. Porque el público sabe que Eve es una ladrona gracias a la información de que las monedas de la dirección marcada "Eve" fueron robadas. En la práctica, esto sucede con bastante frecuencia: en las cadenas de bloques públicas, los fondos generados por vulnerabilidades explotadas en los protocolos DeFi se rastrean para identificar fondos ilícitos que fluyen hacia Tornado Cash.
Cuando cada uno de los cinco usuarios realiza un retiro, puede elegir qué conjunto asociado especificar. Su conjunto de asociaciones debe incluir sus propios depósitos, pero son libres de elegir cuál de las otras direcciones incluir. Los cuatro primeros usuarios estaban motivados, por un lado, por querer proteger al máximo su privacidad. Esto los motiva a tender a ampliar su conjunto de asociaciones. Por otro lado, quieren reducir la posibilidad de que los comerciantes o las casas de cambio consideren sospechosas sus monedas. Hay una manera fácil de hacer esto: no incluyen a Eve en su colección asociada. Por lo tanto, para los cuatro, la elección es clara: que su conjunto de asociaciones sea {Alice, Bob, Carl, David}.
Por supuesto, Eve también quiere maximizar su conjunto asociativo. Pero no puede excluir sus propios depósitos, por lo que se ve obligada a que su conjunto asociativo sea igual al conjunto de los cinco depósitos. La selección de colección asociada de participantes se muestra en la siguiente figura.
Aunque la propia Eva no proporcionó ninguna información, mediante un simple proceso de eliminación, podemos sacar una inferencia clara: la retirada del quinto paso sólo puede provenir de Eva.
2. Construcción de colecciones asociadas
La sección anterior ilustra una posible forma de utilizar colecciones asociadas en un protocolo similar a un grupo de privacidad y cómo se pueden separar los participantes honestos de los malos. Tenga en cuenta que el sistema no se basa en el altruismo de Alice, Bob, Carl y David; tienen incentivos claros para justificar su separación. Veamos ahora con más detalle la construcción de colecciones asociadas. Normalmente, existen dos estrategias principales para generar colecciones de asociaciones. Se describen a continuación y se visualizan en la imagen a continuación.
● **Inclusión (o membresía): **Identifique un conjunto específico de depósitos para los cuales tengamos evidencia concluyente de que son de bajo riesgo y cree un conjunto asociado que contenga solo estos depósitos.
● Exclusión: Identificar un conjunto específico de depósitos para los cuales tenemos evidencia concluyente de que son de alto riesgo y construir un conjunto asociado que incluya todos los depósitos excepto estos depósitos.
En la práctica, los usuarios no seleccionan manualmente los depósitos para incluirlos en su colección asociada. En cambio, los usuarios se suscribirán a intermediarios que llamamos proveedores de colecciones de asociaciones (ASP), que generan colecciones de asociaciones con propiedades específicas. **En algunos casos, las ASP se pueden construir completamente en cadena sin intervención humana (o IA). En otros casos, las ASP generarán colecciones de asociaciones de forma independiente y las publicarán en la cadena o en otro lugar.
Recomendamos encarecidamente publicar al menos la raíz Merkle de la colección de asociaciones en la cadena; esto elimina la capacidad de las ASP maliciosas de realizar ciertos tipos de ataques a los usuarios (por ejemplo, dar a diferentes usuarios diferentes colecciones de asociaciones en un intento de anonimizarlos). . Toda la colección debería estar disponible a través de una API o, idealmente, a través de un sistema de almacenamiento descentralizado de bajo costo como IPFS.
La posibilidad de descargar todo el conjunto asociado es importante porque permite a los usuarios generar pruebas de membresía localmente sin revelar ninguna información adicional al ASP, ni siquiera los depósitos correspondientes a sus retiros.
Así es como se podrían estructurar los ASP en la práctica:
● Adición retrasada, excluidos los malos actores: Cualquier depósito se agrega automáticamente a la colección asociada después de un tiempo fijo (por ejemplo, 7 días), pero si el sistema detecta un depósito vinculado a un mal comportamiento conocido (por ejemplo, robo a gran escala o una dirección en una lista de sanciones publicada por el gobierno), el depósito nunca se agregará. En la práctica, esto podría lograrse a través de colecciones seleccionadas por la comunidad o proveedores de servicios de detección de transacciones existentes que ya realicen trabajos de identificación y seguimiento de depósitos asociados con mal comportamiento.
● Cargo mensual por persona: Para unirse a un conjunto asociado, el valor del depósito debe estar por debajo de un máximo fijo y el depositante debe demostrar sin conocimiento que posee algún token de identidad (por ejemplo, de una entidad respaldada por el gobierno). sistemas de identificación nacionales o mecanismos livianos como la verificación de cuentas de redes sociales). Mezclado con un parámetro adicional que indica el mecanismo de descarte para el mes actual para garantizar que cada identidad solo pueda comprometer depósitos en la colección asociada una vez al mes. El diseño intenta implementar el espíritu de muchas reglas comunes contra el lavado de dinero, según las cuales los pequeños pagos por debajo de un cierto umbral permiten un mayor nivel de privacidad. Tenga en cuenta que esto se puede implementar completamente como un contrato inteligente, que no requiere supervisión manual para mantener la operación continua.
● Tarifa mensual para miembros de la comunidad de confianza: Similar a la tarifa mensual para una sola persona, pero más restrictiva: los usuarios deben demostrar que son miembros de una comunidad altamente confiable. Los miembros de la comunidad que confían mucho acuerdan brindarse privacidad entre sí.
● **Puntuación en tiempo real basada en IA: **El sistema AI ASP puede proporcionar una puntuación de riesgo para cada depósito en tiempo real, y el sistema generará un conjunto asociado que contiene depósitos con una puntuación de riesgo por debajo de un cierto umbral. Potencialmente, ASP podría generar múltiples conjuntos correspondientes a múltiples umbrales de puntuación de riesgo.
4. Descripción técnica adicional
En esta sección, analizamos cómo la propuesta admite denominaciones arbitrarias y discutimos casos especiales como la recertificación, las pruebas directas bilaterales y las pruebas secuenciales.
1. Apoye cualquier denominación
El sistema de monedas simplificado de protección de la privacidad anterior solo admite transferencias de monedas de la misma denominación. Zcash admite denominaciones arbitrarias mediante el uso del modelo UTXO. Cada transacción puede tener múltiples entradas (es necesario publicar el ajuste a cero de cada entrada) y múltiples salidas (es necesario publicar el ID del token de cada salida). Cada ID de token creado debe ir acompañado de un valor de denominación criptográfica. Además de demostrar la validez del ceroizador, cada transacción debe ir acompañada de una prueba adicional de que la suma de las denominaciones de las monedas creadas no excede la suma de las denominaciones de las monedas gastadas. La siguiente figura ilustra esta prueba adicional.
Este diseño puede ampliarse para admitir depósitos y retiros tratando los depósitos como entradas (no cifradas) y los retiros como salidas (no cifradas). Además, el diseño puede restringirse para simplificar el análisis. Por ejemplo, solo se podrían permitir retiros parciales, de modo que la transacción tenga una entrada cifrada y dos salidas: una salida no cifrada que representa el retiro y una salida de "cambio" cifrada que representa los fondos restantes, que pueden usarse para futuros retiros.
Una pregunta natural es cómo ampliar este diseño para admitir grupos de privacidad. Insertarlo sin cambios en un grupo de privacidad no es ideal porque el gráfico de transacciones no coincide con lo que intuitivamente esperamos: si un usuario deposita 10 tokens y luego gasta 1+2+3+4 en cuatro retiros consecutivos de tokens, queremos tratar cada uno de ellos. estos cuatro retiros como fuente del depósito original de 10 tokens. Pero el resultado real se muestra en la siguiente figura: la fuente del primer retiro es el depósito de 10 tokens, y luego la fuente del segundo retiro es el cambio de salida de 9 tokens creado por el primer retiro, y así sucesivamente. Esto causa problemas en la práctica porque requiere que ASP valide el depósito intermedio y lo agregue a su colección asociada.
Para que los cuatro retiros en este ejemplo puedan tener como fuente el depósito original de 10 monedas, debemos resolver dos problemas:
● Asegúrese de que cada retiro parcial no esté vinculado públicamente a otros retiros
● Permitir que cada retiro parcial tenga el depósito como miembro de su conjunto asociado
Si solo admitimos retiros parciales, en lugar de transacciones MIMO más complejas, y nos aseguramos de que cada retiro tenga un "depósito original" único y correspondiente definido, existen múltiples formas de lograrlo directamente. Un enfoque natural y escalable es propagar la promesa de cierta información a través de transacciones. Por ejemplo, podemos exigir que la transacción contenga un hash de compromiso (coinID+hash®), agregar algún valor aleatorio r para garantizar el cegamiento y exigir que ZK-SNARK demuestre que el compromiso en la transacción es el mismo que el de su transacción principal. Si la transacción principal en sí es un retiro, el compromiso es el mismo que el ID de moneda del depósito original, y si la transacción principal es un depósito, el compromiso es el mismo que el ID de moneda del depósito original. Por lo tanto, cada transacción en la cadena debe contener un compromiso con el ID de la moneda de depósito original y debe demostrar que este valor está en el conjunto asociado proporcionado por la transacción.
Para mejorar la privacidad contra ataques de agregación de saldo, también podemos admitir la fusión de monedas. Por ejemplo, si me quedan algunas monedas, puedo fusionarlas con mi próximo depósito. Para dar cabida a esto, podemos exigir que las transacciones se comprometan con un conjunto de ID de monedas y exigir que las transacciones con múltiples entradas se comprometan con la unión de sus transacciones principales. Un retiro contendrá prueba de que todas sus ID de monedas comprometidas están en su conjunto asociado.
2. Circunstancias especiales
● Recertificación: Los usuarios necesitan información de depósito secreta para retirar depósitos de manera similar a los protocolos de grupo de privacidad. La misma información secreta también se utiliza para construir pruebas de pertenencia a conjuntos de asociaciones. Preservar información secreta permite a los usuarios generar nuevas pruebas que se ajusten a diferentes conjuntos o conjuntos asociados actualizados. Esto ofrece a los usuarios una mayor flexibilidad, pero también puede introducir riesgos adicionales.
● Prueba directa bilateral: En algunos casos, es posible que se solicite a los usuarios que revelen la fuente exacta de los retiros a la otra parte. Los usuarios pueden crear una colección asociada que contenga solo sus propios depósitos y generar pruebas de esa colección. Estas pruebas suelen ser la excepción y sólo contribuyen a una privacidad parcial cuando se comparten entre dos partes. Sin embargo, las pruebas compartidas deben establecer supuestos de confianza sólidos.
● Prueba de secuencia: En una economía de transacciones rápidas que utiliza un sistema como un grupo de privacidad, es necesario modificar el protocolo para adaptarse a este entorno. Además de los tipos de transacciones de depósito y retiro, el protocolo también debe admitir operaciones de envío internas para aumentar la eficiencia. Además, al pasar las sucursales y claves de Merkle, los usuarios pueden propagar información relacionada con el historial de transacciones para que los destinatarios puedan verificar el origen de los fondos. Esto garantiza que cada usuario tenga la información mínima que necesita para tener confianza en los fondos que recibe.
En la práctica, una moneda puede tener múltiples "orígenes". Por ejemplo, Bob es dueño de un puesto de café, recibe 5 fichas de Alice, 4 fichas de Ashley, 7 fichas de Anne y al final del día necesita pagarle a Carl 15 fichas para pagar la cena. En cambio, es posible que David haya recibido 15 fichas de Carl, 25 fichas de Chris y quiera depositar 30 fichas a Emma (un intercambio). En estos casos más complejos, seguimos el mismo principio: el historial que se agregó a la colección asociada hace suficiente tiempo puede ignorarse, mientras que el historial más reciente debe transmitirse.
5. Más detalles
Un sistema como un grupo de privacidad podría permitir a los usuarios obtener más protección en la privacidad de sus datos de transacciones financieras y al mismo tiempo mantener la capacidad de demostrar la separación de actividades ilegales conocidas. Esperamos que los usuarios honestos se vean incentivados a participar en dichos esquemas mediante una combinación de dos factores:
● Deseo de privacidad
● Deseo de evitar despertar sospechas
1. Consenso social y recaudación asociativa
Si hubiera un consenso total sobre si los fondos eran buenos o malos, el sistema produciría un equilibrio de separación simple. Todos los usuarios con activos "buenos" tienen un fuerte incentivo y la capacidad de demostrar que pertenecen a un conjunto de asociaciones "solo buenos". Los malos actores, por el contrario, no podrán aportar esta prueba. Todavía pueden depositar fondos "malos" en el fondo común, pero eso no les servirá de nada. Todos pueden determinar fácilmente que los fondos se retiraron de un protocolo de privacidad mejorada y ver que el retiro hace referencia a una colección asociada que contiene depósitos de fuentes cuestionables. Es más, el dinero "malo" no contamina el dinero "bueno". Cuando se retiran fondos de depósitos legítimos, sus propietarios pueden simplemente excluir todos los depósitos "malos" conocidos de su colección asociada.
Cuando existe un consenso global y las conclusiones sobre si los fondos se consideran "buenos" o "malos" dependen de las opiniones o jurisdicciones de la sociedad, los conjuntos de asociaciones pueden variar ampliamente. Supongamos que hay dos jurisdicciones con diferentes conjuntos de reglas. Las entidades en ambas jurisdicciones A y B pueden utilizar el mismo acuerdo de mejora de la privacidad y optar por emitir certificaciones que cumplan con los requisitos de sus respectivas jurisdicciones. Ambos pueden lograr fácilmente privacidad dentro de sus propias colecciones asociadas y excluir retiros que no cumplan con los requisitos de sus respectivas jurisdicciones. Si se desea, se puede emitir un comprobante de membresía por la intersección de dos conjuntos asociados, acreditando así fehacientemente que el depósito correspondiente a su retiro cumple con los requisitos de ambas jurisdicciones.
Por tanto, la propuesta es muy flexible y debe considerarse una infraestructura neutral. Por un lado, lucha contra la censura. Permite que cualquiera se una a una colección asociada de su elección y mantenga la privacidad dentro de su propia comunidad. Por otro lado, los externos pueden exigir pruebas contra un conjunto particular de asociaciones que cumplan con sus requisitos regulatorios. Por lo tanto, incluso si existe una comunidad de malos actores en el protocolo de mejora de la privacidad, no podrán ocultar el origen sospechoso de los depósitos siempre que la información se refleje con precisión en la construcción del conjunto asociado.
2. Propiedades de las colecciones asociadas
Las colecciones asociativas necesitan tener ciertas propiedades para funcionar. Los cobros deben ser precisos para que los usuarios puedan confiar en que están utilizando los fondos retirados de forma segura. Además, las propiedades de cada conjunto deberían ser estables, es decir, menos propensas a cambiar con el tiempo. Esto reduce la necesidad de retiros de revalidación en nuevas colecciones. Finalmente, para lograr una protección de privacidad significativa, el conjunto de asociaciones debe ser lo suficientemente grande y contener varios tipos de depósitos. Sin embargo, estas propiedades entran en conflicto entre sí. En general, las colecciones grandes y diversas pueden tener mejores propiedades de privacidad, pero pueden ser menos precisas y estables, mientras que las colecciones más pequeñas son más fáciles de mantener pero brindan menos privacidad.
3. Consideraciones prácticas y competencia.
Las entidades reguladas que aceptan criptoactivos deben asegurarse de que las leyes y regulaciones a las que están sujetas permitan la aceptación de dichos fondos. Hoy en día, muchas de estas entidades dependen de las llamadas herramientas de detección de transacciones: software o servicios que analizan la cadena de bloques para identificar actividades potencialmente sospechosas, enlaces a direcciones ilegítimas u otras transacciones que no cumplen con las normas. Las herramientas de detección suelen expresar el riesgo asociado con cada transacción a través de una puntuación de riesgo. Esta puntuación se basa en el destino de los fondos transferidos y su historial de transacciones. En este sentido, los protocolos de mejora de la privacidad pueden plantear desafíos. Eliminan el vínculo visible entre depósitos y retiros. Por lo tanto, en presencia de protocolos que mejoran la privacidad, la puntuación de riesgos debe tener en cuenta las pruebas y asignar puntuaciones basadas en conjuntos asociados.
Las herramientas y servicios para la detección de transacciones son proporcionados principalmente por empresas profesionales con experiencia en análisis de blockchain y campos legales relacionados. Idealmente, estas empresas (y cualquier otra persona) tendrían acceso a todos los certificados de membresía y sus correspondientes colecciones asociadas para proporcionar puntuaciones de riesgo precisas para todas las transacciones. Por lo tanto, recomendamos que todas las pruebas se almacenen en blockchain u otro repositorio de pruebas de acceso público. La única excepción es un certificado de membresía de tamaño uno compartido con una contraparte específica. Por razones obvias, estos testimonios no deben hacerse públicos.
El almacenamiento de pruebas directamente en la cadena agrega costos de transacción adicionales, pero reduce los esfuerzos de coordinación, hace que la competencia sea más justa y mitiga los riesgos de cuasi monopolio que los proveedores de herramientas de detección pueden crear debido al conocimiento de pruebas no públicas.
La configuración general de un grupo de privacidad es muy flexible. El protocolo se puede personalizar para diversos casos de uso mediante la creación de colecciones específicas de asociaciones. A continuación se muestran dos ejemplos de estas colecciones especiales de asociaciones:
● **Una federación de banca comercial puede crear un conjunto asociado que contenga únicamente depósitos de sus clientes. **Esto garantiza que la prueba de cualquier retiro creado para el cobro haya pasado por los procedimientos Conozca a su cliente (KYC) y Antilavado de dinero (AML) en uno de los bancos participantes, pero no revela qué retiro pertenece a qué cliente.
● **En los casos en los que se exige a los intermediarios financieros que documenten claramente el origen de los fondos, pueden exigir a los usuarios que proporcionen pruebas contra un conjunto asociado que solo contenga los depósitos de los usuarios. **Esta prueba luego se intercambiará bilateralmente con el intermediario, permitiéndole rastrear los fondos como si el usuario nunca hubiera usado el fondo de privacidad. Si bien esto requiere que los usuarios confíen en que el intermediario no revelará pruebas, lo ideal es que les permita cumplir con las regulaciones sin tener que revelar la información al público.
4. Opciones y alternativas de diseño
Configuración muy flexible basada en colecciones de asociaciones, pruebas zk y divulgaciones voluntarias. Si bien esto es útil para garantizar que la propuesta pueda adaptarse a diferentes jurisdicciones, se debe tener gran cautela con respecto a opciones de diseño específicas. En particular, dos posibles ajustes a los que nos oponemos. Creemos que tienen problemas con los requisitos de confianza y pueden crear estructuras de mercado cuasi monopólicas. A continuación describimos y discutimos brevemente estas alternativas:
● Acceso centralizado: Los organismos encargados de hacer cumplir la ley, los proveedores de puntuación de riesgo criptográfico o actores similares pueden obtener acceso para ver los vínculos entre las transacciones de los usuarios y, al mismo tiempo, mantener la privacidad de los demás.
● lista blanca para todo el sistema: los sistemas de privacidad pueden imponer restricciones a los tipos de usuarios que pueden depositar monedas en sus grupos, exigirles que proporcionen pruebas adicionales o exigir que los depósitos esperen un período de tiempo durante el cual el riesgo centralizado El sistema de puntuación puede negar depósitos.
Los dos métodos son similares en que otorgan privilegios a entidades específicas. Esto plantea complejas cuestiones de gobernanza: ¿quién tiene acceso a esta información? ¿Quién tiene la autoridad para gestionar los permisos? Una empresa privada no parece una buena opción, ya que cualquier privilegio probablemente crearía una estructura de mercado oligopólica, en la que unas pocas empresas tendrían acceso a los datos que proporcionarían estos servicios, mientras que otras no podrían competir.
Del mismo modo, hay muchas cuestiones políticas y de gobernanza que enfrentar al empoderar a las instituciones públicas, especialmente en un entorno internacional. Incluso si una institución es 100% confiable hasta el momento, no abusará de su poder para perseguir una agenda política y no depende de otras entidades que podrían obligarla a abusar de su poder, esta situación es una manifestación de estancamiento. Las organizaciones, los miembros, los países y las estructuras políticas dentro de las organizaciones cambian con el tiempo. Puede haber presión externa y la existencia de estos privilegios puede crear incentivos adicionales para perturbar y ganar influencia sobre los sistemas de gobierno de la organización.
Además, los ataques dentro o fuera de la organización, o los errores por parte de una entidad centralizada, pueden tener consecuencias de gran alcance. Creemos que se debe evitar la creación de tales puntos de falla centralizados.
Dicho esto, reconocemos que diferentes tamaños de transacciones y circunstancias pueden requerir diferentes combinaciones de certificaciones. Por ejemplo, para transacciones grandes, muchos usuarios pueden terminar proporcionando pruebas básicas de exclusión en la cadena y brindando información más detallada sobre el origen de los fondos a sus contrapartes.
5. Dirección de la investigación en profundidad
Si bien este estudio proporciona una descripción general de cómo se pueden utilizar los protocolos de mejora de la privacidad basados en zkSNARK en entornos regulados, hay varios aspectos que merecen una mayor investigación.
En primer lugar, todo el mundo debe darse cuenta de que la privacidad lograda mediante estos protocolos depende de muchos factores diferentes. Un atacante puede asociar retiros con depósitos específicos basándose en un conjunto de asociaciones insuficientemente grande, una mala selección de raíz y un error del usuario.
Además, las elecciones realizadas por otros usuarios pueden afectar negativamente a su propia privacidad. En casos extremos, todos los demás miembros del grupo publicarían una prueba de membresía de tamaño uno, revelando un vínculo directo entre sus depósitos y retiros. Obviamente, esto revelaría implícitamente el vínculo entre las únicas transacciones restantes de depósito y retiro. En un ejemplo más sutil, se pueden utilizar restricciones de varias pruebas de membresía para extraer información y potencialmente correlacionar depósitos y retiros con alta probabilidad. Una vez que esta información certificada se combina con los metadatos de las transacciones, las propiedades de privacidad del protocolo pueden verse comprometidas.
Finalmente, un ASP malicioso podría optar por compilar el conjunto de asociaciones propuesto de una manera que le permita maximizar la extracción de información o aumentar el anonimato percibido agregando depósitos donde se conocen los retiros correspondientes. Todas estas cuestiones requieren más investigaciones para evaluar las propiedades de privacidad proporcionadas. De manera similar, sería interesante investigar más a fondo las propiedades de la separación de equilibrios, modelando cómo se comportan los jugadores buenos y malos bajo ciertos supuestos y cómo la prueba pública de los primeros afecta la privacidad de los segundos.
Los expertos legales pueden investigar más a fondo los requisitos de divulgación específicos. El esquema propuesto en este artículo es flexible y los conocimientos de los expertos legales pueden ayudar a adaptar el acuerdo y el ecosistema construido en torno a él para garantizar el cumplimiento en diversas jurisdicciones legales.
6. Conclusión
En muchos casos, se considera que la privacidad y el cumplimiento están en conflicto. Este artículo propone que este no es necesariamente el caso si un protocolo de mejora de la privacidad permite a los usuarios probar ciertas propiedades de su fuente de fondos. Por ejemplo, se supone que los usuarios pueden demostrar que sus fondos no están vinculados a depósitos de fuentes ilícitas conocidas, o que los fondos son parte de una colección específica de depósitos, sin revelar más información.
Una configuración de este tipo puede producir un equilibrio de separación en el que los usuarios honestos estén fuertemente incentivados a demostrar que pertenecen a algún conjunto de asociaciones compatibles y mantener la privacidad dentro de ese conjunto. Por el contrario, para los usuarios deshonestos, no pueden proporcionar dicha prueba. Esto permite a los usuarios honestos desvincularse de los depósitos de terceros con los que no están de acuerdo o impedirles utilizar sus fondos en un entorno compatible. Creemos que la propuesta es muy flexible y puede ajustarse según posibles diversos requisitos reglamentarios.
Este documento debe considerarse una contribución a la posible coexistencia futura de la privacidad y la regulación financiera. Queremos facilitar las discusiones y dirigir la conversación en una dirección más positiva y constructiva. Se requerirá la colaboración entre profesionales, académicos de diversas disciplinas, formuladores de políticas y reguladores para ampliar y revisar esta propuesta; el objetivo final es crear una infraestructura que mejore la privacidad y que pueda usarse en entornos regulados.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
V El último artículo de Dios: ¿Cómo protege el protocolo del grupo de privacidad la privacidad del usuario y cumple con los requisitos de cumplimiento?
原文：《Privacidad de Blockchain y cumplimiento normativo: hacia un equilibrio práctico》
De: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar y Ameen Soleimani
Compilado por: Odaily Planet Daily Husband How
Hoy, Buterin y otros escribieron conjuntamente un artículo de investigación sobre protocolos de privacidad, titulado "Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium".
El documento describe un nuevo protocolo de mejora de la privacidad basado en contratos inteligentes: grupo de privacidad, analiza sus ventajas y desventajas y muestra cómo equilibra a los usuarios honestos y los usuarios deshonestos. El protocolo está diseñado para utilizar pruebas de conocimiento cero para verificar la legitimidad de los fondos de los usuarios sin revelar su historial completo de transacciones, equilibrando los requisitos regulatorios y de privacidad al tiempo que filtra los fondos asociados con actividades delictivas.
Odaily Planet Daily ahora recopila la esencia del artículo de la siguiente manera.
I. Introducción
Las cadenas de bloques públicas son transparentes por diseño. La idea básica es que cualquiera puede elegir verificar las transacciones sin tener que depender de un tercero centralizado; al reducir las dependencias, proporciona una base neutral para una variedad de aplicaciones, incluidas, entre otras, las finanzas y la identidad soberana.
Sin embargo, desde el punto de vista de la privacidad, los conjuntos de datos públicos poseen cada transacción que contiene cada dirección de blockchain. Cada vez que alguien transfiere un activo a otra dirección o interactúa con un contrato inteligente, esa transacción siempre será visible en la cadena de bloques. Es evidente que esto no se ajusta a los requisitos de privacidad.
Ejemplo: Alice paga la cena en un restaurante con una billetera blockchain. El beneficiario ahora conoce la dirección de Alice y puede analizar toda la actividad pasada y futura en esa dirección. Del mismo modo, Alice ahora conoce la dirección de la billetera del restaurante y puede usar esta información para obtener las direcciones de la billetera de otros huéspedes o para verificar las ganancias del restaurante. O un tercero (como las redes sociales) que conoce el restaurante y la dirección de la billetera de Alice puede deducir fácilmente la dirección residencial real de Alice y estudiar sus transacciones pasadas y futuras.
**El auge de los protocolos de mejora de la privacidad tiene como objetivo resolver los problemas anteriores. Permite a los usuarios depositar fondos en el protocolo, utilizando una dirección, y retirar fondos del protocolo en un momento posterior, utilizando otra dirección. Todos los depósitos y retiros siguen siendo visibles en la cadena de bloques, pero la correspondencia entre transferencias específicas y transferencias ya no es pública. **
Uno de los protocolos de mejora de la privacidad más conocidos es Tornado Cash. Resuelve con éxito los problemas anteriores y permite a los usuarios conservar cierta privacidad. Sin embargo, además de los usuarios legítimos que intentan proteger sus datos, Tornado Cash también es utilizado por una variedad de malos actores. Los datos de depósito muestran que el grupo de piratas informáticos movió fondos a través de este protocolo. La evidencia sugiere que el grupo de piratería norcoreano también utilizó este protocolo de mejora de la privacidad, lo que culminó con la inclusión de las direcciones de contratos inteligentes del protocolo en la Lista de Nacionales Especialmente Designados y Personas Bloqueadas (comúnmente conocida como Lista SDN) mantenida por la Oficina de Activos Extranjeros de EE. UU. Control (OFAC). ).
**El problema clave con Tornado Cash es la línea borrosa entre usuarios legítimos y usuarios criminales. **Por lo tanto, Tornado Cash ofrece una función de cumplimiento que permite a los usuarios crear una prueba de de qué depósito provino un retiro determinado. Si bien este mecanismo permite a las personas demostrar su inocencia, lo hace a costa de tener que confiar en un intermediario centralizado y crear asimetrías de información. Al final, el mecanismo apenas fue utilizado por los usuarios.
Este artículo analiza una extensión de este enfoque que permite a los usuarios dar fe públicamente de información sobre de qué depósitos pueden provenir sus retiros, pero sin perder la privacidad. **Los pools de privacidad tienen un concepto general: permitir pruebas de membresía ("Certifico que mis retiros provienen de uno de estos depósitos") o pruebas de exclusión ("Certifico que mis retiros no provienen de ninguno de estos depósitos" ). **Este artículo analiza esta propuesta y explica cómo se puede utilizar para lograr un equilibrio entre usuarios honestos y deshonestos.
Tenga en cuenta que los grupos de privacidad brindan opciones adicionales al ampliar el conjunto de acciones del usuario. Aún pueden proporcionar pruebas más detalladas a una contraparte específica si es necesario. En algunos casos, sin embargo, puede ser suficiente una prueba de afiliación o exclusión. Además, la opción de hacer públicas estas pruebas tiene una serie de ventajas sobre la divulgación bilateral.
2. Antecedentes técnicos
En esta sección, proporcionamos una breve descripción técnica y analizamos la construcción técnica y los principios generales de protocolos como los grupos de privacidad.
1. Privacidad de blockchain antes de ZK-SNARK
Históricamente, los defensores de blockchain han argumentado que, si bien todas las transacciones son transparentes, las blockchains pueden preservar la privacidad porque brindan anonimato.
Con la llegada de las modernas herramientas de análisis y agrupación, esta protección de la privacidad se ha vuelto insuficiente. Para mejorar la privacidad de las cadenas de bloques públicas, se han introducido técnicas más sólidas, como uniones de tokens y Monero. Sin embargo, estas tecnologías aún conllevan el riesgo de fuga de datos. **
A esto le siguieron tecnologías de uso general a prueba de conocimiento cero, como Zcash y Tornado Cash, que pueden hacer que el conjunto de anonimato de cada transacción sea igual al conjunto completo de todas las transacciones anteriores. Esta técnica a menudo se denomina ZK-SNARK.
2、 ZK-SNARK
ZK-SNARKs es una técnica que permite a un demostrador demostrar una determinada afirmación matemática sobre datos públicos y privados, **al mismo tiempo que satisface dos propiedades clave: conocimiento cero y simplicidad. **
● Conocimiento-Cero: No revela ninguna información sobre los datos privados más que demostrar que dichos datos privados se ajustan a la declaración.
● **Simplicidad: **Las pruebas son breves y se pueden verificar rápidamente, incluso si las afirmaciones comprobadas requieren cálculos que requieren mucho tiempo.
Los ZK-SNARK han recibido una amplia atención por parte de la comunidad blockchain debido a su importancia en la escalabilidad, como los ZK-rollups. Para las aplicaciones de privacidad, la simplicidad no es particularmente importante, pero el conocimiento cero es esencial.
La "declaración" probada por ZK-SNARKs puede verse como un tipo de programa llamado "circuito", que calcula el resultado de una función f(x, w) con entradas públicas y privadas, y luego demuestra que para un público determinado ingrese x, hay una entrada privada w tal que el resultado de f(x, w) es Verdadero.
3. Aplicación de ZK-SNARK en sistemas como Zcash y Tornado Cash
Existen algunas diferencias menores entre las diferentes versiones de Zcash y los sistemas inspirados en él (como Tornado Cash). Sin embargo, la lógica básica en la que se basan es muy similar. Esta sección describe una versión simple que corresponde aproximadamente a cómo funcionan estos protocolos.
Los tokens consisten en secretos mantenidos por sus propietarios. Se pueden derivar dos valores de s:
● ID de token público L = hash(s + 1)
● anuladorU = hash(s + 2)
Entre ellos, hash se refiere a la función hash de contraseña, como SHA 256. Dado s, se pueden calcular el ID del token y el ceroizador. Sin embargo, dado un conjunto de anuladores y un ID de token público, el comportamiento pseudoaleatorio de la función hash garantiza que no pueda estar seguro de qué anulador está asociado con qué ID de token a menos que conozca los secretos que generaron ambos.
La cadena de bloques realiza un seguimiento de todos los ID de tokens que se han "creado" y de todos los anuladores que se han "gastado". Ambos conjuntos están en constante crecimiento (a menos que el protocolo quiera imponer cuándo se deben gastar los tokens).
Una colección de ID de token se almacena en una estructura de datos llamada árbol Merkle: si el árbol contiene N elementos, entonces cada elemento adyacente se procesa mediante hashes (lo que da como resultado ⌈ N/2 ⌉ hashes), y cada uno de estos hashes adyacentes se aplica hash nuevamente (lo que resulta en en ⌈ N/4 ⌉ hash), y así sucesivamente, hasta que todos los datos se confirmen en un único "hash raíz".
Dado un valor particular en un árbol y un hash de raíz, se puede proporcionar una rama de Merkle: un "valor hermano" que se une en cada paso del camino desde ese valor hasta la raíz. Esta rama de Merkle es útil porque es un pequeño dato (log 2(N) hashes) que se puede usar para demostrar que cualquier valor en particular está realmente en el árbol. La siguiente figura muestra un ejemplo de un árbol Merkle con una altura de 4.
Cuando los usuarios envían monedas a otras personas, proporcionan lo siguiente:
● El zerizer U que quieres gastar
● ID de token L' del nuevo token que se desea crear (se solicita al destinatario que lo proporcione)
● UN ZK-SNARK.
ZK-SNARK contiene las siguientes entradas privadas:
● Secretos de usuario
● Rama de Merkle en el árbol de ID del token, lo que demuestra que el token con ID de token L = hash(s + 1) en realidad se creó en algún momento en el pasado.
También contiene las siguientes aportaciones públicas:
● U, el valor cero del token que se está gastando.
● R, el hash raíz al que apunta la prueba de Merkle
ZK-SNARK demuestra dos propiedades:
● U = hash(s + 2)
● Las sucursales de Merkle son válidas.
Además de los ZK-SNARK, el protocolo también verifica lo siguiente:
● R es el hash raíz actual o histórico del árbol de ID del token.
● U no está en el conjunto de anuladores gastados.
Si la transacción es válida, agrega U al conjunto de nilificadores gastados y L' a la lista de ID de token. Mostrar U evita que una sola ficha se gaste dos veces. Sin embargo, no se revelará ninguna otra información. **El mundo exterior solo puede ver cuándo se envían las transacciones; no pueden obtener un patrón sobre quién envía o recibe estas transacciones y no pueden distinguir la fuente unificada de los tokens. **
Hay dos excepciones al modelo anterior: depósitos y retiros. En los depósitos, se pueden crear ID de token sin invalidar un determinado token anterior. Desde una perspectiva de preservación de la privacidad, los depósitos no son anónimos debido a que la asociación entre un L determinado y un evento externo que permite agregar L (en Tornado Cash, depositar ETH en el sistema; en Zcash, nueva minería ZEC) es pública.
En otras palabras, **los depósitos están vinculados a su historial de transacciones pasadas. **En los retiros, se consumirá un Zeroizer sin agregar una nueva ID de token. Esto puede desconectar los retiros de los depósitos correspondientes e indirectamente del historial de transacciones pasadas. Sin embargo, los retiros pueden vincularse a cualquier transacción futura que ocurra después del evento de retiro.
La primera versión de Tornado Cash no tenía concepto de transferencias internas, solo permitía depósitos y retiros. Las versiones posteriores, aún en etapa experimental, también permitieron transferencias internas y monedas de varias denominaciones, incluido el soporte para operaciones de "división" y "fusión". Discutiremos cómo extender el sistema básico de transferencia de monedas de privacidad y el fondo de privacidad a denominaciones arbitrarias en capítulos posteriores.
4. ZK-SNARK en grupo de privacidad
** La idea central del grupo de privacidad es que los usuarios no solo demuestren que el retiro está asociado con un depósito anterior mediante prueba de conocimiento cero, sino que también demuestren que pertenece a un conjunto de asociaciones más estricto. **La colección asociada puede ser un subconjunto de todos los depósitos realizados previamente, una colección que contenga solo los depósitos del usuario o cualquier cosa intermedia. Los usuarios especifican el conjunto proporcionando la raíz Merkle del conjunto asociado como entrada pública.
Como se muestra en la siguiente figura, en aras de la simplicidad, no probamos directamente que el conjunto asociado sea de hecho un subconjunto de los depósitos realizados anteriormente; en cambio, solo requerimos que el usuario use la misma ID de moneda que el nodo hoja para Demuestre las dos ramas de Merkle mediante conocimiento cero:
● Ingrese la rama Merkle de la raíz R del conjunto total de ID de monedas
● Ingrese la rama Merkle del conjunto de asociaciones raíz RA
La intención de esto es colocar el conjunto completo de asociaciones en algún lugar (podría ser en cadena). El concepto central es: en lugar de exigir a los usuarios que especifiquen exactamente de qué depósito provienen sus retiros o, en el otro extremo, no proporcionar ninguna otra información que no sea demostrar que no hubo gastos dobles, permitimos a los usuarios proporcionar un conjunto de opciones a partir de las cuales Los fondos pueden haber llegado, y esta colección puede ser tan amplia o reducida como deseen.
Fomentamos un ecosistema que facilite a los usuarios especificar un conjunto de asociaciones coherentes con sus preferencias. El resto de este artículo solo describirá la infraestructura basada en este mecanismo central simple y sus consecuencias.
3. Consideraciones prácticas y casos de uso
Desde el aspecto de la aplicación, analice cómo se utilizan en la práctica los protocolos de mejora de la privacidad.
1. Casos de uso para colecciones asociativas
Para ilustrar el valor de este programa en un entorno de aplicación de la ley, he aquí un ejemplo:
Supongamos que tenemos cinco usuarios: Alice, Bob, Carl, David, Eve. Los primeros cuatro usuarios son usuarios honestos, respetuosos de la ley pero conscientes de la privacidad, mientras que Eve es una ladrona. Porque el público sabe que Eve es una ladrona gracias a la información de que las monedas de la dirección marcada "Eve" fueron robadas. En la práctica, esto sucede con bastante frecuencia: en las cadenas de bloques públicas, los fondos generados por vulnerabilidades explotadas en los protocolos DeFi se rastrean para identificar fondos ilícitos que fluyen hacia Tornado Cash.
Cuando cada uno de los cinco usuarios realiza un retiro, puede elegir qué conjunto asociado especificar. Su conjunto de asociaciones debe incluir sus propios depósitos, pero son libres de elegir cuál de las otras direcciones incluir. Los cuatro primeros usuarios estaban motivados, por un lado, por querer proteger al máximo su privacidad. Esto los motiva a tender a ampliar su conjunto de asociaciones. Por otro lado, quieren reducir la posibilidad de que los comerciantes o las casas de cambio consideren sospechosas sus monedas. Hay una manera fácil de hacer esto: no incluyen a Eve en su colección asociada. Por lo tanto, para los cuatro, la elección es clara: que su conjunto de asociaciones sea {Alice, Bob, Carl, David}.
Por supuesto, Eve también quiere maximizar su conjunto asociativo. Pero no puede excluir sus propios depósitos, por lo que se ve obligada a que su conjunto asociativo sea igual al conjunto de los cinco depósitos. La selección de colección asociada de participantes se muestra en la siguiente figura.
Aunque la propia Eva no proporcionó ninguna información, mediante un simple proceso de eliminación, podemos sacar una inferencia clara: la retirada del quinto paso sólo puede provenir de Eva.
2. Construcción de colecciones asociadas
La sección anterior ilustra una posible forma de utilizar colecciones asociadas en un protocolo similar a un grupo de privacidad y cómo se pueden separar los participantes honestos de los malos. Tenga en cuenta que el sistema no se basa en el altruismo de Alice, Bob, Carl y David; tienen incentivos claros para justificar su separación. Veamos ahora con más detalle la construcción de colecciones asociadas. Normalmente, existen dos estrategias principales para generar colecciones de asociaciones. Se describen a continuación y se visualizan en la imagen a continuación.
● **Inclusión (o membresía): **Identifique un conjunto específico de depósitos para los cuales tengamos evidencia concluyente de que son de bajo riesgo y cree un conjunto asociado que contenga solo estos depósitos.
● Exclusión: Identificar un conjunto específico de depósitos para los cuales tenemos evidencia concluyente de que son de alto riesgo y construir un conjunto asociado que incluya todos los depósitos excepto estos depósitos.
En la práctica, los usuarios no seleccionan manualmente los depósitos para incluirlos en su colección asociada. En cambio, los usuarios se suscribirán a intermediarios que llamamos proveedores de colecciones de asociaciones (ASP), que generan colecciones de asociaciones con propiedades específicas. **En algunos casos, las ASP se pueden construir completamente en cadena sin intervención humana (o IA). En otros casos, las ASP generarán colecciones de asociaciones de forma independiente y las publicarán en la cadena o en otro lugar.
Recomendamos encarecidamente publicar al menos la raíz Merkle de la colección de asociaciones en la cadena; esto elimina la capacidad de las ASP maliciosas de realizar ciertos tipos de ataques a los usuarios (por ejemplo, dar a diferentes usuarios diferentes colecciones de asociaciones en un intento de anonimizarlos). . Toda la colección debería estar disponible a través de una API o, idealmente, a través de un sistema de almacenamiento descentralizado de bajo costo como IPFS.
La posibilidad de descargar todo el conjunto asociado es importante porque permite a los usuarios generar pruebas de membresía localmente sin revelar ninguna información adicional al ASP, ni siquiera los depósitos correspondientes a sus retiros.
Así es como se podrían estructurar los ASP en la práctica:
● Adición retrasada, excluidos los malos actores: Cualquier depósito se agrega automáticamente a la colección asociada después de un tiempo fijo (por ejemplo, 7 días), pero si el sistema detecta un depósito vinculado a un mal comportamiento conocido (por ejemplo, robo a gran escala o una dirección en una lista de sanciones publicada por el gobierno), el depósito nunca se agregará. En la práctica, esto podría lograrse a través de colecciones seleccionadas por la comunidad o proveedores de servicios de detección de transacciones existentes que ya realicen trabajos de identificación y seguimiento de depósitos asociados con mal comportamiento.
● Cargo mensual por persona: Para unirse a un conjunto asociado, el valor del depósito debe estar por debajo de un máximo fijo y el depositante debe demostrar sin conocimiento que posee algún token de identidad (por ejemplo, de una entidad respaldada por el gobierno). sistemas de identificación nacionales o mecanismos livianos como la verificación de cuentas de redes sociales). Mezclado con un parámetro adicional que indica el mecanismo de descarte para el mes actual para garantizar que cada identidad solo pueda comprometer depósitos en la colección asociada una vez al mes. El diseño intenta implementar el espíritu de muchas reglas comunes contra el lavado de dinero, según las cuales los pequeños pagos por debajo de un cierto umbral permiten un mayor nivel de privacidad. Tenga en cuenta que esto se puede implementar completamente como un contrato inteligente, que no requiere supervisión manual para mantener la operación continua.
● Tarifa mensual para miembros de la comunidad de confianza: Similar a la tarifa mensual para una sola persona, pero más restrictiva: los usuarios deben demostrar que son miembros de una comunidad altamente confiable. Los miembros de la comunidad que confían mucho acuerdan brindarse privacidad entre sí.
● **Puntuación en tiempo real basada en IA: **El sistema AI ASP puede proporcionar una puntuación de riesgo para cada depósito en tiempo real, y el sistema generará un conjunto asociado que contiene depósitos con una puntuación de riesgo por debajo de un cierto umbral. Potencialmente, ASP podría generar múltiples conjuntos correspondientes a múltiples umbrales de puntuación de riesgo.
4. Descripción técnica adicional
En esta sección, analizamos cómo la propuesta admite denominaciones arbitrarias y discutimos casos especiales como la recertificación, las pruebas directas bilaterales y las pruebas secuenciales.
1. Apoye cualquier denominación
El sistema de monedas simplificado de protección de la privacidad anterior solo admite transferencias de monedas de la misma denominación. Zcash admite denominaciones arbitrarias mediante el uso del modelo UTXO. Cada transacción puede tener múltiples entradas (es necesario publicar el ajuste a cero de cada entrada) y múltiples salidas (es necesario publicar el ID del token de cada salida). Cada ID de token creado debe ir acompañado de un valor de denominación criptográfica. Además de demostrar la validez del ceroizador, cada transacción debe ir acompañada de una prueba adicional de que la suma de las denominaciones de las monedas creadas no excede la suma de las denominaciones de las monedas gastadas. La siguiente figura ilustra esta prueba adicional.
Este diseño puede ampliarse para admitir depósitos y retiros tratando los depósitos como entradas (no cifradas) y los retiros como salidas (no cifradas). Además, el diseño puede restringirse para simplificar el análisis. Por ejemplo, solo se podrían permitir retiros parciales, de modo que la transacción tenga una entrada cifrada y dos salidas: una salida no cifrada que representa el retiro y una salida de "cambio" cifrada que representa los fondos restantes, que pueden usarse para futuros retiros.
Una pregunta natural es cómo ampliar este diseño para admitir grupos de privacidad. Insertarlo sin cambios en un grupo de privacidad no es ideal porque el gráfico de transacciones no coincide con lo que intuitivamente esperamos: si un usuario deposita 10 tokens y luego gasta 1+2+3+4 en cuatro retiros consecutivos de tokens, queremos tratar cada uno de ellos. estos cuatro retiros como fuente del depósito original de 10 tokens. Pero el resultado real se muestra en la siguiente figura: la fuente del primer retiro es el depósito de 10 tokens, y luego la fuente del segundo retiro es el cambio de salida de 9 tokens creado por el primer retiro, y así sucesivamente. Esto causa problemas en la práctica porque requiere que ASP valide el depósito intermedio y lo agregue a su colección asociada.
Para que los cuatro retiros en este ejemplo puedan tener como fuente el depósito original de 10 monedas, debemos resolver dos problemas:
● Asegúrese de que cada retiro parcial no esté vinculado públicamente a otros retiros
● Permitir que cada retiro parcial tenga el depósito como miembro de su conjunto asociado
Si solo admitimos retiros parciales, en lugar de transacciones MIMO más complejas, y nos aseguramos de que cada retiro tenga un "depósito original" único y correspondiente definido, existen múltiples formas de lograrlo directamente. Un enfoque natural y escalable es propagar la promesa de cierta información a través de transacciones. Por ejemplo, podemos exigir que la transacción contenga un hash de compromiso (coinID+hash®), agregar algún valor aleatorio r para garantizar el cegamiento y exigir que ZK-SNARK demuestre que el compromiso en la transacción es el mismo que el de su transacción principal. Si la transacción principal en sí es un retiro, el compromiso es el mismo que el ID de moneda del depósito original, y si la transacción principal es un depósito, el compromiso es el mismo que el ID de moneda del depósito original. Por lo tanto, cada transacción en la cadena debe contener un compromiso con el ID de la moneda de depósito original y debe demostrar que este valor está en el conjunto asociado proporcionado por la transacción.
Para mejorar la privacidad contra ataques de agregación de saldo, también podemos admitir la fusión de monedas. Por ejemplo, si me quedan algunas monedas, puedo fusionarlas con mi próximo depósito. Para dar cabida a esto, podemos exigir que las transacciones se comprometan con un conjunto de ID de monedas y exigir que las transacciones con múltiples entradas se comprometan con la unión de sus transacciones principales. Un retiro contendrá prueba de que todas sus ID de monedas comprometidas están en su conjunto asociado.
2. Circunstancias especiales
● Recertificación: Los usuarios necesitan información de depósito secreta para retirar depósitos de manera similar a los protocolos de grupo de privacidad. La misma información secreta también se utiliza para construir pruebas de pertenencia a conjuntos de asociaciones. Preservar información secreta permite a los usuarios generar nuevas pruebas que se ajusten a diferentes conjuntos o conjuntos asociados actualizados. Esto ofrece a los usuarios una mayor flexibilidad, pero también puede introducir riesgos adicionales.
● Prueba directa bilateral: En algunos casos, es posible que se solicite a los usuarios que revelen la fuente exacta de los retiros a la otra parte. Los usuarios pueden crear una colección asociada que contenga solo sus propios depósitos y generar pruebas de esa colección. Estas pruebas suelen ser la excepción y sólo contribuyen a una privacidad parcial cuando se comparten entre dos partes. Sin embargo, las pruebas compartidas deben establecer supuestos de confianza sólidos.
● Prueba de secuencia: En una economía de transacciones rápidas que utiliza un sistema como un grupo de privacidad, es necesario modificar el protocolo para adaptarse a este entorno. Además de los tipos de transacciones de depósito y retiro, el protocolo también debe admitir operaciones de envío internas para aumentar la eficiencia. Además, al pasar las sucursales y claves de Merkle, los usuarios pueden propagar información relacionada con el historial de transacciones para que los destinatarios puedan verificar el origen de los fondos. Esto garantiza que cada usuario tenga la información mínima que necesita para tener confianza en los fondos que recibe.
En la práctica, una moneda puede tener múltiples "orígenes". Por ejemplo, Bob es dueño de un puesto de café, recibe 5 fichas de Alice, 4 fichas de Ashley, 7 fichas de Anne y al final del día necesita pagarle a Carl 15 fichas para pagar la cena. En cambio, es posible que David haya recibido 15 fichas de Carl, 25 fichas de Chris y quiera depositar 30 fichas a Emma (un intercambio). En estos casos más complejos, seguimos el mismo principio: el historial que se agregó a la colección asociada hace suficiente tiempo puede ignorarse, mientras que el historial más reciente debe transmitirse.
5. Más detalles
Un sistema como un grupo de privacidad podría permitir a los usuarios obtener más protección en la privacidad de sus datos de transacciones financieras y al mismo tiempo mantener la capacidad de demostrar la separación de actividades ilegales conocidas. Esperamos que los usuarios honestos se vean incentivados a participar en dichos esquemas mediante una combinación de dos factores:
● Deseo de privacidad
● Deseo de evitar despertar sospechas
1. Consenso social y recaudación asociativa
Si hubiera un consenso total sobre si los fondos eran buenos o malos, el sistema produciría un equilibrio de separación simple. Todos los usuarios con activos "buenos" tienen un fuerte incentivo y la capacidad de demostrar que pertenecen a un conjunto de asociaciones "solo buenos". Los malos actores, por el contrario, no podrán aportar esta prueba. Todavía pueden depositar fondos "malos" en el fondo común, pero eso no les servirá de nada. Todos pueden determinar fácilmente que los fondos se retiraron de un protocolo de privacidad mejorada y ver que el retiro hace referencia a una colección asociada que contiene depósitos de fuentes cuestionables. Es más, el dinero "malo" no contamina el dinero "bueno". Cuando se retiran fondos de depósitos legítimos, sus propietarios pueden simplemente excluir todos los depósitos "malos" conocidos de su colección asociada.
Cuando existe un consenso global y las conclusiones sobre si los fondos se consideran "buenos" o "malos" dependen de las opiniones o jurisdicciones de la sociedad, los conjuntos de asociaciones pueden variar ampliamente. Supongamos que hay dos jurisdicciones con diferentes conjuntos de reglas. Las entidades en ambas jurisdicciones A y B pueden utilizar el mismo acuerdo de mejora de la privacidad y optar por emitir certificaciones que cumplan con los requisitos de sus respectivas jurisdicciones. Ambos pueden lograr fácilmente privacidad dentro de sus propias colecciones asociadas y excluir retiros que no cumplan con los requisitos de sus respectivas jurisdicciones. Si se desea, se puede emitir un comprobante de membresía por la intersección de dos conjuntos asociados, acreditando así fehacientemente que el depósito correspondiente a su retiro cumple con los requisitos de ambas jurisdicciones.
Por tanto, la propuesta es muy flexible y debe considerarse una infraestructura neutral. Por un lado, lucha contra la censura. Permite que cualquiera se una a una colección asociada de su elección y mantenga la privacidad dentro de su propia comunidad. Por otro lado, los externos pueden exigir pruebas contra un conjunto particular de asociaciones que cumplan con sus requisitos regulatorios. Por lo tanto, incluso si existe una comunidad de malos actores en el protocolo de mejora de la privacidad, no podrán ocultar el origen sospechoso de los depósitos siempre que la información se refleje con precisión en la construcción del conjunto asociado.
2. Propiedades de las colecciones asociadas
Las colecciones asociativas necesitan tener ciertas propiedades para funcionar. Los cobros deben ser precisos para que los usuarios puedan confiar en que están utilizando los fondos retirados de forma segura. Además, las propiedades de cada conjunto deberían ser estables, es decir, menos propensas a cambiar con el tiempo. Esto reduce la necesidad de retiros de revalidación en nuevas colecciones. Finalmente, para lograr una protección de privacidad significativa, el conjunto de asociaciones debe ser lo suficientemente grande y contener varios tipos de depósitos. Sin embargo, estas propiedades entran en conflicto entre sí. En general, las colecciones grandes y diversas pueden tener mejores propiedades de privacidad, pero pueden ser menos precisas y estables, mientras que las colecciones más pequeñas son más fáciles de mantener pero brindan menos privacidad.
3. Consideraciones prácticas y competencia.
Las entidades reguladas que aceptan criptoactivos deben asegurarse de que las leyes y regulaciones a las que están sujetas permitan la aceptación de dichos fondos. Hoy en día, muchas de estas entidades dependen de las llamadas herramientas de detección de transacciones: software o servicios que analizan la cadena de bloques para identificar actividades potencialmente sospechosas, enlaces a direcciones ilegítimas u otras transacciones que no cumplen con las normas. Las herramientas de detección suelen expresar el riesgo asociado con cada transacción a través de una puntuación de riesgo. Esta puntuación se basa en el destino de los fondos transferidos y su historial de transacciones. En este sentido, los protocolos de mejora de la privacidad pueden plantear desafíos. Eliminan el vínculo visible entre depósitos y retiros. Por lo tanto, en presencia de protocolos que mejoran la privacidad, la puntuación de riesgos debe tener en cuenta las pruebas y asignar puntuaciones basadas en conjuntos asociados.
Las herramientas y servicios para la detección de transacciones son proporcionados principalmente por empresas profesionales con experiencia en análisis de blockchain y campos legales relacionados. Idealmente, estas empresas (y cualquier otra persona) tendrían acceso a todos los certificados de membresía y sus correspondientes colecciones asociadas para proporcionar puntuaciones de riesgo precisas para todas las transacciones. Por lo tanto, recomendamos que todas las pruebas se almacenen en blockchain u otro repositorio de pruebas de acceso público. La única excepción es un certificado de membresía de tamaño uno compartido con una contraparte específica. Por razones obvias, estos testimonios no deben hacerse públicos.
El almacenamiento de pruebas directamente en la cadena agrega costos de transacción adicionales, pero reduce los esfuerzos de coordinación, hace que la competencia sea más justa y mitiga los riesgos de cuasi monopolio que los proveedores de herramientas de detección pueden crear debido al conocimiento de pruebas no públicas.
La configuración general de un grupo de privacidad es muy flexible. El protocolo se puede personalizar para diversos casos de uso mediante la creación de colecciones específicas de asociaciones. A continuación se muestran dos ejemplos de estas colecciones especiales de asociaciones:
● **Una federación de banca comercial puede crear un conjunto asociado que contenga únicamente depósitos de sus clientes. **Esto garantiza que la prueba de cualquier retiro creado para el cobro haya pasado por los procedimientos Conozca a su cliente (KYC) y Antilavado de dinero (AML) en uno de los bancos participantes, pero no revela qué retiro pertenece a qué cliente.
● **En los casos en los que se exige a los intermediarios financieros que documenten claramente el origen de los fondos, pueden exigir a los usuarios que proporcionen pruebas contra un conjunto asociado que solo contenga los depósitos de los usuarios. **Esta prueba luego se intercambiará bilateralmente con el intermediario, permitiéndole rastrear los fondos como si el usuario nunca hubiera usado el fondo de privacidad. Si bien esto requiere que los usuarios confíen en que el intermediario no revelará pruebas, lo ideal es que les permita cumplir con las regulaciones sin tener que revelar la información al público.
4. Opciones y alternativas de diseño
Configuración muy flexible basada en colecciones de asociaciones, pruebas zk y divulgaciones voluntarias. Si bien esto es útil para garantizar que la propuesta pueda adaptarse a diferentes jurisdicciones, se debe tener gran cautela con respecto a opciones de diseño específicas. En particular, dos posibles ajustes a los que nos oponemos. Creemos que tienen problemas con los requisitos de confianza y pueden crear estructuras de mercado cuasi monopólicas. A continuación describimos y discutimos brevemente estas alternativas:
● Acceso centralizado: Los organismos encargados de hacer cumplir la ley, los proveedores de puntuación de riesgo criptográfico o actores similares pueden obtener acceso para ver los vínculos entre las transacciones de los usuarios y, al mismo tiempo, mantener la privacidad de los demás.
● lista blanca para todo el sistema: los sistemas de privacidad pueden imponer restricciones a los tipos de usuarios que pueden depositar monedas en sus grupos, exigirles que proporcionen pruebas adicionales o exigir que los depósitos esperen un período de tiempo durante el cual el riesgo centralizado El sistema de puntuación puede negar depósitos.
Los dos métodos son similares en que otorgan privilegios a entidades específicas. Esto plantea complejas cuestiones de gobernanza: ¿quién tiene acceso a esta información? ¿Quién tiene la autoridad para gestionar los permisos? Una empresa privada no parece una buena opción, ya que cualquier privilegio probablemente crearía una estructura de mercado oligopólica, en la que unas pocas empresas tendrían acceso a los datos que proporcionarían estos servicios, mientras que otras no podrían competir.
Del mismo modo, hay muchas cuestiones políticas y de gobernanza que enfrentar al empoderar a las instituciones públicas, especialmente en un entorno internacional. Incluso si una institución es 100% confiable hasta el momento, no abusará de su poder para perseguir una agenda política y no depende de otras entidades que podrían obligarla a abusar de su poder, esta situación es una manifestación de estancamiento. Las organizaciones, los miembros, los países y las estructuras políticas dentro de las organizaciones cambian con el tiempo. Puede haber presión externa y la existencia de estos privilegios puede crear incentivos adicionales para perturbar y ganar influencia sobre los sistemas de gobierno de la organización.
Además, los ataques dentro o fuera de la organización, o los errores por parte de una entidad centralizada, pueden tener consecuencias de gran alcance. Creemos que se debe evitar la creación de tales puntos de falla centralizados.
Dicho esto, reconocemos que diferentes tamaños de transacciones y circunstancias pueden requerir diferentes combinaciones de certificaciones. Por ejemplo, para transacciones grandes, muchos usuarios pueden terminar proporcionando pruebas básicas de exclusión en la cadena y brindando información más detallada sobre el origen de los fondos a sus contrapartes.
5. Dirección de la investigación en profundidad
Si bien este estudio proporciona una descripción general de cómo se pueden utilizar los protocolos de mejora de la privacidad basados en zkSNARK en entornos regulados, hay varios aspectos que merecen una mayor investigación.
En primer lugar, todo el mundo debe darse cuenta de que la privacidad lograda mediante estos protocolos depende de muchos factores diferentes. Un atacante puede asociar retiros con depósitos específicos basándose en un conjunto de asociaciones insuficientemente grande, una mala selección de raíz y un error del usuario.
Además, las elecciones realizadas por otros usuarios pueden afectar negativamente a su propia privacidad. En casos extremos, todos los demás miembros del grupo publicarían una prueba de membresía de tamaño uno, revelando un vínculo directo entre sus depósitos y retiros. Obviamente, esto revelaría implícitamente el vínculo entre las únicas transacciones restantes de depósito y retiro. En un ejemplo más sutil, se pueden utilizar restricciones de varias pruebas de membresía para extraer información y potencialmente correlacionar depósitos y retiros con alta probabilidad. Una vez que esta información certificada se combina con los metadatos de las transacciones, las propiedades de privacidad del protocolo pueden verse comprometidas.
Finalmente, un ASP malicioso podría optar por compilar el conjunto de asociaciones propuesto de una manera que le permita maximizar la extracción de información o aumentar el anonimato percibido agregando depósitos donde se conocen los retiros correspondientes. Todas estas cuestiones requieren más investigaciones para evaluar las propiedades de privacidad proporcionadas. De manera similar, sería interesante investigar más a fondo las propiedades de la separación de equilibrios, modelando cómo se comportan los jugadores buenos y malos bajo ciertos supuestos y cómo la prueba pública de los primeros afecta la privacidad de los segundos.
Los expertos legales pueden investigar más a fondo los requisitos de divulgación específicos. El esquema propuesto en este artículo es flexible y los conocimientos de los expertos legales pueden ayudar a adaptar el acuerdo y el ecosistema construido en torno a él para garantizar el cumplimiento en diversas jurisdicciones legales.
6. Conclusión
En muchos casos, se considera que la privacidad y el cumplimiento están en conflicto. Este artículo propone que este no es necesariamente el caso si un protocolo de mejora de la privacidad permite a los usuarios probar ciertas propiedades de su fuente de fondos. Por ejemplo, se supone que los usuarios pueden demostrar que sus fondos no están vinculados a depósitos de fuentes ilícitas conocidas, o que los fondos son parte de una colección específica de depósitos, sin revelar más información.
Una configuración de este tipo puede producir un equilibrio de separación en el que los usuarios honestos estén fuertemente incentivados a demostrar que pertenecen a algún conjunto de asociaciones compatibles y mantener la privacidad dentro de ese conjunto. Por el contrario, para los usuarios deshonestos, no pueden proporcionar dicha prueba. Esto permite a los usuarios honestos desvincularse de los depósitos de terceros con los que no están de acuerdo o impedirles utilizar sus fondos en un entorno compatible. Creemos que la propuesta es muy flexible y puede ajustarse según posibles diversos requisitos reglamentarios.
Este documento debe considerarse una contribución a la posible coexistencia futura de la privacidad y la regulación financiera. Queremos facilitar las discusiones y dirigir la conversación en una dirección más positiva y constructiva. Se requerirá la colaboración entre profesionales, académicos de diversas disciplinas, formuladores de políticas y reguladores para ampliar y revisar esta propuesta; el objetivo final es crear una infraestructura que mejore la privacidad y que pueda usarse en entornos regulados.