Autor: EQ Labs Fuente: equilibrium Traducción: Shanolba, Golden Finance

Nuestra serie de privacidad Parte 1 explicó el significado de la "privacidad", la diferencia entre la privacidad en la cadena de bloques y la privacidad web2, y por qué es difícil lograr la privacidad en la cadena de bloques.

El punto principal de este artículo es que si el estado final ideal es tener una infraestructura de privacidad con  Programabilidad que pueda manejar estados privados compartidos sin ningún punto único de falla, entonces todos los caminos conducen a MPC. También discutiremos la madurez de MPC y sus suposiciones de confianza, destacando enfoques alternativos, comparando compensaciones y brindando una visión general de la industria.

Liberarse de las ataduras del pasado y dar la bienvenida al futuro

La infraestructura de privacidad existente en la cadena Bloquear está diseñada para abordar casos de uso muy específicos, como pagos privados o votaciones. Esta es una perspectiva bastante estrecha que refleja principalmente los usos actuales de la cadena Bloquear (transacciones, transferencias y especulación). Como dijo Tom Walpo, las criptomonedas sufren el paradigma de Fermi:

Además de aumentar la libertad personal, consideramos que la privacidad es una condición previa para ampliar el espacio de diseño de la Cadena de bloques, superando los metadatos especulativos actuales. Muchas aplicaciones requieren algún estado privado y/o lógica oculta para funcionar correctamente:

• Estado oculto : La gran mayoría de los casos de uso financieros requieren (al menos) mantener en secreto la información de otros usuarios, y si no hay algún estado oculto, la diversión de muchos juegos multijugador disminuirá significativamente (por ejemplo, si todos en la mesa de póker pueden ver las cartas de los demás).
• Lógica oculta: Algunos casos de uso requieren ocultar cierta lógica mientras se permite que otros usuarios utilicen la aplicación, como motor correspondiente, estrategias de transacción on-chain, etc.

El análisis empírico (de web2 y web3) muestra que la mayoría de los usuarios no están dispuestos a pagar costos adicionales o saltarse pasos adicionales para aumentar la privacidad, y estamos de acuerdo en que la privacidad en sí misma no es un punto de venta. Sin embargo, sí permite que surjan nuevos casos de uso, con suerte más significativos, en la cadena de bloques, y nos ayuda a superar la paradoja de Fermi.

La tecnología de mejora de la privacidad (PET) y las soluciones modernas de cifrado ('Programabilidad de contraseñas') son los bloques de construcción fundamentales para lograr esta visión (para obtener más información sobre las diferentes soluciones disponibles y sus compensaciones, consulte el apéndice).

Tres suposiciones que afectan nuestra perspectiva

Nuestra opinión sobre cómo se desarrolla la infraestructura de privacidad de la cadena de bloques se basa en tres suposiciones clave:

1. La tecnología de encriptación se abstraerá de las manos de los desarrolladores de aplicaciones: La mayoría de los desarrolladores de aplicaciones no quieren (o no saben cómo lidiar con ella) la tecnología de encriptación necesaria para lidiar con la privacidad. No es razonable esperar que implementen su propia tecnología de encriptación y construyan cadenas de aplicaciones privadas* (por ejemplo, Zcash o Namada) o aplicaciones privadas sobre cadenas públicas (por ejemplo, Tornado Cash). Esto es simplemente demasiado complejo y sobrecargado, y actualmente limita el espacio de diseño para la mayoría de los desarrolladores (incapaces de crear aplicaciones que requieran cierta privacidad). Por lo tanto, creemos que es importante abstraer la complejidad de gestionar la parte de encriptación de las manos de los desarrolladores de aplicaciones. Los dos enfoques aquí son la infraestructura de privacidad de Programabilidad (L1/L2 privada compartida) o "secret-as-a-service", que permite externalizar la informática confidencial.
2. Muchos casos de uso (posiblemente más de los que imaginamos) requieren compartir estados privados: como se mencionó anteriormente, muchas aplicaciones requieren algún estado oculto y/o lógica para funcionar correctamente. Compartir estados privados es un subconjunto de esto, donde múltiples partes calculan sobre el mismo estado privado. Aunque podríamos confiar en una entidad centralizada para hacer esto por nosotros y dejarlo así, idealmente queremos hacerlo de manera que minimice la confianza para evitar puntos únicos de falla. Solo confiar en Prueba de conocimiento cero (ZKP) no logra esto: necesitamos utilizar otras herramientas como Entornos de Ejecución Confiables (TEE), Cifrado homomórfico completo (FHE) y/o Cálculo multipartito (MPC).
3. Conjuntos de enmascaramiento más grandes para una protección de la privacidad máxima: la mayoría de la información se filtra al entrar o salir del conjunto de enmascaramiento, por lo que debemos tratar de minimizar esta situación. La construcción de varias aplicaciones privadas en la misma cadena de bloques puede ayudar a reforzar la protección de la privacidad aumentando el número de usuarios y transacciones dentro del mismo conjunto de enmascaramiento.

