TEE, MPC, FHE y ZKP no son competidores. Son amigos. Las discusiones a menudo comparan esta tecnología para determinar cuál es superior. En realidad, estas tecnologías no son mutuamente excluyentes y pueden funcionar juntas y complementarse entre sí. 1. Cada solución tiene compensaciones, pero no están relacionadas > MPC no tiene un único punto de fallo, sino que requiere un intenso intercambio de datos Un protocolo MPC normalmente se desarrolla en tres etapas. 1. Los usuarios comparten en secreto sus entradas privadas, enviando datos cifrados a los nodos informáticos, garantizando la seguridad a través de la no colusión o un modelo de umbral completo (todos los nodos deben coludirse). 2. Los nodos calculan estos recursos compartidos secretos. 3. Los nodos devuelven sus partes de la salida a los usuarios, quienes reconstruyen el resultado. MPC funciona mejor con nodos bien conectados, pero su costo proviene del intenso intercambio de datos entre ellos, por lo que nos enfrentamos principalmente a problemas de comunicación. En muchos protocolos MPC estándar, cada nodo se comunica con todos los demás nodos para operaciones como puertas de multiplicación. Esto da como resultado una complejidad de comunicación cuadrática O(n²). ¿Qué significa? • Por ejemplo, con 10 nodos y una complejidad computacional de 1 KB, el intercambio de datos es de aproximadamente 100 GB. • Con 100 nodos, alcanza unos 10 TB. El intercambio de datos de MPC limita las aplicaciones prácticas a 2-10 nodos debido a la sobrecarga de comunicación. Entonces, a diferencia de blockchain, un MPC rápido con cientos de nodos aún no es factible. > FHE requiere menos datos, pero más recursos de cómputo FHE aborda un desafío de larga data: ¿cómo permitir la computación segura en datos cifrados sin necesidad de descifrado? Un usuario puede cifrar sus datos confidenciales, cargarlos en un servidor y el servidor puede ejecutar cálculos en este texto cifrado (mensaje cifrado). La salida resultante, aún cifrada, puede ser descifrada por el usuario utilizando su clave privada, a diferencia del cifrado de extremo a extremo (E2EE) tradicional, donde el cálculo de datos cifrados no es factible. FHE utiliza menos transferencia de datos que MPC, pero requiere significativamente más computación del lado del servidor. Esto hace que FHE sea generalmente más lento que MPC, excepto en situaciones con redes extremadamente lentas o una infraestructura informática muy potente. • Una simple consulta a la base de datos que tarda milisegundos sin cifrar puede extenderse de 2 a 10 segundos con FHE • La inferencia de IA con FHE tarda segundos o minutos en comparación con los milisegundos de las operaciones no cifradas > ZK no se trata de cálculos generales y tiene un problema de privacidad Si bien todas estas tecnologías permiten cálculos privados, los ZKP generan específicamente pruebas con resultados "verdaderos" o "falsos" (booleanos). Como la mayoría de la gente sabe, los ZKP se utilizan ampliamente en los zk-rollups, que son pruebas sucintas con un tamaño pequeño, fijo y una verificación rápida, ideales para su uso en cadena. Sin embargo, los zk-rollups utilizan la solidez y la concisión de, pero no su propiedad zk. Si bien los ZKP garantizan que una prueba falsa no pueda parecer válida (solidez) y que cualquiera pueda verificar una prueba, surge un problema de privacidad en los zk-rollups. La entidad que ejecuta el circuito zk tiene acceso completo a los datos de entrada durante el cálculo, es decir, a los datos confidenciales visibles para el probador. Esto compromete la privacidad de las entradas privadas de los usuarios. > TEE es barato y rápido, pero también vulnerable a los ataques de canal lateral A diferencia de otras tecnologías de privacidad, los TEE se basan en hardware específico, como el SGX de Intel. El modelo de seguridad de los TEE es menos transparente que otros métodos, y se han identificado vulnerabilidades en varias implementaciones de TEE. 2. Diferentes compensaciones: diferentes formas de complementarlas Cada tecnología sufre de diferentes problemas y también tiene diferentes pros, por lo que decir que una tecnología es mucho mejor que otra sin dar ningún contexto es ciertamente incorrecto. Cada opción no puede funcionar mejor en ciertas situaciones que otras opciones y viceversa. Por poner un ejemplo: • El problema de la colusión no se relaciona de ninguna manera con la ETE, porque solo hay un entorno aislado donde la colusión es imposible • Los ZKP no pueden relacionarse de ninguna manera con MPC o FHE en términos de cálculos, porque la tecnología ZK solo está relacionada con la generación de pruebas booleanas • La principal suposición de confianza de TEE es que el hardware está siendo hackeado, mientras que el principal problema con el hardware en FHE es que tiene que ser lo suficientemente rápido y eficiente • Estamos hablando del mismo tema (hardware), pero hay puntos absolutamente polares en los que pensar Siguiendo esta lógica, decidí profundizar en esto y ver dónde las diferentes tecnologías pueden complementarse entre sí y ofrecer una mejor solución. 3. Sinergias y roles complementarios Tomemos TEE como una cierta base y veamos cómo pueden funcionar las diferentes combinaciones y cómo podemos solucionar los problemas en esas opciones. > TEE + MPC Problema: Los TEE dependen de claves basadas en hardware para la privacidad, lo que crea problemas con la portabilidad de los datos y la posible censura. Solución: MPC puede resolver esto reemplazando las llaves de hardware y sirviendo como un servicio de administración de claves para TEE. Las soluciones MPC pueden ejecutar cálculos dentro de los TEE para garantizar que las operaciones de cada parte estén aisladas y seguras, lo que las hace aún más seguras, y ya hay varios protocolos que lo hacen. • Si lo miramos desde el otro lado del revés y vemos cómo TEE puede beneficiarse de MPC, es replicando entornos aislados, haciéndolos más distribuidos • En lugar de confiar en un TEE para que se encargue de todo, MPC distribuye la responsabilidad entre varios TEE • TEE puede distribuir la confianza a través de múltiples enclaves seguros y reducir la dependencia de una sola instancia de TEE. • Cada enclave contribuye a la computación sin necesidad de confiar plenamente en los demás debido a las garantías criptográficas de MPC. > TEE + FHE Los problemas con TEE (ataques de canal lateral) y FHE (enormes recursos de cómputo) son diferentes, al igual que las técnicas que aportan. Ejecutar código en un entorno aislado no es lo mismo que tener tecnología para ejecutar cálculos en datos descifrados. Aquí, TEE parece una sobrecarga, porque el código puro se ejecuta en una máquina aislada y requiere descifrado, mientras que FHE permite a los desarrolladores ejecutar cálculos en datos ya cifrados. Si bien puede ser cierto en cierta medida que TEE es una sobrecarga tecnológica, el uso de FHE tiene otra sobrecarga de recursos computacionales realmente altos. Aproximadamente, cuando se usa TEE, hay una sobrecarga del 5%, mientras que cuando se usa FHE, la sobrecarga es de alrededor de 1,000,000x. Si bien puede parecer que los TEE y FHE podrían crear una sobrecarga entre sí, estoy explorando el uso de TEE para administrar de forma segura las claves de descifrado o manejar tareas intensivas en rendimiento con las que FHE lucha. Si lo miramos desde otra manera, FHE puede permitir que TEE procese datos cifrados directamente mientras TEE administra las claves. > TEE + ZK También hay un ejemplo de lo eficiente que es el uso de TEE y ZK utilizando TEE para la demostración de zkVM. Problema: externalizar la prueba de zkVM a cualquier otro dispositivo es problemático, porque la privacidad se pone en riesgo ya que el probador normalmente necesita acceso a las entradas. Solución: Si ejecutamos zkVM dentro de un TEE, el cálculo se produce dentro de un enclave seguro y evita que el host acceda a los datos. El TEE proporciona una certificación de que la prueba se generó correctamente. Por ejemplo, @PhalaNetwork utiliza GPU habilitadas para TEE para ejecutar SP1 zkVM, logrando menos del 20% de sobrecarga para cargas de trabajo complejas como zkEVM. 4. Phala como Fundación TEE Phala construye la nube descentralizada de TEE en criptografía, por lo que cualquiera puede aprovechar TEE y usarla para sus fines, incluidos los equipos cuya oferta principal de productos es MPC, FHE o ZK. Quería aprender más y explorar los equipos que están usando Phala para estos fines. > Phala + MPC @0xfairblock realiza computación confidencial para mitigar los riesgos centralizados y evitar la fuga y manipulación de información en las aplicaciones, donde su tecnología principal es MPC. Sin embargo, aún pueden beneficiarse de los TEE: • El enclave TEE de Phala genera claves privadas, que luego se cifran con umbrales y se dividen en recursos compartidos para su almacenamiento en el MPC de Fairblock • Los contratos inteligentes monitorean las operaciones de TEE al requerir el envío regular de claves cifradas y, básicamente, actúan como un mecanismo de detección de fallas. • Si TEE falla, los contratos inteligentes activan el MPC de Fairblock para reconstruir y descifrar de forma privada las claves para mantener la confidencialidad de las acciones. En este contexto, las claves permanecen cifradas dentro de los TEE en todo momento, y MPC garantiza que ninguna parte pueda acceder a la clave completa. Los mecanismos de recuperación automatizados protegen contra la pérdida de datos debido a bloqueos o reinicios del sistema. > Phala + zkTLS Hay muchos protocolos zk que usan Phala, pero quiero destacar @primus_labs, porque su oferta principal gira en torno a zkTLS. Ya hice un artículo completo sobre zkTLS, pero lo más importante que debe saber es que en zkTLS, el certificador sirve como validador para analizar los flujos de datos cifrados para verificar su autenticidad. Dificultad: reducir la confianza en la confiabilidad del cliente. • Usando Dstack de Phala, los certificadores en Primus pueden ejecutar las certificaciones dentro de un TEE para asegurarse de que cada ZKP esté respaldado por la certificación emitida dentro de un TEE. • En ese caso, cualquiera puede verificar la prueba utilizando un explorador de atestación. TEE mantiene la latencia baja y no conlleva ninguna sobrecarga de tiempo. > Phala + FHE @sporedotfun utiliza tanto FHE en el lado @mindnetwork_xyz como TEE en el lado de Phala. En el sistema de staking para votar de Spore, los atacantes pueden apostar tokens antes de los plazos para engañar a los votantes, y luego dejar de apostar y distorsionar los resultados y los mercados. Dificultad: lograr un equilibrio entre la transparencia y la seguridad para garantizar que las decisiones de gobernanza se alineen con las intenciones a largo plazo de los contribuyentes. • Para contrarrestar el francotirador de votos, Spore adopta FHE a través de Mind Network y permite el voto ciego que protege la privacidad de los votantes. • FHE mantiene los votos encriptados para eliminar la posibilidad de que los francotiradores voten maliciosamente. • TEE proporciona un entorno de confianza cero para la agregación y publicación de votos antes de la publicación final. 5. Las posibilidades son infinitas, pero vale la pena considerar los riesgos y la sobrecarga de rendimiento Como dije antes, hay muchos casos de uso posibles con la base TEE, por lo que las posibilidades son infinitas. La consideración principal es la siguiente: • La industria está experimentando actualmente una creciente demanda de cálculos complejos, impulsados principalmente por la IA • La rápida expansión del sector de la IA aumenta los requisitos de rendimiento. • A medida que aumentan las demandas de rendimiento, debemos considerar no solo el rendimiento y las características de seguridad de tecnologías específicas, sino también sus costos. Para proporcionar estimaciones aproximadas de los gastos generales de rendimiento utilizando cifras aproximadas, se indican las siguientes proyecciones: • TEE: 5% por encima de la cabeza • MPC: 100 veces más de sobrecarga • ZK: 1.000 veces más gastos generales • FHE: 1.000.000 veces los gastos generales Como podemos ver, TEE introduce muy poca sobrecarga en cualquier sistema y es básicamente el entorno más eficaz y rentable para cálculos complejos como la inferencia de IA. En los sistemas actuales, y aún más en los sistemas futuros, los desarrolladores deben considerar TEE como una de las partes del diseño final del sistema, incluso si la oferta principal no gira en torno a los TEE. TEE no solo mitiga las compensaciones individuales de MPC, FHE o ZK, sino que también abre muchas posibilidades para desarrolladores y usuarios.