Bitcoin, lanzado hace casi 14 años, revolucionó las transacciones financieras al eliminar intermediarios. El advenimiento de Ethereum y los contratos inteligentes ha acelerado aún más esta tendencia, eliminando intermediarios de productos financieros complejos como el comercio, préstamos y opciones. Sin embargo, el costo de eliminar intermediarios a menudo ha sido el sacrificio de la privacidad. Nuestra identidad y transacciones en cadena son fácilmente rastreadas por las bolsas centralizadas, las rampas de entrada/salida, las empresas de análisis en cadena y muchas otras entidades. Esta transparencia en cadena limita la expansión de la Web 3 a muchos casos de uso como pagos empresariales, trading en cadena propietario y muchas otras aplicaciones.

Este problema no es nuevo y muchos proyectos, por ejemplo, zCash, han intentado resolverlo desde 2016 mediante la introducción de tecnologías como las Pruebas de Conocimiento Cero (ZKPs). Desde entonces, la tecnología ZK ha avanzado a un ritmo increíble. Además, muchas otras tecnologías como el Cifrado Homomórfico Total (FHE) y las Computaciones Seguras de Multiparte (MPC) están surgiendo para abordar escenarios más sofisticados de uso de datos privados en cadena, también conocido como Estado Privado.

En Alliance creemos que la privacidad en la cadena permitirá casos de uso que antes no eran posibles y, por lo tanto, será un tema central en la Web 3 en los próximos años. Si eres un fundador que construye infraestructura de privacidad o aplicaciones que requieren estado privado, nos gustaría apoyarte. Puedes alcanzar y aplicar a Alianza.

Los diferentes tipos de estado privado

Usar datos privados en cadena significa naturalmente que estos datos están encriptados. La privacidad de esos datos depende de la propiedad de la clave de encriptación/desencriptación. Esta clave, es decir, la clave de privacidad, a menudo es diferente de la Clave Privada regular, es decir, la clave para firmar transacciones. La primera controla solo la privacidad de los datos, la última controla el cambio de estos datos.

La naturaleza de propiedad de la clave de privacidad conduce a diferentes tipos de estados privados. El tipo de estado privado afecta significativamente cómo este estado puede ser representado en la cadena y el mejor enfoque para manejar este estado. En general, el estado privado se puede dividir en Estado Privado Personal (EPP) y Estado Privado Compartido (EPC)

Estado privado personal

Esto significa que los datos/estado son propiedad de una sola entidad y solo esta entidad puede verlos o cambiarlos. Esta entidad también puede decidir permitir que otros vean los datos, por ejemplo, compartiendo una clave de visualización para todos o parte de estos datos. Ejemplos de este estado privado incluyen:

• Saldo de token privado
• Credenciales privadas o información personal. esto incluye la edad, la ciudadanía, el estado de acreditación de inversionista, la cuenta de Twitter o cualquier otro dato de la Web 2 que pueda ser utilizado en la Web 3
• Historial de transacciones privadas

Estado privado compartido

Un estado privado compartido (SPS) es datos privados que múltiples personas pueden cambiar/utilizar para computación sin comprometer la privacidad. Un SPS puede ser un estado que es accesible por cualquier persona y, por lo tanto, puede ser cambiado por cualquier usuario. Esto puede ser el estado de un AMM de piscina oscura, el estado de una piscina de préstamos privada, etc. Un SPS también puede estar limitado a un pequeño grupo de participantes que pueden acceder o cambiar los datos. Ejemplos de esto incluyen el estado de un multijugador en cadena donde solo se permite a los jugadores activos cambiar el estado. También puede incluir entradas privadas a un modelo de IA en cadena, donde solo unas pocas entidades, por ejemplo, el operador del modelo, pueden realizar cálculos sobre los datos privados.

SPS es más difícil de gestionar que el estado privado personal. Siempre es más difícil razonar sobre el tipo de cálculo que se puede realizar en SPS y si este cálculo puede filtrar información al respecto. Por ejemplo, ejecutar una operación comercial contra un AMM de dark-pool puede filtrar algo de información sobre la liquidez dentro del pool.

ZKPs, FHE, y MPC

Existen diferentes enfoques posibles para manejar estados privados en cadena. Cada enfoque es adecuado para un tipo particular de estado privado y, por lo tanto, un conjunto específico de aplicaciones. En muchos casos, la creación de una aplicación útil requiere combinar estos enfoques juntos.

Pruebas de conocimiento cero