El fin de la infraestructura de privacidad

Teniendo en cuenta las suposiciones anteriores, ¿cuál es el objetivo final de la infraestructura de privacidad de la cadena Bloquear? ¿Hay alguna manera que se adapte a todas las aplicaciones? ¿Existe una tecnología de mejora de la privacidad que pueda liderar todas las aplicaciones?

No del todo. Todos estos tienen diferentes compensaciones, y los hemos visto combinarse de diversas formas. En total, hemos identificado 11 métodos diferentes.

Actualmente, los dos métodos más populares para construir infraestructura de privacidad en blockchain son utilizar ZKP o FHE. Sin embargo, ambos tienen defectos fundamentales:

• El protocolo de privacidad basado en ZK y con pruebas de cliente puede proporcionar una fuerte protección de la privacidad, pero no permite cálculos más largos en el mismo estado privado. Esto limita la capacidad de expresión, es decir, qué tipo de aplicaciones pueden construir los desarrolladores.
• FHE admite el cálculo de datos de encriptación y estado privado compartido, pero plantea la pregunta de quién * posee * el estado, es decir, quién posee la Llave secreta de descifrado. Esto limita la fuerza de la protección de la privacidad y el grado en el que podemos confiar en que la privacidad de hoy sea igual mañana.

Si el estado final ideal es tener una infraestructura de privacidad de programabilidad que pueda manejar el estado privado compartido* sin ningún punto único de fallo*, entonces ambas rutas pueden conducir a MPC:

Tenga en cuenta que aunque estos dos métodos eventualmente convergerán, el uso de MPC es diferente:

• Red de ZKP: MPC aumenta la capacidad de expresión mediante el cálculo de estado privado compartido.
• Red FHE: MPC mejora la seguridad y refuerza la privacidad al distribuir la  Llave secreta de descifrado a través del comité MPC (en lugar de a terceros individuales).

Aunque la discusión comienza a centrarse en puntos de vista más detallados, aún no se ha explorado completamente la garantía detrás de estos diferentes enfoques. Dado que nuestra suposición de confianza se reduce a la suposición de MPC, las tres preguntas clave que deben plantearse son:

1. ¿Qué tan fuerte es la protección de privacidad que puede proporcionar el protocolo MPC en la cadena de bloques?
2. ¿Es la tecnología lo suficientemente madura? Si no lo es, ¿cuál es el cuello de botella?
3. ¿Tiene sentido en comparación con otros métodos teniendo en cuenta la fuerza y el costo de la garantía introducida?

Permítanos responder estas preguntas de manera más detallada.

Utilizar MPC para analizar riesgos y debilidades

Siempre que se utiliza FHE en una solución, la gente siempre pregunta: “¿Quién posee la “Llave secreta” de descifrado?”. Si la respuesta es “red”, la pregunta siguiente sería: “¿Qué entidades reales forman esa red?”. La pregunta posterior está relacionada con todos los casos de uso que de alguna manera dependen de MPC.

Fuente de información: Discurso de Zama en ETH CC

