En octubre, el término "TEE (Entorno de Ejecución Confiable)" comenzó a aparecer con frecuencia en las publicaciones de X. Esto me sorprendió ya que TEE tradicionalmente ha sido un tema de nicho, discutido principalmente en el ámbito académico de la seguridad de sistemas. Como alguien que realizó investigaciones en un laboratorio de seguridad de sistemas, me alegró ver este desarrollo. Sin embargo, me intrigó por qué TEE estaba ganando repentinamente atención en el espacio Web3. También noté la falta de contenido accesible que explicara los conceptos de TEE al público en general, lo que me motivó a escribir este artículo.

TEE es un concepto complejo que puede ser difícil de entender completamente sin un conocimiento en ciencias de la computación. Por lo tanto, este artículo comienza con conceptos básicos de TEE, explica por qué Web3 está interesado en utilizar TEE y luego analiza los proyectos actuales de Web3 que implementan TEE y sus limitaciones.

En resumen, este artículo cubrirá los siguientes temas:

• Una introducción a los conceptos de TEE y una breve descripción general de los TEE modernos
• Varios casos de implementación de TEE dentro del ecosistema Web3
• Limitaciones de TEE y perspectivas personales sobre estas limitaciones
• El futuro de TEE en el ecosistema Web3

1. ¿Qué es TEE?

Creo que la mayoría de los lectores puede que no tengan los conocimientos necesarios para entender completamente qué es exactamente TEE. Dado que TEE es un concepto bastante complejo cuando se explora en profundidad, intentaré explicarlo de la manera más sencilla posible.

Conceptos básicos

La mayoría de los servidores Web2 gestionan el acceso a los datos a través de la configuración de autorización. Sin embargo, dado que este enfoque se basa puramente en el software, esencialmente se vuelve ineficaz si se obtienen privilegios de nivel superior. Por ejemplo, si un atacante obtiene privilegios a nivel de kernel en el sistema operativo del servidor, puede acceder potencialmente a todos los datos controlados por permisos en el servidor, incluidas las claves de cifrado. En escenarios tan extremos, prácticamente no hay forma de prevenir el robo de datos solo a través de métodos basados en software. TEE, o Trusted Execution Environment, intenta abordar fundamentalmente este problema a través de la seguridad basada en hardware. Los TEE a menudo se denominan "computación confidencial", pero este es un concepto más amplio que incluye mecanismos de computación que garantizan la privacidad de los datos del usuario, como ZK, MPC y FHE.

fuente: Jujutsu Kaisen

Para usar una analogía simple, TEE actúa como una zona cifrada dentro de la memoria. Todos los datos dentro de TEE están cifrados, lo que hace imposible el acceso de datos sin procesar desde el exterior. Incluso el núcleo del sistema operativo no puede leerlo ni modificarlo en su forma original. Por lo tanto, aunque un atacante obtenga privilegios de administrador en el servidor, no puede descifrar los datos dentro de TEE. Esta área cifrada se llama a menudo 'enclave'.

Crear un enclave y procesar datos dentro de él requiere conjuntos de instrucciones específicos, similares a los opcodes. Estas instrucciones utilizan claves de cifrado almacenadas en áreas protegidas por hardware para realizar cálculos sobre datos dentro del enclave. Dado que TEE es un módulo de seguridad a nivel de hardware, su implementación varía según el proveedor del chip de CPU. Por ejemplo, Intel admite SGX, AMD admite SEV y ARM admite TrustZone. Desde una perspectiva más amplia, estas implementaciones comparten el concepto de "proteger la memoria mediante cifrado a nivel de hardware".

1.1. Cómo TEEs Protegen Datos

Primero examinemos cómo funcionan las TEE más comunes, Intel SGX, AMD SEV y ARM TrustZone, y luego presentemos implementaciones más recientes de TEE.

1.1.1. OG TEEs

Intel SGX

SGX crea y accede a enclaves a nivel de proceso. La siguiente imagen proporciona una representación clara de cómo opera un programa habilitado para SGX.

origen: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction-between-pse-and-application-enclaves

Durante el desarrollo, los desarrolladores deben distinguir entre código no confiable y código confiable. Las variables o funciones que requieren protección por parte del enclave se designan como código confiable, mientras que otras operaciones se clasifican como código no confiable. Cuando el código no confiable necesita ingresar datos en el código confiable, o cuando el código confiable debe interactuar con el código no confiable, se utilizan llamadas especiales al sistema llamadas ECALL y OCALL.

fuente: https://www.intel.com/content/www/us/en/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

Si los usuarios necesitan interactuar directamente con los datos dentro del enclave, por ejemplo, proporcionar entrada o recibir salida, pueden comunicarse a través de canales seguros establecidos mediante protocolos como SSL.

AMD SEV

A diferencia de SGX, que crea enclaves a nivel de proceso, SEV los crea a nivel de máquina virtual. La memoria asignada a las máquinas virtuales está encriptada y se gestiona con claves independientes, protegiendo los datos del sistema operativo del servidor u otras máquinas virtuales. Aunque las máquinas virtuales generalmente se consideran seguras debido a su aislamiento en un entorno controlado, no se pueden descartar por completo las vulnerabilidades que comprometan este aislamiento. SEV está diseñado para proporcionar seguridad en tales escenarios.

SEV genera claves de cifrado a través de un procesador de seguridad que está físicamente separado de la CPU durante la creación de la máquina virtual. Estas claves se utilizan luego para cifrar la memoria de la máquina virtual. El siguiente diagrama ilustra la diferencia entre SGX y SEV.

fuente: 10.1109/SRDS.2018.00042

SGX requiere que los desarrolladores dividan explícitamente el código en segmentos no confiables y confiables. En contraste, SEV cifra toda la memoria de la máquina virtual, lo que exige un esfuerzo relativamente menor por parte de los desarrolladores en términos de implementación.

ARM TrustZone

A diferencia de Intel y AMD, que principalmente producen CPU para escritorios y servidores, ARM diseña conjuntos de chips para sistemas livianos como dispositivos móviles y embebidos. Como resultado, su implementación de Secure Enclave es ligeramente diferente al SGX o SEV utilizados en arquitecturas de nivel superior.

TrustZone divide el sistema en un Mundo Seguro y un Mundo Normal a nivel de hardware. Los desarrolladores que utilizan TrustZone deben implementar funciones críticas de seguridad en el Mundo Seguro, mientras que las funciones generales se ejecutan en el Mundo Normal. Las transiciones entre estos dos mundos ocurren a través de llamadas especiales al sistema conocidas como Llamadas al Monitor Seguro, similares a SGX.

Una distinción clave es que la enclave de TrustZone se extiende más allá de la CPU o memoria; abarca todo el sistema, incluyendo el bus del sistema, periféricos y controladores de interrupciones. Apple también utiliza una TEE llamada Secure Enclave en sus productos, que es muy similar a TrustZone a un alto nivel.

