Guía para desarrolladores orientada a TEE

Autor: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Compilación: Shew, GodRealmX

Desde que Apple anunció el lanzamiento de la nube privada y NVIDIA ofrece cálculos confidenciales en las GPU, el entorno de ejecución confiable (TEE) se ha vuelto cada vez más popular. Su garantía de confidencialidad ayuda a proteger los datos del usuario (que pueden incluir claves privadas), mientras que su aislamiento asegura que la ejecución de los programas desplegados en él no sea alterada, ya sea por humanos, otros programas o sistemas operativos. Por lo tanto, no es sorprendente que se utilice ampliamente TEE en la construcción de productos en el campo de Crypto x AI.

Como cualquier nueva tecnología, TEE está experimentando un período experimental optimista. Este artículo tiene como objetivo proporcionar una guía conceptual básica para desarrolladores y lectores en general, para que comprendan qué es TEE, el modelo de seguridad de TEE, vulnerabilidades comunes y las mejores prácticas de seguridad para utilizar TEE de manera óptima. (Nota: Para facilitar la comprensión del texto, hemos sustituido deliberadamente los términos de TEE por palabras equivalentes más simples).

¿Qué es TEE

TEE es un entorno de aislamiento en procesadores o centros de datos donde los programas pueden ejecutarse sin interferencias del resto del sistema. Para evitar interferencias en el TEE por parte de otras partes del sistema, se requiere una serie de diseños, que incluyen principalmente un estricto control de acceso para controlar el acceso de otras partes del sistema a los programas y datos dentro del TEE. Actualmente, el TEE está presente en teléfonos móviles, servidores, PC y entornos en la nube, por lo que es muy accesible y tiene un precio razonable.

El contenido anterior puede sonar vago y abstracto, de hecho, la implementación de TEE varía entre diferentes servidores y proveedores de nube, pero su propósito fundamental es evitar la interferencia de otros programas en TEE.

La mayoría de los lectores probablemente utilizarán información de reconocimiento biológico para ingresar a sus dispositivos, como desbloquear un teléfono con huella digital. Pero, ¿cómo podemos asegurarnos de que las aplicaciones maliciosas, sitios web o sistemas operativos de jailbreak no puedan acceder y robar esta información de reconocimiento biológico? De hecho, aparte de cifrar los datos, los circuitos en los dispositivos TEE simplemente no permiten que ningún programa acceda al área de memoria y procesador ocupada por los datos sensibles.

La cartera de hardware es otro ejemplo de un escenario de aplicación de TEE. La cartera de hardware se conecta a la computadora y se comunica con ella en un entorno seguro, pero la computadora no puede acceder directamente a la frase mnemotécnica almacenada en la cartera de hardware. En ambos casos anteriores, los usuarios confían en que el fabricante del dispositivo pueda diseñar correctamente el chip y proporcionar actualizaciones de firmware adecuadas para evitar la exportación o visualización de datos confidenciales dentro del TEE.

Modelo de seguridad

Lamentablemente, hay muchos tipos de implementaciones de TEE, y estas diferentes implementaciones (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) requieren modelos de seguridad independientes para ser analizados. En el resto de este artículo, nos centraremos principalmente en IntelSGX, TDX y AWSNitro, ya que estos sistemas TEE son los más utilizados y cuentan con herramientas de desarrollo completas disponibles. Estos sistemas mencionados también son los más comunes en Web3.

En general, el flujo de trabajo de las aplicaciones desplegadas en TEE es el siguiente:

1. Los desarrolladores han escrito algunos códigos, que pueden ser de código abierto o no
2. Luego, el desarrollador empaqueta el código en un archivo de imagen de enclave (EIF) que puede ejecutarse en TEE.
3. EIF se aloja en un servidor con sistema TEE. En algunos casos, los desarrolladores pueden usar una computadora personal con TEE para alojar EIF y proporcionar servicios externos.
4. Los usuarios pueden interactuar con la aplicación a través de una interfaz predefinida.

Obviamente, hay 3 riesgos potenciales aquí:

• Desarrolladores: ¿Cuál es el propósito de preparar el código EIF? El código EIF puede no cumplir con la lógica empresarial promocionada por el proyecto y podría comprometer los datos de privacidad del usuario.
• Servidor: ¿El servidor TEE está ejecutando el archivo EIF como se esperaba? ¿O el EIF realmente se está ejecutando dentro de TEE? El servidor también puede estar ejecutando otros programas dentro de TEE
• Proveedor: ¿Es seguro el diseño de TEE? ¿Hay alguna puerta trasera que pueda filtrar todos los datos dentro de TEE al proveedor?

Afortunadamente, ahora TEE tiene un plan para eliminar los riesgos anteriores, es decir, construcciones reproducibles(Reproducible Builds) y atestaciones remotas(Remote Atteststations).

Entonces, ¿qué es la construcción repetible? El desarrollo de software moderno a menudo requiere la importación de una gran cantidad de dependencias, como herramientas externas, bibliotecas o marcos, entre otros. Estos archivos de dependencias también pueden tener riesgos potenciales. Ahora, soluciones como npm utilizan el hash del código correspondiente al archivo de dependencias como identificador único. Cuando npm detecta que un archivo de dependencias no coincide con el valor hash registrado, se considera que dicho archivo de dependencias ha sido modificado.

La construcción repetible puede considerarse como un conjunto de estándares cuyo objetivo es obtener un valor hash consistente siempre que se construya cualquier código en cualquier dispositivo siguiendo un proceso predefinido. Por supuesto, también podemos utilizar productos distintos de los valores hash como identificadores en la práctica, a los que llamamos medición de código (code measurement).

Nix es una herramienta común para compilaciones repetibles. Cuando se expone el código fuente del programa, cualquiera puede inspeccionar el código para asegurarse de que el desarrollador no ha insertado nada inusual, y cualquiera puede compilar el código usando Nix para verificar si el producto compilado tiene las mismas métricas/hash de código que el producto implementado por el equipo del proyecto en producción. Pero, ¿cómo conocemos las métricas de código para un programa en el TEE? Esto nos lleva al concepto llamado “prueba remota”. **

Remote Attestation es un mensaje de firma del Trusted Execution Environment (TEE) que incluye valores métricos de código de programa, la versión de la plataforma TEE, etc. La atestación remota permite a los observadores externos saber que un programa se está ejecutando en un lugar seguro al que nadie más puede acceder (un TEE REALM real de la versión xx).

La capacidad de construcción repetible y la prueba remota permiten que cualquier usuario conozca el código real que se ejecuta dentro de TEE y la información de la versión de la plataforma TEE, evitando así que los desarrolladores o servidores actúen de manera maliciosa.

Sin embargo, en el caso de TEE, siempre es necesario confiar en su proveedor. Si el proveedor de TEE actúa de forma maliciosa, puede falsificar directamente pruebas remotas. Por lo tanto, si se considera al proveedor como un posible medio de ataque, se debe evitar depender únicamente de TEE y es mejor combinarlos con ZK o protocolos de consenso.

El encanto de TEE

En nuestra opinión, las características especialmente populares de TEE, especialmente la amigabilidad para implementar AI Agent, se deben principalmente a los siguientes puntos:

• Rendimiento: TEE puede ejecutar el modelo LLM con un rendimiento y costo similares a los servidores normales. Por otro lado, zkML requiere una gran cantidad de potencia de cálculo para generar pruebas zk para LLM.
• Soporte de GPU: NVIDIA ofrece soporte de cálculo de TEE en sus últimas series de GPU (Hopper, Blackwell, etc.)
• Corrección : LLMs son no deterministas; ingresar la misma palabra clave varias veces dará resultados diferentes. Por lo tanto, varios nodos (incluidos los observadores que intentan crear pruebas de fraude) pueden nunca llegar a un consenso sobre el resultado de LLM. En este escenario, podemos confiar en que LLM en funcionamiento en TEE no puede ser manipulado por actores malintencionados, el programa dentro de TEE siempre se ejecuta como se escribió, lo que hace que TEE sea más adecuado que opML o consenso para garantizar la confiabilidad de los resultados de razonamiento de LLM
• Confidencialidad: Los datos en TEE no son visibles para los programas externos. Por lo tanto, las claves privadas generadas o recibidas en TEE siempre son seguras. Esta característica se puede utilizar para asegurar a los usuarios que cualquier mensaje firmado con esta clave proviene de un programa interno de TEE. Los usuarios pueden confiar en TEE para alojar las claves privadas y establecer algunas condiciones de firma, y pueden confirmar que la firma de TEE cumple con las condiciones de firma preestablecidas
• Conexión a Internet: a través de algunas herramientas, los programas que se ejecutan en TEE pueden acceder de forma segura a Internet (sin revelar consultas o respuestas al servidor que ejecuta TEE, al mismo tiempo que garantizan la correcta recuperación de datos para terceros). Esto es muy útil para la recuperación de información de API de terceros, y puede utilizarse para subcontratar cálculos a proveedores de modelos confiables pero propietarios.
• Permiso de escritura: A diferencia del esquema zk, el código que se ejecuta en TEE puede construir mensajes (ya sea tweets o transacciones) y enviarlos a través de la red API y RPC.
• Amigable para los desarrolladores: los marcos y SDK relacionados con TEE permiten a las personas escribir código en cualquier idioma y desplegar fácilmente programas en TEE como en servidores en la nube