El primer enfoque que surgió para manejar la privacidad en la cadena de bloques fue utilizar ZKPs. Este enfoque es particularmente adecuado para datos personales privados. En este enfoque, el propietario de los datos simplemente puede descifrar los datos localmente utilizando su clave de privacidad, realizar los cambios necesarios, encriptar el resultado utilizando su clave, y finalmente generar un ZKP para demostrar a la red que sus cambios en el estado privado son válidos.

Esto hizo que ZK fuera particularmente adecuado para redes de pago, por ejemplo, zCash, Iron Fish y muchos otros. En esta arquitectura, cuando los usuarios realizan transacciones utilizando activos privados, realizan todos los cálculos localmente, es decir, gastan UTXOs y crean nuevos para el destinatario, y modifican sus saldos de tokens privados. Dado que la computación y la generación de ZKP ocurren localmente en el dispositivo del usuario, la privacidad de los saldos y el historial de transacciones está protegida. Los mineros de la red solo ven el ZKP generado y el nuevo UTXO cifrado.

A pesar de la simplicidad de las operaciones necesarias para realizar pagos, la experiencia de usuario de los pagos privados era difícil debido a los largos tiempos de generación de ZKP. Sin embargo, con mejoras significativas en los sistemas de demostración de conocimiento nulo, el tiempo de generación de prueba para pagos simples cayó por debajo de 1 segundo en hardware de consumo. Esto también permitió la introducción de programabilidad general en sistemas basados en zk.Azteca y Aleoson dos grandes redes que están llevando la programabilidad general a las cadenas basadas en zk. Aztec y Aleo tienen algunas diferencias, pero ambas se basan en gran medida en el modelo ZEXEEn este modelo, cada aplicación debe implementarse como un zk-circuito. Esto creó la necesidad de que tanto la red abstraiga la complejidad zk para los desarrolladores de aplicaciones y usuarios. Esto requirió la creación de lenguajes de programación de alto nivel, por ejemplo, Noir (Aztec) y Leo (Aleo), que pueden convertir el código de alto nivel de manera eficiente en circuitos zk.

Por ejemplo, Aztec utiliza Noir y su marco de desarrollo de contratos inteligentes asociado, Aztec.nr, para descomponer cada contrato inteligente en un conjunto de funciones. Cada función se implementa como un circuito zk. Los usuarios pueden realizar cálculos generales sobre sus datos privados descargando las funciones necesarias y realizando los cálculos localmente en sus dispositivos. Los detalles de cómo se ejecutan los contratos inteligentes de Aztec se discutieron en este hilo.

La implementación como Aztec ha mejorado significativamente la usabilidad de los sistemas zk al introducir programabilidad general. Sin embargo, dichos sistemas aún enfrentan varios desafíos:

1. Cualquier computación sobre estado privado debe ocurrir en el lado del cliente. Esto degrada la UX y requiere que los usuarios tengan dispositivos capaces para usar la red.
2. El enfoque zk no es adecuado para manejar el estado privado compartido. De forma predeterminada, todas las aplicaciones tienen un estado público. Esto hace que sea difícil construir aplicaciones como juegos con información incompleta y DeFi privado.
3. Mayor composabilidad, no es posible ejecutar transacciones que requieran cambiar varios estados privados, ya que cada estado debe ser calculado por un usuario diferente. Dichas transacciones deben dividirse en piezas y cada pieza debe ejecutarse en un bloque separado.
4. También existen desafíos en la descubribilidad de datos privados. Si un usuario recibe una transacción con un estado privado, no puede descubrir este estado a menos que descargue todo el estado privado de la red, intente descifrar cada parte de él usando su clave de privacidad. Esto crea una experiencia de usuario desafiante incluso para realizar tareas simples como consultar su saldo como se explica en estahilo.

Aplicaciones adecuadas para sistemas basados en zk

Las sólidas garantías de privacidad de zk lo hacen adecuado para un número considerable de casos de uso

Medios de comunicación social anónimos

Algunas figuras destacadas no pueden compartir sus verdaderos pensamientos y experiencias por temor a la reacción social y la cancelación. Esto fomenta un nuevo tipo de redes sociales donde los participantes pueden demostrar de forma privada ciertos rasgos sobre sí mismos, por ejemplo, riqueza en cadena o posesión de un NFT específico, y utilizar esta prueba para publicar de forma anónima sin revelar su verdadera identidad. Ejemplos incluyen Canciones de ballenasprototipo por mi colegaDavid,

Credenciales privadas en cadena