1.1.2. Advanced TEEs

Como discutiremos más adelante, muchos TEEs originales, incluido Intel SGX, han encontrado vulnerabilidades de canal lateral y desafíos de desarrollo debido a problemas estructurales. Para abordar estos problemas, los proveedores han lanzado versiones mejoradas. Con la creciente demanda de computación en la nube segura, plataformas como AWS/Azure/GCP han comenzado a ofrecer sus propios servicios de TEE. Recientemente, el concepto de TEE se ha extendido también a las GPUs. Algunos casos de uso de Web3 están implementando estos TEEs avanzados, así que los explicaré brevemente.

Cloud TEEs: AWS Nitro, Azure Confidential Computing, Google Cloud Confidential Computing

Con la creciente demanda de servicios de computación en la nube, los proveedores han comenzado a desarrollar sus propias soluciones de TEE. Nitro de AWS es un entorno de computación enclavada que funciona junto con las instancias de EC2. Logra una separación física del entorno de computación utilizando un chip de seguridad Nitro dedicado para la certificación y la gestión de claves. El hipervisor Nitro protege las áreas de memoria del enclave a través de funciones proporcionadas por el chip, protegiendo eficazmente contra ataques tanto de usuarios como de proveedores de la nube.

Azure admite varias especificaciones de TEE, incluidas Intel SGX, AMD SEV-SNP y su propio aislamiento basado en virtualización. Esta flexibilidad en la selección del entorno de hardware ofrece a los usuarios más opciones, pero puede aumentar la superficie de ataque cuando el usuario utiliza varios TEE.

Google Cloud ofrece servicios de computación confidencial que utilizan Entornos de Ejecución Confiables (TEE), centrándose en cargas de trabajo de IA/ML. Si bien es diferente de AWS Nitro, Google Cloud, al igual que Azure, ofrece aislamiento basado en virtualización utilizando la infraestructura TEE existente. Los diferenciadores clave incluyen el soporte para aceleradores de CPU como Intel AMX para manejar tareas intensivas de IA/ML, y la computación confidencial basada en GPU a través de NVIDIA, que se detallará más adelante.

ARM CCA

ARM CCA, lanzado a finales de 2021, está diseñado para entornos en la nube, a diferencia de TrustZone, que fue diseñado para entornos embebidos o móviles individuales. TrustZone administra estáticamente regiones de memoria segura pre-designadas, mientras que CCA facilita la creación dinámica de Reinos (enclaves seguros). Esto permite múltiples entornos aislados dentro de una única configuración física.

CCA se puede asemejar a una versión ARM de Intel SGX, aunque con diferencias notables. Mientras que SGX tiene limitaciones de memoria, CCA proporciona una asignación de memoria flexible. Además, CCA emplea un enfoque de seguridad fundamentalmente diferente al cifrar toda la memoria física, no solo las regiones de enclave designadas como lo hace SGX.

Intel TDX

Intel presentó TDX, una tecnología que cifra la memoria a nivel de MV, similar a SEV de AMD. Esta versión aborda los comentarios sobre las limitaciones de SGX(v1), incluido el límite de tamaño de enclave de 256 MB y la mayor complejidad de desarrollo debido a la creación de enclave a nivel de proceso. La diferencia clave con SEV es que TDX confía parcialmente en el sistema operativo, específicamente en el hipervisor, para la gestión de recursos de MV. Además, existen diferencias en los mecanismos de cifrado para cada MV.

AMD SEV-SNP

SEV-SNP mejora la seguridad del modelo SEV existente. El SEV original se basaba en un modelo de confianza que dejaba vulnerabilidades, permitiendo a los hipervisores modificar el mapeo de memoria. SEV-SNP aborda esto añadiendo un administrador de hardware para rastrear los estados de la memoria, evitando tales modificaciones.

Además, permite a los usuarios realizar una atestación remota directamente, minimizando así los anclajes de confianza. SEV-SNP también introdujo una Tabla de Mapeo Inverso para monitorear los estados de las páginas de memoria y la propiedad, proporcionando defensa contra modelos de ataque maliciosos del hipervisor.

GPU TEE: NVIDIA Confidential Computing

El desarrollo de TEE tradicionalmente se ha centrado en las CPUs debido a su dependencia de los proveedores de hardware. Sin embargo, la necesidad de manejar cálculos complejos como el entrenamiento seguro de IA y la protección de datos de entrenamiento ha destacado la necesidad de GPU TEE. En respuesta, NVIDIA introdujo características de computación confidencial en la GPU H100 en 2023.

NVIDIA Confidential Computing ofrece instancias de GPU cifradas y administradas de forma independiente, asegurando seguridad de extremo a extremo cuando se combina con CPU TEE. Actualmente, logra esto mediante la integración con AMD SEV-SNP o Intel TDX para construir canalizaciones de cómputo confidenciales.

1.2. ¿Cómo confiamos en TEE?

Cuando se examinan los proyectos Web3, a menudo se ven reclamos de gobernanza comunitaria a través de cargas de código en GitHub. ¿Pero cómo se puede verificar que el programa implementado en el servidor realmente coincide con el código de GitHub?

Blockchain ofrece un entorno donde los contratos inteligentes siempre son públicos e inmodificables debido a un consenso continuo. En contraste, los servidores típicos de Web2 permiten a los administradores actualizar los programas en cualquier momento. Para verificar la autenticidad, los usuarios deben comparar los valores hash de los binarios construidos a partir de programas de código abierto en plataformas como GitHub o verificar la integridad a través de firmas de desarrolladores.

El mismo principio se aplica a los programas dentro de los enclaves TEE. Para que los usuarios confíen plenamente en los programas implementados en el servidor, deben verificar (atestiguar) que el código y los datos dentro del enclave permanezcan sin cambios. En el caso de SGX, se comunica con IAS (Servicio de Atestación de Intel) utilizando una clave almacenada en un enclave especial. IAS verifica la integridad del enclave y sus datos internos, luego devuelve los resultados a los usuarios. En resumen, TEE requiere comunicación con servidores de atestación proporcionados por el proveedor de hardware para garantizar la integridad del enclave.

2. TEE en Web3

¿Por qué TEE en Web3?

TEE puede parecer desconocido para el público en general, ya que su conocimiento suele estar confinado a dominios especializados. Sin embargo, la aparición de TEE se alinea bien con los principios de Web3. La premisa fundamental de usar TEE es "no confiar en nadie". Cuando se implementa correctamente, TEE puede proteger los datos del usuario del implementador del programa, del propietario del servidor físico e incluso del núcleo del sistema operativo.