Ya sea bueno o malo, actualmente es difícil encontrar alternativas para muchos casos de uso de TEE. Creemos que la introducción de TEE expande aún más el espacio de desarrollo de aplicaciones en cadena, lo que podría impulsar la aparición de nuevos escenarios de aplicación.

TEE no es una bala de plata

Los programas que se ejecutan en TEE siguen siendo susceptibles a una serie de ataques y errores. Al igual que los contratos inteligentes, son propensos a una serie de problemas. Para mayor simplicidad, clasificaremos las posibles vulnerabilidades de la siguiente manera:

• Desarrollador descuidado
• Vulnerabilidad en tiempo de ejecución
• Defectos en el diseño de la arquitectura
• Problemas de operación

Descuido del desarrollador

Ya sea intencional o no, los desarrolladores pueden debilitar la garantía de seguridad del programa en TEE a través de código intencional o no intencional. Esto incluye:

• Código opaco: El modelo de seguridad de TEE depende de la verificabilidad externa. La transparencia del código es crucial para la verificación de terceros externos.
• Problema de métricas de código: Incluso si el código es público, si no hay un tercero que reconstruya el código y verifique los valores de métricas de código en la prueba remota, y luego realice la verificación en función de las métricas de código proporcionadas en la prueba remota. Esto es similar a recibir una prueba zk pero no verificarla.
• Código inseguro: incluso si genera y gestiona cuidadosamente las claves correctamente en TEE, la lógica incluida en el código podría filtrar las claves dentro de TEE durante el proceso de llamada externa. Además, el código podría contener puertas traseras o vulnerabilidades. En comparación con el desarrollo tradicional del lado del servidor, requiere que el proceso de desarrollo y auditoría de software cumpla con altos estándares, similar al desarrollo de contratos inteligentes.
• Ataque a la cadena de suministro: El desarrollo de software moderno utiliza una gran cantidad de código de terceros. Los ataques a la cadena de suministro representan una gran amenaza para la integridad de TEE.

Vulnerabilidad en tiempo de ejecución

Los desarrolladores, incluso con extrema precaución, pueden convertirse en víctimas de vulnerabilidades en tiempo de ejecución. Los desarrolladores deben considerar cuidadosamente si alguno de los siguientes aspectos podría afectar la seguridad de su proyecto:

• Código dinámico: es posible que no siempre se pueda mantener todo el código transparente. A veces, el caso de uso en sí mismo requiere la ejecución dinámica de código no transparente cargado en TEE durante el tiempo de ejecución. Este tipo de código es fácil de divulgar información confidencial o romper invariantes, por lo que debe tenerse mucho cuidado para evitar esta situación.
• Datos dinámicos: La mayoría de las aplicaciones utilizan API externas y otras fuentes de datos durante la ejecución. El modelo de seguridad se extiende para incluir estas fuentes de datos que se encuentran en la misma posición que los oráculos en DeFi, datos incorrectos o desactualizados pueden causar desastres. Por ejemplo, en el caso de uso del Agente de IA, una dependencia excesiva en servicios LLM como Claude.
• Comunicaciones inseguras e inestables: TEE requiere ser ejecutado dentro de un servidor que contiene componentes de TEE. Desde un punto de vista de seguridad, el servidor que ejecuta TEE actúa como un intermediario perfecto (MitM) entre TEE y las interacciones externas. El servidor no solo puede espiar las conexiones externas de TEE y ver el contenido que se está enviando, sino que también puede examinar IP específicas, restringir conexiones e inyectar paquetes de datos en las conexiones, con el objetivo de engañar a una de las partes haciéndole creer que provienen de xx.

