¿Todos los caminos conducen a MPC?Explore el final de la infraestructura de privacidad

Autor: EQ Labs Fuente: Traducción de equilibrio: Shan Oppa, Bittain Vision

La Parte 1 de nuestra serie de privacidad cubre lo que significa «privacidad», cómo la privacidad en una red blockchain difiere de la privacidad de Web2 y por qué la privacidad es difícil de lograr en blockchain.

El punto principal de este artículo es que si el estado final ideal es tener una infraestructura de privacidad programable que pueda manejar el estado privado compartido sin ningún punto de falla, entonces todas las carreteras conducen a MPC.También exploraremos la madurez de MPC y sus supuestos de confianza, enfatizaremos los enfoques alternativos, compararán las compensaciones y proporcionaremos una visión general de la industria.

Deshágase de los grilletes del pasado y dan la bienvenida al futuro

La infraestructura de privacidad existente en blockchain está diseñada para manejar casos de uso muy específicos, como pagos privados o votación.Esta es una visión bastante estrecha, que refleja principalmente el propósito actual de blockchain (transacciones, transferencias y especulaciones).Como dijo Tom Walpo: las criptomonedas sufren de paradoja de Fermi:

Además de aumentar la libertad personal, creemos que la privacidad es un requisito previo para expandir el espacio de diseño de blockchain más allá de los metadatos especulativos actuales.Muchas aplicaciones requieren algún estado privado y/o lógica oculta para funcionar correctamente:

• Esconder el estado: La gran mayoría de los casos de uso financiero requieren (al menos) mantenerse confidenciales para otros usuarios, y sin algún estado oculto, muchos juegos multijugador serán significativamente menos divertidos (por ejemplo, si todos en la mesa de póker pueden ver las cartas de los demás).

• Ocultar la lógica: Algunos casos de uso requieren que se oculte alguna lógica al tiempo que permiten que otros usen la aplicación, como motores de coincidencia, estrategias comerciales en cadena, etc.

El análisis empírico (de Web2 y Web3) muestra que la mayoría de los usuarios son reacios a pagar tarifas adicionales o omitir enlaces adicionales para aumentar la privacidad, y también estamos de acuerdo en que la privacidad en sí no es un punto de venta.Sin embargo, sí permite que existan casos de uso nuevos y (con suerte) más significativos por encima de la cadena de bloques: descartemos de la paradoja de Fermi.

Tecnología de mejora de la privacidad (PET) y soluciones modernas de contraseña(«Contraseña programable«)Es el componente básico de la construcción para realizar esta visión.(Para obtener más información sobre las diferentes soluciones disponibles y sus compensaciones, verapéndice).

Tres suposiciones que influyen en nuestra visión

Tres supuestos clave determinan nuestra opinión sobre cómo se desarrolla la infraestructura de privacidad de blockchain:

1. La tecnología de cifrado se abstrae de las manos de los desarrolladores de aplicaciones: la mayoría de los desarrolladores de aplicaciones no quieren (o no saben cómo tratar) la tecnología de cifrado que necesitan para manejar la privacidad.Espero que implementen su propia tecnología de cifrado y creen cadenas privadas específicas de aplicaciones(Por ejemploZcashoNamada) o en la cadena pública(por ejemplo, tornado efectivo)Una aplicación privada anterior no es razonable.Esto es demasiado complejo y sobrecarga, y actualmente limita el espacio de diseño de la mayoría de los desarrolladores (no puede construir aplicaciones que requieran cierta garantía de privacidad).Por lo tanto, creemos que la complejidad de administrar la parte de cifrado debe abstraerse de las manos de los desarrolladores de aplicaciones.Los dos métodos aquí son la infraestructura de privacidad programable (L1/L2 privado compartido) o«Confidencial como servicio», este último permite la externalización de cálculos confidenciales.