Si bien los proyectos actuales de blockchain han logrado una descentralización estructural significativa, muchos todavía dependen de entornos de servidor fuera de la cadena, como secuenciadores, relés fuera de la cadena y bots guardianes. Los protocolos que necesitan procesar información sensible del usuario, como KYC o datos biométricos, o aquellos que tienen como objetivo admitir transacciones privadas, enfrentan el desafío de requerir confianza en los proveedores de servicios. Estos problemas pueden mitigarse sustancialmente mediante el procesamiento de datos dentro de enclaves.

Como resultado, TEE ha ganado popularidad en la segunda mitad de este año, alineándose con temas relacionados con la IA como la privacidad de los datos y los agentes de IA confiables. Sin embargo, los intentos de integrar TEE en el ecosistema Web3 existieron mucho antes. En este artículo, presentaremos proyectos en diversos campos que han aplicado TEE en el ecosistema Web3, más allá del sector de la IA.

2.1. Coprocesador Confidencial

Marlin

Marlin es un protocolo de computación verificable diseñado para ofrecer un entorno de computación seguro utilizando tecnología TEE o ZK. Uno de sus objetivos principales es desarrollar una web descentralizada. Marlin gestiona dos subredes: Oyster y Kalypso, y Oyster funciona como el protocolo de coprocesamiento basado en TEE.

1) Oyster CVM

Oyster CVM (Oyster para mayor comodidad) actúa como un mercado P2P TEE. Los usuarios compran entornos informáticos AWS Nitro Enclave a través del mercado fuera de la cadena de Oyster y despliegan sus imágenes de programa allí. A continuación se muestra una estructura abstracta de Oyster:

fuente: https://docs.marlin.org/oyster/protocol/cvm/workflow/

Oyster tiene una estructura muy similar a Akash. En Oyster, el papel de la cadena de bloques es verificar si cada entorno informático TEE está funcionando correctamente, y esto se hace a través de observadores llamados Proveedores. Los Proveedores verifican continuamente la disponibilidad de los Enclaves en tiempo real y informan sus hallazgos a la red de Oyster. Apuestan $PONDtokens, que corren el riesgo de ser reducidos si participan en actividades maliciosas. Además, existe una red descentralizada de entidades, denominadas 'auditores', encargadas de supervisar la reducción del proveedor. En cada época, a los auditores se les asignan sus trabajos y envían solicitudes de auditoría a enclaves que son seleccionados al azar por una semilla generada dentro de un enclave.

Sin embargo, Oyster ha implementado un contrato llamadoNitroProver que verifica los resultados de la atestación remota en la cadena, lo que permite a los usuarios verificar la integridad de su TEE comprado en la cadena.

Las instancias implementadas por el usuario pueden accederse tanto a través de contratos inteligentes como de API Web2. Los resultados de la computación pueden integrarse en los contratos presentándolos como oráculos. Como se muestra en el panel de control, esta capacidad es adecuada no solo para contratos inteligentes sino también para descentralizar servicios Web2.

Similar a Akash, Oyster es susceptible a posibles tomas de instancia por parte de atacantes si hay vulnerabilidades en el mercado fuera de la cadena. En tales escenarios, aunque los datos del enclave podrían permanecer seguros, los datos en bruto almacenados fuera del enclave y los privilegios de operación del servicio podrían verse comprometidos. En caso de datos sensibles, que se almacenan en memoria no confiable pero no deben ser expuestos, los desarrolladores deben cifrar esos datos y almacenarlos por separado. Marlin actualmente proporciona un almacenamiento externo con una clave persistente basada en MPC para manejar estos casos.

2) Oyster sin servidor

Mientras que Oyster CVM funciona como un mercado P2P de TEE, Oyster Serverless se asemeja a AWS Lambda (o Function-as-a-Service) con TEE. Utilizando Oyster Serverless, los usuarios pueden ejecutar funciones sin alquilar instancias, pagando bajo demanda.

El flujo de ejecución de Oyster Serverless sería el siguiente:

1. Los usuarios crean solicitudes al contrato Relay
2. El servidor de la puerta de enlace fuera de la cadena observa las solicitudes de los usuarios a través del evento
3. el servidor de la puerta de enlace retransmite la solicitud del usuario al Protocolo de la puerta de enlace
4. El Protocolo de Gateway crea y asigna un trabajo al Protocolo Serverless, basado en la solicitud del usuario
5. Los servidores ejecutores escuchan los trabajos asignados al protocolo sin servidor, ejecutan el trabajo y envían la respuesta
6. La respuesta, el resultado de la solicitud del usuario, se transmite secuencialmente al usuario

Con Oyster Serverless, los usuarios pueden enviar solicitudes de API web2 o llamadas de contrato inteligente a través de un contrato inteligente, mientras que la integridad de la ejecución se garantiza a través de TEE. Los usuarios también pueden suscribirse a Serverless para ejecución periódica, lo que sería particularmente útil para los recolectores de oráculos.

Red Phala

Phala, previamente discutido en nuestro artículo de AI X Crypto, ha cambiado significativamente su enfoque a coprocesadores de IA.

El diseño básico de la Red Phala incluye Trabajadores y gatekeepers. Los Trabajadores funcionan como nodos regulares que ejecutan cálculos para los clientes. Los gatekeepers, por otro lado, administran claves que permiten a los Trabajadores descifrar y calcular valores de estado cifrados. Los Trabajadores manejan valores de estado de contrato cifrados a través de Intel SGX, lo que requiere claves de los gatekeepers para leer o escribir estos valores.

fuente: https://docs.phala.network/tech-specs/blockchain

Phala ha ampliado su oferta al admitir SDK para VM confidenciales en entornos Intel TDX. Recientemente, en colaboración con Flashbot, lanzaron Dstack. Este producto presenta una API de atestación remota para verificar el estado operativo de múltiples imágenes de contenedores Docker implementadas en VM confidenciales. La atestación remota a través de Dstack garantiza transparencia a través de un Explorador.

Otro desarrollo significativo es su producto de Inferencia de IA Confidencial, introducido en respuesta al reciente aumento en proyectos de IA. Phala Network ahora admite la computación confidencial relativamente nueva de Nvidia, con el objetivo de mejorar los servicios de inferencia de IA utilizando ZK/FHE. Esta tecnología anteriormente enfrentaba desafíos debido a la alta sobrecarga, lo que limitaba su practicidad.

fuente: https://docs.phala.network/overview/phala-network/confidential-ai-inference

La imagen ilustra la estructura del sistema de inferencia de IA confidencial de la red Phala. Este sistema utiliza entornos de ejecución confiables (TEEs) a nivel de máquina virtual, como Intel TDX y AMD SEV, para implementar modelos de IA. Realiza la inferencia de IA a través de la informática confidencial de Nvidia y transmite de manera segura los resultados de vuelta al enclave de la CPU. Este método puede incurrir en una sobrecarga significativa en comparación con los modelos regulares, ya que implica dos rondas de cálculo del enclave. Sin embargo, se espera que brinde mejoras de rendimiento sustanciales en comparación con los métodos existentes de inferencia de IA basados en TEE que dependen únicamente del rendimiento de la CPU. Según el papelpublicado por Phala Network, la sobrecarga de inferencia LLM basada en Llama3 se midió en alrededor del 6-8%.