Por ejemplo, en TEE se puede ejecutar un motor de emparejamiento de transacciones encriptadas, el cual no puede proporcionar una garantía de ordenación justa (anti-MEV) ya que los enrutadores/puertas de enlace/anfitriones todavía pueden descartar, retrasar o dar prioridad a los paquetes de datos según la dirección IP de origen.

Defecto de arquitectura

La pila tecnológica utilizada por las aplicaciones TEE debe ser tratada con precaución. Al construir aplicaciones TEE, pueden surgir los siguientes problemas:

• Aplicaciones con una superficie de ataque más grande: La superficie de ataque de una aplicación se refiere a la cantidad de módulos de código que deben ser completamente seguros. El código con una superficie de ataque más grande es más difícil de auditar y puede ocultar errores o vulnerabilidades explotables. Esto suele entrar en conflicto con la experiencia de los desarrolladores. Por ejemplo, las aplicaciones de TEE que dependen de Docker tienen una superficie de ataque mucho mayor en comparación con las que no dependen de Docker. Las Enclaves que dependen de sistemas operativos maduros tienen una superficie de ataque más grande en comparación con las que utilizan sistemas operativos ligeros.**
• Portabilidad y activación: En Web3, las aplicaciones deben tener resistencia a la censura. Cualquiera puede iniciar un TEE y hacerse cargo de los participantes inactivos del sistema, lo que hace que las aplicaciones dentro del TEE sean portátiles. El mayor desafío aquí es la portabilidad de las claves. Algunos sistemas TEE tienen mecanismos de derivación de claves, pero una vez que se utiliza el mecanismo de derivación de claves dentro del TEE, otros servidores no pueden generar claves de programas TEE externos localmente, lo que hace que los programas TEE generalmente estén limitados a la misma máquina, lo que no es suficiente para mantener la portabilidad.
• Raíz de confianza no segura：Por ejemplo, al ejecutar un Agente de IA en TEE, ¿cómo se verifica si una dirección dada pertenece a ese Agente? Si no se diseña cuidadosamente en este punto, la raíz de confianza real podría ser un tercero externo o una plataforma de custodia de claves, en lugar de TEE en sí mismo.

Problemas operativos

Por último, pero no menos importante, también hay algunos puntos prácticos sobre cómo ejecutar realmente un servidor que ejecute un programa TEE:

• Versiones de plataforma inseguras: Ocasionalmente, la plataforma TEE recibe actualizaciones de seguridad, las cuales se reflejan como versiones de plataforma en el atestador remoto. Si su TEE no se está ejecutando en una versión segura de la plataforma, los hackers pueden aprovechar medios de ataque conocidos para robar claves de su TEE. Lo peor de todo es que su TEE puede estar funcionando en una versión segura de la plataforma hoy, pero podría ser insegura mañana.
• Sin seguridad física: Aunque haga todo lo posible, TEE puede ser vulnerable a ataques de canal lateral, que generalmente requieren acceso físico y control del servidor en el que se encuentra TEE. Por lo tanto, la seguridad física es una capa de defensa profunda importante. Un concepto relacionado es la prueba en la nube, donde puede demostrar que TEE se está ejecutando en un centro de datos en la nube con garantías de seguridad física.

Construyendo programas TEE seguros

Dividiremos nuestras recomendaciones en los siguientes puntos:

• La solución más segura
• Medidas preventivas necesarias tomadas
• Recomendaciones basadas en casos de uso

1. La solución más segura: sin dependencias externas

La creación de aplicaciones altamente seguras puede implicar la eliminación de dependencias externas, como entradas externas, API o servicios, para reducir la superficie de ataque. Este enfoque garantiza que la aplicación funcione de forma independiente, sin interacciones externas que puedan comprometer su integridad o seguridad. Aunque esta estrategia puede limitar la diversidad de funciones del programa, puede ofrecer un alto nivel de seguridad.

Si el modelo se ejecuta localmente, se puede lograr este nivel de seguridad para la mayoría de los casos de uso de CryptoxAI.

2. Medidas preventivas necesarias tomadas

¡Ya sea que la aplicación tenga dependencias externas o no, el siguiente contenido es obligatorio!