2. Muchos casos de uso (probablemente más de lo que pensamos) requieren compartir un estado privado: como se mencionó anteriormente, muchas aplicaciones requieren algún estado y/o lógica ocultos para funcionar correctamente.El estado privado compartido es un subconjunto de ellos, en el que varias partes calculan el mismo estado privado.Si bien podemos confiar en una parte centralizada para hacer esto por nosotros y parar allí, idealmente queremos hacerlo con una minimización de confianza para evitar un solo punto de falla.Esto no es posible solo con la prueba de conocimiento cero (ZKP): necesitamos aprovechar otras herramientas, como el entorno de ejecución de confianza (TEE), el cifrado totalmente homomórfico (FHE) y/o la computación múltiple (MPC).

3. Conjuntos bloqueados más grandes Maximizan la privacidad: la mayor parte de la información se filtra al ingresar o salir de conjuntos bloqueados, por lo que debemos minimizar esto.La creación de múltiples aplicaciones privadas en la misma cadena de bloques puede ayudar a fortalecer la privacidad al aumentar el número de usuarios y transacciones dentro del mismo conjunto bloqueado.

El fin de la infraestructura de privacidad

Teniendo en cuenta los supuestos anteriores, ¿cuál es el objetivo final de la infraestructura de privacidad de blockchain?¿Hay alguna forma de adaptarse a todas las aplicaciones?¿Existe una tecnología de mejora de la privacidad que pueda dominar todas las aplicaciones?

No exactamente.Todas estas tienen diferentes compensaciones y las hemos visto unirse de varias maneras.En general, hemos identificado 11 enfoques diferentes.

Actualmente, las dos formas más populares de construir infraestructura de privacidad en blockchain son aprovechar ZKP o FHE.Sin embargo, ambos tienen defectos fundamentales:

• Un protocolo de privacidad basado en ZK y con la prueba del cliente puede proporcionar fuertes garantías de privacidad, pero no permite que varias partes calculen el mismo estado privado.Esto limita el poder expresivo, es decir, qué tipos de aplicaciones puede construir un desarrollador.

• El FHE admite informes de datos cifrados y estado privado compartido, pero ¿a quién lo hizo?tenerEl problema con este estado es quién posee la clave de descifrado.Esto limita la fuerza de la protección de la privacidad y la medida en que podemos creer que la privacidad de hoy seguirá siendo mañana.

Si el estado final ideal es tener una infraestructura de privacidad programable, se puede manejar el estado privado compartidoSin ningún punto de falla, entonces, ambas rutas pueden conducir a MPC:

Tenga en cuenta que aunque estos dos métodos eventualmente tenderán a mezclarse, MPC usa de manera diferente:

• Red ZKP: MPC aumenta la capacidad de expresión al implementar el cálculo del estado privado compartido.

• FHE Red: MPC mejora la seguridad y fortalece la privacidad al distribuir claves de descifrado al comité MPC (en lugar de un único tercero).

Si bien la discusión comenzó a convertirse en un punto de vista más matizado, las garantías detrás de estos diferentes enfoques aún no se aplicaban.Dado que nuestra hipótesis de confianza se reduce a la hipótesis de MPC, tres preguntas clave que deben hacerse son:

1. ¿Qué tan fuerte es la garantía de privacidad que el protocolo MPC puede proporcionar en blockchain?

2. ¿La tecnología es lo suficientemente madura?Si no es suficiente, ¿cuál es el cuello de botella?

3. ¿Tiene sentido en comparación con otros métodos considerando la fuerza de la garantía y su sobrecarga?

Respondamos estas preguntas con más detalle.

Use MPC para analizar riesgos y debilidades

Cada vez que la solución usa FHE, las personas siempre necesitan preguntar: «¿Quién tiene la clave de descifrado?».Si la respuesta es «red», entonces la pregunta posterior es: «¿Qué entidades reales constituyen esta red?».La última pregunta está relacionada con todos los casos de uso que dependen de MPC de alguna forma.