Un ejemplo relacionado es permitir que las personas que tienen ciertas credenciales participen de forma anónima en un DAO o voten de forma anónima sobre temas que requieren experiencia específica. Un ejemplo de Web 3 de eso es HeyAnoun. Un dominio de aplicación más amplio está aprovechando las credenciales del mundo real, por ejemplo, riqueza del mundo real, títulos académicos, para participar de forma anónima en protocolos en cadena. Integrar credenciales privadas del mundo real en cadena puede permitir múltiples casos de uso como préstamos DeFi sin garantía, KYC en cadena o bloqueo geográfico. ZK es adecuado para estos casos de uso porque permite la existencia de claves de visualización especializadas para partes del estado privado que pueden ser utilizadas en circunstancias específicas, por ejemplo, incumplimiento de préstamos.

El principal desafío de incorporar credenciales de la vida real en la cadena es cómo garantizar la autenticidad de las credenciales/datos de la vida real. Algunos enfoques como zkEmailyTLSNotaryabordar este problema mediante la autenticación del tráfico web a dominios web específicos y que el dominio contenga los datos requeridos.

Facturación/pagos empresariales

Un subconjunto importante de pagos privados es el pago empresarial. Las empresas a menudo no desean revelar a sus socios comerciales/proveedores o los términos contractuales de sus acuerdos. La transparencia de los pagos en cadena ha limitado la adopción empresarial de los pagos con monedas estables. Con la privacidad adecuada en cadena,adopción de empresas de pagos en cadenapuede acelerarse en función de una mayor eficiencia y rentabilidad en comparación con las vías bancarias existentes.

Enfoque FHE

El cifrado totalmente homomórfico permite realizar cálculos sobre datos cifrados y generar resultados cifrados correctos sin descifrar los datos durante el cálculo. Esto hace que FHE sea particularmente adecuado para manejar estados privados compartidos. Con FHE, es posible crear aplicaciones on-chain que tengan un estado privado, como pools AMM privados o una urna electoral privada. El estado privado existe on-chain en un formato cifrado que permite a cualquier usuario realizar cálculos sobre estos datos. La incorporación de FHE on-chain puede habilitar y simplificar numerosos casos de uso que antes no eran posibles, como votaciones privadas y juegos con información incompleta, por ejemplo, Poker.

Ventajas de FHE

Una ventaja significativa de FHE es mejorar la composición en múltiples aspectos.

1. Varios usuarios/pagos pueden cambiar el mismo estado privado dentro del mismo bloque. Por ejemplo, múltiples intercambios pueden usar la misma reserva oscura.
2. Una sola transacción puede cambiar múltiples estados privados. Por ejemplo, una transacción de intercambio puede utilizar múltiples pools AMM oscuros para completar un intercambio.

Otra ventaja es una mejor experiencia de usuario. En FHE, los cálculos sobre el estado privado son realizados por los validadores de la red que pueden implementar hardware especializado para realizar estos cálculos más rápido.

Una tercera ventaja del FHE es la mejora de la experiencia del desarrollador. Aunque los desarrolladores todavía tienen que actualizar sus modelos mentales para manejar adecuadamente el estado privado, la barrera es mucho menor que en los sistemas zk. En primer lugar, los sistemas FHE pueden operar con el mismo modelo de cuenta que utilizan las cadenas de contratos inteligentes. En segundo lugar, las operaciones FHE se pueden agregar encima de las implementaciones de VM existentes, lo que permite a los usuarios utilizar los mismos marcos de desarrollo, herramientas, billeteras e infraestructura a las que están acostumbrados. Este es el caso para el fhEVMimplementación deZamaque simplemente han agregado las variables encriptadas y las operaciones FHE como precompilados. Contraintuitivamente, esta ventaja es crítica para el crecimiento de las aplicaciones privadas en cadena, los desarrolladores son la clave para crear aplicaciones interesantes que atraigan a los usuarios. Una experiencia de desarrollo perfecta puede atraer a más desarrolladores al espacio FHE.

Limitaciones de FHE

Privacidad Confianza Supuestos

Las cadenas FHE requieren claves globales de cifrado/descifrado para todo el estado privado. Esto es crucial para lograr la composabilidad. Normalmente, estas claves son mantenidas por el grupo de validadores para poder descifrar los resultados de las operaciones FHE sobre el estado privado. Esto significa que el grupo de validadores también de confianzano romper la privacidad de los estados privados existentes.

Potencial Fuga de Privacidad
Realizar múltiples cálculos sobre los datos encriptados puede comprometer la privacidad. Por ejemplo, las operaciones ejecutadas en un pool AMM oscuro pueden revelar cierta información sobre la estructura actual de liquidez del pool.