El principal riesgo de MPC es la colusión, es decir, cuando hay suficientes participantes que colaboran maliciosamente para descifrar datos o robar cálculos. La colusión puede lograrse off-chain y solo se revela cuando la parte maliciosa toma ciertas acciones obvias (chantaje, acuñando Tokens de la nada, etc.). Sin duda, esto tiene un impacto significativo en la privacidad que el sistema puede proporcionar. El riesgo de colusión depende de:

• ¿Cuántas partes maliciosas puede soportar este protocolo?
• ¿De qué partes se compone Internet? ¿Cómo de confiables son?
• Número y distribución de las diferentes partes involucradas en la red - ¿Existen medios de ataque comunes?
• ¿La red es permisiva o requiere permisos (beneficios económicos y reputación/base legal)?
• ¿Cuál es el castigo por comportamiento malicioso? ¿El amañamiento de juegos es el resultado óptimo en teoría?

¿Cuál es la privacidad que el protocolo MPC puede proporcionar en la cadena de bloques?

TLDR: No es tan poderoso como esperábamos, pero es más poderoso que depender de un tercero centralizado.

El umbral requerido para descifrar depende del esquema de MPC seleccionado, principalmente el equilibrio entre la actividad ('entrega garantizada de resultados') y la seguridad. Puede optar por un esquema N/N muy seguro, pero si un Nodo está desconectado, fallará. Por otro lado, los esquemas N/2 o N/3 son más robustos, pero con un mayor riesgo de conspiración.

Las dos condiciones que deben equilibrarse son:

1. La información confidencial nunca se revelará (por ejemplo, descifrar Llave secreta)
2. La información confidencial nunca desaparecerá (incluso si 1/3 de los participantes se van de repente).

El plan seleccionado variará según la implementación. Por ejemplo, el objetivo de Zama es N/3, mientras que Arcium actualmente está implementando el plan N/N, pero más adelante también admitirá planes con garantías de actividad más altas (y suposiciones de confianza más grandes).

En este punto medio, una solución de compromiso es adoptar un enfoque mixto:

• Comité de Alta Confianza se maneja con un umbral de N/3, como el tratamiento de la Llave secreta.
• La * Comisión de Cálculo * es rotativa, por ejemplo, hay un umbral de N-1 (o varias comisiones de cálculo diferentes con características diferentes para que los usuarios elijan).

Aunque esto es teóricamente atractivo, también introduce complejidades adicionales, como la interacción entre el comité de cálculo y el comité de alta confianza.

Otra forma de fortalecer la seguridad es ejecutar MPC en hardware de confianza para almacenar y compartir la Llave secreta en un área segura. Esto hace que sea más difícil extraer o utilizar la Llave secreta compartida para cualquier operación que no sea la definida por el protocolo. Al menos Zama y Arcium están explorando desde la perspectiva del TEE.

Los riesgos más sutiles incluyen situaciones marginales como la ingeniería social, por ejemplo, todas las empresas en el clúster de MPC emplean a un ingeniero senior durante más de 10 a 15 años.

2. ¿Es la tecnología lo suficientemente madura? Si no lo es, ¿cuál es el obstáculo?

Desde el punto de vista del rendimiento, el desafío clave que enfrenta MPC es el gasto de comunicación. Aumenta con la complejidad de los cálculos y el aumento de Nodo en la red (requiere más comunicación de ida y vuelta). Para el caso de uso de la cadena Bloquear, esto tendrá dos impactos prácticos:

1. Pequeño conjunto de operadores: Para controlar los gastos de comunicación, la mayoría de los protocolos existentes actualmente están limitados a un pequeño conjunto de operadores. Por ejemplo, la red de descifrado de Zama actualmente solo permite un máximo de 4 Nodo (aunque planean expandirse a 16). Según el Indicador de referencia inicial publicado por Zama para su red de descifrado (TKMS), incluso con un clúster de solo 4 Nodo, el descifrado lleva de 0.5 a 1 segundos (el proceso completo de extremo a extremo lleva más tiempo). Otro ejemplo es el MPC implementado por Taceo para la base de datos de iris de Worldcoin, que involucra a 3 partes (suponiendo que 2/3 son partes honestas).