Fuente:El discurso de Zama en ETH CC

El riesgo principal de MPC es la colusión, es decir, hay suficientes partes involucradas en coludir maliciosamente para descifrar datos o cálculos mal apropiados.La colusión se puede acordar fuera de la cadena y solo se revelará si el partido malicioso toma una acción obvia (ransformación, tokens acuñado fuera de la nada, etc.).No hace falta decir que esto tiene un impacto significativo en las garantías de privacidad que el sistema puede proporcionar.El riesgo de colusión depende de:

• ¿Cuántas partes maliciosas pueden llevar este acuerdo?

• ¿Cuáles son las redes?¿Qué tan creíbles son?

• El número de partes diferentes involucradas en la red y su distribución: ¿hay vectores de ataque comunes?

• ¿La red es libre de licencia o es necesaria (intereses económicos y reputación/base legal)?

• ¿Cuáles son los castigos por el comportamiento malicioso?¿Es teóricamente el juego de colusión el resultado óptimo?

1. ¿Qué tan fuerte es la garantía de privacidad que el protocolo MPC puede proporcionar en blockchain?

TLDR: No tan poderoso como esperábamos, pero más fuerte que confiar en un tercero centralizado.

El umbral requerido para el descifrado depende del esquema MPC seleccionado, en gran medida del nivel de actividad(«Entrega de salida garantizada»)y compensaciones de seguridad.Puede tomar un esquema N/N muy seguro, pero se bloqueará mientras haya un nodo fuera de línea.Por otro lado, el esquema N/2 o N/3 es más robusto, pero el riesgo de conspiración es mayor.

Dos condiciones que deben ser equilibradas son:

1. La información secreta nunca se filtra (como las claves de descifrado)

2. La información secreta nunca desaparece (incluso si 1/3 de los participantes de repente se van).

El esquema seleccionado varía mediante la implementación.Por ejemplo, Zama tiene como objetivo ser N/3, mientras que Arcium actualmente está implementando un esquema N/N, pero también respaldará un esquema con una mayor garantía de actividad (y mayores supuestos de confianza) más adelante.

En esta compensación, una solución de compromiso es adoptar una solución híbrida:

• Comité de confianzaEl procesamiento clave se realiza con, por ejemplo, el umbral de N/3.

• Comité de cálculoes rotacional, por ejemplo, con un umbral N-1 (o múltiples comités informáticos diferentes con diferentes características para que los usuarios los elijan).

Si bien esto es teóricamente atractivo, también presenta una complejidad adicional, como cómo el comité de computación interactúa con el comité de alta confianza.

Otra forma de fortalecer la seguridad es ejecutar MPC en hardware de confianza para mantener el intercambio de llaves en un área segura.Esto hace que sea más difícil extraer o usar el intercambio de clave para cualquier operación que no sean definiciones de protocolo.Al menos Zama y Arcium están explorando el ángulo de tee.

Los riesgos más sutiles incluyen casos de borde como la ingeniería social, donde, por ejemplo, todas las empresas en un clúster de MPC han contratado a un ingeniero senior durante más de 10 a 15 años.

2. ¿La tecnología es lo suficientemente madura?Si no eres lo suficientemente maduro, ¿cuál es el cuello de botella?

Desde una perspectiva de rendimiento, el desafío clave que enfrenta MPCS es la sobrecarga de comunicación.Crece con la complejidad de la computación y el número de nodos en la red (necesita más comunicación de ida y vuelta).Para los casos de uso de blockchain, esto tiene dos implicaciones prácticas:

1. Conjuntos de operadores pequeños: para hacer que la comunicación se pueda controlar la sobrecarga, la mayoría de los protocolos existentes se limitan actualmente a pequeños conjuntos de operadores.Por ejemplo, la red descifrada de Zama actualmente permite hasta 4 nodos (aunque planean escalar a 16).De acuerdo con el punto de referencia inicial publicado por Zama para su red de descifrado (TKMS), incluso si un clúster con solo 4 nodos es de solo 0.5-1 segundo (el proceso E2E completo lleva más tiempo).Otro ejemplo es el MPC implementado por Taceo para la base de datos de Iris de Worldcoin, que tiene 3 partes (suponiendo 2/3 partes honestas).

   Fuente:El discurso de Zama en ETH CC

2. 

3. Conjuntos de operadores con licencia: en la mayoría de los casos, los conjuntos de operadores tienen licencia.Esto significa que dependemos de la reputación y los contratos legales, no económicos o criptográficos.El principal desafío con un conjunto de operadores sin permisos es la incapacidad de saber si las personas coluden fuera de la cadena.Además, requiere arrancamiento periódico o reasignar acciones clave para que los nodos puedan ingresar/salir dinámicamente la red.Si bien el conjunto de operadores sin permiso es el objetivo final y cómo se extiende el mecanismo POS para lograr MPC umbral (por ejemplo, Zama), la ruta del permiso parece ser el mejor camino a seguir en este momento.

Método alternativo

Una cartera de privacidad integral incluye:

• Se utiliza para delegar los cálculos de privacidad

• ZKP se usa para verificar que el cálculo de la FHE se ejecute correctamente

• MPC para el descifrado de umbral

• Cada nodo MPC se ejecuta dentro de la TEE para obtener una seguridad mejorada

Esto es complejo, introduciendo muchos extremos inexplorados, con muchos gastos generales y puede no ser práctico durante muchos años.Otro riesgo es que las personas pueden tener una falsa sensación de seguridad al superponer múltiples conceptos complejos juntos.Cuanto más complejidad y suposiciones de confianza agregamos, más difícil será inferir la seguridad de la solución general.

¿Vale la pena?Tal vez valga la pena, pero también vale la pena explorar otros métodos que pueden conducir a una eficiencia informática significativamente mejor, mientras que las garantías de privacidad solo serán un poco más débiles.Como señala Lyron de Seísmico: debemos centrarnos en las soluciones más simples para cumplir con nuestros criterios para el nivel de privacidad y las compensaciones aceptables necesarias, en lugar de diseñar demasiado solo por ello.

1. Use directamente MPC para cálculos generales

Si tanto ZK como FHE finalmente regresan a la suposición de confianza del MPC, ¿por qué no usar directamente MPC para los cálculos?Esta es una pregunta razonable, y es algo que equipos como Arcium, Sodalabs (utilizado por Coti V2), Taceo y Nillion están tratando de hacer.Tenga en cuenta que MPC viene en muchas formas, pero entre los tres métodos principales, nos referimos aquí a base deIntercambio secretoyCircuito de basura (GC)en lugar de un protocolo basado en FHE que utiliza MPC para el descifrado.

Si bien MPC se ha utilizado para cálculos simples, como firmas distribuidas y billeteras más seguras, el principal desafío en la computación más general con MPC es la sobrecarga de comunicación (aumentar con la complejidad del cálculo y el número de nodos involucrados).

Hay formas de reducir la sobrecarga, como el preprocesamiento fuera de línea por adelantado (es decir, la parte más cara del protocolo), tanto el arco como los sodalabs están explorando esto.El cálculo se realiza luego en la fase en línea, que consume algunos datos generados en la fase fuera de línea.Esto reduce en gran medida la sobrecarga de comunicación general.

La siguiente tabla para Sodalabs muestra cuánto tiempo lleva ejecutar diferentes códigos de operación 1,000 veces en su GCEVM(en microsegundos).Si bien este es un paso en la dirección correcta, todavía hay mucho trabajo por hacer para mejorar la eficiencia y extender el conjunto de operadores más allá de unos pocos nodos.

Fuente: Sodalabs