Complejidad computacional de la computación FHE

Incluso con implementaciones avanzadas, las operaciones FHE suelen ser de 1000 a 1.000.000 veces más costosas desde el punto de vista computacional que los cálculos normales. Esta complejidad limita el posible rendimiento de las aplicaciones FHE en cadena. Las estimaciones actuales de Inco Network indican un rendimiento de entre 1 y 5 TPS para las operaciones de FHE. Con la aceleración de GPU y FPGA, este rendimiento se puede acelerar de 10 a 50 veces.

Fuente: https://eprint.iacr.org/2021/1402.pdf

Aplicaciones adecuadas para sistemas FHE

Los sistemas FHE son particularmente adecuados para aplicaciones que requieren un alto grado de composabilidad

Juegos con información incompleta. Ejemplos aquí incluyen juegos de cartas, por ejemplo, póquer, donde el estado del mazo de cartas es accesible y puede ser modificado por múltiples jugadores.

La votación privada, MPC simplifica la implementación de encuestas secretas cuando los votos pueden cambiar el recuento de votos sin conocer el resultado de la votación anterior

La implementación de AMM privados o piscinas privadas de DeFi en general se simplifica al representar el estado de la piscina como variable encriptada.

Enfoque de MPC

La computación multiparte (MPC) ha sido conocida y popular dentro de la industria de la criptografía por el caso de uso específico de la custodia de activos. Algunas de las empresas más grandes en el espacio, por ejemplo, Fireblockshan construido negocios exitosos en torno al uso seguro de MPC para la custodia de la concurrencia. Además, muchos proveedores de billeteras como servicio, por ejemplo, Coinbase,0xPass, utilizar MPC para mejorar la seguridad y la experiencia de usuario.

Sin embargo, MPC se puede utilizar para más que asegurar claves privadas. En general, MPC resuelve el problema de realizar cálculos sobre entradas privadas, es decir, datos, y solo revelar la salida de los cálculos sin violar la privacidad de las entradas. En el contexto específico de la custodia de activos, las entradas privadas son los fragmentos de la clave privada. Los propietarios de estos fragmentos colaboran para realizar una 'computación' sobre estas entradas privadas. La computación aquí implica generar una firma de transacción. Las partes múltiples aquí generan y descifran colectivamente la firma sin que ninguno de ellos acceda a las entradas privadas, es decir, la clave privada.

Del mismo modo, MPC permite cualquier tipo de computación sobre datos privados sin revelarlos. Esto permite a MPC manejar un estado privado en un contexto de cadena de bloques. Un ejemplo de ello es el entrenamiento descentralizado de IA sobre conjuntos de datos privados. Diferentes propietarios de datos y proveedores de computación pueden colaborar para realizar un entrenamiento de IA basado en MPC sobre los conjuntos de datos privados para calcular los pesos del modelo. La salida de la computación, es decir, los pesos, son descifrados por el grupo de MPC después de la fase de entrenamiento para crear el modelo de IA completo.

Muchas implementaciones de MPC logran sólidas garantías de privacidad para la privacidad de los datos, es decir, minoría honesta, lo que significa que tiene garantías de privacidad similares a los sistemas zk. MPC también puede parecerse a FHE ya que permite realizar cálculos sobre un SPS, lo que significa que puede permitir la composabilidad. Sin embargo, en comparación con FHE, MPC tiene algunas limitaciones

1. La computación solo puede ser realizada por las entidades que forman parte del grupo MPC. Nadie fuera de este grupo puede realizar cálculos sobre los datos
2. Para lograr garantías minoritarias honestas, todas las partes de MPC necesitan cooperar para realizar el MPC. Esto significa que la computación puede ser censurada por cualquier miembro del grupo de MPC. Esta limitación puede relajarse al reducir el umbral de MPC, es decir, el número de entidades requeridas para realizar la computación. Sin embargo, el precio aquí es que la privacidad de los datos puede ser vulnerada por una coordinación entre un número menor de participantes.

Aplicaciones adecuadas para sistemas de MPC

CLOBs de Dark Pool

Una de las primeras aplicaciones reales de MPC en DeFi es la implementación de Dark Pool CLOBs. En este sistema, los operadores pueden colocar órdenes limitadas o de mercado sin conocimiento previo del estado del libro de órdenes. La conciliación de pedidos se realiza a través de MPC a través de los datos privados, es decir, el libro de pedidos existente. Finanzas Renegadases una de las empresas que construyen un sistema de este tipo.