Fuente de información: Discurso de Zama en ETH CC 2. 3. Conjunto de operadores con licencia: En la mayoría de los casos, el conjunto de operadores está licenciado. Esto significa que confiamos en la reputación y los contratos legales en lugar de la seguridad económica o de encriptación. El principal desafío de un conjunto de operadores sin licencia es que no se puede saber si las personas están conspirando fuera de la cadena. Además, se requiere la guía o redistribución periódica de las partes clave para que los nodos puedan entrar y salir dinámicamente de la red. Aunque el conjunto de operadores sin licencia es el objetivo final y se está investigando cómo ampliar el mecanismo de PoS para lograr MPC de umbral (como Zama), la ruta con licencia parece ser la mejor dirección a seguir en este momento.

Métodos alternativos

La combinación completa de privacidad incluye:

• FHE se utiliza para la computación de privacidad delegada
• ZKP se utiliza para verificar si los cálculos de FHE se ejecutan correctamente
• MPC para descifrado de umbral
• Cada MPC Nodo se ejecuta dentro de TEE para mejorar la seguridad

Esto es muy complicado, implica muchos casos extremos no explorados, tiene un gran costo y puede que no se pueda implementar en la práctica durante muchos años. Otro riesgo es que las personas puedan tener una falsa sensación de seguridad al superponer varios conceptos complejos. Cuanto más complejidad y suposiciones de confianza agreguemos, más difícil será inferir la seguridad de la solución global.

¿Vale la pena? Quizás sí, pero también vale la pena explorar otras opciones que podrían proporcionar una eficiencia de cálculo significativamente mejor, aunque con una leve disminución en la privacidad garantizada. Como señaló Lyron de Seismic, debemos enfocarnos en soluciones más simples que cumplan con nuestros estándares de privacidad necesarios y compromisos aceptables, en lugar de sobre diseñar solo por el bien de ello.

1. Realizar cálculos generales utilizando MPC

Si tanto ZK como FHE finalmente regresan a la suposición de confianza de MPC, ¿por qué no usar directamente MPC para los cálculos? Esta es una pregunta razonable, y también es lo que equipos como Arcium, SodaLabs (Coti v2), Taceo y Nillion están intentando hacer. Tenga en cuenta que MPC tiene varias formas, pero entre los tres métodos principales, aquí nos referimos al protocolo basado en intercambio secreto y circuitos garbled (GC), en lugar del protocolo basado en FHE para descifrar con MPC.

Aunque MPC se ha utilizado para la firma distribuida y cálculos simples más seguros, el principal desafío de utilizar MPC para cálculos más generales es el costo de comunicación (que aumenta con la complejidad del cálculo y el número de Nodos involucrados).

Hay algunas formas de Soltar gastos, como el preprocesamiento fuera de línea anticipado (es decir, la parte más costosa del protocolo) - Arcium y SodaLabs están explorando esto. Luego, realizar cálculos en línea, que consumirá algunos datos generados en la etapa fuera de línea. Esto reduce considerablemente el gasto total de comunicación.

La siguiente tabla de SodaLabs muestra cuánto tiempo se necesita inicialmente en microsegundos para ejecutar 1,000 veces diferentes Código de operación en su gcEVM, Indicador de referencia*. Aunque es un paso en la dirección correcta, todavía hay mucho trabajo por hacer para mejorar la eficiencia y ampliar el conjunto de operadores más allá de varios Nodos.

Fuente: SodaLabs

La ventaja de los métodos basados en ZK es que solo utiliza MPC para casos de uso que requieren cálculos en un estado privado compartido. La competencia entre FHE y MPC es más directa y depende en gran medida de la aceleración del hardware.

2. Entorno de ejecución confiable

Recientemente, ha resurgido el interés por TEE. Puede ser utilizado de forma independiente (como una cadena de bloques privada basada en TEE o un coprocesador), o combinado con otros PET, como soluciones basadas en ZK (solo para cálculos que comparten estados privados utilizando TEE).

