Parte 1 de nuestra serie de privacidad cubrió lo que implica la "privacidad", cómo la privacidad en las redes blockchain difiere de la privacidad web2, y por qué es difícil de lograr en las blockchains.

El argumento principal de esta publicación es que si el estado final deseable es tener una infraestructura de privacidad programable que pueda manejar un estado privado compartido sin ningún punto único de falla, entonces todos los caminos conducen a MPC. También exploramos la madurez de MPC y sus suposiciones de confianza, destacamos enfoques alternativos, comparamos compensaciones y brindamos una visión general de la industria.

¿Estamos todos construyendo lo mismo? Sigue leyendo para descubrirlo.

Gracias a Avishay (SodaLabs), Lukas ( Taceo), Michael (Equilibrio), y Nico (Arciumpara las discusiones que ayudaron a dar forma a esta publicación.

Lo que puede ser, sin verse agobiado por lo que ha sido

La infraestructura de privacidad existente en las blockchains está diseñada para manejar casos de uso muy específicos, como pagos privados o votaciones. Esta es una visión bastante limitada y refleja en su mayoría para qué se utilizan actualmente las blockchains (comercio, transferencias y especulación). As Tom Walpo lo puso- La criptomoneda sufre de una Paradoja de Fermi:

Además de aumentar la libertad individual, creemos que la privacidad es un requisito previo para expandir el espacio de diseño de las cadenas de bloques más allá de la actual meta especulativa. 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 (como mínimo) privacidad frente a otros usuarios y muchos juegos multijugador son significativamente menos divertidos de jugar sin algún estado oculto (por ejemplo, si todos en la mesa de póker pudieran ver las cartas de los demás).
• Lógica oculta: algunos casos de uso requieren ocultar cierta lógica mientras se permite que otros utilicen la aplicación, como un motor de coincidencia, una estrategia de trading en cadena, etc.

El análisis empírico (tanto de web2 como de web3) muestra que la mayoría de los usuarios no están dispuestos a pagar más o a pasar por bucles adicionales por una mayor privacidad, y estamos de acuerdo en que la privacidad no es un punto de venta en sí misma. Sin embargo, sí permite que existan nuevos y (esperemos) casos de uso más significativos en las blockchains, lo que nos permite salir del Paradoja de Fermi.

Tecnologías de mejora de privacidad (PET) y soluciones de criptografía moderna (“criptografía programable"") son los componentes fundamentales para hacer realidad esta visión (ver apéndicepara obtener más información sobre las diferentes soluciones disponibles y sus compensaciones).

Tres hipótesis que moldean nuestras opiniones

Tres hipótesis clave dan forma a nuestras opiniones sobre cómo creemos que la infraestructura de privacidad en blockchains podría evolucionar:

1. La criptografía se abstraerá de los desarrolladores de aplicaciones: la mayoría de los desarrolladores de aplicaciones no quieren (o no saben cómo) lidiar con la criptografía necesaria para la privacidad. No es razonable esperar que implementen su propia criptografía y construyan cadenas de aplicaciones privadas (por ejemplo, ZcashoNamada) o aplicaciones privadas en la parte superior de una cadena pública (por ejemplo, Tornado Cash). Esto es simplemente demasiada complejidad y sobrecarga, lo que actualmente restringe el espacio de diseño para la mayoría de los desarrolladores (no pueden crear aplicaciones que requieran algunas garantías de privacidad). Debido a esto, creemos que la complejidad de administrar la parte de criptografía debe abstraerse de los desarrolladores de aplicaciones. Dos enfoques aquí son la infraestructura de privacidad programable (una L1/L2 privada compartida) o la "confidencialidad como servicio" que permite la externalización de la computación confidencial.
2. Muchos casos de uso (probablemente más de lo que pensamos) requieren un estado privado compartido: 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 esto, en el que varias partes calculan sobre la misma parte del estado privado. Si bien podríamos confiar en que una parte centralizada lo haga por nosotros y dar por terminado el día, lo ideal es que lo hagamos de una manera que minimice la confianza para evitar puntos únicos de falla. Las pruebas de conocimiento cero (ZKP) por sí solas no pueden lograr esto: necesitamos aprovechar herramientas adicionales como entornos de ejecución confiables (TEE), cifrado totalmente homomórfico (FHE) y/o computación multipartita (MPC).
3. Los conjuntos de escudos más grandes maximizan la privacidad: la mayor parte de la información se revela cuando ingresando o saliendoel conjunto protegido, por lo que debemos tratar de minimizar eso. Tener múltiples aplicaciones privadas construidas sobre la misma cadena de bloques puede ayudar a fortalecer las garantías de privacidad al aumentar el número de usuarios y transacciones dentro del mismo conjunto protegido.

Juego final de la infraestructura de privacidad

Con las hipótesis anteriores en mente, ¿cuál es el objetivo final de la infraestructura de privacidad en las cadenas de bloques? ¿Existe un enfoque que sea adecuado para cada aplicación? ¿Una tecnología de mejora de la privacidad para gobernarlos a todos?

No del todo. Todos estos tienen diferentes compensaciones y ya estamos viendo cómo se combinan de diversas formas. En total, hemos identificado 11 enfoques diferentes (ver apéndice).

Hoy en día, los dos enfoques más populares para construir infraestructura de privacidad en blockchains aprovechan ZKPs o FHE. Sin embargo, ambos tienen fallas fundamentales:

• Los protocolos de privacidad basados en ZK con demostración del lado del cliente pueden ofrecer garantías sólidas de privacidad, pero no permiten que múltiples partes computen sobre el mismo estado privado. Esto limita la expresividad, es decir, los tipos de aplicaciones que los desarrolladores pueden construir.
• FHE permite realizar cálculos sobre datos encriptados y estados privados compartidos, pero plantea la pregunta de quién es el propietario de ese estado, es decir, quién posee la clave de desencriptación. Esto limita la fortaleza de las garantías de privacidad y cuánto podemos confiar en que lo que es privado hoy seguirá siéndolo mañana.

Si el estado final deseado es tener una infraestructura de privacidad programable que pueda manejar un estado privado compartido sin ningún punto único de falla, entonces ambos caminos conducen a MPC:

Tenga en cuenta que aunque estos dos enfoques convergen en última instancia, MPC se utiliza para cosas diferentes:

• Redes de ZKP: MPC se utiliza para agregar expresividad al permitir el cálculo sobre un estado privado compartido.
• Redes FHE: MPC se utiliza para aumentar la seguridad y fortalecer las garantías de privacidad al distribuir la clave de descifrado a un comité de MPC (en lugar de a un único tercero).

Si bien el debate está empezando a desplazarse hacia una visión más matizada, las garantías que subyacen a estos diferentes enfoques siguen siendo poco exploradas. Dado que nuestras suposiciones de confianza se reducen a las de MPC, las tres preguntas clave que hay que hacerse son:

1. ¿Qué tan fuertes son las garantías de privacidad que pueden proporcionar los protocolos MPC en las blockchains?
2. ¿La tecnología es lo suficientemente madura? Si no lo es, ¿cuáles son los cuellos de botella?
3. Dadas la fortaleza de las garantías y la sobrecarga que introduce, ¿tiene sentido en comparación con enfoques alternativos?

Abordemos estas preguntas con más detalle.

Analizando riesgos y debilidades con MPC

Cuando una solución utiliza MPC, siempre es necesario preguntar: '¿Quién posee la clave de descifrado?'. Si la respuesta es 'la red', la pregunta de seguimiento es: '¿Qué entidades reales componen esta red?'. Esta última pregunta es relevante para todos los casos de uso que dependen de MPC de alguna manera.

Fuente: Charla de Zama en ETH CC

El riesgo principal con MPC es la colusión, es decir, suficientes partes que actúan de manera maliciosa y se coluden para descifrar datos o apropiarse indebidamente de la computación. La colusión puede acordarse fuera de la cadena y solo se revela si las partes malintencionadas hacen algo obvio (chantaje, acuñación de tokens de la nada, etc.). No hace falta decir que esto tiene implicaciones significativas para las garantías de privacidad que el sistema puede proporcionar. El riesgo de colusión depende de:

• ¿Qué umbral de partes maliciosas puede resistir el protocolo?
• ¿Qué partes componen la red y qué tan confiables son?
• Número de partes diferentes que participan en la red y su distribución - ¿Hay vectores de ataque comunes?
• ¿La red es sin permiso o con permiso (apuesta económica vs basada en reputación/legal)?
• ¿Cuál es el castigo por comportamiento malicioso? ¿La colusión es el resultado teóricamente óptimo del juego?

1. ¿Qué tan sólidas son las garantías de privacidad que los protocolos MPC pueden proporcionar en las blockchains?

En resumen: No es tan fuerte como nos gustaría, pero más fuerte que depender de solo un tercero centralizado.

La cantidad umbral requerida para descifrar depende del esquema MPC elegido, en gran medida un compromiso entre la vivacidad ("entrega garantizada de resultados") y la seguridad. Puede tener un esquema N/N que es muy seguro pero falla si solo un nodo se desconecta. Por otro lado, los esquemas N/2 o N/3 son más robustos pero tienen un mayor riesgo de colusión.

Las dos condiciones a equilibrar son:

1. La información secreta nunca se filtra (por ejemplo, la clave de descifrado)
2. La información secreta nunca desaparece (incluso si un tercio de las partes se va repentinamente).

El esquema elegido varía según las implementaciones. Por ejemplo, Zama apunta a N/3, mientras que Arcium está implementando actualmente un Esquema N/Npero más adelante también se pretende admitir esquemas con garantías de mayor vigencia (y supuestos de confianza más amplios).

Un compromiso a lo largo de esta frontera de compensación sería tener una solución mixta:

• Comité de alta confianza que maneja las claves con umbral, por ejemplo, N/3.
• Comités de cálculo que son rotativos y tienen, por ejemplo, un umbral N-1 (o múltiples comités de cálculo diferentes con características distintas para que los usuarios elijan).

Si bien esto es atractivo en teoría, también introduce complejidad adicional, como la forma en que el comité de cálculo interactuaría con el comité de alta confianza.

Otra forma de fortalecer las garantías de seguridad es ejecutar el MPC en hardware confiable para que las partes clave se mantengan dentro de un enclave seguro. Esto dificulta la extracción o el uso de las partes clave para cualquier otra cosa que no esté definida por el protocolo. Al menos ZamayArciumestán explorando el ángulo de TEE.

Riesgos más sutiles incluyen casos particulares relacionados con temas como la ingeniería social, donde, por ejemplo, un ingeniero senior es contratado por todas las empresas incluidas en el grupo MPC durante 10-15 años.

2. ¿La tecnología es lo suficientemente madura? Si no, ¿cuáles son los cuellos de botella?

Desde el punto de vista del rendimiento, el desafío clave con MPC es la sobrecarga de comunicación. Esta aumenta con la complejidad de la computación y el número de nodos que forman parte de la red (se requiere más comunicación de ida y vuelta). Para los casos de uso de blockchain, esto conduce a dos implicaciones prácticas:

1. Conjunto de operadores pequeños: Para mantener la sobrecarga de comunicación bajo control, la mayoría de los protocolos existentes están actualmente restringidos a conjuntos de operadores pequeños. Por ejemplo, la red de descifrado de Zama actualmente permite un máximo de 4 nodos (aunque planean expandirse a 16). Según las pruebas iniciales publicadas por Zama para su red de descifrado (TKMS), se tarda de 0.5 a 1s en descifrar incluso con un clúster de 4 nodos (el flujo completo de extremo a extremo lleva mucho más tiempo). Otro ejemplo es Taceo's.Implementación de MPC para la base de datos de iris de Worldcoin, que tiene 3 partes (con la suposición de una parte honesta de 2/3).

1. Fuente: Charla de Zama en ETH CC
2. Conjunto de operadores con permisos: en la mayoría de los casos, el conjunto de operadores tiene permisos. Esto significa que confiamos en la reputación y los contratos legales en lugar de la seguridad económica o criptográfica. El principal desafío con un conjunto de operadores sin permisos es que no hay forma de saber si las personas se confabulan fuera de la cadena. Además, requeriría un arranque regular o una redistribución del recurso compartido de claves para que los nodos puedan entrar y salir dinámicamente de la red. Si bien los conjuntos de operadores sin permisos son el objetivo final y hay investigaciones en curso sobre cómo extender un mecanismo PoS para un MPC de umbral (por ejemplo, por Zama), la ruta con permisos parece ser la mejor manera de avanzar por ahora.

Enfoques Alternativos

El cóctel completo de privacidad consta de:

• FHE para computación privada delegada
• ZKP para verificar que el cálculo FHE se ejecutó correctamente
• MPC para descifrado de umbral
• Cada nodo MPC se ejecuta dentro de un TEE para seguridad adicional

Esto es complejo, presenta una gran cantidad de casos extremos inexplorados, tiene una gran sobrecarga y es posible que no sea factible en la práctica durante muchos años. Otro riesgo es la falsa sensación de seguridad que se puede obtener al agregar múltiples conceptos complejos uno encima del otro. Cuanta más complejidad y suposiciones de confianza agreguemos, más difícil será razonar sobre la seguridad de la solución general.

¿Vale la pena? Tal vez, pero también vale la pena explorar enfoques alternativos que podrían brindar una eficiencia computacional significativamente mejor a costa de garantías de privacidad ligeramente más débiles. Como Lyron de Seismicnotado - debemos centrarnos en la solución más sencilla que satisfaga nuestros criterios para el nivel de privacidad requerido y los compromisos aceptables, en lugar de sobreingeniería solo por el hecho de hacerlo.

1. Utilizando MPC Directamente Para Cómputo General

Si tanto ZK como FHE finalmente vuelven a las suposiciones de confianza de MPC, ¿por qué no usar MPC para la computación directamente? Esta es una pregunta válida y algo que equipos como Arcium, SodaLabs (utilizado por Cotiv2), Taceo, y NillionEstamos intentando hacer algo. Tenga en cuenta que MPC toma muchas formas, pero de los tres enfoques principales, aquí nos referimos a los protocolos basados en compartición de secretos y circuito enmascarado (GC), no a los protocolos basados en FHE que utilizan MPC para el descifrado.

Si bien MPC ya se utiliza para cálculos simples como firmas distribuidas y billeteras más seguras, el desafío principal al utilizar MPC para cálculos más generales es la sobrecarga de comunicación (que aumenta tanto con la complejidad del cálculo como con el número de nodos involucrados).

Hay algunas formas de reducir los costos generales, como hacer el preprocesamiento (es decir, las partes más caras del protocolo) de antemano y sin conexión, algo que ambosArciumySodaLabsse está explorando. La computación se ejecuta en la fase en línea, que consume parte de los datos producidos en la fase fuera de línea. Esto reduce significativamente la sobrecarga de comunicación en general.

La tabla de SodaLabs a continuación muestra resultados iniciales sobre cuánto tiempo se tarda en ejecutar diferentes opcodes 1,000 veces en su gcEVM (anotado en microsegundos). Si bien esto es un paso en la dirección correcta, queda mucho trabajo por hacer para mejorar la eficiencia y expandir 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 sobre un estado privado compartido. FHE compite más directamente con MPC y depende en gran medida de la aceleración de hardware.

2. Entornos de Ejecución Confiables

Recientemente ha habido un renovado interés en TEEs, que pueden ser aprovechados ya sea de forma aislada (blockchains privados basados en TEE o coprocesadores) o en combinación con otros PETs como soluciones basadas en ZK (usar solo TEE para cálculos sobre un estado privado compartido).

Si bien las TEEs son, de alguna manera, más maduras e introducen menos sobrecarga de rendimiento, no están exentas de inconvenientes. En primer lugar, las TEEs tienen suposiciones de confianza diferentes (1/N) y ofrecen una solución basada en hardware en lugar de software. Una crítica que se escucha con frecuencia se refiere a eventos pasados.vulnerabilidades de SGX, pero vale la pena señalar que TEE ≠ Intel SGX. También se necesita confiar en el proveedor de hardware para los TEEs y el hardware es costoso (no accesible para la mayoría). Una solución al riesgo de ataques físicos podría ser ejecutar TEEs en el espaciopara cosas críticas para la misión.

En general, las TEE parecen más adecuadas para la certificación o casos de uso que solo requieren privacidad a corto plazo (descifrado de umbral, libros de órdenes oscuros, etc). Para la privacidad permanente o a largo plazo, las garantías de seguridad parecen menos atractivas.

3. DAC privado y otros enfoques que dependen de terceros de confianza para la privacidad

La privacidad intermediada puede ofrecer privacidad frente a otros usuarios, pero las garantías de privacidad provienen únicamente de la confianza en un tercero (punto único de fallo). Si bien se asemeja a la "privacidad web2" (privacidad de otros usuarios), puede reforzarse con garantías adicionales (criptográficas o económicas) y permitir la verificación de la correcta ejecución.

Los comités de disponibilidad de datos privados (DAC) son un ejemplo de esto; Los miembros del DAC almacenan datos fuera de la cadena y los usuarios confían en ellos para almacenar correctamente los datos y hacer cumplir las actualizaciones de transición de estado. Otro ejemplo de esto es el Secuenciador Franquiciadopropuesto por Tom Walpo.

Si bien este enfoque implica grandes sacrificios en las garantías de privacidad, podría ser la única alternativa factible para aplicaciones de menor valor y alto rendimiento en términos de costo y rendimiento (al menos por ahora). Un ejemplo es Protocolo de lentes, que planea utilizar un DAC privado para lograr feeds privados. Para casos de uso como social en cadena, el equilibrio entre privacidad y coste/rendimiento probablemente sea razonable por ahora (dado el coste y la sobrecarga de las alternativas).

4. Direcciones ocultas

Las direcciones ocultas pueden proporcionar garantías de privacidad similares a las de crear una nueva dirección para cada transacción, pero el proceso se automatiza en el backend y se abstrae de los usuarios. Para obtener más información, consulta esta visión general por Vitaliko estoprofundizar en diferentes enfoquesLos principales jugadores en este campo incluyen UmbrayFluidkey.

Si bien las direcciones ocultas ofrecen una solución relativamente simple, la principal desventaja es que solo pueden agregar garantías de privacidad para transacciones (pagos y transferencias), no para la computación de propósito general. Esto las diferencia de las otras tres soluciones mencionadas anteriormente.

Además, las garantías de privacidad que proporcionan las direcciones ocultas no son tan fuertes como las alternativas. La anonimidad puede ser comprometida conanálisis de agrupamiento simple, especialmente si las transferencias entrantes y salientes no están en un rango similar (por ejemplo, recibir $10,000, pero gastar en promedio $10-100 en transacciones diarias). Otro desafío con las direcciones ocultas es la actualización de claves, que hoy en día debe hacerse individualmente para cada billetera (los rollups de almacenamiento de claves podrían ayudar con este problema). Desde el lado de la experiencia de usuario, los protocolos de direcciones ocultas también requieren abstracción de cuentas o un pagador para cubrir las tarifas si la cuenta no tiene el token de tarifa (por ejemplo, ETH).

Riesgos para nuestra tesis

Dada la rápida velocidad de desarrollo y la incertidumbre general en torno a diferentes soluciones técnicas, existen varios riesgos para nuestra tesis de que MPC sea el resultado final. Las principales razones por las que podríamos no terminar necesitando MPC de una forma o de otra son:

1. El estado privado compartido no es tan importante como pensamos: En ese caso, la infraestructura basada en ZK está mejor posicionada para ganar, ya que ofrece garantías de privacidad más sólidas y un menor sobrecosto que FHE. Ya existen casos de uso en los que los sistemas basados en ZK funcionan bien para casos de uso aislados, como el protocolo de pagos privados.Payy.
2. El intercambio en rendimiento no vale la pena el beneficio en garantías de privacidad: Se podría argumentar que los supuestos de confianza de una red MPC con 2-3 partes con permiso no son significativamente diferentes de un único jugador centralizado y que el aumento significativo en costos / overhead no lo vale. Esto puede ser cierto para muchas aplicaciones, particularmente aquellas de bajo valor y sensibles al costo (por ejemplo, sociales o de juegos). Sin embargo, también hay muchos casos de uso de alto valor donde la colaboración es actualmente muy costosa (o imposible) debido a problemas legales o a una gran fricción de coordinación. Este último es donde las soluciones basadas en MPC y FHE pueden destacar.
3. La especialización gana al diseño de propósito general: construir una nueva cadena y arrancar una comunidad de usuarios y desarrolladores es difícil. Debido a esto, la infraestructura de privacidad de uso general (L1/L2) puede tener dificultades para obtener tracción. Otra cuestión se refiere a la especialización; Es muy difícil que un solo diseño de protocolo cubra todo el espacio de compensación. En este mundo, prevalecerían las soluciones que proporcionan privacidad a los ecosistemas existentes (confidencialidad como servicio) o a los casos de uso especializados (por ejemplo, para los pagos). Sin embargo, somos escépticos sobre este último debido a la complejidad que introduce a los desarrolladores de aplicaciones que necesitarían implementar algo de criptografía ellos mismos (en lugar de abstraerla).
4. La regulación sigue obstaculizando la experimentación en torno a las soluciones de privacidad: esto representa un riesgo para cualquier persona que construya tanto infraestructuras de privacidad como aplicaciones con algunas garantías de privacidad. Los casos de uso no financieros enfrentan menos riesgo regulatorio, pero es difícil (imposible) controlar lo que se construye sobre la infraestructura de privacidad sin permisos. Es posible que resolvamos los problemas técnicos antes que los regulatorios.
5. El sobrecosto de los esquemas basados en MPC y FHE sigue siendo demasiado alto para la mayoría de los casos de uso: mientras que el MPC sufre principalmente de sobrecarga de comunicación, los equipos de FHE dependen en gran medida de la aceleración de hardware para mejorar su rendimiento. Sin embargo, si podemos extrapolar la evolución del hardware especializado en el lado de ZK, tomará mucho más tiempo del que la mayoría desearía antes de que obtengamos hardware FHE listo para producción. Ejemplos de equipos trabajando en la aceleración de hardware FHE incluyen Optalysys, Fhela, y Niobio.

Resumen

En última instancia, una cadena es tan fuerte como su eslabón más débil. En el caso de la infraestructura de privacidad programable, las garantías de confianza se reducen a las de MPC si queremos que pueda manejar un estado privado compartido sin un solo punto de fallo.

Si bien esta pieza puede sonar crítica hacia MPC, no lo es. MPC ofrece una gran mejora al estado actual de depender de terceros centralizados. El principal problema, en nuestra opinión, es la falsa sensación de confianza en toda la industria y los problemas que se barren debajo de la alfombra. En su lugar, debemos abordar los problemas directamente y enfocarnos en evaluar los posibles riesgos.

Sin embargo, no todos los problemas deben resolverse con las mismas herramientas. A pesar de que creemos que MPC es el objetivo final, los enfoques alternativos son opciones viables siempre que los gastos generales de las soluciones impulsadas por MPC sigan siendo altos. Siempre vale la pena considerar qué enfoque se adapta mejor a las necesidades/características específicas de los problemas que estamos tratando de resolver y qué compensaciones estamos dispuestos a hacer.

Aunque tengas el mejor martillo del mundo, no todo es un clavo.

Apéndice 1: Diferentes Enfoques de Privacidad en Blockchains

Tecnologías de mejora de la privacidad, o PET, tiene como objetivo mejorar uno o más aspectos de lo anterior. Más concretamente, son soluciones técnicas para proteger datos durante el almacenamiento, cálculo y comunicación.

Hay muchos PET diferentes para elegir, pero los más relevantes para la industria de la cadena de bloques incluyen la sopa de tres letras: ZKP, MPC, FHE y TEE, junto con métodos adicionales como direcciones ocultas:

Estos PET se pueden combinar de varias maneras para lograr diferentes compensaciones y suposiciones de confianza. También disponemos de soluciones que dependen de un tercero de confianza (privacidad intermediada), como los comités de disponibilidad de datos privados (DAC). Estos pueden permitir la privacidad de otros usuarios, pero las garantías de privacidad provienen únicamente de confiar en un tercero. En este sentido, se asemeja a la "privacidad web2" (privacidad de otros usuarios), pero puede reforzarse con garantías adicionales (criptográficas o económicas).

En total, hemos identificado 11 enfoques diferentes para lograr algunas garantías de privacidad en redes blockchain. Algunos de los compromisos observados incluyen:

• Privacidad confiable vs. privacidad minimizada de confianza (¿Existe un único punto de fallo?)
• Enfoque de hardware frente a software
• Casos aislados frente a la combinación de múltiples PET
• L1 vs L2
• Nueva cadena vs. Agregue privacidad a las cadenas existentes ("confidencialidad como servicio")
• Tamaño del conjunto protegido (MPC > Cadena única > Aplicación > Activo único)

Apéndice 2: Descripción general de la industria

Dentro de estas 11 categorías, muchas empresas diferentes están trabajando en una o más soluciones. A continuación se muestra una descripción general (no exhaustiva) del estado actual de la industria:

Descargo de responsabilidad:

1. Este artículo es una reimpresión de [equilibrio], Todos los derechos de autor pertenecen al autor original [Hannes Huitula]. Si hay objeciones a esta reimpresión, póngase en contacto con el Gate Aprenderel equipo y ellos se ocuparán de ello rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo 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 lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.