Otros

En el dominio de AI X Crypto, otros ejemplos de uso de TEE como coprocesadores incluyen iExec RLC, PIN AI y Super Protocol. iExec RLC y PIN AI se centran en la protección de modelos de IA y datos de entrenamiento a través de TEE, respectivamente. Super Protocol se está preparando para lanzar un mercado para el comercio de entornos informáticos TEE, similar a Marlin. Sin embargo, no hay información técnica detallada sobre estos proyectos disponible públicamente. Proporcionaremos actualizaciones después de los lanzamientos de sus productos.

2.2. Contratos Inteligentes Seguros

Oasis (Prev. Rose)

Oasis, anteriormente conocido como Rose, es una blockchain de Capa 1 diseñada para proteger la privacidad del usuario durante las transacciones mediante la ejecución de su cliente dentro de un enclave SGX. Aunque es una cadena relativamente madura, Oasis ha implementado de manera innovadora el soporte multi-VM en su capa de ejecución.

La capa de ejecución, llamada Paratime, incluye tres componentes: Cipher, una VM confidencial basada en WASM; Sapphire, una VM confidencial basada en EVM; y Emerald, una VM compatible con EVM estándar. Oasis protege fundamentalmente los contratos inteligentes y sus procesos computacionales de modificaciones arbitrarias por parte de los nodos, garantizando que el cliente de ejecución funcione dentro de un enclave TEE. Esta estructura se ilustra en el diagrama adjunto.

fuente: https://docs.oasis.io/general/oasis-network/

Cuando los usuarios envían transacciones, cifran los datos de la transacción utilizando una clave efímera generada por el administrador de claves del Nodo Oasis dentro del enclave y lo transmiten al módulo de cálculo. El módulo de cálculo recibe la clave privada de la clave efímera del administrador de claves, la utiliza para descifrar los datos dentro del enclave, ejecuta el contrato inteligente y modifica los valores de estado del nodo. Dado que los resultados de la ejecución de la transacción también se entregan a los usuarios en forma cifrada, ni el servidor que opera el cliente del nodo Oasis ni entidades externas pueden observar el contenido de la transacción.

Oasis resalta su fortaleza en facilitar la creación de DApps que manejan información personal sensible en blockchains públicos, utilizando su Confidential Paratime. Esta característica permite el desarrollo de servicios que requieren verificación de identidad, como SocialFi, préstamos crediticios, servicios de integración CEX y servicios basados en reputación. Estas aplicaciones pueden recibir y verificar de forma segura la información biométrica o KYC del usuario dentro de un enclave seguro.

Red Secret

Secret Network es una cadena de capa 1 dentro del ecosistema Cosmos y se encuentra entre las blockchains basadas en TEE más antiguas. Aprovecha los enclaves Intel SGX para cifrar los valores del estado de la cadena, lo que permite transacciones privadas para sus usuarios.

En la Red Secreta, cada contrato tiene una clave secreta única almacenada en el enclave de cada nodo. Cuando los usuarios llaman a los contratos a través de transacciones cifradas con claves públicas, los nodos descifran los datos de la transacción dentro del TEE para interactuar con los valores de estado del contrato. Estos valores de estado modificados se registran luego en bloques, permaneciendo cifrados.

El contrato en sí mismo puede compartirse con entidades externas en forma de bytecode o código fuente. Sin embargo, la red garantiza la privacidad de las transacciones del usuario al evitar la observación directa de los datos de transacciones enviados por el usuario y bloquear la observación externa o la manipulación de los valores actuales del estado del contrato.

Dado que todos los valores de estado de los contratos inteligentes están encriptados, verlos requiere descifrarlos. Secret Network aborda esto mediante la introducción de claves de visualización. Estas claves vinculan contraseñas de usuario específicas a contratos, lo que permite que solo los usuarios autorizados observen los valores de estado del contrato.

Clique, Protocolo Quex

A diferencia de las L1 basadas en TEE introducidas anteriormente, los protocolos Clique y Quex ofrecen infraestructura que permite a las DApps generales delegar cálculos privados a un entorno TEE fuera de la cadena. Estos resultados se pueden utilizar a nivel de contrato inteligente. Se utilizan notablemente para mecanismos de distribución de incentivos verificables, libros de órdenes fuera de la cadena, oráculos y protección de datos KYC.

2.3. Sistema de Prueba de Validez

Algunas cadenas ZK L2 emplean sistemas de múltiples pruebas para abordar la inestabilidad inherente de las pruebas de conocimiento cero, a menudo incorporando pruebas TEE. Los mecanismos modernos de prueba de conocimiento cero aún no han madurado lo suficiente para ser completamente confiables en cuanto a su seguridad, y los errores relacionados con la solidez en los circuitos ZK requieren un esfuerzo significativo para parchear cuando ocurren incidentes. Como precaución, las cadenas que utilizan pruebas ZK o ZK-EVM están adoptando pruebas TEE para detectar posibles errores volviendo a ejecutar bloques a través de VM locales dentro de enclaves. Actualmente, las L2 que utilizan sistemas de múltiples pruebas, incluida TEE, son Taiko, Scroll y Ternoa. Veamos brevemente sus motivaciones para usar sistemas de múltiples pruebas y sus estructuras.

Taiko

Taiko es actualmente la cadena rollup (plan-to-be) más prominente. Una cadena rollup delega la secuenciación a los proponentes de bloques de Ethereum sin mantener un secuenciador centralizado separado. Según el diagrama de Based Rollup de Taiko, los buscadores de L2 componen paquetes de transacciones y los entregan a L1 en lotes. Los proponentes de bloques de L1 luego reconstruyen estos, junto con las transacciones de L1, para generar bloques de L1 y capturar MEV.

fuente: https://docs.taiko.xyz/core-concepts/multi-proofs/

En Taiko, se utiliza TEE no durante la etapa de composición de bloques sino en la etapa de generación de pruebas, que explicaremos. Taiko, con su estructura descentralizada, no requiere verificación de fallas del secuenciador. Sin embargo, si hay errores dentro del código del cliente del nodo L2, una configuración completamente descentralizada no puede manejarlos rápidamente. Esto requiere pruebas de validez de alto nivel para garantizar la seguridad, lo que resulta en un diseño de desafío más complejo en comparación con otros rollups.

Los bloques de Taiko pasan por tres etapas de confirmación: propuesta, probada y verificada. Un bloque se considera propuesto cuando su validez es verificada por el contrato L1 de Taiko (contrato de rollup). Alcanza el estado probado cuando es verificado por probadores paralelos y el estado verificado cuando su bloque padre ha sido probado. Para verificar los bloques, Taiko utiliza tres tipos de pruebas: prueba basada en SGX V2 TEE, prueba basada en Succinct/RiscZero ZK y prueba Guardian, que se basa en multisig centralizada.