El beneficio del enfoque basado en ZK es que solo usa MPC para casos de uso que requieren cálculos en un estado privado compartido.El FHE compite más directamente con MPC y depende en gran medida de la aceleración de hardware.

2. Entorno de ejecución de confianza

Recientemente, el interés en Tee ha reavivado, que puede usarse solo (una cadena de bloques privada o coprocesador basado en TEE) o en combinación con otras mascotas como las soluciones basadas en ZK (usando solo Tee).

Si bien las camisetas son más maduras de alguna manera e introducen menos gastos generales de rendimiento, no están exentos de sus inconvenientes.Primero, TEE tiene diferentes supuestos de confianza (1/n) y proporciona soluciones basadas en hardware en lugar de software.Las críticas que las personas a menudo escuchan son vulnerabilidades en torno al pasado de SGX, pero vale la pena señalar que Tee ≠ Intel SGX.Tee también necesita confiar en los proveedores de hardware, que son caros (que la mayoría de las personas no pueden pagar).Una solución al riesgo de ataques físicos podría ser ejecutar camisetas en el espacio para manejar misiones críticas.

En general, la TEE parece ser más adecuada para pruebas o casos de uso que solo requieren privacidad a corto plazo (descifrado de umbral, libro mayor de disco oscuro, etc.).La seguridad parece menos atractiva para la privacidad permanente o a largo plazo.

3. DAC privado y otras formas de confiar en terceros de confianza para proteger la privacidad

La privacidad intermedia puede proporcionar privacidad para evitar el acceso a otros usuarios, pero las garantías de privacidad provienen completamente de confianza en terceros (punto único de falla).Si bien es similar a la «privacidad de Web2» (evitando la privacidad de otros usuarios), se puede fortalecer con garantías adicionales (cifrado o económica) y permite que la verificación se realice correctamente.

Un ejemplo es el Comité de Disponibilidad de Datos Privados (DAC);Otra forma es el secuenciador con licencia propuesto por Tom Walpo.

Si bien este enfoque hace una gran compensación en términos de garantía de privacidad, puede ser la única alternativa viable (al menos por ahora) en términos de costo y rendimiento.Por ejemplo, el protocolo de lente planea usar DAC privados para implementar el flujo de información privada.Para casos de uso como Social en la cadena, la compensación entre privacidad y costo/desempeño puede ser razonable en este momento (considerando el costo y la sobrecarga de alternativas).

4. Dirección invisible

Una dirección invisible puede proporcionar una garantía de privacidad similar a la creación de una nueva dirección para cada transacción, pero el proceso se realiza automáticamente en el backend y no se divulga al usuario.Para obtener más información, consulte esta descripción general de Vitalik o este artículo que profundiza en diferentes enfoques.Los principales actores en este campo incluyen Umbra y Fluidkey.

Si bien las direcciones invisibles proporcionan una solución relativamente simple, el principal inconveniente es que solo agregan garantías de privacidad a las transacciones (pagos y transferencias) y no a la informática general.Esto los hace diferentes de las otras tres soluciones mencionadas anteriormente.

Además, las garantías de privacidad proporcionadas por las direcciones invisibles no son tan poderosas como otras alternativas.El anonimato se puede romper con un análisis de agrupación simple, especialmente cuando las transferencias entrantes y salientes no están dentro de un rango similar (por ejemplo, se reciben $ 10,000, pero la transacción diaria promedio cuesta $ 10-100).Otro desafío con direcciones invisibles es actualizar las claves, que ahora requieren actualizaciones individuales para cada billetera (el resumen de almacenamiento de clave puede ayudar a resolver este problema).Desde la perspectiva de la experiencia del usuario, si la cuenta no tiene tokens de tarifa (como ETH), el protocolo de dirección invisible también requiere que la abstracción o el pagador pague la tarifa.

Riesgos para nuestro argumento