Inferencia descentralizada de modelos de IA propietarios

Algunas aplicaciones, por ejemplo, los administradores de estrategias basadas en IA de DeFi o Calificación crediticia de la Web 3, puede implementar MPC para realizar inferencias utilizando modelos patentados. En esta arquitectura, los pesos del modelo de IA son privados. Los pesos pueden compartirse de forma segura entre varios nodos de cálculo de modo que cada uno tenga solo un subconjunto de pesos del modelo. Los nodos pueden colaborar para realizar inferencias de IA sobre eventos actualizados en cadena para tomar decisiones y enviar transacciones que ejecuten la estrategia DeFi.

Entrenamiento de modelos de inteligencia artificial abierta utilizando datos patentados

Un ejemplo común aquí es entrenar modelos de diagnóstico médico utilizando registros de salud privados. En este caso, los creadores de modelos, empresas y propietarios de datos, es decir, pacientes, pueden colaborar utilizando MPC para ejecutar el proceso de entrenamiento sobre los datos privados sin comprometer la privacidad de los datos privados. Redes como BittensoryNillionpuede habilitar tales casos de uso.

Estado privado compartido pseudo-permisible

Con un diseño cuidadoso, MPC se puede utilizar para manejar SPS seudopermisivas. Por ejemplo, el estado de un grupo oscuro de AMM y el cálculo sobre este estado se pueden construir como un MPC entre varios entidades. Los usuarios que deseen interactuar con el AMM deben compartir sus transacciones con el grupo MPC para realizar los cálculos en su nombre. La ventaja de este enfoque es que cada SPS puede tener un conjunto diferente de claves de privacidad (en comparación con las claves globales en el caso de FHE). El riesgo de este enfoque es la posibilidad de censura por parte del grupo MPC. Sin embargo, con un diseño económico cuidadoso, este riesgo puede mitigarse.

Competencia o Sinergias

Los enfoques discutidos para manejar el estado privado en la cadena de bloques parecen competitivos a primera vista. Sin embargo, si dejamos de lado los incentivos financieros de los diferentes equipos que construyen estas redes, zk, FHE y MPC son en realidad tecnologías complementarias.

Por un lado, los sistemas zk ofrecen garantías de privacidad más sólidas porque los datos "no cifrados" nunca salen del dispositivo del usuario. Además, es imposible que alguien ejecute algún cálculo sobre estos datos sin el permiso del propietario. El precio de estas sólidas garantías de privacidad es una composabilidad más débil.

Por otro lado, FHE facilita una componibilidad más fuerte, pero una privacidad más débil. El riesgo de privacidad se deriva de confiar en una entidad o en un pequeño número de entidades con las claves de descifrado FHE globales. A pesar de ese riesgo y debido a que la componibilidad es un ingrediente fundamental en las criptomonedas, FHE puede habilitar la privacidad en muchos casos de uso importantes como DeFi.

La implementación de MPC ofrece un punto intermedio único entre los enfoques zk y FHE. MPC permite la computación sobre datos privados compartidos. Por lo tanto, ofrece más capacidad de composición que las Pruebas de Conocimiento Cero. Sin embargo, la computación sobre este estado privado está limitada a un pequeño grupo de participantes y no es sin permiso (a diferencia de FHE).

Dado cómo difieren las ZKPs, MPC y FHE en su ritmo de aplicaciones, a menudo las aplicaciones prácticas requieren combinar estas tecnologías. Por ejemplo, Renegade Finance combina MPC y ZKPs para permitir la construcción de un Dark Pool CLOB que también garantiza que los participantes tengan suficiente capital para cubrir sus órdenes ocultas. Del mismo modo, el juego de póker en cadena, zkHoldem combina ZKPs y FHE.

Esperamos que las redes centradas en la privacidad combinen estas tecnologías bajo el capó para ofrecer a los desarrolladores en estos ecosistemas todas las herramientas que necesitan para construir aplicaciones de forma transparente. Por ejemplo, Aztec puede combinar alguna forma de MPC en la red para manejar el estado privado compartido. De manera similar, Red Incopuede utilizar ZKPs para permitir direcciones privadas e historial de transacciones privadas.

Con esta visión de un futuro centrado en la privacidad, Alliance espera apoyar a los fundadores que construyen este futuro. Si estás construyendo en este ámbito, ponerse en contacto y aplicar a Alianza.

Descargo de responsabilidad：

1. Este artículo ha sido reimprimido de [Alianza], Todos los derechos de autor pertenecen al autor original [Mohamed Fouda]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Aprenderequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.