Taiko emplea un modelo de impugnación para la verificación de bloques, estableciendo una jerarquía de niveles de seguridad entre Provers: TEE, ZK, ZK+TEE y Guardian. Esta configuración permite a los aspirantes obtener mayores recompensas cuando identifican pruebas incorrectas generadas por modelos de nivel superior. Las pruebas requeridas para cada bloque se asignan aleatoriamente con las siguientes ponderaciones: 5% para SGX+ZKP, 20% para ZKP y el resto usando SGX. Esto garantiza que los probadores de ZK siempre puedan obtener mayores recompensas tras los desafíos exitosos.

Los lectores podrían preguntarse cómo generan y verifican pruebas los probadores de SGX. El papel principal de los probadores de SGX es demostrar que los bloques de Taiko se generaron a través de cálculos estándar. Estos probadores generan pruebas de cambios de valor de estado y verifican el entorno usando resultados de la reejecución de bloques a través de una VM local dentro del entorno TEE, junto con los resultados de la atestación del enclave.

A diferencia de la generación de prueba ZK, que implica costos computacionales significativos, la generación de prueba basada en TEE verifica la integridad computacional a un costo mucho menor bajo supuestos de seguridad similares. La verificación de estas pruebas implica controles simples, como asegurarse de que la firma ECDSA utilizada en la prueba coincida con la firma del probador.

En conclusión, las pruebas de validez basadas en TEE pueden verse como un método para verificar la integridad de la cadena mediante la generación de pruebas con niveles de seguridad ligeramente inferiores pero a un costo considerablemente menor en comparación con las pruebas de conocimiento nulo (ZK proofs).

Desplazarse

Scroll es un rollup notable que adopta un sistema multi-prueba. Colabora con Automata, una capa de certificación que se introducirá más adelante, para generar tanto pruebas ZK como pruebas TEE para todos los bloques. Esta colaboración activa un sistema de disputas para resolver conflictos entre las dos pruebas.

fuente: https://scroll.io/blog/scaling-security

Scroll planea admitir varios entornos de hardware (actualmente solo SGX), incluyendo Intel SGX, AMD SEV y AWS Nitro, para minimizar las dependencias de hardware. Abordan posibles problemas de seguridad en TEE recopilando pruebas de entornos diversos mediante firmas de umbral.

Ternoa

Ternoa prioriza la detección de acciones maliciosas por parte de entidades centralizadas de L2 sobre la solución de errores en la propia ejecución. A diferencia de Taiko o Scroll, que utilizan prueba de integridad de la tecnología (TEEs, por sus siglas en inglés) para complementar las pruebas de conocimiento nulo (ZK, por sus siglas en inglés) existentes, Ternoa emplea Observadores en entornos basados en TEE. Estos Observadores detectan acciones maliciosas por parte de secuenciadores y validadores de L2, centrándose en áreas que no pueden evaluarse únicamente a partir de los datos de transacción. Ejemplos incluyen nodos de RPC que censuran transacciones según la dirección IP, secuenciadores que alteran los algoritmos de secuenciación o que no envían intencionalmente datos en lotes.

Ternoa opera una red L2 separada llamada Integrity Verification Chain (IVC) para tareas de verificación relacionadas con entidades de rollup. El proveedor del marco de rollup envía la última imagen del secuenciador a la IVC. Cuando se solicita el despliegue de un nuevo rollup, la IVC devuelve las imágenes de servicio almacenadas en TEE. Después del despliegue, los observadores verifican regularmente si el rollup desplegado utiliza la imagen del secuenciador como se pretende. Luego envían pruebas de integridad, incorporando sus resultados de verificación e informes de certificación de su entorno TEE, para confirmar la integridad de la cadena.

2.3. Seguridad de Ethereum

2.3.1. Descentralización del Constructor de Bloques

Flashbots BuilderNet

Flashbots, ampliamente reconocido como proveedor de soluciones MEV, ha explorado de manera constante la aplicación de Entornos de Ejecución Confiables (TEE) en la tecnología blockchain. Los esfuerzos de investigación destacados incluyen:

• Investigando la ejecución de Geth dentro de un SGX Enclave y sus limitaciones
• Implementando un constructor de bloques basado en SGX
• Construyendo una cadena de coprocesador TEE basada en la ejecución de REVM dentro de un Enclave SGX, complementada por una capa de verificación de Autómatas

En este artículo, delinearemos brevemente el papel actual de Flashbots y discutiremos BuilderNet, una iniciativa reciente dirigida a descentralizar la construcción de bloques. Flashbots ha anunciado planes de migración completos para su solución existente a través de BuilderNet.

Ethereum utiliza un modelo de Separación de Propositor-Constructor. Este sistema divide la creación de bloques en dos roles: 1) Constructores: Responsables de la creación de bloques y extracción de MEV 2) Propositores: Firman y propagan los bloques creados por los Constructores para descentralizar las ganancias de MEV. Esta estructura ha llevado a que algunas aplicaciones descentralizadas coludan con los Constructores fuera de la cadena para capturar ganancias sustanciales de MEV. Como resultado, algunos Constructores, como Beaverbuild y Titan Builder, crean de forma monopolística más del 90% de los bloques de Ethereum. En casos graves, estos Constructores pueden censurar transacciones arbitrarias. Por ejemplo, las transacciones reguladas, como las de Tornado Cash, son activamente censuradas por los Constructores principales.

BuilderNet aborda estos problemas mejorando la privacidad de las transacciones y reduciendo las barreras para la participación de los constructores de bloques. Su estructura se puede resumir de manera general de la siguiente manera:

fuente: https://buildernet.org/docs/architecture

Los nodos constructores, que reciben las transacciones de los usuarios (Orderflow), son gestionados por varios operadores de nodos. Cada uno de ellos opera instancias de constructores de código abierto dentro de los entornos de Intel TDX. Los usuarios pueden verificar libremente el entorno TEE de cada operador y enviar transacciones cifradas. Los operadores comparten luego su Orderflow recibido, envían bloques al relé de impulso de MEV y distribuyen las recompensas por bloque a los buscadores y otros involucrados en la creación de bloques tras el envío exitoso.

Esta estructura proporciona varios beneficios de descentralización:

• Verificabilidad: cada instancia de Builder opera dentro de un entorno de ejecución confidencial (TEE), lo que permite a los usuarios verificar que los Builders no han censurado transacciones o modificado clientes arbitrariamente. La política de distribución de recompensas para los contribuyentes de la creación de bloques también es transparente dentro del TEE.
• Resistencia a la censura: En BuilderNet, los nodos constructores son operados por múltiples operadores, cada uno con diferentes políticas regulatorias. Esta diversidad significa que eligen diferentes transacciones a excluir. Incluso si algunos operadores censuran transacciones, otros aún pueden seleccionarlas. Teóricamente, si hay al menos un constructor que no censura, las transacciones de los usuarios pueden incluirse en bloques. BuilderNet también ofrece una solución a problemas de censura L2, mostrando que L2s pueden lograr una resistencia a la censura más alta que los secuenciadores individuales mediante la externalización de la construcción de bloques a BuilderNet. (En este caso, el nivel de resistencia a la censura puede verse afectado por componentes adicionales que filtran las transacciones antes del secuenciador, por ejemplo, cortafuegos)
• Descentralización: Los constructores de bloques actuales se enfrentan al desafío de la dependencia de la infraestructura centralizada. BuilderNet tiene como objetivo abordar esto integrando varios constructores, comenzando con Beaverbuild. A medida que más constructores de bloques se unan a BuilderNet, la estructura PBS de Ethereum verá una mayor descentralización. En la actualidad, solo Beaverbuild, Flashbots y Nethermind son parte de BuilderNet. Otros constructores necesitan permiso para unirse, pero hay planes para hacer que el despliegue del operador sea sin permiso y eliminar por completo la infraestructura centralizada en el futuro.

2.3.2. Protección del validador

Finanzas Puffer

Puffer Finance ha introducido una herramienta Secure Signer diseñada para reducir el riesgo de que los validadores de Ethereum sean sancionados debido a errores o fallas del cliente. Esta herramienta utiliza un firmante basado en SGX Enclave para una seguridad mejorada.

fuente: https://docs.puffer.fi/technology/secure-signer/

El Secure Signer opera generando y almacenando claves de validador BLS dentro del enclave SGX, accediendo a ellas solo cuando es necesario. Su lógica es sencilla: junto con la seguridad proporcionada por el Entorno de Ejecución Confiable (TEE), puede detectar errores o acciones maliciosas del validador. Esto se logra asegurando que los espacios hayan aumentado estrictamente antes de firmar bloques o pruebas. Puffer Finance destaca que esta configuración permite a los validadores alcanzar niveles de seguridad comparables a las billeteras de hardware, superando las protecciones típicas ofrecidas por las soluciones de software.

2.4. Descentralización del secuenciador de L2

Unichain

Unichain, la cadena de capa 2 (L2) de Ethereum de Uniswap programada para su lanzamiento en el primer trimestre del próximo año, ha compartido planes en su libro blanco para descentralizar los mecanismos de creación de bloques de L2 utilizando Entornos de Ejecución Confiables (TEE). Aunque las especificaciones técnicas detalladas aún no se han publicado, aquí hay un resumen de sus propuestas clave:

• Separación de Secuenciador-Construcción: Para mejorar las estructuras de rollup existentes donde la secuenciación y la generación de bloques L2 son gestionadas por secuenciadores centralizados, Unichain ha colaborado con Flashbots. Esta asociación tiene como objetivo separar los secuenciadores L2 de los constructores de bloques. Los constructores de bloques de Unichain funcionarán utilizando código de código abierto dentro de Intel TDX, asegurando transparencia al liberar públicamente los resultados de la certificación para la ejecución.
• Flashblock: Unichain identifica limitaciones en la escalabilidad con el proceso de preconfirmación actual proporcionado por los secuenciadores de rollup, como la serialización y la generación de la raíz del estado. Para abordar estos problemas, planean introducir los “Flashblocks”, que permiten a los usuarios recibir bloques pendientes inmediatamente después del ordenamiento de transacciones a través de los constructores de TEE. Insisten en que el ordenamiento dentro de TEE garantizará que el orden de las transacciones se base únicamente en las tarifas de prioridad y el tiempo de envío, sin interferencia del secuenciador, lo que permitirá una preconfirmación más rápida.

Además, Unichain tiene la intención de desarrollar varias funciones basadas en TEE, incluyendo una mempool encriptada, transacciones programadas y contratos inteligentes protegidos por TEE.

2.5. RPC privado

Automata

Si bien la cadena de bloques ha logrado una descentralización considerable en aspectos arquitectónicos, muchos elementos aún no tienen suficiente resistencia a la censura debido a la dependencia de los operadores del servidor. Automata tiene como objetivo proporcionar soluciones que minimicen la dependencia de los operadores del servidor y la exposición de datos en la arquitectura de la cadena de bloques basada en TEE. Las implementaciones destacadas de Automata incluyen código abierto SGX Provery Verificador,TEE Compilarque verifica las coincidencias entre los ejecutables implementados en TEE y el código fuente, yConstructor de TEEque agrega privacidad a los mecanismos de construcción de bloques a través de TEE-based mempool y block builder. Además, Automata permite que el resultado de la atestación remota de TEE se publique en la cadena, lo que permite que sea públicamente verificable e integrado en contratos inteligentes.

Automata actualmente opera 1RPC, un servicio RPC basado en TEE diseñado para proteger la información de identificación de los remitentes de transacciones, como la dirección IP y los detalles del dispositivo, a través de enclaves seguros. Automata destaca el riesgo de que, con la comercialización de UserOp debido al desarrollo de la abstracción de cuentas, los servicios RPC puedan inferir patrones de UserOp para usuarios específicos a través de la integración de IA, comprometiendo potencialmente la privacidad. La estructura de 1RPC es sencilla. Establece conexiones seguras con los usuarios, recibe transacciones (UserOp) en el TEE y las procesa con el código desplegado dentro del enclave. Sin embargo, 1RPC solo protege los metadatos de UserOp. Las partes reales involucradas y los contenidos de las transacciones permanecen expuestos durante la interacción con el Punto de Entrada en cadena. Un enfoque más fundamental para garantizar la privacidad de las transacciones implicaría proteger las capas de mempool y block builder con TEE. Esto podría lograrse mediante la integración con el TEE Builder de Automata.

2.6. Agentes de IA

fuente:https://x.com/tee_hee_he

Lo que finalmente llevó al meta de TEE a la prominencia en web3 fue el agente de IA de Twitter basado en TEE. Es probable que muchas personas se encuentren por primera vez con TEE cuando un agente de IA llamado @tee_hee_heapareció en X a finales de octubre y lanzó su memecoin en Ethereum.@tee_hee_hees un agente de inteligencia artificial desarrollado conjuntamente por Nous Research y el proyecto Teleport de Flashbots. Surgió en respuesta a las preocupaciones de que las cuentas de agentes de inteligencia artificial populares en ese momento no podían demostrar que realmente estaban transmitiendo resultados generados por modelos de inteligencia artificial. Los desarrolladores diseñaron un modelo que minimizaba la intervención de entidades centralizadas en procesos como la configuración de cuentas de Twitter, la creación de billeteras de criptomonedas y la transmisión de resultados del modelo de inteligencia artificial.

fuente: @tee_hee_he/setting-your-pet-rock-free-3e7895201f46"">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