Aunque TEE es más maduro en algunos aspectos y tiene menos costos de rendimiento introducidos, no está exento de desventajas. En primer lugar, TEE tiene suposiciones de confianza diferentes (1/N) y ofrece soluciones basadas en hardware en lugar de software. Una crítica común es en torno a las vulnerabilidades pasadas de SGX, pero es importante tener en cuenta que TEE ≠ Intel SGX. TEE también requiere confiar en los proveedores de hardware, que son costosos (la mayoría de las personas no pueden permitírselo). Una solución para mitigar el riesgo de ataques físicos puede ser ejecutar TEE en el espacio para manejar tareas críticas.

En general, TEE parece más adecuado para la prueba o casos de uso de privacidad a corto plazo (descifrado de umbral, libros de contabilidad oscuros, etc.). Parece que no es muy atractivo para la privacidad permanente o a largo plazo.

3. Métodos de protección de la privacidad basados en DAC privados y otros que dependen de terceros confiables

El intermediario puede proporcionar privacidad para evitar que otros usuarios accedan, pero la garantía de privacidad proviene completamente de la confianza en terceros (punto único de falla). Aunque es similar a la “privacidad web2” (para evitar la privacidad de otros usuarios), puede fortalecerse con garantías adicionales (encriptación o económicas) y permitir la verificación de la ejecución correcta.

El Comité de accesibilidad de datos privados (DAC) es un ejemplo; Los miembros del DAC almacenan datos fuera de la cadena, confiando en ellos para almacenar y actualizar correctamente los datos y ejecutar transiciones de estado. Otra forma es el secuenciador con licencia propuesto por Tom Walpo.

Aunque este enfoque hace grandes concesiones en términos de privacidad, puede ser la única alternativa viable para aplicaciones de bajo valor y alto rendimiento en términos de coste y rendimiento (al menos por ahora). Por ejemplo, Lens Protocol planea utilizar DAC privados para lograr un flujo de información privada. En el caso de casos de uso como la interacción social en la cadena, el equilibrio entre privacidad y coste/rendimiento puede ser razonable en la actualidad (considerando el coste y la carga de las alternativas).

4. Ocultar DIRECCIÓN

La DIRECCIÓN de ocultamiento puede proporcionar un nivel similar de privacidad a la creación de una nueva DIRECCIÓN para cada transacción, pero este proceso se realiza automáticamente en el backend y no se revela al usuario. Para obtener más información, consulte este resumen de Vitalik o este artículo que explora diferentes métodos. Los principales actores en este campo incluyen Umbra y Fluidkey.

Aunque DIRECCIÓN proporciona una solución relativamente simple, su principal desventaja es que solo puede agregar garantías de privacidad a las transacciones (pagos y transferencias), no a los cálculos generales. Esto los diferencia de las otras tres soluciones mencionadas anteriormente.

Además, la privacidad que ofrece la dirección oculta DIRECCIÓN no es tan fuerte como otras soluciones alternativas. El anonimato puede ser desglosado mediante un simple análisis de clustering, especialmente cuando las transferencias entrantes y salientes no están dentro de un rango similar (por ejemplo, se recibe 10,000 dólares pero el gasto promedio diario es de 10-100 dólares). Otro desafío de la dirección oculta DIRECCIÓN es actualizar la llave secreta, lo que ahora debe hacerse para cada billetera individualmente (el almacenamiento de llaves secretas agregadas puede ayudar a resolver este problema). Desde la perspectiva de la experiencia del usuario, si la cuenta no tiene Token de cuota (como ETH), el protocolo de dirección oculta DIRECCIÓN también requiere una abstracción de cuenta o un pagador para pagar la cuota.

Los riesgos que enfrenta nuestro argumento

Dado el rápido ritmo de desarrollo y la general incertidumbre sobre las diferentes soluciones tecnológicas, creemos que existe cierto riesgo en argumentar que MPC será la solución final. Es posible que finalmente no necesitemos algún tipo de MPC, principalmente debido a:

1. Compartir estados privados no es tan importante como imaginamos: en este caso, la infraestructura basada en ZK es más probable que triunfe que FHE, ya que tiene garantías de privacidad más sólidas y menores costos que FHE. Ya hay algunos casos de uso que indican que los sistemas basados en ZK funcionan bien en casos de uso aislados, como el protocolo de pago privado Payy.
2. El compromiso de rendimiento no vale la pena el beneficio de la privacidad: Algunos pueden argumentar que la suposición de confianza de una red MPC con 2-3 partes autorizadas no difiere mucho de un único participante centralizado, y el aumento significativo de costos/gastos no lo justifica. Para muchas aplicaciones, especialmente las de bajo valor y sensibles al costo (como las sociales o de juegos), esto puede ser cierto. Sin embargo, hay muchos casos de uso de alto valor en los que la colaboración es actualmente muy costosa (o imposible) debido a problemas legales o fricciones de coordinación. Aquí es donde brillan las soluciones de MPC y FHE.
3. La especialización es mejor que el diseño general: construir una nueva cadena y guiar a la comunidad de usuarios y desarrolladores puede ser muy difícil. Por lo tanto, puede resultar difícil obtener una infraestructura general de privacidad (L1/L2). Otro problema está relacionado con la especialización; es difícil que un diseño de protocolo único cubra todo el espacio de equilibrio. En este mundo, las soluciones que proporcionan privacidad para los ecosistemas existentes (confidencialidad como servicio) o casos de uso específicos (como los pagos) tendrán la ventaja. Sin embargo, somos escépticos con respecto a este último, ya que agrega complejidad para los desarrolladores de aplicaciones, quienes necesitan implementar tecnologías de encriptación por sí mismos (en lugar de abstraerlas).
4. La regulación continúa obstaculizando las pruebas de soluciones de privacidad: para cualquiera que construya infraestructura de privacidad y aplicaciones con ciertas protecciones de privacidad, esto es un riesgo. Los casos de uso no financieros enfrentan un menor riesgo regulatorio, pero es difícil (si no imposible) controlar lo que se construye encima de la infraestructura de privacidad no autorizada. Es probable que resolvamos los problemas técnicos antes de resolver los problemas regulatorios.
5. Para la mayoría de los casos de uso, los costos de las soluciones basadas en MPC y FHE siguen siendo demasiado altos: aunque el MPC está principalmente afectado por los costos de comunicación, el equipo de FHE depende en gran medida de la aceleración de hardware para mejorar su rendimiento. Sin embargo, si podemos inferir el desarrollo de hardware especializado en el aspecto ZK, el tiempo necesario antes de que obtengamos hardware FHE disponible para producción será mucho más largo de lo que la mayoría de la gente imagina. Los equipos dedicados a la aceleración de hardware FHE incluyen Optalysys, fhela y Niobium.

Resumen

*En última instancia, la fuerza de una cadena depende de su eslabón más débil. En el caso de la infraestructura de privacidad programable, si queremos que pueda manejar un estado privado compartido sin tener puntos únicos de falla, entonces la garantía de confianza se reduce a la garantía de MPC.

Aunque este artículo puede sonar crítico con respecto al MPC, en realidad no lo es. El MPC ha mejorado enormemente la situación actual que depende en gran medida de terceros centralizados. Creemos que el problema principal es la falsa confianza que impera en toda la industria, y que este problema ha sido encubierto. En lugar de eso, debemos enfrentar el problema y centrarnos en evaluar los riesgos potenciales.

Sin embargo, no todos los problemas requieren la misma herramienta para resolverlos. Aunque consideramos que el MPC es el objetivo final, mientras el costo de las soluciones impulsadas por MPC siga siendo alto, también existen otras opciones viables. Siempre vale la pena considerar qué método es el más adecuado para las necesidades/características específicas del problema que estamos tratando de resolver, así como qué compensaciones estamos dispuestos a hacer.

Incluso si tienes el mejor martillo del mundo, no todo es un clavo.