Considerar las aplicaciones de TEE como contratos inteligentes en lugar de aplicaciones de backend; mantener una frecuencia de actualización baja y realizar pruebas rigurosas.

La construcción de programas TEE debe ser tan estricta como escribir, probar y actualizar contratos inteligentes. Al igual que los contratos inteligentes, TEE se ejecuta en un entorno altamente sensible e inmutable, donde los errores o comportamientos inesperados pueden tener consecuencias graves, incluida la pérdida total de fondos. Una auditoría exhaustiva, pruebas extensas y actualizaciones mínimas y cuidadosamente auditadas son fundamentales para garantizar la integridad y confiabilidad de las aplicaciones basadas en TEE.

Auditar el código y revisar el canal de construcción

La seguridad de una aplicación no solo depende del código en sí, sino también de las herramientas utilizadas durante el proceso de construcción. Un canal de construcción seguro es crucial para prevenir vulnerabilidades. TEE solo garantiza que el código proporcionado se ejecutará según lo esperado, pero no puede solucionar defectos introducidos durante el proceso de construcción.

Para reducir el riesgo, es necesario realizar pruebas y auditorías estrictas del código para eliminar errores y prevenir filtraciones de información innecesarias. Además, la construcción repetible desempeña un papel crucial, especialmente cuando el código es desarrollado por una parte y utilizado por otra. La construcción repetible permite a cualquier persona verificar si el programa ejecutado dentro del TEE coincide con el código fuente original, garantizando así transparencia y confianza. Sin una construcción repetible, es casi imposible determinar el contenido exacto del programa ejecutado dentro del TEE, lo que pone en peligro la seguridad de la aplicación.

Por ejemplo, el código fuente de DeepWorm (el proyecto que ejecuta un modelo de simulación de cerebro de gusano en TEE) es completamente abierto. El programa en ejecución en TEE se construye de manera reproducible utilizando el canal Nix.

Utilizar bibliotecas auditadas o verificadas

Cuando se manejan datos sensibles en programas de TEE, solo se deben utilizar bibliotecas auditadas para la gestión de claves y el procesamiento de datos privados. El uso de bibliotecas no auditadas puede exponer las claves y comprometer la seguridad de la aplicación. Es prioritario considerar dependencias revisadas exhaustivamente y centradas en la seguridad para mantener la confidencialidad e integridad de los datos.

Verificación constante de la prueba proveniente de TEE

Los usuarios que interactúan con TEE deben verificar las pruebas remotas o mecanismos de verificación generados por TEE para garantizar una interacción segura y confiable. Sin estas verificaciones, el servidor podría manipular las respuestas, lo que dificultaría distinguir entre la salida real de TEE y los datos manipulados. Las pruebas remotas proporcionan pruebas clave sobre las bibliotecas de código y la configuración que se ejecutan en TEE, lo que nos permite determinar si los programas ejecutados en TEE son consistentes con lo esperado en función de las pruebas remotas.

La prueba concreta puede ser verificada en la cadena (IntelSGX, AWSNitro), utilizando pruebas de conocimiento cero (IntelSGX, AWSNitro) para verificación fuera de la cadena, o verificada por el usuario mismo o un servicio de alojamiento (como t16z o MarlinHub).

3. Sugerencias basadas en casos de uso

Según el caso de uso y la estructura de la aplicación, los siguientes consejos pueden ayudar a que su aplicación sea más segura.

Asegúrese de que la interacción entre el usuario y TEE se realice siempre en un canal seguro

El servidor en el que se encuentra TEE es esencialmente no confiable. El servidor puede interceptar y modificar la comunicación. En algunos casos, puede ser aceptable que el servidor lea los datos pero no los cambie, mientras que en otros casos, incluso la lectura de los datos puede ser inaceptable. Para reducir estos riesgos, es crucial establecer un canal de cifrado de extremo a extremo seguro entre el usuario y TEE. Al menos, asegúrese de que los mensajes contengan una firma para verificar su autenticidad y origen. Además, el usuario siempre debe verificar la prueba remota proporcionada por TEE para verificar que está en comunicación con el TEE correcto. Esto garantiza la integridad y confidencialidad de la comunicación.