Implementaron el agente de IA en un entorno Intel TDX, generando correo electrónico, contraseñas de cuentas X y tokens OAuth para el acceso a Twitter a través de la simulación del navegador, y luego eliminaron todas las opciones de recuperación.

Recientemente, TEE se utilizó en un contexto similar para AI-Pool, donde @123skelycon éxito llevó a cabo la recaudación de fondos. Actualmente, después de que las monedas de memes de IA despliegan sus contratos y se hacen públicas las direcciones, los bots de francotirador técnicamente superiores suelen asegurar la mayor parte de la liquidez y manipular los precios. AI-Pool intenta resolver este problema al permitir que la IA realice un tipo de preventa.

fuente:https://x.com/0xCygaar/status/1871421277832954055

Otro caso interesante es DeepWorm, un agente de IA con una red neural bio que simula el cerebro de un gusano. Similar a los otros agentes de IA, DeepWorm carga la imagen del enclave de su cerebro de gusano a la Red Marlin para proteger su modelo y proporcionar verificabilidad a su operación.

fuente: https://x.com/deepwormxyz/status/1867190794354078135

Desde @tee_hee_heal haber abierto todo el código necesario para su implementación, desplegar agentes de IA basados en TEE confiables y seguros se ha vuelto bastante fácil. Recientemente, Phala Network desplegó a Eliza de a16z en TEE. Como destacó a16z en su informe de perspectivas del mercado de criptomonedas para 2025, se espera que el mercado de agentes de IA basados en TEE sirva como infraestructura esencial en el futuro mercado de memecoins de agentes de IA.

2.7. Juego Social

Azuki Bobu

Azuki, un reconocido proyecto NFT de Ethereum, colaboró con Flashbots el pasado mes de octubre para organizar un evento social único.

fuente: https://x.com/Azuki/status/1841906534151864557

Esto implicaba delegar los permisos de carga de la cuenta de Twitter a Flashbots y Bobu, quienes luego publicaron tweets simultáneamente, similar a un flash mob. El evento fue un éxito, como se muestra en la imagen a continuación.

fuente: https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

Diseñada por Flashbots y Azuki, la estructura del evento fue la siguiente:

1. Genera claves privadas y certificados TLS, así como claves privadas de Ethereum, dentro de Gramin-SGX.
2. Los usuarios crearon tokens OAuth con permisos limitados para publicar un solo tweet y los enviaron al TEE de Flashbots a través de TLS.
3. Se creó un contrato en Arbitrum para gestionar certificados de usuario, evitando el doble gasto e implementando salidas de eventos al subir tweets de usuario.

Azuki aseguró la confiabilidad del proceso del evento al publicar la imagen Docker de Enclave en Docker Hub. También subieron scripts de verificación de registros de transparencia de certificados y resultados de atestación remota para el entorno TEE en GitHub. Aunque Flashbots identificó dependencias en nodos RPC y blockchain como riesgos restantes, estos podrían mitigarse mediante el uso de RPC TEE o rollups basados en TEE como Unichain.

Si bien el proyecto no logró un avance técnico, es digno de mención por llevar a cabo un evento social confiable utilizando exclusivamente una pila TEE.

3. Seguridad de TEE

TEE proporciona una seguridad mucho mayor en comparación con las soluciones de software típicas, ya que ofrece seguridad a nivel de hardware que el software no puede comprometer directamente. Sin embargo, TEE ha tardado en adoptarse en productos reales debido a varias limitaciones, que presentaremos.

1) Mecanismo de Attestación Centralizado

Como se mencionó anteriormente, los usuarios pueden utilizar mecanismos de atestación remota para verificar la integridad de los enclaves TEE y que los datos dentro de los enclaves no hayan sido manipulados. Sin embargo, este proceso de verificación depende inevitablemente de los servidores del fabricante del chip. El grado de confianza varía ligeramente según el proveedor: SGX/TDX depende completamente del servidor de atestación de Intel, mientras que SEV permite a los propietarios de VM realizar la atestación directamente. Este es un problema inherente en la estructura de TEE, y los investigadores de TEE están trabajando para resolverlo mediante el desarrollo de un TEE de código abierto, que mencionaremos más adelante.

2) Ataques de canal lateral

TEE nunca debe exponer datos almacenados dentro de los enclaves. Sin embargo, debido a que TEE solo puede cifrar datos dentro de los enclaves, pueden surgir vulnerabilidades a partir de ataques que aprovechan información secundaria, no los datos originales. Desde el lanzamiento público de Intel SGX en 2015, se han destacado numerosos ataques críticos de canal lateral en las principales conferencias de seguridad del sistema. A continuación se presentan posibles escenarios de ataque en casos de uso de TEE, categorizados por su impacto:

• Fuga de flujo de control: los sistemas operativos o programas maliciosos podrían recuperar datos explotando la información disponible. Por ejemplo, pueden aprovechar el hecho de que el acceso a datos de la caché de la CPU es mucho más rápido que el acceso a datos de DRAM. Esto les permite identificar patrones de ejecución del código de operación e inferir información clave del programa, como claves RSA. Además, un ataque puede ocurrir cuando un sistema operativo malicioso restringe el acceso a la página de memoria, causando fallos de página en el código de enclave para exponer patrones de acceso a la memoria. La manipulación del búfer de destino de la rama para predecir y gestionar las ramas del código también puede revelar el flujo de ejecución del código. Además, los atacantes pueden ejecutar repetidamente el código de enclave en ataques de microscopio para inferir información.
• Fugas de Datos: Las vulnerabilidades que filtran datos de Enclave pueden provocar ataques críticos, poniendo en riesgo la Attestation Remota. Es importante señalar que se han filtrado claves secretas en un Enclave mediante la creación de aplicaciones sombra que emulan el código y los datos del Enclave, ejecutando ataques ROP en ellos (Dark-ROP). Aparecen vulnerabilidades adicionales debido a la ejecución especulativa de programas por parte de las CPUs Intel para la optimización del rendimiento (Foreshadow). Aunque la memoria del Enclave está protegida por cifrado, los datos a los que se accede mediante instrucciones de ejecución especulativa pueden permanecer brevemente en la caché. Esto puede ser explotado para leer datos del Enclave a través de ataques de canal lateral de caché.
• Ataques DoS: Para SGX, cuando las comprobaciones de integridad de memoria detectan manipulaciones, el sistema se detiene. Esta vulnerabilidad ha sido aprovechada para ataques DoS al causar intencionadamente fallos en las comprobaciones de integridad. Los atacantes pueden provocar la detención del sistema accediendo repetidamente a filas específicas de DRAM para inducir cambios de bits en filas adyacentes, lo que podría dañar la memoria del enclave.