Dado el rápido ritmo de desarrollo y la incertidumbre general de las diferentes soluciones tecnológicas, creemos que existen algunos riesgos en el argumento de que MPC será la solución final.Es posible que no terminemos necesitando alguna forma de MPC, las razones principales incluyen:

1. El estado privado compartido no es tan importante como pensamos: en este caso, es más probable que la infraestructura basada en ZK gane porque tiene garantías de privacidad más fuertes y una sobrecarga más baja que la FHE.Ya hay algunos casos de uso que muestran que los sistemas basados ​​en ZK funcionan bien en casos de uso huérfano, como el Protocolo de pago privado Payy.

2. Las compensaciones de rendimiento no son dignas de los beneficios de la protección de la privacidad: se podría decir que la suposición de confianza de una red MPC con 2-3 licenciantes no es muy diferente de un solo jugador centralizado, y que no vale la pena un aumento significativo en el costo/gasto de alto nivel él.Esto puede ser cierto para muchas aplicaciones, especialmente aplicaciones de bajo valor y sensibles a los costos (como sociales o juegos).Sin embargo, también 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 fricción de coordinación.Este último es donde pueden brillar las soluciones basadas en MPC y FHE.

3. Especialización Beats Diseño general: construir nuevas cadenas y guiar a la comunidad de usuarios y desarrolladores es muy difícil.Por lo tanto, la infraestructura de privacidad universal (L1/L2) puede ser difícil para llamar la atención.Otro problema implica la especialización;En este mundo, prevalecerán las soluciones que brindan privacidad para los ecosistemas existentes (confidencialidad como servicio) o casos de uso dedicados (como el pago).Sin embargo, somos escépticos de este último porque aporta complejidad a los desarrolladores de aplicaciones que necesitan implementar algunas técnicas de cifrado ellos mismos (en lugar de abstraerlos).

4. La regulación continúa obstaculizando los ensayos de soluciones de privacidad: este es un riesgo para cualquier persona que construya una infraestructura de privacidad y aplicaciones con ciertas garantías de privacidad.Los casos de uso no financiero enfrentan menos riesgos regulatorios, pero es difícil (imposible) controlar lo que se basa en una infraestructura de privacidad sin licencia.Es probable que abordemos problemas técnicos antes de resolver problemas regulatorios.

5. Para la mayoría de los casos de uso, la sobrecarga de soluciones basadas en MPC y FHE sigue siendo demasiado alta: mientras que los MPC se ven afectados principalmente por la sobrecarga de comunicación, el equipo de FHE depende en gran medida de la aceleración de hardware para mejorar su rendimiento.Pero si podemos inferir el desarrollo de hardware dedicado en el lado ZK, llevará mucho más tiempo de lo que la mayoría de la gente piensa antes de que tengamos hardware disponible para la producción.Los equipos dedicados a la aceleración de hardware de la FHE incluyen Optalysys, FHELA y Niobium.

Resumen

En última instancia, la fuerza de la cadena depende de su eslabón más débil.En el caso de la infraestructura de privacidad programable, siQueremos que maneje el estado privado compartido sin un único punto de falla, y luego la garantía de fideicomiso se reduce a la garantía de MPC.

Si bien esta publicación suena como una crítica de MPC, ese no es el caso.MPC ha mejorado enormemente la situación actual de depender de terceros centralizados.Creemos que el principal problema es que hay falsa confianza en toda la industria y el problema está cubierto.En cambio, debemos enfrentar el problema de frente y centrarnos en evaluar los riesgos potenciales.

Sin embargo, no todos los problemas deben resolverse utilizando las mismas herramientas.Aunque creemos que MPC es el objetivo final, otros enfoques también son opciones viables siempre que la sobrecarga de las soluciones impulsadas por MPC siga siendo alta.Siempre vale la pena considerar qué enfoque es más adecuado para las necesidades/características específicas del problema que estamos tratando de resolver y qué compensaciones estamos dispuestos a hacer.

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