Por ejemplo, Oyster puede admitir emisiones seguras de TLS mediante el uso de registros CAA y RFC8657. Además, proporciona un protocolo TLS nativo llamado Scallop, que no depende de WebPKI.

Saber que la memoria TEE es transitoria

La memoria TEE es transitoria, lo que significa que cuando se cierra TEE, su contenido (incluidas las claves de cifrado) se perderá. Sin un mecanismo seguro para guardar esta información, los datos críticos podrían quedar permanentemente inaccesibles, lo que podría poner en peligro los fondos o la operación.

Una red de cálculo multipartito (MPC) con sistemas de almacenamiento descentralizado como IPFS puede servir como solución a este problema. La red MPC divide la clave en múltiples nodos para garantizar que ningún nodo individual posea la clave completa, al mismo tiempo que permite a la red reconstruir la clave cuando sea necesario. Los datos encriptados con esta clave pueden almacenarse de forma segura en IPFS.

Si es necesario, la red MPC puede proporcionar claves a nuevos servidores TEE que ejecuten la misma imagen, siempre que se cumplan ciertas condiciones. Este método garantiza la elasticidad y una seguridad sólida, lo que permite que los datos sean accesibles y confidenciales incluso en entornos no confiables.

Todavía hay otra solución, es decir, TEE entrega las transacciones correspondientes a diferentes servidores de MPC, los servidores de MPC firman y luego agregan las firmas para finalmente llevar las transacciones a la cadena. Este método es mucho menos flexible y no se puede utilizar para almacenar claves API, contraseñas o cualquier dato arbitrario (sin un servicio de almacenamiento de terceros de confianza).

Reducir la superficie de ataque

Para casos de uso críticos de seguridad, vale la pena sacrificar la experiencia del desarrollador para intentar reducir al mínimo las dependencias periféricas. Por ejemplo, Dstack viene con un kernel mínimo basado en Yocto que solo incluye los módulos necesarios para que Dstack funcione. Incluso puede valer la pena utilizar tecnologías antiguas como SGX (más allá de TDX), ya que esta tecnología no requiere que el gestor de arranque o el sistema operativo formen parte de un entorno de ejecución en confianza (TEE).

Aislamiento físico

Al aislar físicamente la TEE de posibles intervenciones humanas, se puede mejorar aún más la seguridad de la TEE. Si bien podemos confiar en que los centros de datos pueden proporcionar seguridad física al alojar servidores TEE en ellos y en proveedores de servicios en la nube, proyectos como Spacecoin están explorando una alternativa bastante interesante: el espacio. El documento de SpaceTEE se basa en medidas de seguridad, como la medición del momento de inercia después del lanzamiento, para verificar si los satélites se desvían de lo esperado durante su entrada en órbita.

Multi Proof

Al igual que Ethereum depende de varias implementaciones de clientes para reducir el riesgo de errores que afecten a toda la red, multiprovers utiliza diferentes esquemas de implementación de TEE para mejorar la seguridad y la flexibilidad. Al ejecutar los mismos pasos de cálculo en múltiples plataformas de TEE, la verificación múltiple asegura que las vulnerabilidades en una implementación de TEE no pongan en peligro toda la aplicación. Aunque este enfoque requiere que el flujo de cálculo sea determinista, o que se defina un consenso entre las diferentes implementaciones de TEE en casos de no determinismo, también ofrece ventajas significativas como el aislamiento de fallos, la redundancia y la verificación cruzada, lo que lo convierte en una buena opción para aplicaciones que requieren garantías de fiabilidad.

Mirando hacia el futuro

El TEE claramente se ha convertido en un campo muy emocionante. Como se mencionó anteriormente, la ubicuidad de la IA y su acceso continuo a los datos sensibles del usuario significa que grandes empresas de tecnología como Apple y NVIDIA están utilizando TEE en sus productos y lo están ofreciendo como parte de sus productos.

Por otro lado, la comunidad criptográfica siempre ha prestado mucha atención a la seguridad. A medida que los desarrolladores intentan ampliar las aplicaciones y casos de uso en la cadena, hemos visto que la TEE se ha vuelto popular como una solución que ofrece un equilibrio correcto entre la funcionalidad y la suposición de confianza. Aunque la TEE no es tan minimalista en la confianza como una solución ZK completa, esperamos que la TEE se convierta en el camino para la fusión gradual de las empresas Web3 y los productos de grandes empresas de tecnología.