Si bien TEE no es un sistema que neutralice todos los vectores de ataque y pueda filtrar varios niveles de información debido a sus características fundamentales, estos ataques requieren fuertes requisitos previos, como el código del atacante y la víctima que se ejecutan en el mismo núcleo de CPU. Esto ha llevado a algunos a describirlo como el modelo de seguridad "El hombre con la Glock".

fuente: https://x.com/hdevalence/status/1613247598139428864

Sin embargo, dado que el principio fundamental de TEE es "no confiar en nadie", creo que TEE debería ser capaz de proteger los datos incluso dentro de este modelo para cumplir plenamente su función como módulo de seguridad.

3) Explotaciones recientes / del mundo real en TEE

Se han descubierto numerosos errores en las implementaciones de TEE, especialmente en SGX, y la mayoría se han parcheado con éxito. Sin embargo, la compleja arquitectura de hardware de los sistemas TEE significa que pueden aparecer nuevas vulnerabilidades con cada lanzamiento de hardware. Más allá de la investigación académica, ha habido explotaciones del mundo real que afectan a proyectos Web3, lo que justifica un examen detallado.

• Red secreta: Como una de las pocas víctimas de exploits TEE genuinos, este proyecto basado en SGX sucumbió al ataque ÆPIC Leakage descubierto en 2022. El ataque se dirigió al conjunto de instrucciones AVX (Advanced Vector Extensions) en las CPU Intel recientes. Aprovechó los patrones de ejecución especulativos durante las operaciones AVX para recuperar las claves de cifrado almacenadas en las regiones del enclave. Secret Network utilizó una semilla de consenso para que los validadores descifraran las transacciones privadas. El atacante extrajo con éxito esta semilla, lo que permitió descifrar todas las transacciones privadas históricas en la red. Más detalles de la vulnerabilidad se describen en sgx.fail.
• Exposición de la Llave Raíz SGX: En agosto, el investigador de seguridad Mark Ermolov anunció la exitosa descifrado de la Llave de Provisión Raíz y la Llave de Sellado Raíz de SGX, componentes esenciales del modelo de confianza criptográfica de SGX. Estas claves suelen estar protegidas por una lógica compleja dentro de un dispositivo físico de control de fusibles. Sin embargo, se encontró una vulnerabilidad crítica donde copias de estas claves permanecían en búferes internos durante las operaciones. Aunque poseer estas dos claves por sí solas no compromete completamente SGX, obtener la Llave Global de Envoltura podría exponer potencialmente todo el sistema SGX a vulnerabilidades. A pesar de que SGX se ha eliminado en las CPU comerciales de Intel lanzadas después de 2021, sigue siendo un vector de ataque viable ya que varios proyectos todavía lo utilizan.
• Vulnerabilidad AMD SEV-SNP: AMD SEV, una implementación de TEE relativamente nueva con un amplio alcance de protección a nivel de máquina virtual, ha mostrado históricamente menos vulnerabilidades en comparación con SGX. Sin embargo, la aceptación de un documento en el IEEE S&P 2025 en el que se habla de "BadRAM", una vulnerabilidad dirigida a AMD SEV-SNP, pone de manifiesto que incluso las implementaciones modernas de TEE no son inmunes a los fallos de seguridad. BadRAM explota los módulos de memoria DDR4 y DDR5 para crear alias de espacio de direcciones en la memoria física. Mediante el uso de una Raspberry Pi Pico, que cuesta alrededor de 10 dólares, los atacantes pueden modificar los chips de memoria para engañar a la CPU sobre el tamaño de la memoria física. De este modo, se evita el mecanismo de protección RMP (tabla de mapa inverso) de AMD SEV-SNP. Más detalles de la vulnerabilidad se describen en badram.eu.

Estos casos indican que un "TEE completamente seguro" es inalcanzable, y los usuarios deben ser conscientes de las posibles vulnerabilidades con los nuevos lanzamientos de hardware.

4. Conclusión: El código abierto es el futuro

En noviembre, Georgios Konstantopoulos de Paradigm delineó un marcopara la evolución confidencial del hardware, categorizando el hardware seguro en cinco niveles distintos:

• Nivel 1: Ofrece suficiente confidencialidad para aplicaciones de oráculo y puente, con seguridad dependiente de la cadena de suministro. Ejemplos incluyen SGX.
• Nivel 2: Conserva la seguridad de nivel 1 al tiempo que mejora la experiencia del desarrollador y admite aplicaciones avanzadas como la delegación de cuentas de OAuth, como se ve con Teleport. Gramine SGX ejemplifica este nivel.
• Nivel 3: Extiende la seguridad del Nivel 1 con soporte de GPU, lo que permite aplicaciones sofisticadas como el aprendizaje automático privado y verificable. Intel TDX + Nvidia Confidential Computing representa este nivel.
• Nivel 4: Utiliza conjuntos de instrucciones de código abierto con procesos de fabricación públicamente verificables, eliminando las dependencias de los proveedores de hardware, como demuestra OpenTEE.
• Nivel 5: Logra un estado ideal en el que múltiples OpenTEEs trabajan juntos a través de FHE/MPC, manteniendo la integridad incluso si las unidades de hardware individuales están comprometidas.

Actualmente, proyectos como Confidential AI Inference de Phala Network operan en el Nivel 3, mientras que la mayoría de los servicios permanecen en el Nivel 2 utilizando la nube TEE o Intel TDX. Aunque los proyectos basados en Web3 TEE deberían llegar a pasar al hardware de nivel 4, las limitaciones de rendimiento actuales hacen que esto sea poco práctico. Sin embargo, con importantes empresas de capital riesgo como Paradigm y equipos de investigación como Flashbots y Nethermind trabajando hacia la democratización de la ETE, y dada la alineación de la ETE con los principios de la Web3, es probable que se convierta en una infraestructura esencial para los proyectos de la Web3.

Acerca de ChainLight

Ecosystem Explorer es el informe de ChainLight que presenta un análisis interno sobre proyectos de tendencia del ecosistema web3 desde una perspectiva de seguridad, escrito por nuestros analistas de investigación. Con la misión de ayudar a los investigadores de seguridad y desarrolladores a aprender, crecer y contribuir colectivamente para hacer de Web3 un lugar más seguro, publicamos periódicamente nuestro informe de forma gratuita.

Para recibir las últimas investigaciones e informes realizados por expertos galardonados:

👉 Seguir @ChainLight_io @c4lvin

Establecida en 2016, los expertos galardonados de ChainLight proporcionan soluciones de seguridad personalizadas para fortalecer su contrato inteligente y ayudarle a prosperar en la cadena de bloques.

Descargo de responsabilidad:

1. Este artículo se reproduce de [ gateLuz de cadena]. Todos los derechos de autor pertenecen al autor original [c4lvin*]. Si hay objeciones a esta reimpresión, por favor contacte a la Aprendizaje de la puertael equipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
3. El equipo de aprendizaje de Gate tradujo el artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos, a menos que se mencione.