5 publicaciones etiquetados con "privacidad"

Las cadenas de bloques públicas dan a cada participante un libro mayor sincronizado y auditable, pero también exponen todos los datos por defecto. Seal, disponible en la red principal de Sui desde el 3 de septiembre de 2025, resuelve este dilema al combinar políticas on-chain con una gestión descentralizada de claves para que los desarrolladores decidan quién puede descifrar cada payload.

Resumen rápido​

• Qué es: Seal es una red de gestión de secretos que permite a los contratos inteligentes de Sui hacer cumplir políticas de descifrado on-chain mientras los clientes cifran datos con cifrado basado en identidades (IBE) y dependen de servidores de claves con umbral para derivar claves.
• Por qué importa: En lugar de backends personalizados o scripts opacos fuera de la cadena, la privacidad y el control de acceso se convierten en primitivas de Move de primera clase. Los desarrolladores pueden almacenar los cifrados en cualquier lugar—Walrus es el compañero natural—y seguir controlando quién puede leer.
• Quién se beneficia: Equipos que publican contenidos tokenizados, revelaciones con bloqueo temporal, mensajería privada o agentes de IA conscientes de políticas pueden conectarse al SDK de Seal y centrarse en la lógica del producto, no en el andamiaje criptográfico.

La lógica de políticas vive en Move​

Los paquetes de Seal incluyen funciones Move seal_approve* que definen quién puede solicitar claves para una identidad determinada y bajo qué condiciones. Las políticas pueden combinar propiedad de NFT, listas blancas, bloqueos temporales o sistemas de roles personalizados. Cuando un usuario o agente solicita descifrar, los servidores de claves evalúan estas políticas mediante el estado de un nodo completo de Sui y solo aprueban si la cadena está de acuerdo.

Como las reglas de acceso forman parte de tu paquete on-chain, son transparentes, auditables y versionables junto con el resto del código de tus contratos inteligentes. Las actualizaciones de gobernanza se pueden desplegar como cualquier otra actualización de Move, con revisión comunitaria e historial en cadena.

La criptografía umbral gestiona las claves​

Seal cifra los datos con identidades definidas por la aplicación. Un comité de servidores de claves independientes—elegido por el desarrollador—comparte el secreto maestro de IBE. Cuando la política aprueba la solicitud, cada servidor deriva una porción de clave para la identidad solicitada. Una vez que responde el quórum de t servidores, el cliente combina las porciones y obtiene una clave de descifrado utilizable.

Puedes ajustar el equilibrio entre disponibilidad y confidencialidad seleccionando a los miembros del comité (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One o Enoki de Mysten) y el umbral. ¿Necesitas más disponibilidad? Elige un comité más grande con un umbral más bajo. ¿Buscas mayores garantías de privacidad? Reduce el quórum y apóyate en proveedores con permisos.

Experiencia para desarrolladores: SDK y claves de sesión​

Seal ofrece un SDK de TypeScript (npm i @mysten/seal) que gestiona los flujos de cifrado y descifrado, el formato de identidades y los lotes de solicitudes. También emite claves de sesión para que las billeteras no reciban solicitudes constantes cuando una aplicación necesita acceso repetido. Para flujos avanzados, los contratos Move pueden solicitar descifrado on-chain mediante modos especializados, lo que permite ejecutar directamente en cadena lógica como liberaciones en custodia o subastas resistentes a MEV.

Como Seal es agnóstico al almacenamiento, los equipos pueden combinarlo con Walrus para blobs verificables, con IPFS o incluso con almacenes centralizados cuando sea necesario. El perímetro de cifrado—y su política de aplicación—viaja con los datos sin importar dónde resida el cifrado.

Diseñar con Seal: buenas prácticas​

• Modela el riesgo de disponibilidad: Umbrales como 2 de 3 o 3 de 5 se traducen directamente en garantías de tiempo activo. Los despliegues en producción deben mezclar proveedores, monitorear telemetría y negociar SLA antes de confiar flujos críticos.
• Cuidado con la variación de estado: La evaluación de políticas depende de llamadas dry_run en nodos completos. Evita reglas basadas en contadores que cambian rápidamente u ordenamientos dentro del checkpoint para prevenir aprobaciones inconsistentes entre servidores.
• Planifica la higiene de claves: Las claves derivadas viven en el cliente. Instrumenta registros, rota claves de sesión y considera cifrado envolvente—usa Seal para proteger una clave simétrica que cifra el payload mayor—para limitar el impacto si se compromete un dispositivo.
• Arquitecta la rotación: El comité de un cifrado queda fijado en el momento del cifrado. Construye rutas de actualización que vuelvan a cifrar los datos con nuevos comités cuando necesites cambiar proveedores o ajustar supuestos de confianza.

Lo que viene​

La hoja de ruta de Seal apunta a servidores MPC operados por validadores, herramientas de cliente tipo DRM y opciones KEM poscuánticas. Para los equipos que exploran agentes de IA, contenidos premium o flujos de datos regulados, la versión actual ya ofrece una guía clara: codifica tu política en Move, compón un comité de claves diverso y entrega experiencias cifradas que respeten la privacidad del usuario sin salir del perímetro de confianza de Sui.

Si estás evaluando Seal para tu próximo lanzamiento, comienza con un prototipo sencillo de política con NFT y un comité abierto de 2 de 3, y después itera hasta lograr la mezcla de proveedores y controles operativos que coincidan con el perfil de riesgo de tu aplicación.

1. Descripción General de la Tecnología TEE​

Definición y Arquitectura: Un Entorno de Ejecución Confiable (TEE) es un área segura de un procesador que protege el código y los datos cargados en su interior con respecto a la confidencialidad y la integridad. En términos prácticos, un TEE actúa como un "enclave" aislado dentro de la CPU, una especie de caja negra donde los cálculos sensibles pueden ejecutarse protegidos del resto del sistema. El código que se ejecuta dentro de un enclave TEE está protegido de tal manera que incluso un sistema operativo o hipervisor comprometido no puede leer ni manipular los datos o el código del enclave. Las propiedades clave de seguridad que proporcionan los TEEs incluyen:

• Aislamiento: La memoria del enclave está aislada de otros procesos e incluso del kernel del sistema operativo. Incluso si un atacante obtiene privilegios de administrador completos en la máquina, no puede inspeccionar o modificar directamente la memoria del enclave.
• Integridad: El hardware garantiza que el código que se ejecuta en el TEE no pueda ser alterado por ataques externos. Cualquier manipulación del código del enclave o del estado de ejecución será detectada, evitando resultados comprometidos.
• Confidencialidad: Los datos dentro del enclave permanecen cifrados en la memoria y solo se descifran para su uso dentro de la CPU, por lo que los datos secretos no se exponen en texto plano al mundo exterior.
• Atestación Remota: El TEE puede producir pruebas criptográficas (atestaciones) para convencer a una parte remota de que es genuino y que un código de confianza específico se está ejecutando en su interior. Esto significa que los usuarios pueden verificar que un enclave se encuentra en un estado confiable (por ejemplo, ejecutando el código esperado en hardware genuino) antes de proporcionarle datos secretos.

Diagrama conceptual de un Entorno de Ejecución Confiable como un enclave seguro tipo "caja negra" para la ejecución de contratos inteligentes. Las entradas cifradas (datos y código del contrato) se descifran y procesan dentro del enclave seguro, y solo los resultados cifrados salen del enclave. Esto garantiza que los datos sensibles del contrato permanezcan confidenciales para todos fuera del TEE.

Bajo el capó, los TEEs son posibles gracias al cifrado de memoria basado en hardware y al control de acceso en la CPU. Por ejemplo, cuando se crea un enclave TEE, la CPU le asigna una región de memoria protegida y utiliza claves dedicadas (grabadas en el hardware o gestionadas por un coprocesador seguro) para cifrar/descifrar datos sobre la marcha. Cualquier intento de software externo de leer la memoria del enclave solo obtiene bytes cifrados. Esta protección única a nivel de CPU permite que incluso el código a nivel de usuario defina regiones de memoria privadas (enclaves) que el malware privilegiado o incluso un administrador de sistema malicioso no puede espiar o modificar. En esencia, un TEE proporciona un nivel de seguridad más alto para las aplicaciones que el entorno operativo normal, al tiempo que es más flexible que los elementos seguros dedicados o los módulos de seguridad de hardware.

Implementaciones Clave de Hardware: Existen varias tecnologías de TEE de hardware, cada una con diferentes arquitecturas pero con el objetivo similar de crear un enclave seguro dentro del sistema:

• Intel SGX (Software Guard Extensions): Intel SGX es una de las implementaciones de TEE más utilizadas. Permite a las aplicaciones crear enclaves a nivel de proceso, con cifrado de memoria y controles de acceso aplicados por la CPU. Los desarrolladores deben dividir su código en código "confiable" (dentro del enclave) y código "no confiable" (mundo normal), utilizando instrucciones especiales (ECALL/OCALL) para transferir datos dentro y fuera del enclave. SGX proporciona un fuerte aislamiento para los enclaves y admite la atestación remota a través del Servicio de Atestación de Intel (IAS). Muchos proyectos de blockchain, especialmente Secret Network y Oasis Network, construyeron funcionalidades de contratos inteligentes que preservan la privacidad sobre enclaves SGX. Sin embargo, el diseño de SGX en arquitecturas x86 complejas ha llevado a algunas vulnerabilidades (ver §4), y la atestación de Intel introduce una dependencia de confianza centralizada.

• ARM TrustZone: TrustZone adopta un enfoque diferente al dividir todo el entorno de ejecución del procesador en dos mundos: un Mundo Seguro y un Mundo Normal. El código sensible se ejecuta en el Mundo Seguro, que tiene acceso a cierta memoria y periféricos protegidos, mientras que el Mundo Normal ejecuta el sistema operativo y las aplicaciones regulares. Los cambios entre mundos son controlados por la CPU. TrustZone se utiliza comúnmente en dispositivos móviles e IoT para cosas como una interfaz de usuario segura, procesamiento de pagos o gestión de derechos digitales. En un contexto de blockchain, TrustZone podría habilitar aplicaciones Web3 orientadas a móviles al permitir que las claves privadas o la lógica sensible se ejecuten en el enclave seguro del teléfono. Sin embargo, los enclaves de TrustZone suelen ser de grano más grueso (a nivel de SO o VM) y no son tan comúnmente adoptados en los proyectos Web3 actuales como SGX.

• AMD SEV (Secure Encrypted Virtualization): La tecnología SEV de AMD se dirige a entornos virtualizados. En lugar de requerir enclaves a nivel de aplicación, SEV puede cifrar la memoria de máquinas virtuales enteras. Utiliza un procesador de seguridad integrado para gestionar claves criptográficas y realizar el cifrado de memoria para que la memoria de una VM permanezca confidencial incluso para el hipervisor anfitrión. Esto hace que SEV sea muy adecuado para casos de uso en la nube o en servidores: por ejemplo, un nodo de blockchain o un trabajador off-chain podría ejecutarse dentro de una VM totalmente cifrada, protegiendo sus datos de un proveedor de nube malicioso. El diseño de SEV significa menos esfuerzo para el desarrollador para particionar el código (se puede ejecutar una aplicación existente o incluso un sistema operativo completo en una VM protegida). Iteraciones más nuevas como SEV-SNP añaden características como la detección de manipulaciones y permiten a los propietarios de VM atestiguar sus VM sin depender de un servicio centralizado. SEV es muy relevante para el uso de TEE en la infraestructura de blockchain basada en la nube.

Otras implementaciones de TEE emergentes o de nicho incluyen Intel TDX (Trust Domain Extensions, para una protección similar a un enclave en VMs en chips Intel más nuevos), TEEs de código abierto como Keystone (RISC-V), y chips de enclave seguro en móviles (como el Secure Enclave de Apple, aunque generalmente no está abierto para código arbitrario). Cada TEE viene con su propio modelo de desarrollo y supuestos de confianza, pero todos comparten la idea central de la ejecución segura aislada por hardware.

2. Aplicaciones de los TEEs en Web3​

Los Entornos de Ejecución Confiables se han convertido en una herramienta poderosa para abordar algunos de los desafíos más difíciles de Web3. Al proporcionar una capa de computación segura y privada, los TEEs habilitan nuevas posibilidades para las aplicaciones de blockchain en áreas de privacidad, escalabilidad, seguridad de oráculos e integridad. A continuación, exploramos los principales dominios de aplicación:

Contratos Inteligentes que Preservan la Privacidad​

Uno de los usos más prominentes de los TEEs en Web3 es habilitar contratos inteligentes confidenciales, programas que se ejecutan en una blockchain pero que pueden manejar datos privados de forma segura. Las blockchains como Ethereum son transparentes por defecto: todos los datos de las transacciones y el estado de los contratos son públicos. Esta transparencia es problemática para casos de uso que requieren confidencialidad (por ejemplo, transacciones financieras privadas, votaciones secretas, procesamiento de datos personales). Los TEEs proporcionan una solución al actuar como un enclave de computación que preserva la privacidad conectado a la blockchain.

En un sistema de contratos inteligentes impulsado por TEE, las entradas de las transacciones pueden enviarse a un enclave seguro en un nodo validador o trabajador, procesarse dentro del enclave donde permanecen cifradas para el mundo exterior, y luego el enclave puede emitir un resultado cifrado o hasheado de vuelta a la cadena. Solo las partes autorizadas con la clave de descifrado (o la propia lógica del contrato) pueden acceder al resultado en texto plano. Por ejemplo, Secret Network utiliza Intel SGX en sus nodos de consenso para ejecutar contratos inteligentes CosmWasm sobre entradas cifradas, de modo que cosas como los saldos de las cuentas, los montos de las transacciones o el estado del contrato pueden mantenerse ocultos al público mientras siguen siendo utilizables en los cálculos. Esto ha permitido aplicaciones de DeFi secreto, por ejemplo, intercambios de tokens privados donde los montos son confidenciales, o subastas secretas donde las ofertas están cifradas y solo se revelan después del cierre de la subasta. Otro ejemplo es Parcel de Oasis Network y su ParaTime confidencial, que permiten que los datos se tokenicen y se utilicen en contratos inteligentes bajo restricciones de confidencialidad, habilitando casos de uso como la calificación crediticia o los datos médicos en la blockchain con cumplimiento de la privacidad.

Los contratos inteligentes que preservan la privacidad a través de TEEs son atractivos para la adopción empresarial e institucional de la blockchain. Las organizaciones pueden aprovechar los contratos inteligentes mientras mantienen la lógica empresarial y los datos sensibles confidenciales. Por ejemplo, un banco podría usar un contrato habilitado para TEE para manejar solicitudes de préstamos o liquidaciones de operaciones sin exponer los datos de los clientes en la cadena, pero aún así beneficiarse de la transparencia y la integridad de la verificación de la blockchain. Esta capacidad aborda directamente los requisitos de privacidad regulatorios (como GDPR o HIPAA), permitiendo el uso compatible de la blockchain en la atención médica, las finanzas y otras industrias sensibles. De hecho, los TEEs facilitan el cumplimiento de las leyes de protección de datos al garantizar que los datos personales puedan procesarse dentro de un enclave con solo salidas cifradas, satisfaciendo a los reguladores de que los datos están salvaguardados.

Más allá de la confidencialidad, los TEEs también ayudan a hacer cumplir la equidad en los contratos inteligentes. Por ejemplo, un exchange descentralizado podría ejecutar su motor de emparejamiento dentro de un TEE para evitar que los mineros o validadores vean las órdenes pendientes y realicen front-running de manera injusta. En resumen, los TEEs aportan una muy necesaria capa de privacidad a Web3, desbloqueando aplicaciones como DeFi confidencial, votación/gobernanza privada y contratos empresariales que antes eran inviables en los registros públicos.

Escalabilidad y Computación Off-Chain​

Otro papel crítico para los TEEs es mejorar la escalabilidad de la blockchain al descargar cálculos pesados fuera de la cadena a un entorno seguro. Las blockchains tienen dificultades con tareas complejas o computacionalmente intensivas debido a los límites de rendimiento y los costos de la ejecución en la cadena. La computación off-chain habilitada por TEE permite que estas tareas se realicen fuera de la cadena principal (por lo tanto, sin consumir gas de bloque ni ralentizar el rendimiento en la cadena) mientras se conservan las garantías de confianza sobre la corrección de los resultados. En efecto, un TEE puede servir como un acelerador de computación off-chain verificable para Web3.

Por ejemplo, la plataforma iExec utiliza TEEs para crear un mercado descentralizado de computación en la nube donde los desarrolladores pueden ejecutar cálculos off-chain y obtener resultados que son confiables para la blockchain. Una dApp puede solicitar que una computación (digamos, una inferencia de un modelo de IA complejo o un análisis de big data) sea realizada por los nodos trabajadores de iExec. Estos nodos trabajadores ejecutan la tarea dentro de un enclave SGX, produciendo un resultado junto con una atestación de que el código correcto se ejecutó en un enclave genuino. El resultado se devuelve luego en la cadena, y el contrato inteligente puede verificar la atestación del enclave antes de aceptar la salida. Esta arquitectura permite que las cargas de trabajo pesadas se manejen off-chain sin sacrificar la confianza, aumentando efectivamente el rendimiento. La integración del Orquestador de iExec con Chainlink demuestra esto: un oráculo de Chainlink obtiene datos externos, luego entrega una computación compleja a los trabajadores TEE de iExec (por ejemplo, agregando o puntuando los datos), y finalmente el resultado seguro se entrega en la cadena. Los casos de uso incluyen cosas como cálculos de seguros descentralizados (como demostró iExec), donde se puede realizar una gran cantidad de procesamiento de datos off-chain y de manera económica, con solo el resultado final yendo a la blockchain.

La computación off-chain basada en TEE también sustenta algunas soluciones de escalado de Capa 2. El prototipo temprano de Oasis Labs, Ekiden (el precursor de Oasis Network), utilizó enclaves SGX para ejecutar transacciones off-chain en paralelo, y luego confirmar solo las raíces de estado en la cadena principal, de manera efectiva similar a las ideas de rollup pero utilizando la confianza del hardware. Al realizar la ejecución de contratos en TEEs, lograron un alto rendimiento mientras dependían de los enclaves para preservar la seguridad. Otro ejemplo es la próxima L2 Op-Succinct de Sanders Network, que combina TEEs y zkSNARKs: los TEEs ejecutan transacciones de forma privada y rápida, y luego se generan pruebas ZK para demostrar la corrección de esas ejecuciones a Ethereum. Este enfoque híbrido aprovecha la velocidad de los TEE y la verificabilidad de ZK para una solución L2 escalable y privada.

En general, los TEEs pueden ejecutar cálculos con un rendimiento casi nativo (ya que utilizan instrucciones reales de la CPU, solo con aislamiento), por lo que son órdenes de magnitud más rápidos que las alternativas puramente criptográficas como el cifrado homomórfico o las pruebas de conocimiento cero para lógica compleja. Al descargar el trabajo a los enclaves, las blockchains pueden manejar aplicaciones más complejas (como aprendizaje automático, procesamiento de imágenes/audio, análisis grandes) que serían imprácticas en la cadena. Los resultados regresan con una atestación, que el contrato en la cadena o los usuarios pueden verificar como originarios de un enclave de confianza, preservando así la integridad de los datos y la corrección. Este modelo a menudo se llama "computación off-chain verificable", y los TEEs son una piedra angular para muchos de estos diseños (por ejemplo, el Trusted Compute Framework de Hyperledger Avalon, desarrollado por Intel, iExec y otros, utiliza TEEs para ejecutar bytecode de EVM off-chain con una prueba de corrección publicada en la cadena).

Oráculos Seguros e Integridad de Datos​

Los oráculos conectan las blockchains con datos del mundo real, pero introducen desafíos de confianza: ¿cómo puede un contrato inteligente confiar en que una fuente de datos off-chain es correcta y no ha sido manipulada? Los TEEs proporcionan una solución al servir como un sandbox seguro para los nodos de oráculo. Un nodo de oráculo basado en TEE puede obtener datos de fuentes externas (APIs, servicios web) y procesarlos dentro de un enclave que garantiza que los datos no han sido manipulados por el operador del nodo o un malware en el nodo. El enclave puede luego firmar o atestiguar la veracidad de los datos que proporciona. Esto mejora significativamente la integridad y confiabilidad de los datos del oráculo. Incluso si un operador de oráculo es malicioso, no puede alterar los datos sin romper la atestación del enclave (que la blockchain detectará).

Un ejemplo notable es Town Crier, un sistema de oráculo desarrollado en Cornell que fue uno de los primeros en utilizar enclaves Intel SGX para proporcionar datos autenticados a los contratos de Ethereum. Town Crier recuperaría datos (por ejemplo, de sitios web HTTPS) dentro de un enclave SGX y los entregaría a un contrato junto con una prueba (una firma del enclave) de que los datos provenían directamente de la fuente y no fueron falsificados. Chainlink reconoció el valor de esto y adquirió Town Crier en 2018 para integrar oráculos basados en TEE en su red descentralizada. Hoy en día, Chainlink y otros proveedores de oráculos tienen iniciativas de TEE: por ejemplo, DECO y Fair Sequencing Services de Chainlink involucran TEEs para garantizar la confidencialidad de los datos y el ordenamiento justo. Como se señaló en un análisis, "TEE revolucionó la seguridad de los oráculos al proporcionar un entorno a prueba de manipulaciones para el procesamiento de datos... incluso los propios operadores de nodos no pueden manipular los datos mientras se están procesando". Esto es particularmente crucial para las fuentes de datos financieros de alto valor (como los oráculos de precios para DeFi): un TEE puede prevenir incluso manipulaciones sutiles que podrían llevar a grandes exploits.

Los TEEs también permiten a los oráculos manejar datos sensibles o propietarios que no podrían publicarse en texto plano en una blockchain. Por ejemplo, una red de oráculos podría usar enclaves para agregar datos privados (como libros de órdenes de acciones confidenciales o datos de salud personales) y alimentar solo resultados derivados o pruebas validadas a la blockchain, sin exponer las entradas sensibles en bruto. De esta manera, los TEEs amplían el alcance de los datos que pueden integrarse de forma segura en los contratos inteligentes, lo cual es crítico para la tokenización de activos del mundo real (RWA), la calificación crediticia, los seguros y otros servicios en cadena intensivos en datos.

En el tema de los puentes cross-chain, los TEEs mejoran de manera similar la integridad. Los puentes a menudo dependen de un conjunto de validadores o una multifirma para custodiar activos y validar transferencias entre cadenas, lo que los convierte en objetivos principales para ataques. Al ejecutar la lógica del validador del puente dentro de TEEs, se pueden asegurar las claves privadas y los procesos de verificación del puente contra la manipulación. Incluso si el sistema operativo de un validador está comprometido, el atacante no debería poder extraer claves privadas o falsificar mensajes desde dentro del enclave. Los TEEs pueden hacer cumplir que las transacciones del puente se procesen exactamente de acuerdo con las reglas del protocolo, reduciendo el riesgo de que operadores humanos o malware inyecten transferencias fraudulentas. Además, los TEEs pueden permitir que los atomic swaps y las transacciones cross-chain se manejen en un enclave seguro que completa ambos lados o se aborta limpiamente, evitando escenarios donde los fondos se quedan atascados debido a interferencias. Varios proyectos de puentes y consorcios han explorado la seguridad basada en TEE para mitigar la plaga de hackeos de puentes que han ocurrido en los últimos años.

Integridad de Datos y Verificabilidad Off-Chain​

En todos los escenarios anteriores, un tema recurrente es que los TEEs ayudan a mantener la integridad de los datos incluso fuera de la blockchain. Debido a que un TEE puede probar qué código está ejecutando (a través de la atestación) y puede garantizar que el código se ejecute sin interferencias, proporciona una forma de computación verificable. Los usuarios y los contratos inteligentes pueden confiar en los resultados que provienen de un TEE como si se hubieran calculado en la cadena, siempre que la atestación sea válida. Esta garantía de integridad es la razón por la que a veces se hace referencia a los TEEs como un "ancla de confianza" para los datos y la computación off-chain.

Sin embargo, vale la pena señalar que este modelo de confianza traslada algunas suposiciones al hardware (ver §4). La integridad de los datos es tan fuerte como la seguridad del TEE. Si el enclave se ve comprometido o la atestación se falsifica, la integridad podría fallar. No obstante, en la práctica, los TEEs (cuando se mantienen actualizados) hacen que ciertos ataques sean significativamente más difíciles. Por ejemplo, una plataforma de préstamos DeFi podría usar un TEE para calcular puntajes de crédito a partir de los datos privados de un usuario off-chain, y el contrato inteligente aceptaría el puntaje solo si va acompañado de una atestación de enclave válida. De esta manera, el contrato sabe que el puntaje fue calculado por el algoritmo aprobado sobre datos reales, en lugar de confiar ciegamente en el usuario o en un oráculo.

Los TEEs también juegan un papel en los sistemas emergentes de identidad descentralizada (DID) y autenticación. Pueden gestionar de forma segura claves privadas, datos personales y procesos de autenticación de una manera que la información sensible del usuario nunca se exponga a la blockchain o a los proveedores de dApps. Por ejemplo, un TEE en un dispositivo móvil podría manejar la autenticación biométrica y firmar una transacción de blockchain si la verificación biométrica pasa, todo sin revelar los datos biométricos del usuario. Esto proporciona tanto seguridad como privacidad en la gestión de la identidad, un componente esencial si Web3 va a manejar cosas como pasaportes, certificados o datos KYC de una manera soberana para el usuario.

En resumen, los TEEs sirven como una herramienta versátil en Web3: permiten la confidencialidad para la lógica en la cadena, permiten el escalado a través de la computación segura off-chain, protegen la integridad de los oráculos y puentes, y abren nuevos usos (desde la identidad privada hasta el intercambio de datos compatible). A continuación, veremos proyectos específicos que aprovechan estas capacidades.

3. Proyectos Web3 Notables que Aprovechan los TEEs​

Varios proyectos líderes de blockchain han construido sus ofertas principales en torno a los Entornos de Ejecución Confiables. A continuación, nos sumergimos en algunos de los más notables, examinando cómo cada uno utiliza la tecnología TEE y qué valor único añade:

Secret Network​

Secret Network es una blockchain de capa 1 (construida sobre el SDK de Cosmos) que fue pionera en los contratos inteligentes que preservan la privacidad utilizando TEEs. Todos los nodos validadores en Secret Network ejecutan enclaves Intel SGX, que ejecutan el código del contrato inteligente de modo que el estado del contrato y las entradas/salidas permanecen cifrados incluso para los operadores de los nodos. Esto convierte a Secret en una de las primeras plataformas de contratos inteligentes con privacidad por defecto: la privacidad no es un complemento opcional, sino una característica predeterminada de la red a nivel de protocolo.

En el modelo de Secret Network, los usuarios envían transacciones cifradas, que los validadores cargan en su enclave SGX para su ejecución. El enclave descifra las entradas, ejecuta el contrato (escrito en un tiempo de ejecución CosmWasm modificado) y produce salidas cifradas que se escriben en la blockchain. Solo los usuarios con la clave de visualización correcta (o el propio contrato con su clave interna) pueden descifrar y ver los datos reales. Esto permite que las aplicaciones utilicen datos privados en la cadena sin revelarlos públicamente.

La red ha demostrado varios casos de uso novedosos:

• DeFi Secreto: por ejemplo, SecretSwap (un AMM) donde los saldos de las cuentas de los usuarios y los montos de las transacciones son privados, mitigando el front-running y protegiendo las estrategias de trading. Los proveedores de liquidez y los traders pueden operar sin transmitir cada uno de sus movimientos a la competencia.
• Subastas Secretas: Contratos de subasta donde las ofertas se mantienen en secreto hasta que finaliza la subasta, evitando el comportamiento estratégico basado en las ofertas de otros.
• Votación y Gobernanza Privada: Los poseedores de tokens pueden votar sobre propuestas sin revelar sus opciones de voto, mientras que el recuento aún puede ser verificado, asegurando una gobernanza justa y libre de intimidación.
• Mercados de datos: Conjuntos de datos sensibles pueden ser transaccionados y utilizados en cálculos sin exponer los datos brutos a compradores o nodos.

Secret Network esencialmente incorpora TEEs a nivel de protocolo para crear una propuesta de valor única: ofrece privacidad programable. Los desafíos que abordan incluyen la coordinación de la atestación de enclaves en un conjunto de validadores descentralizado y la gestión de la distribución de claves para que los contratos puedan descifrar las entradas mientras las mantienen en secreto para los validadores. A todas luces, Secret ha demostrado la viabilidad de la confidencialidad impulsada por TEE en una blockchain pública, estableciéndose como un líder en el espacio.

Oasis Network​

Oasis Network es otra capa 1 orientada a la escalabilidad y la privacidad, que utiliza extensivamente TEEs (Intel SGX) en su arquitectura. Oasis introdujo un diseño innovador que separa el consenso de la computación en diferentes capas llamadas la Capa de Consenso y la Capa ParaTime. La Capa de Consenso se encarga del ordenamiento y la finalidad de la blockchain, mientras que cada ParaTime puede ser un entorno de ejecución para contratos inteligentes. Notablemente, el Emerald ParaTime de Oasis es un entorno compatible con EVM, y Sapphire es un EVM confidencial que utiliza TEEs para mantener privado el estado de los contratos inteligentes.

El uso de TEEs por parte de Oasis se centra en la computación confidencial a escala. Al aislar la computación pesada en ParaTimes paralelizables (que pueden ejecutarse en muchos nodos), logran un alto rendimiento, y al usar TEEs dentro de esos nodos ParaTime, aseguran que los cálculos puedan incluir datos sensibles sin revelarlos. Por ejemplo, una institución podría ejecutar un algoritmo de calificación crediticia en Oasis alimentando datos privados en un ParaTime confidencial: los datos permanecen cifrados para el nodo (ya que se procesan en el enclave), y solo sale la puntuación. Mientras tanto, el consenso de Oasis solo registra la prueba de que la computación se realizó correctamente.

Técnicamente, Oasis añadió capas adicionales de seguridad más allá de SGX estándar. Implementaron una "raíz de confianza en capas": utilizando el Enclave de Cotización SGX de Intel y un kernel ligero personalizado para verificar la confiabilidad del hardware y para aislar las llamadas al sistema del enclave. Esto reduce la superficie de ataque (al filtrar qué llamadas al SO pueden hacer los enclaves) y protege contra ciertos ataques conocidos de SGX. Oasis también introdujo características como enclaves duraderos (para que los enclaves puedan persistir el estado a través de reinicios) y registro seguro para mitigar los ataques de reversión (donde un nodo podría intentar reproducir un estado de enclave antiguo). Estas innovaciones se describieron en sus documentos técnicos y son parte de por qué Oasis es visto como un proyecto impulsado por la investigación en la computación de blockchain basada en TEE.

Desde una perspectiva de ecosistema, Oasis se ha posicionado para cosas como DeFi privado (permitiendo que los bancos participen sin filtrar los datos de los clientes) y la tokenización de datos (donde individuos o empresas pueden compartir datos con modelos de IA de manera confidencial y ser compensados, todo a través de la blockchain). También han colaborado con empresas en proyectos piloto (por ejemplo, trabajando con BMW en la privacidad de datos, y otros en el intercambio de datos de investigación médica). En general, Oasis Network muestra cómo la combinación de TEEs con una arquitectura escalable puede abordar tanto la privacidad como el rendimiento, convirtiéndolo en un actor significativo en las soluciones Web3 basadas en TEE.

Sanders Network​

Sanders Network es una red de computación en la nube descentralizada en el ecosistema de Polkadot que utiliza TEEs para proporcionar servicios de computación confidenciales y de alto rendimiento. Es una parachain en Polkadot, lo que significa que se beneficia de la seguridad e interoperabilidad de Polkadot, pero introduce su propio tiempo de ejecución novedoso para la computación off-chain en enclaves seguros.

La idea central de Sanders es mantener una gran red de nodos trabajadores (llamados mineros de Sanders) que ejecutan tareas dentro de TEEs (específicamente, Intel SGX hasta ahora) y producen resultados verificables. Estas tareas pueden variar desde ejecutar segmentos de contratos inteligentes hasta computación de propósito general solicitada por los usuarios. Debido a que los trabajadores se ejecutan en SGX, Sanders asegura que los cálculos se realizan con confidencialidad (los datos de entrada están ocultos para el operador del trabajador) e integridad (los resultados vienen con una atestación). Esto crea efectivamente una nube sin confianza donde los usuarios pueden desplegar cargas de trabajo sabiendo que el anfitrión no puede espiar ni manipularlas.

Se puede pensar en Sanders como análogo a Amazon EC2 o AWS Lambda, pero descentralizado: los desarrolladores pueden desplegar código en la red de Sanders y hacer que se ejecute en muchas máquinas habilitadas para SGX en todo el mundo, pagando con el token de Sanders por el servicio. Algunos casos de uso destacados:

• Análisis e IA en Web3: Un proyecto podría analizar datos de usuarios o ejecutar algoritmos de IA en enclaves de Sanders, de modo que los datos brutos de los usuarios permanezcan cifrados (protegiendo la privacidad) mientras que solo las ideas agregadas salen del enclave.
• Backends de juegos y Metaverso: Sanders puede manejar lógica de juego intensiva o simulaciones de mundos virtuales off-chain, enviando solo compromisos o hashes a la blockchain, permitiendo una jugabilidad más rica sin confiar en un solo servidor.
• Servicios en cadena: Sanders ha construido una plataforma de computación off-chain llamada Sanders Cloud. Por ejemplo, puede servir como backend para bots, servicios web descentralizados, o incluso un libro de órdenes off-chain que publica operaciones en un contrato inteligente de DEX con atestación TEE.

Sanders enfatiza que puede escalar la computación confidencial horizontalmente: ¿necesitas más capacidad? Añade más nodos trabajadores TEE. Esto es diferente a una sola blockchain donde la capacidad de cómputo está limitada por el consenso. Así, Sanders abre posibilidades para dApps computacionalmente intensivas que aún desean seguridad sin confianza. Es importante destacar que Sanders no se basa únicamente en la confianza del hardware; se está integrando con el consenso de Polkadot (por ejemplo, staking y slashing por resultados incorrectos) e incluso explorando una combinación de TEE con pruebas de conocimiento cero (como se mencionó, su próxima L2 utiliza TEE para acelerar la ejecución y ZKP para verificarla de manera sucinta en Ethereum). Este enfoque híbrido ayuda a mitigar el riesgo de cualquier compromiso de un solo TEE al agregar verificación criptográfica por encima.

En resumen, Sanders Network aprovecha los TEEs para ofrecer una nube descentralizada y confidencial para Web3, permitiendo la computación off-chain con garantías de seguridad. Esto libera una clase de aplicaciones de blockchain que necesitan tanto cómputo pesado como privacidad de datos, cerrando la brecha entre los mundos on-chain y off-chain.

iExec​

iExec es un mercado descentralizado para recursos de computación en la nube construido sobre Ethereum. A diferencia de los tres anteriores (que son sus propias cadenas o parachains), iExec opera como una red de capa 2 o off-chain que se coordina con los contratos inteligentes de Ethereum. Los TEEs (específicamente Intel SGX) son una piedra angular del enfoque de iExec para establecer la confianza en la computación off-chain.

La red iExec consta de nodos trabajadores contribuidos por varios proveedores. Estos trabajadores pueden ejecutar tareas solicitadas por los usuarios (desarrolladores de dApps, proveedores de datos, etc.). Para garantizar que estos cálculos off-chain sean confiables, iExec introdujo un marco de "Computación Off-chain Confiable": las tareas pueden ejecutarse dentro de enclaves SGX, y los resultados vienen con una firma de enclave que prueba que la tarea se ejecutó correctamente en un nodo seguro. iExec se asoció con Intel para lanzar esta función de computación confiable e incluso se unió al Confidential Computing Consortium para avanzar en los estándares. Su protocolo de consenso, llamado Prueba de Contribución (PoCo), agrega votos/atestaciones de múltiples trabajadores cuando es necesario para alcanzar un consenso sobre el resultado correcto. En muchos casos, la atestación de un solo enclave puede ser suficiente si el código es determinista y la confianza en SGX es alta; para una mayor seguridad, iExec puede replicar tareas en varios TEEs y usar un consenso o un voto mayoritario.

La plataforma de iExec permite varios casos de uso interesantes:

• Computación de Oráculos Descentralizados: Como se mencionó anteriormente, iExec puede trabajar con Chainlink. Un nodo de Chainlink podría obtener datos brutos, luego entregarlos a un trabajador SGX de iExec para realizar un cálculo (por ejemplo, un algoritmo propietario o una inferencia de IA) sobre esos datos, y finalmente devolver un resultado en la cadena. Esto amplía lo que los oráculos pueden hacer más allá de simplemente retransmitir datos: ahora pueden proporcionar servicios computados (como llamar a un modelo de IA o agregar muchas fuentes) con TEE garantizando la honestidad.
• IA y DePIN (Red de Infraestructura Física Descentralizada): iExec se está posicionando como una capa de confianza para aplicaciones de IA descentralizadas. Por ejemplo, una dApp que utiliza un modelo de aprendizaje automático puede ejecutar el modelo en un enclave para proteger tanto el modelo (si es propietario) como los datos del usuario que se introducen. En el contexto de DePIN (como las redes de IoT distribuidas), los TEEs se pueden utilizar en dispositivos de borde para confiar en las lecturas de los sensores y los cálculos sobre esas lecturas.
• Monetización Segura de Datos: Los proveedores de datos pueden hacer que sus conjuntos de datos estén disponibles en el mercado de iExec en forma cifrada. Los compradores pueden enviar sus algoritmos para que se ejecuten sobre los datos dentro de un TEE (de modo que los datos brutos del proveedor de datos nunca se revelen, protegiendo su propiedad intelectual, y los detalles del algoritmo también pueden ocultarse). El resultado del cálculo se devuelve al comprador, y el pago apropiado al proveedor de datos se maneja a través de contratos inteligentes. Este esquema, a menudo llamado intercambio seguro de datos, es facilitado por la confidencialidad de los TEEs.

En general, iExec proporciona el pegamento entre los contratos inteligentes de Ethereum y la ejecución segura off-chain. Demuestra cómo los "trabajadores" TEE pueden conectarse en red para formar una nube descentralizada, completa con un mercado (utilizando el token RLC de iExec para el pago) y mecanismos de consenso. Al liderar el grupo de trabajo de Computación Confiable de la Enterprise Ethereum Alliance y contribuir a los estándares (como Hyperledger Avalon), iExec también impulsa una adopción más amplia de los TEEs en escenarios de blockchain empresarial.

Otros Proyectos y Ecosistemas​

Más allá de los cuatro anteriores, hay algunos otros proyectos que vale la pena señalar:

• Integritee – otra parachain de Polkadot similar a Sanders (de hecho, surgió del trabajo de TEE de la Energy Web Foundation). Integritee utiliza TEEs para crear "parachain-como-servicio" para empresas, combinando el procesamiento de enclaves on-chain y off-chain.
• Automata Network – un protocolo de middleware para la privacidad en Web3 que aprovecha los TEEs para transacciones privadas, votación anónima y procesamiento de transacciones resistente a MEV. Automata funciona como una red off-chain que proporciona servicios como un relé RPC privado y se mencionó que utiliza TEEs para cosas como identidad protegida y transacciones privadas sin gas.
• Hyperledger Sawtooth (PoET) – en el ámbito empresarial, Sawtooth introdujo un algoritmo de consenso llamado Prueba de Tiempo Transcurrido que se basaba en SGX. Cada validador ejecuta un enclave que espera un tiempo aleatorio y produce una prueba; el que tiene la espera más corta "gana" el bloque, una lotería justa impuesta por SGX. Aunque Sawtooth no es un proyecto Web3 per se (más bien blockchain empresarial), es un uso creativo de los TEEs para el consenso.
• Cadenas Empresariales/de Consorcio – Muchas soluciones de blockchain empresarial (por ejemplo, ConsenSys Quorum, IBM Blockchain) incorporan TEEs para permitir transacciones de consorcio confidenciales, donde solo los nodos autorizados ven ciertos datos. Por ejemplo, el plan del Trusted Compute Framework (TCF) de la Enterprise Ethereum Alliance utiliza TEEs para ejecutar contratos privados off-chain y entregar pruebas de Merkle en la cadena.

Estos proyectos muestran colectivamente la versatilidad de los TEEs: impulsan L1s enteras centradas en la privacidad, sirven como redes off-chain, aseguran piezas de infraestructura como oráculos y puentes, e incluso sustentan algoritmos de consenso. A continuación, consideramos los beneficios y desafíos más amplios del uso de TEEs en entornos descentralizados.

4. Beneficios y Desafíos de los TEEs en Entornos Descentralizados​

La adopción de Entornos de Ejecución Confiables en sistemas de blockchain conlleva importantes beneficios técnicos, así como notables desafíos y compromisos. Examinaremos ambos lados: lo que los TEEs ofrecen a las aplicaciones descentralizadas y qué problemas o riesgos surgen de su uso.

Beneficios y Fortalezas Técnicas​

• Fuerte Seguridad y Privacidad: El principal beneficio son las garantías de confidencialidad e integridad. Los TEEs permiten que el código sensible se ejecute con la seguridad de que no será espiado ni alterado por malware externo. Esto proporciona un nivel de confianza en la computación off-chain que antes no estaba disponible. Para la blockchain, esto significa que se pueden utilizar datos privados (mejorando la funcionalidad de las dApps) sin sacrificar la seguridad. Incluso en entornos no confiables (servidores en la nube, nodos validadores gestionados por terceros), los TEEs mantienen los secretos a salvo. Esto es especialmente beneficioso para gestionar claves privadas, datos de usuario y algoritmos propietarios dentro de los sistemas cripto. Por ejemplo, una billetera de hardware o un servicio de firma en la nube podría usar un TEE para firmar transacciones de blockchain internamente para que la clave privada nunca se exponga en texto plano, combinando conveniencia con seguridad.

• Rendimiento Casi Nativo: A diferencia de los enfoques puramente criptográficos para la computación segura (como las pruebas ZK o el cifrado homomórfico), la sobrecarga de los TEE es relativamente pequeña. El código se ejecuta directamente en la CPU, por lo que un cálculo dentro de un enclave es aproximadamente tan rápido como ejecutarlo fuera (con cierta sobrecarga por las transiciones del enclave y el cifrado de memoria, típicicamente ralentizaciones de un solo dígito porcentual en SGX). Esto significa que los TEEs pueden manejar tareas computacionalmente intensivas de manera eficiente, permitiendo casos de uso (como fuentes de datos en tiempo real, contratos inteligentes complejos, aprendizaje automático) que serían órdenes de magnitud más lentos si se hicieran con protocolos criptográficos. La baja latencia de los enclaves los hace adecuados donde se necesita una respuesta rápida (por ejemplo, bots de trading de alta frecuencia asegurados por TEEs, o aplicaciones y juegos interactivos donde la experiencia del usuario sufriría con grandes retrasos).

• Escalabilidad Mejorada (a través de la Descarga): Al permitir que los cálculos pesados se realicen de forma segura off-chain, los TEEs ayudan a aliviar la congestión y los costos de gas en las cadenas principales. Habilitan diseños de Capa 2 y protocolos secundarios donde la blockchain se utiliza solo para verificación o liquidación final, mientras que la mayor parte de la computación ocurre en enclaves paralelos. Esta modularización (lógica computacionalmente intensiva en TEEs, consenso en la cadena) puede mejorar drásticamente el rendimiento y la escalabilidad de las aplicaciones descentralizadas. Por ejemplo, un DEX podría hacer el emparejamiento en un TEE off-chain y solo publicar las operaciones emparejadas en la cadena, aumentando el rendimiento y reduciendo el gas en la cadena.

• Mejor Experiencia de Usuario y Funcionalidad: Con los TEEs, las dApps pueden ofrecer características como confidencialidad o análisis complejos que atraen a más usuarios (incluidas las instituciones). Los TEEs también permiten transacciones sin gas o meta-transacciones al ejecutarlas de forma segura off-chain y luego enviar los resultados, como se señaló en el uso de TEEs por parte de Automata para reducir el gas en transacciones privadas. Además, almacenar el estado sensible off-chain en un enclave puede reducir los datos publicados en la cadena, lo cual es bueno para la privacidad del usuario y la eficiencia de la red (menos datos en la cadena para almacenar/verificar).

• Composabilidad con Otras Tecnologías: Curiosamente, los TEEs pueden complementar otras tecnologías (no es estrictamente un beneficio inherente a los TEEs solos, sino en combinación). Pueden servir como el pegamento que une soluciones híbridas: por ejemplo, ejecutar un programa en un enclave y también generar una prueba ZK de su ejecución, donde el enclave ayuda con partes del proceso de prueba para acelerarlo. O usar TEEs en redes MPC para manejar ciertas tareas con menos rondas de comunicación. Discutiremos las comparaciones en el §5, pero muchos proyectos destacan que los TEEs no tienen que reemplazar la criptografía, pueden trabajar junto a ella para reforzar la seguridad (el mantra de Sanders: "La fuerza de los TEEs radica en apoyar a otros, no en reemplazarlos").

Supuestos de Confianza y Vulnerabilidades de Seguridad​

A pesar de sus fortalezas, los TEEs introducen supuestos de confianza específicos y no son invulnerables. Es crucial entender estos desafíos:

• Confianza en el Hardware y Centralización: Al usar TEEs, uno está depositando inherentemente confianza en el proveedor de silicio y en la seguridad de su diseño de hardware y cadena de suministro. Por ejemplo, usar Intel SGX significa confiar en que Intel no tiene puertas traseras, que su fabricación es segura y que el microcódigo de la CPU implementa correctamente el aislamiento del enclave. Este es un modelo de confianza más centralizado en comparación con la criptografía pura (que se basa en supuestos matemáticos distribuidos entre todos los usuarios). Además, la atestación para SGX históricamente depende de contactar al Servicio de Atestación de Intel, lo que significa que si Intel se desconectara o decidiera revocar claves, los enclaves a nivel mundial podrían verse afectados. Esta dependencia de la infraestructura de una sola empresa plantea preocupaciones: podría ser un único punto de fallo o incluso un objetivo de regulación gubernamental (por ejemplo, los controles de exportación de EE. UU. podrían en teoría restringir quién puede usar TEEs fuertes). AMD SEV mitiga esto al permitir una atestación más descentralizada (los propietarios de VM pueden atestiguar sus VM), pero aún así se confía en el chip y el firmware de AMD. El riesgo de centralización a menudo se cita como algo antitético a la descentralización de la blockchain. Proyectos como Keystone (TEE de código abierto) y otros están investigando formas de reducir la dependencia de cajas negras propietarias, pero aún no son de uso generalizado.

• Canal Lateral y Otras Vulnerabilidades: Un TEE no es una bala de plata; puede ser atacado a través de medios indirectos. Los ataques de canal lateral explotan el hecho de que incluso si el acceso directo a la memoria está bloqueado, la operación de un enclave podría influir sutilmente en el sistema (a través del tiempo, el uso de la caché, el consumo de energía, las emisiones electromagnéticas, etc.). En los últimos años, se han demostrado numerosos ataques académicos a Intel SGX: desde Foreshadow (extracción de secretos del enclave a través de fugas de tiempo de la caché L1) hasta Plundervolt (inyección de fallos de voltaje a través de instrucciones privilegiadas) y SGAxe (extracción de claves de atestación), entre otros. Estos ataques sofisticados muestran que los TEEs pueden ser comprometidos sin necesidad de romper las protecciones criptográficas, sino explotando comportamientos microarquitectónicos o fallos en la implementación. Como resultado, se reconoce que "los investigadores han identificado varios vectores de ataque potenciales que podrían explotar vulnerabilidades de hardware o diferencias de tiempo en las operaciones de TEE". Aunque estos ataques no son triviales y a menudo requieren acceso local o hardware malicioso, son una amenaza real. Los TEEs tampoco protegen generalmente contra ataques físicos si un adversario tiene el chip en sus manos (por ejemplo, decapsular el chip, sondear buses, etc., puede derrotar a la mayoría de los TEEs comerciales).

  Las respuestas de los proveedores a los descubrimientos de canales laterales han sido parches de microcódigo y actualizaciones del SDK del enclave para mitigar las fugas conocidas (a veces a costa del rendimiento). Pero sigue siendo un juego del gato y el ratón. Para Web3, esto significa que si alguien encuentra un nuevo canal lateral en SGX, un contrato DeFi "seguro" que se ejecuta en SGX podría ser explotado (por ejemplo, para filtrar datos secretos o manipular la ejecución). Por lo tanto, depender de los TEEs significa aceptar una superficie de vulnerabilidad potencial a nivel de hardware que está fuera del modelo de amenaza típico de la blockchain. Es un área activa de investigación para fortalecer los TEEs contra estos (por ejemplo, diseñando código de enclave con operaciones de tiempo constante, evitando patrones de acceso a memoria dependientes de secretos y utilizando técnicas como la RAM ajena). Algunos proyectos también aumentan los TEEs con verificaciones secundarias, por ejemplo, combinándolos con pruebas ZK, o haciendo que múltiples enclaves se ejecuten en hardware de diferentes proveedores para reducir el riesgo de un solo chip.

• Rendimiento y Restricciones de Recursos: Aunque los TEEs se ejecutan a una velocidad casi nativa para tareas ligadas a la CPU, tienen algunas sobrecargas y límites. Entrar en un enclave (un ECALL) y salir (OCALL) tiene un costo, al igual que el cifrado/descifrado de las páginas de memoria. Esto puede afectar el rendimiento en cruces de límites de enclave muy frecuentes. Los enclaves también suelen tener limitaciones de tamaño de memoria. Por ejemplo, los primeros SGX tenían una Caché de Páginas de Enclave limitada y cuando los enclaves usaban más memoria, las páginas tenían que ser intercambiadas (con cifrado), lo que ralentizaba masivamente el rendimiento. Incluso los TEEs más nuevos a menudo no permiten usar toda la RAM del sistema fácilmente; hay una región de memoria segura que podría estar limitada. Esto significa que los cálculos o conjuntos de datos a muy gran escala podrían ser difíciles de manejar por completo dentro de un TEE. En contextos de Web3, esto podría limitar la complejidad de los contratos inteligentes o los modelos de ML que pueden ejecutarse en un enclave. Los desarrolladores tienen que optimizar la memoria y posiblemente dividir las cargas de trabajo.

• Complejidad de la Atestación y la Gestión de Claves: Usar TEEs en un entorno descentralizado requiere flujos de trabajo de atestación robustos: cada nodo necesita demostrar a los demás que está ejecutando un enclave auténtico con el código esperado. Configurar esta verificación de atestación en la cadena puede ser complejo. Generalmente implica codificar la clave pública de atestación o el certificado del proveedor en el protocolo y escribir la lógica de verificación en contratos inteligentes o clientes off-chain. Esto introduce una sobrecarga en el diseño del protocolo, y cualquier cambio (como que Intel cambie su formato de clave de firma de atestación de EPID a DCAP) puede causar cargas de mantenimiento. Además, la gestión de claves dentro de los TEEs (para descifrar datos o firmar resultados) añade otra capa de complejidad. Los errores en la gestión de claves del enclave podrían socavar la seguridad (por ejemplo, si un enclave expone inadvertidamente una clave de descifrado a través de un error, todas sus promesas de confidencialidad se derrumban). Las mejores prácticas implican el uso de las API de sellado del TEE para almacenar claves de forma segura y rotar las claves si es necesario, pero de nuevo, esto requiere un diseño cuidadoso por parte de los desarrolladores.

• Denegación de Servicio y Disponibilidad: Un problema quizás menos discutido: los TEEs no ayudan con la disponibilidad e incluso pueden introducir nuevas vías de DoS. Por ejemplo, un atacante podría inundar un servicio basado en TEE con entradas que son costosas de procesar, sabiendo que el enclave no puede ser inspeccionado o interrumpido fácilmente por el operador (ya que está aislado). Además, si se encuentra una vulnerabilidad y un parche requiere actualizaciones de firmware, durante ese ciclo muchos servicios de enclave podrían tener que pausarse (por seguridad) hasta que los nodos estén parcheados, causando tiempo de inactividad. En el consenso de la blockchain, imagina si se encontrara un error crítico en SGX: redes como Secret podrían tener que detenerse hasta que haya una solución, ya que la confianza en los enclaves se rompería. La coordinación de tales respuestas en una red descentralizada es un desafío.

Composabilidad y Limitaciones del Ecosistema​

• Composabilidad Limitada con Otros Contratos: En una plataforma de contratos inteligentes pública como Ethereum, los contratos pueden llamar fácilmente a otros contratos y todo el estado está abierto, lo que permite los legos de dinero de DeFi y una rica composición. En un modelo de contrato basado en TEE, el estado privado no se puede compartir o componer libremente sin romper la confidencialidad. Por ejemplo, si el Contrato A en un enclave necesita interactuar con el Contrato B, y ambos tienen algunos datos secretos, ¿cómo colaboran? O deben realizar un complejo protocolo seguro multipartita (lo que niega parte de la simplicidad de los TEEs) o se combinan en un solo enclave (reduciendo la modularidad). Este es un desafío que Secret Network y otros enfrentan: las llamadas entre contratos con privacidad no son triviales. Algunas soluciones implican tener un solo enclave que maneje la ejecución de múltiples contratos para que pueda gestionar internamente los secretos compartidos, pero eso puede hacer que el sistema sea más monolítico. Por lo tanto, la composabilidad de los contratos privados es más limitada que la de los públicos, o requiere nuevos patrones de diseño. De manera similar, la integración de módulos basados en TEE en dApps de blockchain existentes requiere un diseño de interfaz cuidadoso: a menudo solo el resultado de un enclave se publica en la cadena, que podría ser un snark o un hash, y otros contratos solo pueden usar esa información limitada. Esto es ciertamente un compromiso; proyectos como Secret proporcionan claves de visualización y permiten compartir secretos según sea necesario, pero no es tan fluido como la composabilidad normal en la cadena.

• Estandarización e Interoperabilidad: El ecosistema TEE actualmente carece de estándares unificados entre los proveedores. Intel SGX, AMD SEV, ARM TrustZone tienen todos diferentes modelos de programación y métodos de atestación. Esta fragmentación significa que una dApp escrita para enclaves SGX no es trivialmente portable a TrustZone, etc. En la blockchain, esto puede atar un proyecto a un hardware específico (por ejemplo, Secret y Oasis están atados a servidores x86 con SGX en este momento). Si en el futuro quisieran admitir nodos ARM (digamos, validadores en móviles), requeriría un desarrollo adicional y quizás una lógica de verificación de atestación diferente. Hay esfuerzos (como el CCC – Confidential Computing Consortium) para estandarizar la atestación y las API de enclaves, pero aún no hemos llegado a ese punto. La falta de estándares también afecta las herramientas para desarrolladores: uno podría encontrar el SDK de SGX maduro pero luego necesitar adaptarse a otro TEE con un SDK diferente. Este desafío de interoperabilidad puede ralentizar la adopción y aumentar los costos.

• Curva de Aprendizaje para Desarrolladores: Construir aplicaciones que se ejecutan dentro de TEEs requiere un conocimiento especializado que muchos desarrolladores de blockchain pueden no tener. A menudo se necesita programación de bajo nivel en C/C++ (para SGX/TrustZone) o comprensión de la seguridad de la memoria y la codificación resistente a canales laterales. La depuración del código del enclave es notoriamente complicada (¡no se puede ver fácilmente dentro de un enclave mientras se está ejecutando por razones de seguridad!). Aunque existen frameworks y lenguajes de nivel superior (como el uso de Rust por parte de Oasis para su tiempo de ejecución confidencial, o incluso herramientas para ejecutar WebAssembly en enclaves), la experiencia del desarrollador sigue siendo más difícil que el desarrollo típico de contratos inteligentes o el desarrollo web2 off-chain. Esta curva de aprendizaje pronunciada y las herramientas inmaduras pueden disuadir a los desarrolladores o llevar a errores si no se manejan con cuidado. También está el aspecto de necesitar hardware para probar: ejecutar código SGX necesita una CPU habilitada para SGX o un emulador (que es más lento), por lo que la barrera de entrada es más alta. Como resultado, relativamente pocos desarrolladores hoy en día están profundamente familiarizados con el desarrollo de enclaves, lo que hace que las auditorías y el apoyo de la comunidad sean más escasos que en, digamos, la bien transitada comunidad de Solidity.

• Costos Operativos: Ejecutar una infraestructura basada en TEE puede ser más costoso. El hardware en sí podría ser más caro o escaso (por ejemplo, ciertos proveedores de la nube cobran una prima por las VM con capacidad SGX). También hay una sobrecarga en las operaciones: mantener el firmware actualizado (para parches de seguridad), gestionar la red de atestación, etc., lo que los proyectos pequeños podrían encontrar oneroso. Si cada nodo debe tener una cierta CPU, podría reducir el grupo potencial de validadores (no todos tienen el hardware requerido), afectando así la descentralización y posiblemente llevando a un mayor uso de alojamiento en la nube.

En resumen, aunque los TEEs desbloquean características potentes, también traen compromisos de confianza (confianza en el hardware vs. confianza en las matemáticas), debilidades de seguridad potenciales (especialmente canales laterales) y obstáculos de integración en un contexto descentralizado. Los proyectos que utilizan TEEs deben ingeniárselas cuidadosamente en torno a estos problemas, empleando defensa en profundidad (no asumir que el TEE es inquebrantable), manteniendo la base de computación confiable al mínimo y siendo transparentes sobre los supuestos de confianza para los usuarios (para que quede claro, por ejemplo, que se está confiando en el hardware de Intel además del consenso de la blockchain).

5. TEEs vs. Otras Tecnologías que Preservan la Privacidad (ZKP, FHE, MPC)​

Los Entornos de Ejecución Confiables son un enfoque para lograr la privacidad y la seguridad en Web3, pero existen otras técnicas importantes que incluyen las Pruebas de Conocimiento Cero (ZKPs), el Cifrado Totalmente Homomórfico (FHE) y la Computación Segura Multipartita (MPC). Cada una de estas tecnologías tiene un modelo de confianza y un perfil de rendimiento diferentes. En muchos casos, no son mutuamente excluyentes, pueden complementarse entre sí, pero es útil comparar sus compromisos en rendimiento, confianza y usabilidad para el desarrollador:

Para definir brevemente las alternativas:

• ZKPs: Pruebas criptográficas (como zk-SNARKs, zk-STARKs) que permiten a una parte demostrar a otras que una afirmación es verdadera (por ejemplo, "conozco un secreto que satisface este cálculo") sin revelar por qué es verdadera (ocultando la entrada secreta). En la blockchain, las ZKPs se utilizan para transacciones privadas (por ejemplo, Zcash, Aztec) y para la escalabilidad (rollups que publican pruebas de ejecución correcta). Garantizan una fuerte privacidad (no se filtra ningún dato secreto, solo pruebas) y una integridad garantizada por las matemáticas, pero generar estas pruebas puede ser computacionalmente pesado y los circuitos deben diseñarse cuidadosamente.
• FHE: Esquema de cifrado que permite la computación arbitraria sobre datos cifrados, de modo que el resultado, al ser descifrado, coincide con el resultado de computar sobre textos planos. En teoría, el FHE proporciona la máxima privacidad: los datos permanecen cifrados en todo momento, y no es necesario confiar en nadie con los datos brutos. Pero el FHE es extremadamente lento para cálculos generales (aunque está mejorando con la investigación); todavía se encuentra principalmente en uso experimental o especializado debido al rendimiento.
• MPC: Protocolos donde múltiples partes calculan conjuntamente una función sobre sus entradas privadas sin revelar esas entradas entre sí. A menudo implica compartir secretos de los datos entre las partes y realizar operaciones criptográficas para que la salida sea correcta pero las entradas individuales permanezcan ocultas. El MPC puede distribuir la confianza (ningún punto único ve todos los datos) y puede ser eficiente para ciertas operaciones, pero típicamente incurre en una sobrecarga de comunicación y coordinación y puede ser complejo de implementar para redes grandes.

A continuación se presenta una tabla comparativa que resume las diferencias clave:

Tecnología	Modelo de Confianza	Rendimiento	Privacidad de Datos	Usabilidad para el Desarrollador
TEE (Intel SGX, etc.)	Confianza en el fabricante del hardware (servidor de atestación centralizado en algunos casos). Asume que el chip es seguro; si el hardware se ve comprometido, la seguridad se rompe.	Velocidad de ejecución casi nativa; sobrecarga mínima. Bueno para computación en tiempo real y grandes cargas de trabajo. La escalabilidad está limitada por la disponibilidad de nodos habilitados para TEE.	Los datos están en texto plano dentro del enclave, pero cifrados para el mundo exterior. Fuerte confidencialidad si el hardware se mantiene, pero si el enclave es vulnerado, los secretos quedan expuestos (sin protección matemática adicional).	Complejidad moderada. A menudo se puede reutilizar código/lenguajes existentes (C, Rust) y ejecutarlo en un enclave con modificaciones menores. La barrera de entrada más baja entre estos: no es necesario aprender criptografía avanzada, pero requiere programación de sistemas y conocimiento específico del SDK del TEE.
ZKP (zk-SNARK/STARK)	Confianza en supuestos matemáticos (por ejemplo, la dureza de los problemas criptográficos) y a veces una configuración confiable (para SNARKs). Sin dependencia de ninguna parte única en tiempo de ejecución.	La generación de pruebas es computacionalmente pesada (especialmente para programas complejos), a menudo órdenes de magnitud más lenta que la nativa. La verificación en la cadena es rápida (pocos ms). No es ideal para grandes cálculos de datos debido al tiempo de prueba. Escalabilidad: buena para la verificación sucinta (rollups) pero el probador es el cuello de botella.	Privacidad muy fuerte: se puede probar la corrección sin revelar ninguna entrada privada. Solo se filtra información mínima (como el tamaño de la prueba). Ideal para la privacidad financiera, etc.	Alta complejidad. Requiere aprender lenguajes especializados (circuitos, zkDSLs como Circom o Noir) y pensar en términos de circuitos aritméticos. La depuración es difícil. Menos expertos disponibles.
FHE	Confianza en las matemáticas (problemas de retículos). Sin parte confiable; la seguridad se mantiene mientras el cifrado no se rompa.	Muy lento para uso general. Las operaciones sobre datos cifrados son varios órdenes de magnitud más lentas que en texto plano. Mejora algo con avances de hardware y mejores algoritmos, pero actualmente es impráctico para uso en tiempo real en contextos de blockchain.	Máxima privacidad: los datos permanecen cifrados todo el tiempo, incluso durante la computación. Esto es ideal para datos sensibles (por ejemplo, médicos, análisis interinstitucionales) si el rendimiento lo permitiera.	Muy especializado. Los desarrolladores necesitan conocimientos de criptografía. Existen algunas bibliotecas (como Microsoft SEAL, TFHE), pero escribir programas arbitrarios en FHE es difícil y tortuoso. Aún no es un objetivo de desarrollo rutinario para dApps.
MPC	Confianza distribuida entre múltiples partes. Asume que un umbral de partes es honesto (sin colusión más allá de cierto número). No se necesita confianza en el hardware. Falla la confianza si demasiados coluden.	Típicamente más lento que el nativo debido a las rondas de comunicación, pero a menudo más rápido que el FHE. El rendimiento varía: operaciones simples (suma, multiplicación) pueden ser eficientes; la lógica compleja puede disparar el costo de comunicación. La latencia es sensible a las velocidades de la red. La escalabilidad puede mejorarse con sharding o supuestos de confianza parcial.	Fuerte privacidad si se cumplen los supuestos: ningún nodo ve la entrada completa. Pero algo de información puede filtrarse a través de la salida o si las partes se caen (además, carece de la sucinta de ZK: obtienes el resultado pero no una prueba fácilmente compartible sin ejecutar el protocolo de nuevo).	Alta complejidad. Requiere diseñar un protocolo personalizado para cada caso de uso o usar frameworks (como SPDZ, o la oferta de Partisia). Los desarrolladores deben razonar sobre protocolos criptográficos y a menudo coordinar el despliegue de múltiples nodos. La integración en aplicaciones de blockchain puede ser compleja (necesita rondas off-chain).

Citas: La comparación anterior se basa en fuentes como el análisis de Sanders Network y otros, que destacan que los TEEs sobresalen en velocidad y facilidad de uso, mientras que ZK y FHE se centran en la máxima falta de confianza a costa de un cómputo pesado, y MPC distribuye la confianza pero introduce una sobrecarga de red.

De la tabla, algunos compromisos clave se vuelven claros:

• Rendimiento: Los TEEs tienen una gran ventaja en velocidad bruta y baja latencia. El MPC a menudo puede manejar una complejidad moderada con cierta ralentización, ZK es lento para producir pero rápido para verificar (uso asíncrono), y FHE es actualmente el más lento con diferencia para tareas arbitrarias (aunque está bien para operaciones limitadas como sumas/multiplicaciones simples). Si tu aplicación necesita procesamiento complejo en tiempo real (como aplicaciones interactivas, decisiones de alta frecuencia), los TEEs o quizás el MPC (con pocas partes en buenas conexiones) son las únicas opciones viables hoy en día. ZK y FHE serían demasiado lentos en tales escenarios.

• Modelo de Confianza: ZKP y FHE son puramente sin confianza (solo confían en las matemáticas). MPC traslada la confianza a supuestos sobre la honestidad de los participantes (que pueden reforzarse teniendo muchas partes o incentivos económicos). TEE deposita la confianza en el hardware y el proveedor. Esta es una diferencia fundamental: los TEEs introducen un tercero de confianza (el chip) en el mundo generalmente sin confianza de la blockchain. En contraste, ZK y FHE a menudo son elogiados por alinearse mejor con el ethos descentralizado: no hay entidades especiales en las que confiar, solo la dureza computacional. MPC se encuentra en el medio: la confianza está descentralizada pero no eliminada (si N de M nodos coluden, la privacidad se rompe). Así que para una máxima falta de confianza (por ejemplo, un sistema verdaderamente resistente a la censura y descentralizado), uno podría inclinarse hacia soluciones criptográficas. Por otro lado, muchos sistemas prácticos se sienten cómodos asumiendo que Intel es honesto o que un conjunto de validadores principales no coludirá, intercambiando un poco de confianza por enormes ganancias en eficiencia.

• Seguridad/Vulnerabilidades: Los TEEs, como se discutió, pueden ser socavados por errores de hardware o canales laterales. La seguridad de ZK y FHE puede ser socavada si las matemáticas subyacentes (digamos, una curva elíptica o un problema de retículo) se rompen, pero esos son problemas bien estudiados y los ataques probablemente se notarían (además, las elecciones de parámetros pueden mitigar los riesgos conocidos). La seguridad de MPC puede ser rota por adversarios activos si el protocolo no está diseñado para eso (algunos protocolos de MPC asumen participantes "honestos pero curiosos" y podrían fallar si alguien hace trampa abiertamente). En el contexto de la blockchain, una brecha en un TEE podría ser más catastrófica (todos los contratos basados en enclaves podrían estar en riesgo hasta que se parcheen), mientras que una ruptura criptográfica de ZK (como descubrir un fallo en una función hash utilizada por un rollup ZK) también podría ser catastrófica, pero generalmente se considera menos probable dada la suposición más simple. La superficie de ataque es muy diferente: los TEEs tienen que preocuparse por cosas como el análisis de potencia, mientras que ZK tiene que preocuparse por los avances matemáticos.

• Privacidad de Datos: FHE y ZK ofrecen las garantías de privacidad más fuertes: los datos permanecen protegidos criptográficamente. MPC asegura que los datos se comparten en secreto, por lo que ninguna parte los ve (aunque algo de información podría filtrarse si las salidas son públicas o si los protocolos no están diseñados cuidadosamente). TEE mantiene los datos privados del exterior, pero dentro del enclave los datos se descifran; si alguien de alguna manera obtiene el control del enclave, la confidencialidad de los datos se pierde. Además, los TEEs típicamente permiten que el código haga cualquier cosa con los datos (incluyendo filtrarlos inadvertidamente a través de canales laterales o la red si el código es malicioso). Por lo tanto, los TEEs requieren que también confíes en el código del enclave, no solo en el hardware. En contraste, las ZKPs prueban propiedades del código sin revelar nunca secretos, por lo que ni siquiera tienes que confiar en el código (más allá de que realmente tenga la propiedad probada). Si una aplicación de enclave tuviera un error que filtrara datos a un archivo de registro, el hardware del TEE no lo evitaría, mientras que un sistema de prueba ZK simplemente no revelaría nada excepto la prueba prevista. Este es un matiz: los TEEs protegen contra adversarios externos, pero no necesariamente contra errores lógicos en el propio programa del enclave, mientras que el diseño de ZK fuerza un enfoque más declarativo (pruebas exactamente lo que se pretende y nada más).

• Composabilidad e Integración: Los TEEs se integran con bastante facilidad en los sistemas existentes: puedes tomar un programa existente, ponerlo en un enclave y obtener algunos beneficios de seguridad sin cambiar demasiado el modelo de programación. ZK y FHE a menudo requieren reescribir el programa en un circuito o forma restrictiva, lo que puede ser un esfuerzo masivo. Por ejemplo, escribir una verificación simple de un modelo de IA en ZK implica transformarlo en una serie de operaciones aritméticas y restricciones, lo que está muy lejos de simplemente ejecutar TensorFlow en un TEE y atestiguar el resultado. De manera similar, MPC puede requerir un protocolo personalizado por caso de uso. Así que desde el punto de vista de la productividad y el costo del desarrollador, los TEEs son atractivos. Hemos visto una adopción más rápida de los TEEs en algunas áreas precisamente porque se pueden aprovechar los ecosistemas de software existentes (muchas bibliotecas se ejecutan en enclaves con pequeños ajustes). ZK/MPC requieren talento de ingeniería especializado que es escaso. Sin embargo, la otra cara de la moneda es que los TEEs producen una solución que a menudo está más aislada (tienes que confiar en ese enclave o en ese conjunto de nodos), mientras que ZK te da una prueba que cualquiera puede verificar en la cadena, lo que la hace altamente componible (cualquier contrato puede verificar una prueba ZK). Así que los resultados de ZK son portátiles: producen una pequeña prueba que cualquier número de otros contratos o usuarios pueden usar para ganar confianza. Los resultados de TEE generalmente vienen en forma de una atestación vinculada a un hardware particular y posiblemente no sucinta; pueden no ser tan fácilmente compartibles o agnósticos a la cadena (aunque puedes publicar una firma del resultado y tener contratos programados para aceptarla si conocen la clave pública del enclave).

En la práctica, estamos viendo enfoques híbridos: por ejemplo, Sanders Network argumenta que TEE, MPC y ZK brillan cada uno en diferentes áreas y pueden complementarse entre sí. Un caso concreto es la identidad descentralizada: se podrían usar pruebas ZK para probar una credencial de identidad sin revelarla, pero esa credencial podría haber sido verificada y emitida por un proceso basado en TEE que verificó tus documentos de forma privada. O considera el escalado: los rollups ZK proporcionan pruebas sucintas para muchas transacciones, pero la generación de esas pruebas podría acelerarse utilizando TEEs para hacer algunos cálculos más rápido (y luego solo probar una afirmación más pequeña). La combinación a veces puede reducir el requisito de confianza en los TEEs (por ejemplo, usar TEEs para el rendimiento, pero aún así verificar la corrección final a través de una prueba ZK o mediante un juego de desafío en la cadena para que un TEE comprometido no pueda hacer trampa sin ser atrapado). Mientras tanto, el MPC se puede combinar con los TEEs haciendo que el nodo de cómputo de cada parte sea un TEE, añadiendo una capa extra para que incluso si algunas partes coluden, todavía no puedan ver los datos de los demás a menos que también rompan la seguridad del hardware.

En resumen, los TEEs ofrecen un camino muy práctico e inmediato hacia la computación segura con supuestos modestos (confianza en el hardware), mientras que ZK y FHE ofrecen un camino más teórico y sin confianza pero a un alto costo computacional, y MPC ofrece un camino de confianza distribuida con costos de red. La elección correcta en Web3 depende de los requisitos de la aplicación:

• Si necesitas computación rápida y compleja sobre datos privados (como IA, grandes conjuntos de datos), los TEEs (o MPC con pocas partes) son actualmente la única forma factible.
• Si necesitas máxima descentralización y verificabilidad, las pruebas ZK brillan (por ejemplo, las transacciones de criptomonedas privadas favorecen a ZKP como en Zcash, porque los usuarios no quieren confiar en nada más que en las matemáticas).
• Si necesitas computación colaborativa entre múltiples partes interesadas, el MPC es naturalmente adecuado (como la gestión de claves multipartita o las subastas).
• Si tienes datos extremadamente sensibles y la privacidad a largo plazo es una necesidad, el FHE podría ser atractivo si el rendimiento mejora, porque incluso si alguien obtuviera tus textos cifrados años después, sin la clave no aprenderían nada; mientras que un compromiso de enclave podría filtrar secretos retroactivamente si se guardaran registros.

Vale la pena señalar que el espacio de la blockchain está explorando activamente todas estas tecnologías en paralelo. Es probable que veamos combinaciones: por ejemplo, soluciones de Capa 2 que integran TEEs para secuenciar transacciones y luego usan un ZKP para probar que el TEE siguió las reglas (un concepto que se está explorando en algunas investigaciones de Ethereum), o redes MPC que usan TEEs en cada nodo para reducir la complejidad de los protocolos MPC (ya que cada nodo es internamente seguro y puede simular múltiples partes).

En última instancia, TEEs vs ZK vs MPC vs FHE no es una elección de suma cero: cada uno apunta a diferentes puntos en el triángulo de seguridad, rendimiento y falta de confianza. Como dijo un artículo, los cuatro enfrentan un "triángulo imposible" de rendimiento, costo y seguridad; ninguna solución única es superior en todos los aspectos. El diseño óptimo a menudo utiliza la herramienta adecuada para la parte correcta del problema.

6. Adopción en los Principales Ecosistemas de Blockchain​

Los Entornos de Ejecución Confiables han visto niveles variables de adopción en diferentes ecosistemas de blockchain, a menudo influenciados por las prioridades de esas comunidades y la facilidad de integración. Aquí evaluamos cómo se están utilizando (o explorando) los TEEs en algunos de los principales ecosistemas: Ethereum, Cosmos y Polkadot, además de tocar otros.

Ethereum (y Capas 1 en General)​

En la mainnet de Ethereum misma, los TEEs no son parte del protocolo central, pero se han utilizado en aplicaciones y Capas 2. La filosofía de Ethereum se inclina hacia la seguridad criptográfica (por ejemplo, los emergentes ZK-rollups), pero los TEEs han encontrado roles en oráculos y ejecución off-chain para Ethereum:

• Servicios de Oráculo: Como se discutió, Chainlink ha incorporado soluciones basadas en TEE como Town Crier. Aunque no todos los nodos de Chainlink usan TEEs por defecto, la tecnología está ahí para fuentes de datos que requieren confianza extra. Además, API3 (otro proyecto de oráculo) ha mencionado el uso de Intel SGX para ejecutar APIs y firmar datos para garantizar la autenticidad. Estos servicios alimentan datos a los contratos de Ethereum con mayores garantías.

• Capa 2 y Rollups: Hay una investigación y un debate en curso en la comunidad de Ethereum sobre el uso de TEEs en secuenciadores o validadores de rollups. Por ejemplo, el concepto de "ZK-Portal" de ConsenSys y otros han propuesto usar TEEs para hacer cumplir el ordenamiento correcto en rollups optimistas o para proteger al secuenciador de la censura. El artículo de Medium que vimos incluso sugiere que para 2025, los TEE podrían convertirse en una característica predeterminada en algunas L2 para cosas como la protección del trading de alta frecuencia. Proyectos como Catalyst (un DEX de trading de alta frecuencia) y Flashbots (para relés de MEV) han considerado los TEEs para hacer cumplir el ordenamiento justo de las transacciones antes de que lleguen a la blockchain.

• Ethereum Empresarial: En redes de Ethereum de consorcio o permisionadas, los TEEs son más ampliamente adoptados. El Trusted Compute Framework (TCF) de la Enterprise Ethereum Alliance era básicamente un plan para integrar TEEs en los clientes de Ethereum. Hyperledger Avalon (anteriormente EEA TCF) permite que partes de los contratos inteligentes de Ethereum se ejecuten off-chain en un TEE y luego se verifiquen en la cadena. Varias empresas como IBM, Microsoft e iExec contribuyeron a esto. Aunque en el Ethereum público esto no se ha vuelto común, en despliegues privados (por ejemplo, un grupo de bancos usando Quorum o Besu), los TEEs pueden usarse para que incluso los miembros del consorcio no vean los datos de los demás, solo los resultados autorizados. Esto puede satisfacer los requisitos de privacidad en un entorno empresarial.

• Proyectos Notables: Aparte de iExec que opera en Ethereum, hubo proyectos como Enigma (que originalmente comenzó como un proyecto de MPC en el MIT, luego pivotó para usar SGX; más tarde se convirtió en Secret Network en Cosmos). Otro fue Decentralized Cloud Services (DCS) en las primeras discusiones de Ethereum. Más recientemente, OAuth (Oasis Ethereum ParaTime) permite que los contratos de Solidity se ejecuten con confidencialidad utilizando el backend TEE de Oasis pero liquidando en Ethereum. Además, algunas dApps basadas en Ethereum como el intercambio de datos médicos o los juegos han experimentado con TEEs al tener un componente de enclave off-chain que interactúa con sus contratos.

Así que la adopción de Ethereum es algo indirecta: no ha cambiado el protocolo para requerir TEEs, pero tiene un rico conjunto de servicios y extensiones opcionales que aprovechan los TEEs para quienes los necesitan. Es importante destacar que los investigadores de Ethereum siguen siendo cautelosos: las propuestas para hacer una "shard solo de TEE" o para integrar profundamente los TEEs han encontrado escepticismo en la comunidad debido a preocupaciones de confianza. En cambio, los TEEs son vistos como "coprocesadores" para Ethereum en lugar de componentes centrales.

Ecosistema Cosmos​

El ecosistema de Cosmos es amigable con la experimentación a través de su SDK modular y cadenas soberanas, y Secret Network (cubierto anteriormente) es un excelente ejemplo de la adopción de TEE en Cosmos. Secret Network es en realidad una cadena del SDK de Cosmos con consenso Tendermint, modificada para exigir SGX en sus validadores. Es una de las zonas de Cosmos más prominentes después del Cosmos Hub principal, lo que indica una adopción significativa de la tecnología TEE en esa comunidad. El éxito de Secret en proporcionar privacidad entre cadenas (a través de sus conexiones IBC, Secret puede servir como un centro de privacidad para otras cadenas de Cosmos) es un caso notable de integración de TEE en L1.

Otro proyecto relacionado con Cosmos es Oasis Network (aunque no está construido sobre el SDK de Cosmos, fue diseñado por algunas de las mismas personas que contribuyeron a Tendermint y comparte un ethos similar de arquitectura modular). Oasis es independiente pero puede conectarse a Cosmos a través de puentes, etc. Tanto Secret como Oasis muestran que en el mundo de Cosmos, la idea de "la privacidad como una característica" a través de TEEs ganó suficiente tracción como para justificar redes dedicadas.

Cosmos incluso tiene un concepto de "proveedores de privacidad" para aplicaciones entre cadenas; por ejemplo, una aplicación en una cadena puede llamar a un contrato en Secret Network a través de IBC para realizar un cálculo confidencial y luego recibir el resultado. Esta composabilidad está surgiendo ahora.

Además, el proyecto Anoma (no estrictamente de Cosmos, pero relacionado en el sentido de la interoperabilidad) ha hablado de usar TEEs para arquitecturas centradas en la intención, aunque es más teórico.

En resumen, Cosmos tiene al menos una cadena principal que abraza completamente los TEEs (Secret) y otras que interactúan con ella, lo que ilustra una adopción saludable en esa esfera. La modularidad de Cosmos podría permitir más cadenas de este tipo (por ejemplo, uno podría imaginar una zona de Cosmos especializada en oráculos o identidad basados en TEE).

Polkadot y Substrate​

El diseño de Polkadot permite que las parachains se especialicen, y de hecho Polkadot alberga múltiples parachains que utilizan TEEs:

• Sanders Network: Ya descrito; una parachain que ofrece una nube de cómputo basada en TEE. Sanders ha estado en vivo como parachain, proporcionando servicios a otras cadenas a través de XCMP (paso de mensajes entre cadenas). Por ejemplo, otro proyecto de Polkadot puede descargar una tarea confidencial a los trabajadores de Sanders y recibir una prueba o un resultado de vuelta. La economía de tokens nativa de Sanders incentiva la ejecución de nodos TEE, y tiene una comunidad considerable, lo que indica una fuerte adopción.
• Integritee: Otra parachain que se centra en soluciones empresariales y de privacidad de datos utilizando TEEs. Integritee permite a los equipos desplegar sus propias side-chains privadas (llamadas Teewasms) donde la ejecución se realiza en enclaves. Se dirige a casos de uso como el procesamiento de datos confidenciales para corporaciones que aún desean anclarse a la seguridad de Polkadot.
• /Root o Crust?: Hubo ideas sobre el uso de TEEs para almacenamiento descentralizado o balizas aleatorias en algunos proyectos relacionados con Polkadot. Por ejemplo, Crust Network (almacenamiento descentralizado) originalmente planeó una prueba de almacenamiento basada en TEE (aunque luego se movió a otro diseño). Y la parachain aleatoria de Polkadot (Entropy) consideró TEEs vs VRFs.

La dependencia de Polkadot de la gobernanza y las actualizaciones en la cadena significa que las parachains pueden incorporar nueva tecnología rápidamente. Tanto Sanders como Integritee han pasado por actualizaciones para mejorar su integración de TEE (como admitir nuevas características de SGX o refinar los métodos de atestación). La Web3 Foundation también financió esfuerzos anteriores en proyectos TEE basados en Substrate como SubstraTEE (un prototipo temprano que mostraba la ejecución de contratos off-chain en TEEs con verificación en la cadena).

El ecosistema de Polkadot muestra así múltiples equipos independientes apostando por la tecnología TEE, lo que indica una tendencia de adopción positiva. Se está convirtiendo en un punto de venta para Polkadot que "si necesitas contratos inteligentes confidenciales o cómputo off-chain, tenemos parachains para eso".

Otros Ecosistemas y Adopción General​

• Empresas y Consorcios: Fuera de la cripto pública, Hyperledger y las cadenas empresariales han adoptado constantemente los TEEs para entornos permisionados. Por ejemplo, el Comité de Basilea probó una blockchain de finanzas comerciales basada en TEE. El patrón general es: donde la privacidad o la confidencialidad de los datos es una necesidad, y los participantes son conocidos (por lo que incluso podrían invertir colectivamente en módulos de seguridad de hardware), los TEEs encuentran un hogar cómodo. Puede que no aparezcan en las noticias de cripto, pero en sectores como la cadena de suministro, los consorcios bancarios o las redes de intercambio de datos de salud, los TEEs son a menudo la opción preferida (como alternativa a simplemente confiar en un tercero o usar criptografía pesada).

• Capas 1 fuera de Ethereum: Algunas L1 más nuevas han incursionado con TEEs. NEAR Protocol tuvo un concepto temprano de una shard basada en TEE para contratos privados (aún no implementado). Celo consideró los TEEs para pruebas de clientes ligeros (sus pruebas Plumo ahora se basan en snarks, pero en un momento consideraron SGX para comprimir datos de la cadena para móviles). Concordium, una L1 de privacidad regulada, utiliza ZK para el anonimato pero también explora TEEs para la verificación de identidad. Dfinity/Internet Computer utiliza enclaves seguros en sus máquinas de nodos, pero para el arranque de la confianza (no para la ejecución de contratos, ya que su criptografía "Chain Key" se encarga de eso).

• Bitcoin: Aunque Bitcoin en sí no utiliza TEEs, ha habido proyectos paralelos. Por ejemplo, soluciones de custodia basadas en TEE (como sistemas de Bóveda) para claves de Bitcoin, o ciertas propuestas en DLC (Contratos de Registro Discreto) para usar oráculos que podrían estar asegurados por TEE. Generalmente, la comunidad de Bitcoin es más conservadora y no confiaría fácilmente en Intel como parte del consenso, pero como tecnología auxiliar (billeteras de hardware con elementos seguros) ya está aceptada.

• Reguladores y Gobiernos: Una faceta interesante de la adopción: algunas investigaciones sobre CBDC (moneda digital de banco central) han considerado los TEEs para hacer cumplir la privacidad mientras permiten la auditabilidad. Por ejemplo, el Banco de Francia realizó experimentos en los que utilizaron un TEE para manejar ciertas verificaciones de cumplimiento en transacciones que de otro modo serían privadas. Esto muestra que incluso los reguladores ven los TEEs como una forma de equilibrar la privacidad con la supervisión: podrías tener una CBDC donde las transacciones están cifradas para el público pero un enclave regulador puede revisarlas bajo ciertas condiciones (esto es hipotético, pero se discute en círculos de políticas).

• Métricas de Adopción: Es difícil cuantificar la adopción, pero podemos observar indicadores como: número de proyectos, fondos invertidos, disponibilidad de infraestructura. En ese frente, hoy (2025) tenemos: al menos 3-4 cadenas públicas (Secret, Oasis, Sanders, Integritee, Automata como off-chain) que utilizan explícitamente TEEs; las principales redes de oráculos lo incorporan; grandes empresas tecnológicas respaldan la computación confidencial (Microsoft Azure, Google Cloud ofrecen VMs TEE, y estos servicios están siendo utilizados por nodos de blockchain como opciones). El Confidential Computing Consortium ahora incluye miembros centrados en blockchain (Ethereum Foundation, Chainlink, Fortanix, etc.), lo que muestra una colaboración interindustrial. Todo esto apunta a una adopción creciente pero de nicho: los TEEs aún no son ubicuos en Web3, pero han encontrado nichos importantes donde se requiere privacidad y cómputo seguro off-chain.

7. Consideraciones Empresariales y Regulatorias​

El uso de TEEs en aplicaciones de blockchain plantea varios puntos empresariales y regulatorios que las partes interesadas deben considerar:

Cumplimiento de la Privacidad y Adopción Institucional​

Uno de los impulsores empresariales para la adopción de TEE es la necesidad de cumplir con las regulaciones de privacidad de datos (como GDPR en Europa, HIPAA en los EE. UU. para datos de salud) mientras se aprovecha la tecnología blockchain. Las blockchains públicas por defecto transmiten datos a nivel mundial, lo que entra en conflicto con las regulaciones que requieren que los datos personales sensibles estén protegidos. Los TEEs ofrecen una forma de mantener los datos confidenciales en la cadena y solo compartirlos de manera controlada, permitiendo así el cumplimiento. Como se señaló, "los TEEs facilitan el cumplimiento de las regulaciones de privacidad de datos al aislar los datos sensibles del usuario y garantizar que se manejen de forma segura". Esta capacidad es crucial para atraer a empresas e instituciones a Web3, ya que no pueden arriesgarse a violar las leyes. Por ejemplo, una dApp de atención médica que procesa información de pacientes podría usar TEEs para garantizar que ningún dato bruto de pacientes se filtre en la cadena, satisfaciendo los requisitos de HIPAA de cifrado y control de acceso. De manera similar, un banco europeo podría usar una cadena basada en TEE para tokenizar y comerciar activos sin exponer los detalles personales de los clientes, alineándose con el GDPR.

Esto tiene un ángulo regulatorio positivo: algunos reguladores han indicado que soluciones como los TEEs (y conceptos relacionados de computación confidencial) son favorables porque proporcionan una aplicación técnica de la privacidad. Hemos visto al Foro Económico Mundial y a otros destacar los TEEs como un medio para construir "privacidad por diseño" en los sistemas de blockchain (esencialmente incorporando el cumplimiento a nivel de protocolo). Por lo tanto, desde una perspectiva empresarial, los TEEs pueden acelerar la adopción institucional al eliminar uno de los bloqueadores clave (la confidencialidad de los datos). Las empresas están más dispuestas a usar o construir sobre blockchain si saben que hay una salvaguarda de hardware para sus datos.

Otro aspecto del cumplimiento es la auditabilidad y la supervisión. Las empresas a menudo necesitan registros de auditoría y la capacidad de demostrar a los auditores que tienen el control de los datos. Los TEEs pueden ayudar aquí al producir informes de atestación y registros seguros de lo que se accedió. Por ejemplo, el "registro duradero" de Oasis en un enclave proporciona un registro resistente a la manipulación de operaciones sensibles. Una empresa puede mostrar ese registro a los reguladores para demostrar que, por ejemplo, solo se ejecutó código autorizado y solo se realizaron ciertas consultas sobre los datos de los clientes. Este tipo de auditoría atestiguada podría satisfacer a los reguladores más que un sistema tradicional donde se confía en los registros del administrador del sistema.

Confianza y Responsabilidad​

Por otro lado, la introducción de TEEs cambia la estructura de confianza y, por lo tanto, el modelo de responsabilidad en las soluciones de blockchain. Si una plataforma DeFi utiliza un TEE y algo sale mal debido a un fallo de hardware, ¿quién es responsable? Por ejemplo, considera un escenario en el que un error de Intel SGX conduce a una fuga de detalles de transacciones de intercambio secretas, lo que hace que los usuarios pierdan dinero (front-running, etc.). Los usuarios confiaron en las afirmaciones de seguridad de la plataforma. ¿Es culpa de la plataforma o de Intel? Legalmente, los usuarios podrían ir tras la plataforma (quien a su vez podría tener que ir tras Intel). Esto complica las cosas porque tienes un proveedor de tecnología de terceros (el proveedor de la CPU) profundamente involucrado en el modelo de seguridad. Las empresas que utilizan TEEs deben considerar esto en los contratos y las evaluaciones de riesgos. Algunas podrían buscar garantías o soporte de los proveedores de hardware si utilizan sus TEEs en infraestructura crítica.

También está la preocupación por la centralización: si la seguridad de una blockchain depende del hardware de una sola empresa (Intel o AMD), los reguladores podrían verlo con escepticismo. Por ejemplo, ¿podría un gobierno citar o coaccionar a esa empresa para comprometer ciertos enclaves? Esta no es una preocupación puramente teórica; considera las leyes de control de exportaciones: el hardware de cifrado de alto grado puede estar sujeto a regulación. Si una gran parte de la infraestructura cripto depende de los TEEs, es concebible que los gobiernos puedan intentar insertar puertas traseras (aunque no hay evidencia de ello, la percepción importa). Algunos defensores de la privacidad señalan esto a los reguladores: que los TEEs concentran la confianza y, en todo caso, los reguladores deberían examinarlos cuidadosamente. Por el contrario, los reguladores que desean más control podrían preferir los TEEs sobre la privacidad basada en matemáticas como ZK, porque con los TEEs hay al menos una noción de que las fuerzas del orden podrían acercarse al proveedor de hardware con una orden judicial si fuera absolutamente necesario (por ejemplo, para obtener una clave de atestación maestra o algo así, no es que sea fácil o probable, pero es una vía que no existe con ZK). Así que la recepción regulatoria puede dividirse: los reguladores de privacidad (agencias de protección de datos) están a favor de los TEE para el cumplimiento, mientras que las fuerzas del orden podrían ser cautelosamente optimistas ya que los TEEs no están "a oscuras" de la misma manera que el cifrado fuerte; hay una palanca teórica (el hardware) que podrían intentar usar.

Las empresas necesitan navegar esto posiblemente participando en certificaciones. Existen certificaciones de seguridad como FIPS 140 o Common Criteria para módulos de hardware. Actualmente, SGX y otros tienen algunas certificaciones (por ejemplo, SGX tuvo certificación Common Criteria EAL para ciertos usos). Si una plataforma de blockchain puede señalar que la tecnología del enclave está certificada con un alto estándar, los reguladores y socios podrían sentirse más cómodos. Por ejemplo, un proyecto de CBDC podría requerir que cualquier TEE utilizado esté certificado por FIPS para confiar en su generación de números aleatorios, etc. Esto introduce un proceso adicional y posiblemente restringe a ciertas versiones de hardware.

Consideraciones de Ecosistema y Costo​

Desde una perspectiva empresarial, el uso de TEEs podría afectar la estructura de costos de una operación de blockchain. Los nodos deben tener CPUs específicas (que podrían ser más caras o menos eficientes energéticamente). Esto podría significar facturas de alojamiento en la nube más altas o gastos de capital. Por ejemplo, si un proyecto exige Intel Xeon con SGX para todos los validadores, eso es una restricción: los validadores no pueden ser cualquiera con una Raspberry Pi o una computadora portátil vieja; necesitan ese hardware. Esto puede centralizar quién puede participar (posiblemente favoreciendo a aquellos que pueden permitirse servidores de alta gama o que utilizan proveedores de la nube que ofrecen VMs SGX). En casos extremos, podría empujar a la red a ser más permisionada o a depender de proveedores de la nube, lo cual es un compromiso de descentralización y un compromiso empresarial (la red podría tener que subsidiar a los proveedores de nodos).

Por otro lado, algunas empresas podrían encontrar esto aceptable porque quieren validadores conocidos o tienen una lista blanca (especialmente en consorcios empresariales). Pero en las redes cripto públicas, esto ha causado debates; por ejemplo, cuando se requería SGX, la gente preguntaba "¿significa esto que solo los grandes centros de datos ejecutarán nodos?". Es algo que afecta el sentimiento de la comunidad y, por lo tanto, la adopción del mercado. Por ejemplo, algunos puristas de las criptomonedas podrían evitar una cadena que requiere TEEs, etiquetándola como "menos sin confianza" o demasiado centralizada. Por lo tanto, los proyectos tienen que manejar las relaciones públicas y la educación de la comunidad, dejando claro cuáles son los supuestos de confianza y por qué sigue siendo seguro. Vimos a Secret Network abordar el FUD explicando el riguroso monitoreo de las actualizaciones de Intel y que los validadores son penalizados si no actualizan los enclaves, etc., creando básicamente una capa social de confianza sobre la confianza en el hardware.

Otra consideración son las asociaciones y el soporte. El ecosistema empresarial en torno a los TEEs incluye grandes empresas tecnológicas (Intel, AMD, ARM, Microsoft, Google, etc.). Los proyectos de blockchain que utilizan TEEs a menudo se asocian con estas (por ejemplo, iExec asociándose con Intel, Secret Network trabajando con Intel en mejoras de atestación, Oasis con Microsoft en IA confidencial, etc.). Estas asociaciones pueden proporcionar financiación, asistencia técnica y credibilidad. Es un punto estratégico: alinearse con la industria de la computación confidencial puede abrir puertas (para financiación o pilotos empresariales), pero también significa que un proyecto cripto podría alinearse con grandes corporaciones, lo que tiene implicaciones ideológicas en la comunidad.

Incertidumbres Regulatorias​

A medida que crecen las aplicaciones de blockchain que utilizan TEEs, pueden surgir nuevas preguntas regulatorias. Por ejemplo:

• Jurisdicción de Datos: Si los datos se procesan dentro de un TEE en un país determinado, ¿se considera que se "procesan en ese país" o en ninguna parte (ya que están cifrados)? Algunas leyes de privacidad requieren que los datos de los ciudadanos no salgan de ciertas regiones. Los TEEs podrían difuminar las líneas: podrías tener un enclave en una región de la nube, pero solo entran/salen datos cifrados. Es posible que los reguladores necesiten aclarar cómo ven dicho procesamiento.
• Controles de Exportación: La tecnología de cifrado avanzada puede estar sujeta a restricciones de exportación. Los TEEs implican el cifrado de la memoria; históricamente esto no ha sido un problema (ya que las CPUs con estas características se venden a nivel mundial), pero si eso cambiara, podría afectar el suministro. Además, algunos países podrían prohibir o desalentar el uso de TEEs extranjeros debido a la seguridad nacional (por ejemplo, China tiene su propio equivalente a SGX, ya que no confían en el de Intel, y podrían no permitir SGX para usos sensibles).
• Compulsión Legal: Un escenario: ¿podría un gobierno citar a un operador de nodo para extraer datos de un enclave? Normalmente no pueden porque incluso el operador no puede ver dentro. Pero, ¿y si citan a Intel por una clave de atestación específica? El diseño de Intel es tal que ni siquiera ellos pueden descifrar la memoria del enclave (emiten claves a la CPU que hace el trabajo). Pero si existiera una puerta trasera o un firmware especial pudiera ser firmado por Intel para volcar la memoria, esa es una hipótesis que preocupa a la gente. Legalmente, una empresa como Intel podría negarse si se le pidiera socavar su seguridad (probablemente lo harían, para no destruir la confianza en su producto). Pero la mera posibilidad podría aparecer en las discusiones regulatorias sobre el acceso legal. Las empresas que utilizan TEEs deben mantenerse al tanto de cualquier desarrollo de este tipo, aunque actualmente no existe un mecanismo público para que Intel/AMD extraigan datos de enclaves; ese es el punto de los TEEs.

Diferenciación de Mercado y Nuevos Servicios​

En el lado positivo para los negocios, los TEEs permiten nuevos productos y servicios que pueden ser monetizados. Por ejemplo:

• Mercados de datos confidenciales: Como han señalado iExec, Ocean Protocol y otros, las empresas tienen datos valiosos que podrían monetizar si tuvieran garantías de que no se filtrarán. Los TEEs permiten el "alquiler de datos" donde los datos nunca salen del enclave, solo las ideas lo hacen. Esto podría desbloquear nuevas fuentes de ingresos y modelos de negocio. Vemos startups en Web3 que ofrecen servicios de computación confidencial a empresas, esencialmente vendiendo la idea de "obtener ideas de la blockchain o de datos entre empresas sin exponer nada".
• DeFi Empresarial: Las instituciones financieras a menudo citan la falta de privacidad como una razón para no participar en DeFi o en la blockchain pública. Si los TEEs pueden garantizar la privacidad de sus posiciones o transacciones, podrían participar, trayendo más liquidez y negocio al ecosistema. Los proyectos que atienden a esto (como los préstamos secretos de Secret, o el AMM privado de Oasis con controles de cumplimiento) se están posicionando para atraer a usuarios institucionales. Si tienen éxito, eso puede ser un mercado significativo (imagina pools de AMM institucionales donde las identidades y los montos están protegidos pero un enclave asegura que las verificaciones de cumplimiento como AML se realizan internamente; ese es un producto que podría traer mucho dinero a DeFi con comodidad regulatoria).
• Seguros y Gestión de Riesgos: Con los TEEs reduciendo ciertos riesgos (como la manipulación de oráculos), podríamos ver primas de seguro más bajas o nuevos productos de seguro para plataformas de contratos inteligentes. Por el contrario, los TEEs introducen nuevos riesgos (como el fallo técnico de los enclaves) que podrían ser eventos asegurables. Hay un área incipiente de seguros cripto; cómo tratan los sistemas dependientes de TEE será interesante. Una plataforma podría comercializar que utiliza TEEs para reducir el riesgo de violación de datos, lo que la haría más fácil/barata de asegurar, dándole una ventaja competitiva.

En conclusión, el panorama empresarial y regulatorio de Web3 habilitado por TEE se trata de equilibrar la confianza y la innovación. Los TEEs ofrecen una ruta para cumplir con las leyes y desbloquear casos de uso empresariales (una gran ventaja para la adopción generalizada), pero también traen una dependencia de los proveedores de hardware y complejidades que deben gestionarse de forma transparente. Las partes interesadas deben interactuar tanto con los gigantes tecnológicos (para obtener soporte) como con los reguladores (para obtener claridad y seguridad) para realizar plenamente el potencial de los TEEs en la blockchain. Si se hace bien, los TEEs podrían ser una piedra angular que permita a la blockchain integrarse profundamente con industrias que manejan datos sensibles, expandiendo así el alcance de Web3 a áreas previamente fuera de los límites debido a preocupaciones de privacidad.

Conclusión​

Los Entornos de Ejecución Confiables han surgido como un componente poderoso en la caja de herramientas de Web3, permitiendo una nueva clase de aplicaciones descentralizadas que requieren confidencialidad y computación segura off-chain. Hemos visto que los TEEs, como Intel SGX, ARM TrustZone y AMD SEV, proporcionan una "caja fuerte" aislada por hardware para la computación, y esta propiedad ha sido aprovechada para contratos inteligentes que preservan la privacidad, oráculos verificables, procesamiento escalable off-chain y más. Proyectos en todos los ecosistemas, desde los contratos privados de Secret Network en Cosmos, hasta los ParaTimes confidenciales de Oasis, la nube TEE de Sanders en Polkadot y el mercado off-chain de iExec en Ethereum, demuestran las diversas formas en que los TEEs se están integrando en las plataformas de blockchain.

Técnicamente, los TEEs ofrecen beneficios convincentes de velocidad y fuerte confidencialidad de datos, pero vienen con sus propios desafíos: la necesidad de confiar en los proveedores de hardware, posibles vulnerabilidades de canal lateral y obstáculos en la integración y la composabilidad. Comparamos los TEEs con alternativas criptográficas (ZKPs, FHE, MPC) y encontramos que cada uno tiene su nicho: los TEEs brillan en rendimiento y facilidad de uso, mientras que ZK y FHE proporcionan la máxima falta de confianza a un alto costo, y MPC distribuye la confianza entre los participantes. De hecho, muchas soluciones de vanguardia son híbridas, utilizando TEEs junto con métodos criptográficos para obtener lo mejor de ambos mundos.

La adopción de soluciones basadas en TEE está creciendo constantemente. Las dApps de Ethereum aprovechan los TEEs para la seguridad de los oráculos y los cálculos privados, Cosmos y Polkadot tienen soporte nativo a través de cadenas especializadas, y los esfuerzos de blockchain empresarial están adoptando los TEEs para el cumplimiento. Desde el punto de vista empresarial, los TEEs pueden ser un puente entre la tecnología descentralizada y la regulación, permitiendo que los datos sensibles se manejen en la cadena bajo las salvaguardas de la seguridad del hardware, lo que abre la puerta al uso institucional y a nuevos servicios. Al mismo tiempo, usar TEEs significa comprometerse con nuevos paradigmas de confianza y garantizar que el ethos de descentralización de la blockchain no se vea socavado por un silicio opaco.

En resumen, los Entornos de Ejecución Confiables están desempeñando un papel crucial en la evolución de Web3: abordan algunas de las preocupaciones más apremiantes de privacidad y escalabilidad, y aunque no son una panacea (y no están exentos de controversia), expanden significativamente lo que las aplicaciones descentralizadas pueden hacer. A medida que la tecnología madura, con mejoras en la seguridad del hardware y estándares para la atestación, y a medida que más proyectos demuestran su valor, podemos esperar que los TEEs (junto con la tecnología criptográfica complementaria) se conviertan en un componente estándar de las arquitecturas de blockchain destinadas a desbloquear todo el potencial de Web3 de una manera segura y confiable. El futuro probablemente depara soluciones en capas donde el hardware y la criptografía trabajen de la mano para ofrecer sistemas que sean tanto performantes como demostrablemente seguros, satisfaciendo las necesidades de usuarios, desarrolladores y reguladores por igual.

Fuentes: La información de este informe se recopiló de una variedad de fuentes actualizadas, incluyendo documentación y blogs oficiales de proyectos, análisis de la industria e investigación académica, como se cita a lo largo del texto. Las referencias notables incluyen la guía de Metaschool 2025 sobre TEEs en Web3, comparaciones de Sanders Network, conocimientos técnicos de ChainCatcher y otros sobre FHE/TEE/ZKP/MPC, y declaraciones sobre cumplimiento regulatorio de Binance Research, entre muchos otros. Estas fuentes proporcionan más detalles y se recomiendan para los lectores que deseen explorar aspectos específicos con mayor profundidad.

Las blockchains públicas proporcionan transparencia e integridad a costa de la privacidad: cada transacción y estado de contrato está expuesto a todos los participantes. Esta apertura crea problemas como los ataques de MEV (Valor Extraíble por Mineros), el copy-trading y la filtración de lógica de negocio sensible. La privacidad programable busca resolver estos problemas permitiendo cómputos sobre datos privados sin revelar los datos en sí. Dos paradigmas criptográficos emergentes están haciendo esto posible: las Máquinas Virtuales de Cifrado Totalmente Homomórfico (FHE-VM) y los Coprocesadores de Conocimiento Cero (ZK). Estos enfoques permiten el cómputo off-chain o cifrado con verificación on-chain, preservando la confidencialidad mientras se mantiene la corrección sin confianza (trustless). En este informe, profundizamos en las arquitecturas de FHE-VM y coprocesadores ZK, comparamos sus ventajas y desventajas, y exploramos casos de uso en finanzas, identidad, salud, mercados de datos y aprendizaje automático descentralizado.

Máquina Virtual de Cifrado Totalmente Homomórfico (FHE-VM)​

El Cifrado Totalmente Homomórfico (FHE) permite realizar cómputos arbitrarios sobre datos cifrados sin necesidad de descifrarlos. Una Máquina Virtual FHE integra esta capacidad en los contratos inteligentes de la blockchain, permitiendo estado y lógica de contrato cifrados. En una blockchain habilitada para FHE (a menudo llamada fhEVM para diseños compatibles con EVM), todas las entradas, el almacenamiento del contrato y las salidas permanecen cifrados durante toda la ejecución. Esto significa que los validadores pueden procesar transacciones y actualizar el estado sin conocer ningún valor sensible, logrando una ejecución on-chain con confidencialidad de los datos.

Arquitectura y Diseño de FHE-VM​

Una FHE-VM típica extiende un tiempo de ejecución de contrato inteligente estándar (como la Máquina Virtual de Ethereum) con soporte nativo para tipos de datos y operaciones cifradas. Por ejemplo, la FHEVM de Zama introduce enteros cifrados (euint8, euint32, etc.), booleanos cifrados (ebool) e incluso arreglos cifrados como tipos de primera clase. Los lenguajes de contratos inteligentes como Solidity se aumentan mediante bibliotecas o nuevos opcodes para que los desarrolladores puedan realizar operaciones aritméticas (add, mul, etc.), lógicas y comparaciones directamente sobre textos cifrados. Por debajo, estas operaciones invocan primitivas FHE (por ejemplo, usando la biblioteca TFHE) para manipular bits cifrados y producir resultados cifrados.

El almacenamiento de estado cifrado es compatible para que las variables del contrato permanezcan cifradas en el estado de la blockchain. El flujo de ejecución es típicamente:

1. Cifrado del Lado del Cliente: Los usuarios cifran sus entradas localmente usando la clave pública FHE antes de enviar las transacciones. La clave de cifrado es pública (para cifrar y evaluar), mientras que la clave de descifrado permanece secreta. En algunos diseños, cada usuario gestiona su propia clave; en otros, se utiliza una única clave FHE global (discutido a continuación).
2. Cómputo Homomórfico On-Chain: Los mineros/validadores ejecutan el contrato con opcodes cifrados. Realizan las mismas operaciones homomórficas deterministas sobre los textos cifrados, por lo que se puede alcanzar un consenso sobre el nuevo estado cifrado. Crucialmente, los validadores nunca ven datos en texto plano; solo ven texto cifrado "sin sentido" pero aún pueden procesarlo de manera consistente.
3. Descifrado (Opcional): Si un resultado necesita ser revelado o utilizado off-chain, una parte autorizada con la clave privada puede descifrar el texto cifrado de salida. De lo contrario, los resultados permanecen cifrados y pueden ser utilizados como entradas para transacciones posteriores (permitiendo cómputos consecutivos sobre un estado cifrado persistente).

Una consideración de diseño importante es la gestión de claves. Un enfoque es el de claves por usuario, donde cada usuario posee su clave secreta y solo ellos pueden descifrar las salidas relevantes para ellos. Esto maximiza la privacidad (nadie más puede descifrar tus datos), pero las operaciones homomórficas no pueden mezclar datos cifrados bajo diferentes claves sin complejos protocolos de claves múltiples. Otro enfoque, utilizado por la FHEVM de Zama, es una clave FHE global: una única clave pública cifra todos los datos del contrato y un conjunto distribuido de validadores posee partes de la clave de descifrado de umbral. Las claves públicas de cifrado y evaluación se publican on-chain, para que cualquiera pueda cifrar datos para la red; la clave privada se divide entre los validadores que pueden descifrar colectivamente si es necesario bajo un esquema de umbral. Para evitar que la colusión de validadores comprometa la privacidad, Zama emplea un protocolo FHE de umbral (basado en su investigación Noah’s Ark) con "inundación de ruido" para hacer seguras las descifraciones parciales. Solo si un quórum suficiente de validadores coopera se puede recuperar un texto plano, por ejemplo, para atender una solicitud de lectura. Sin embargo, en operación normal, ningún nodo individual ve texto plano; los datos permanecen cifrados on-chain en todo momento.

El control de acceso es otro componente crucial. Las implementaciones de FHE-VM incluyen controles detallados para gestionar quién (si es que alguien) puede activar descifrados o acceder a ciertos campos cifrados. Por ejemplo, la fhEVM de Cypher admite Listas de Control de Acceso en textos cifrados, permitiendo a los desarrolladores especificar qué direcciones o contratos pueden interactuar o recifrar ciertos datos. Algunos frameworks admiten el recifrado: la capacidad de transferir un valor cifrado de la clave de un usuario a la de otro sin exponer el texto plano. Esto es útil para cosas como mercados de datos, donde un propietario de datos puede cifrar un conjunto de datos con su clave y, tras la compra, recifrarlo a la clave del comprador, todo on-chain, sin descifrarlo públicamente.

Garantizando la Corrección y la Privacidad​

Uno podría preguntarse: si todos los datos están cifrados, ¿cómo hacemos cumplir la corrección de la lógica del contrato? ¿Cómo puede la cadena prevenir operaciones inválidas si no puede "ver" los valores? El FHE por sí solo no proporciona una prueba de corrección: los validadores pueden realizar los pasos homomórficos, pero no pueden saber inherentemente si la entrada cifrada de un usuario fue válida o si se debe tomar una bifurcación condicional, etc., sin descifrar. Las pruebas de conocimiento cero (ZKPs) pueden complementar el FHE para resolver esta brecha. En una FHE-VM, típicamente los usuarios deben proporcionar una prueba ZK que certifique ciertas condiciones del texto plano cuando sea necesario. El diseño de Zama, por ejemplo, utiliza una Prueba ZK de Conocimiento de Texto Plano (ZKPoK) para acompañar cada entrada cifrada. Esto prueba que el usuario conoce el texto plano correspondiente a su texto cifrado y que cumple con los criterios esperados, sin revelar el texto plano en sí. Dichos "textos cifrados certificados" evitan que un usuario malicioso envíe un cifrado mal formado o un valor fuera de rango. De manera similar, para operaciones que requieren una decisión (por ejemplo, asegurar que el saldo de la cuenta ≥ monto del retiro), el usuario puede proporcionar una prueba ZK de que esta condición se cumple en los textos planos antes de que se ejecute la operación cifrada. De esta manera, la cadena no descifra ni ve los valores, pero gana confianza en que las transacciones cifradas siguen las reglas.

Otro enfoque en los rollups FHE es realizar una validación off-chain con ZKPs. Fhenix (un rollup L2 que usa FHE) opta por un modelo optimista donde un componente de red separado llamado Red de Servicio de Umbral puede descifrar o verificar resultados cifrados, y cualquier cómputo incorrecto puede ser desafiado con una prueba de fraude. En general, combinar FHE + ZK o pruebas de fraude asegura que la ejecución cifrada permanezca sin confianza. Los validadores descifran colectivamente solo cuando están autorizados, o verifican pruebas de que cada transición de estado cifrada fue válida sin necesidad de ver el texto plano.

Consideraciones de rendimiento: Las operaciones FHE son computacionalmente pesadas, muchos órdenes de magnitud más lentas que la aritmética normal. Por ejemplo, una simple suma de 64 bits en Ethereum cuesta ~3 gas, mientras que una suma en un entero cifrado de 64 bits (euint64) bajo la FHEVM de Zama cuesta aproximadamente 188,000 gas. Incluso una suma de 8 bits puede costar ~94k gas. Esta enorme sobrecarga significa que una implementación directa en los nodos existentes sería imprácticamente lenta y costosa. Los proyectos de FHE-VM abordan esto con bibliotecas criptográficas optimizadas (como la biblioteca TFHE-rs de Zama para el bootstrapping de compuertas binarias) y modificaciones personalizadas de EVM para el rendimiento. Por ejemplo, el cliente Geth modificado de Cypher agrega nuevos opcodes y optimiza la ejecución de instrucciones homomórficas en C++/ensamblador para minimizar la sobrecarga. Sin embargo, lograr un rendimiento utilizable requiere aceleración. El trabajo en curso incluye el uso de GPUs, FPGAs e incluso chips fotónicos especializados para acelerar los cómputos FHE. Zama informa que su rendimiento FHE mejoró 100 veces desde 2024 y apunta a miles de TPS con aceleración por GPU/FPGA. Servidores coprocesadores FHE dedicados (como el LightLocker Node de Optalysys) pueden conectarse a los nodos validadores para descargar operaciones cifradas al hardware, soportando >100 transferencias ERC-20 cifradas por segundo por nodo. A medida que el hardware y los algoritmos mejoren, la brecha entre el FHE y el cómputo en texto plano se reducirá, permitiendo que los contratos privados se acerquen a velocidades más prácticas.

Compatibilidad: Un objetivo clave de los diseños de FHE-VM es mantener la compatibilidad con los flujos de trabajo de desarrollo existentes. Las implementaciones de fhEVM de Cypher y Zama permiten a los desarrolladores escribir contratos en Solidity con cambios mínimos, utilizando una biblioteca para declarar tipos y operaciones cifradas. El resto de la cadena de herramientas de Ethereum (Remix, Hardhat, etc.) todavía se puede utilizar, ya que las modificaciones subyacentes se encuentran principalmente a nivel de cliente/nodo. Esto reduce la barrera de entrada: los desarrolladores no necesitan ser expertos en criptografía para escribir un contrato inteligente confidencial. Por ejemplo, una simple suma de dos números se puede escribir como euint32 c = a + b; y la FHEVM se encargará de los detalles específicos del cifrado tras bambalinas. Los contratos pueden incluso interoperar con contratos normales; por ejemplo, un contrato cifrado podría generar un resultado descifrado para un contrato estándar si se desea, permitiendo una mezcla de partes privadas y públicas en un ecosistema.

Proyectos FHE-VM Actuales: Varios proyectos son pioneros en este espacio. Zama (una startup de FHE con sede en París) desarrolló el concepto central de FHEVM y las bibliotecas (TFHE-rs y una biblioteca fhevm-solidity). No tienen la intención de lanzar su propia cadena, sino de proporcionar infraestructura a otros. Inco es una blockchain L1 (construida sobre Cosmos SDK con Evmos) que integró la FHEVM de Zama para crear una cadena confidencial modular. Sus redes de prueba (llamadas Gentry y Paillier) muestran transferencias ERC-20 cifradas y otras primitivas DeFi privadas. Fhenix es un rollup optimista de Capa 2 de Ethereum que utiliza FHE para la privacidad. Se decidieron por un enfoque optimista (prueba de fraude) en lugar de un ZK-rollup debido al alto costo de hacer FHE y ZK juntos para cada bloque. Fhenix utiliza la misma biblioteca TFHE-rs (con algunas modificaciones) e introduce una Red de Servicio de Umbral para manejar los descifrados de manera descentralizada. También hay equipos independientes como Fhenix (ahora renombrado) y startups que exploran híbridos de MPC + FHE. Además, Cypher (de Z1 Labs) está construyendo una red de Capa 3 centrada en IA y privacidad, utilizando una fhEVM con características como almacenes secretos y soporte para aprendizaje federado. El ecosistema es incipiente pero está creciendo rápidamente, impulsado por una financiación significativa; por ejemplo, Zama se convirtió en un "unicornio" con más de $130M recaudados para 2025 para avanzar en la tecnología FHE.

En resumen, una FHE-VM permite contratos inteligentes que preservan la privacidad al ejecutar toda la lógica sobre datos cifrados on-chain. Este paradigma garantiza la máxima confidencialidad —nada sensible se expone nunca en las transacciones o el estado— mientras aprovecha el consenso de la blockchain existente para la integridad. El costo es una mayor carga computacional para los validadores y complejidad en la gestión de claves y la integración de pruebas. A continuación, exploramos un paradigma alternativo que descarga el cómputo completamente off-chain y solo utiliza la cadena para la verificación: el coprocesador de conocimiento cero.

Coprocesadores de Conocimiento Cero (Coprocesadores ZK)​

Un coprocesador ZK es un nuevo patrón de arquitectura de blockchain donde los cómputos costosos se realizan off-chain, y una prueba de conocimiento cero sucinta de su corrección se verifica on-chain. Esto permite que los contratos inteligentes aprovechen una potencia computacional y datos mucho mayores de lo que permitiría la ejecución on-chain, sin sacrificar la falta de confianza (trustlessness). El término coprocesador se utiliza por analogía con los coprocesadores de hardware (como un coprocesador matemático o una GPU) que manejan tareas especializadas para una CPU. Aquí, la "CPU" de la blockchain (la VM nativa como la EVM) delega ciertas tareas a un sistema de prueba de conocimiento cero que actúa como un coprocesador criptográfico. El coprocesador ZK devuelve un resultado y una prueba de que el resultado se calculó correctamente, que el contrato on-chain puede verificar y luego usar.

Arquitectura y Flujo de Trabajo​

En una configuración típica, un desarrollador de dApp identifica partes de la lógica de su aplicación que son demasiado costosas o complejas para la ejecución on-chain (por ejemplo, grandes cómputos sobre datos históricos, algoritmos pesados, inferencia de modelos de ML, etc.). Implementan esas partes como un programa off-chain (en un lenguaje de alto nivel o un DSL de circuito) que puede producir una prueba de conocimiento cero de su ejecución. El componente on-chain es un contrato inteligente verificador que comprueba las pruebas y pone los resultados a disposición del resto del sistema. El flujo se puede resumir en:

1. Solicitud – El contrato on-chain desencadena una solicitud para que se realice un cierto cómputo off-chain. Esto podría ser iniciado por una transacción de usuario o por un contrato que llama a la interfaz del coprocesador ZK. Por ejemplo, un contrato DeFi podría llamar a “proveInterestRate(currentState)” o un usuario llama a “queryHistoricalData(query)”.
2. Ejecución y Prueba Off-Chain – Un servicio off-chain (que podría ser una red descentralizada de probadores o un servicio de confianza, dependiendo del diseño) recoge la solicitud. Reúne los datos necesarios (estado on-chain, entradas off-chain, etc.) y ejecuta el cómputo en una Máquina Virtual ZK (ZKVM) o circuito especial. Durante la ejecución, se genera una traza de prueba. Al final, el servicio produce una prueba sucinta (por ejemplo, un SNARK o STARK) que atestigua que “Calcular la función F sobre la entrada X produce la salida Y” y opcionalmente atestigua la integridad de los datos (más sobre esto a continuación).
3. Verificación On-Chain – La prueba y el resultado se devuelven a la blockchain (a menudo a través de una función de devolución de llamada o callback). El contrato verificador comprueba la validez de la prueba utilizando una verificación criptográfica eficiente (comprobaciones de emparejamiento, etc.). Si es válida, el contrato puede ahora confiar en la salida Y como correcta. El resultado puede almacenarse en el estado, emitirse como un evento o introducirse en la lógica posterior del contrato. Si la prueba es inválida o no se proporciona en un cierto tiempo, la solicitud puede considerarse fallida (y potencialmente se activa alguna lógica de respaldo o de tiempo de espera).

Figura 1: Arquitectura de un Coprocesador ZK (ejemplo de Bonsai de RISC Zero). Off-chain, un programa se ejecuta en una ZKVM con entradas de la llamada al contrato inteligente. Se devuelve una prueba de ejecución on-chain a través de un contrato relay, que invoca una devolución de llamada (callback) con los resultados verificados.

Críticamente, el costo de gas on-chain para la verificación es constante (o crece muy lentamente) independientemente de cuán complejo fue el cómputo off-chain. Verificar una prueba sucinta podría costar del orden de unos cientos de miles de gas (una fracción de un bloque de Ethereum), pero esa prueba podría representar millones de pasos computacionales realizados off-chain. Como bromeó un desarrollador, “¿Quieres probar una firma digital? ~$15. ¿Quieres probar un millón de firmas? También ~$15.”. Esta escalabilidad es una gran ventaja: las dApps pueden ofrecer funcionalidades complejas (análisis de big data, modelos financieros elaborados, etc.) sin congestionar la blockchain.

Los componentes principales de un sistema de coprocesador ZK son:

• Entorno de Generación de Pruebas: Puede ser una ZKVM de propósito general (capaz de ejecutar programas arbitrarios) o circuitos personalizados adaptados a cómputos específicos. Los enfoques varían:

  • Algunos proyectos utilizan circuitos hechos a mano para cada consulta o función soportada (maximizando la eficiencia para esa función).
  • Otros proporcionan un Lenguaje Específico de Dominio (DSL) o un DSL Embebido que los desarrolladores usan para escribir su lógica off-chain, que luego se compila en circuitos (equilibrando la facilidad de uso y el rendimiento).
  • El enfoque más flexible es una zkVM: una máquina virtual (a menudo basada en arquitecturas RISC) donde los programas se pueden escribir en lenguajes estándar (Rust, C, etc.) y probarse automáticamente. Esto sacrifica el rendimiento (simular una CPU en un circuito agrega sobrecarga) por la máxima experiencia del desarrollador.

• Acceso e Integridad de los Datos: Un desafío único es alimentar el cómputo off-chain con los datos correctos, especialmente si esos datos residen en la blockchain (bloques pasados, estados de contratos, etc.). Una solución ingenua es que el probador lea de un nodo de archivo y confíe en él, pero eso introduce suposiciones de confianza. En cambio, los coprocesadores ZK suelen probar que cualquier dato on-chain utilizado fue auténtico al vincularlo a pruebas de Merkle o compromisos de estado. Por ejemplo, el programa de consulta podría tomar un número de bloque y una prueba de Merkle de una ranura de almacenamiento o transacción, y el circuito verificará esa prueba contra un hash de encabezado de bloque conocido. Existen tres patrones:

  1. Datos en Línea: Poner los datos necesarios on-chain (como entrada al verificador) para que puedan ser verificados directamente. Esto es muy costoso para grandes volúmenes de datos y socava todo el propósito.
  2. Confiar en un Oráculo: Hacer que un servicio de oráculo alimente los datos a la prueba y los certifique. Esto es más simple pero reintroduce la confianza en un tercero.
  3. Probar la Inclusión de Datos vía ZK: Incorporar pruebas de inclusión de datos en el historial de la cadena dentro del propio circuito de conocimiento cero. Esto aprovecha el hecho de que cada encabezado de bloque de Ethereum se compromete con todo el estado anterior (a través de la raíz de estado) y el historial de transacciones. Al verificar las pruebas de Merkle Patricia de los datos dentro del circuito, la prueba de salida asegura al contrato que “este cómputo utilizó datos genuinos de la blockchain del bloque N” sin necesidad de confianza adicional.

  El tercer enfoque es el más trustless y es utilizado por coprocesadores ZK avanzados como Axiom y Xpansion (aumenta el costo de la prueba, pero es preferible por seguridad). Por ejemplo, el sistema de Axiom modela la estructura de bloques de Ethereum, el trie de estado y el trie de transacciones dentro de sus circuitos, por lo que puede probar afirmaciones como “la cuenta X tenía un saldo Y en el bloque N” o “una transacción con ciertas propiedades ocurrió en el bloque N”. Aprovecha el hecho de que, dado un hash de bloque reciente de confianza, se puede probar recursivamente la inclusión de datos históricos sin confiar en ninguna parte externa.

• Contrato Verificador: Este contrato on-chain contiene la clave de verificación y la lógica para aceptar o rechazar pruebas. Para SNARKs como Groth16 o PLONK, el verificador podría hacer algunos emparejamientos de curvas elípticas; para STARKs, podría hacer algunos cómputos de hash. Las optimizaciones de rendimiento como la agregación y la recursión pueden minimizar la carga on-chain. Por ejemplo, Bonsai de RISC Zero utiliza un envoltorio de STARK a SNARK: ejecuta una VM basada en STARK off-chain por velocidad, pero luego genera una pequeña prueba SNARK que atestigua la validez del STARK. Esto reduce el tamaño de la prueba de cientos de kilobytes a unos pocos cientos de bytes, haciendo que la verificación on-chain sea factible y barata. El verificador de Solidity entonces solo comprueba el SNARK (que es una operación de tiempo constante).

En términos de despliegue, los coprocesadores ZK pueden funcionar como redes similares a la capa 2 o como servicios puramente off-chain. Algunos, como Axiom, comenzaron como un servicio especializado para Ethereum (con el respaldo de Paradigm) donde los desarrolladores envían consultas a la red de probadores de Axiom y obtienen pruebas on-chain. El eslogan de Axiom era proporcionar a los contratos de Ethereum “acceso sin confianza a todos los datos on-chain y cómputo expresivo arbitrario sobre ellos”. Actúa efectivamente como un oráculo de consultas donde las respuestas son verificadas por ZKPs en lugar de confianza. Otros, como Bonsai de RISC Zero, ofrecen una plataforma más abierta: cualquier desarrollador puede subir un programa (compilado a una ZKVM compatible con RISC-V) y usar el servicio de pruebas de Bonsai a través de un contrato relay. El patrón de relay, como se ilustra en la Figura 1, implica un contrato que media las solicitudes y respuestas: el contrato de la dApp llama al relay para solicitar una prueba, el servicio off-chain escucha esto (por ejemplo, a través de un evento o una llamada directa), calcula la prueba, y luego el relay invoca una función de devolución de llamada en el contrato de la dApp con el resultado y la prueba. Este modelo asíncrono es necesario porque la prueba puede tardar desde segundos hasta minutos dependiendo de la complejidad. Introduce una latencia (y una suposición de liveness de que el probador responderá), mientras que los cómputos de FHE-VM ocurren sincrónicamente dentro de un bloque. Diseñar la aplicación para manejar este flujo de trabajo asíncrono (posiblemente similar a las respuestas de un Oráculo) es parte del uso de un coprocesador ZK.

Proyectos Notables de Coprocesadores ZK​

• Axiom: Axiom es un coprocesador ZK diseñado para Ethereum, enfocado originalmente en probar consultas de datos on-chain históricos. Utiliza el framework de pruebas Halo2 (un SNARK tipo Plonk) para crear pruebas que incorporan las estructuras criptográficas de Ethereum. En el sistema de Axiom, un desarrollador puede consultar cosas como “¿cuál era el estado del contrato X en el bloque N?” o realizar un cómputo sobre todas las transacciones en un rango. Por debajo, los circuitos de Axiom tuvieron que implementar la lógica de estado/trie de Ethereum, incluso realizando operaciones de curva elíptica y verificación de SNARK dentro del circuito para soportar la recursión. Trail of Bits, en una auditoría, señaló la complejidad de los circuitos Halo2 de Axiom que modelan bloques y estados completos. Después de la auditoría, Axiom generalizó su tecnología en una OpenVM, permitiendo que código Rust arbitrario sea probado con la misma infraestructura basada en Halo2. (Esto refleja la tendencia de pasar de circuitos específicos de dominio a un enfoque de ZKVM más general). El equipo de Axiom demostró consultas ZK que Ethereum nativamente no puede hacer, permitiendo un acceso sin estado a cualquier dato histórico con integridad criptográfica. También han enfatizado la seguridad, detectando y corrigiendo errores de circuitos sub-restringidos y asegurando la solidez. Aunque el producto inicial de Axiom fue cerrado durante su pivote, su enfoque sigue siendo un hito en los coprocesadores ZK.

• RISC Zero Bonsai: RISC Zero es una ZKVM basada en la arquitectura RISC-V. Su zkVM puede ejecutar programas arbitrarios (escritos en Rust, C++ y otros lenguajes compilados a RISC-V) y producir una prueba STARK de la ejecución. Bonsai es el servicio en la nube de RISC Zero que proporciona esta prueba bajo demanda, actuando como un coprocesador para contratos inteligentes. Para usarlo, un desarrollador escribe un programa (digamos una función que realiza matemáticas complejas o verifica una respuesta de API off-chain), lo sube al servicio Bonsai y despliega un contrato verificador correspondiente. Cuando el contrato necesita ese cómputo, llama al relay de Bonsai que desencadena la generación de la prueba y devuelve el resultado a través de una devolución de llamada. Una aplicación de ejemplo demostrada fue el cómputo de gobernanza off-chain: RISC Zero mostró una DAO usando Bonsai para contar votos y calcular métricas de votación complejas off-chain, y luego publicar una prueba para que el contrato Gobernador on-chain pudiera confiar en el resultado con un costo de gas mínimo. La tecnología de RISC Zero enfatiza que los desarrolladores pueden usar paradigmas de programación familiares —por ejemplo, escribir una función en Rust para calcular algo— y el trabajo pesado de la creación de circuitos es manejado por la zkVM. Sin embargo, las pruebas pueden ser grandes, por lo que, como se señaló anteriormente, implementaron una compresión SNARK para la verificación on-chain. En agosto de 2023, verificaron con éxito pruebas de RISC Zero en la red de prueba Sepolia de Ethereum, con un costo del orden de 300k de gas por prueba. Esto abre la puerta para que las dApps de Ethereum usen Bonsai hoy como una solución de escalado y privacidad. (Bonsai todavía está en alfa, no listo para producción, y utiliza una configuración SNARK temporal sin una ceremonia).

• Otros: Existen numerosos otros actores e iniciativas de investigación. Expansion/Xpansion (como se menciona en un blog) utiliza un enfoque de DSL embebido, donde los desarrolladores pueden escribir consultas sobre datos on-chain con un lenguaje especializado, y este se encarga internamente de la generación de pruebas. Cairo de StarkWare y zkEVM de Polygon son VMs de ZK-rollup más generales, pero su tecnología podría ser reutilizada para un uso similar a un coprocesador al verificar pruebas dentro de contratos L1. También vemos proyectos en el dominio de ZKML (ZK Machine Learning), que actúan efectivamente como coprocesadores para verificar la inferencia de modelos de ML o los resultados de entrenamiento on-chain. Por ejemplo, una configuración de zkML puede probar que “una inferencia de red neuronal sobre entradas privadas produjo la clasificación X” sin revelar las entradas ni realizar el cómputo on-chain. Estos son casos especiales del concepto de coprocesador aplicado a la IA.

Suposiciones de confianza: Los coprocesadores ZK se basan en la solidez de las pruebas criptográficas. Si el sistema de prueba es seguro (y cualquier configuración de confianza se realiza honestamente), entonces una prueba aceptada garantiza que el cómputo fue correcto. No se necesita confianza adicional en el probador; incluso un probador malicioso no puede convencer al verificador de una afirmación falsa. Sin embargo, existe una suposición de liveness: alguien debe realizar realmente el cómputo off-chain y producir la prueba. En la práctica, esto podría ser una red descentralizada (con incentivos o tarifas para hacer el trabajo) o un único operador de servicio. Si nadie proporciona la prueba, la solicitud on-chain podría quedar sin resolver. Otro aspecto sutil de confianza es la disponibilidad de datos para entradas off-chain que no están en la blockchain. Si el cómputo depende de algunos datos privados o externos, el verificador no puede saber si esos datos se proporcionaron honestamente a menos que se utilicen medidas adicionales (como compromisos de datos o firmas de oráculos). Pero para cómputos de datos puramente on-chain, los mecanismos descritos aseguran una falta de confianza equivalente a la de la propia cadena (Axiom argumentó que sus pruebas ofrecen "seguridad criptográficamente equivalente a Ethereum" para consultas históricas).

Privacidad: Las pruebas de conocimiento cero también soportan inherentemente la privacidad: el probador puede mantener las entradas ocultas mientras prueba afirmaciones sobre ellas. En un contexto de coprocesador, esto significa que una prueba puede permitir que un contrato utilice un resultado que se derivó de datos privados. Por ejemplo, una prueba podría mostrar “la puntuación de crédito del usuario > 700, por lo tanto, aprobar el préstamo” sin revelar la puntuación de crédito real o los datos brutos. El caso de uso de Axiom se centraba más en datos públicamente conocidos (historial de la blockchain), por lo que la privacidad no era el foco allí. Pero la zkVM de RISC Zero podría usarse para probar afirmaciones sobre datos secretos proporcionados por un usuario: los datos permanecen off-chain y solo el resultado necesario va on-chain. Vale la pena señalar que, a diferencia del FHE, una prueba ZK no suele proporcionar confidencialidad continua del estado; es una prueba única. Si un flujo de trabajo necesita mantener un estado secreto a través de transacciones, se podría construir haciendo que el contrato almacene un compromiso con el estado y cada prueba muestre una transición de estado válida del compromiso antiguo al nuevo, con los secretos ocultos. Así es esencialmente como funcionan los zk-rollups para transacciones privadas (como Aztec o Zcash). Por lo tanto, los coprocesadores ZK pueden facilitar máquinas de estado totalmente privadas, pero la implementación no es trivial; a menudo se utilizan para cómputos únicos donde la entrada o la salida (o ambas) pueden ser privadas según sea necesario.

Experiencia del desarrollador: Usar un coprocesador ZK generalmente requiere aprender nuevas herramientas. Escribir circuitos personalizados (opción (1) anterior) es bastante complejo y generalmente solo se hace para propósitos específicos. Opciones de nivel superior como los DSLs o las zkVMs facilitan la vida pero aún agregan sobrecarga: el desarrollador debe escribir y desplegar código off-chain y gestionar la interacción. A diferencia de la FHE-VM, donde el cifrado se maneja principalmente tras bambalinas y el desarrollador escribe código de contrato inteligente normal, aquí el desarrollador necesita particionar su lógica y posiblemente escribir en un lenguaje diferente (Rust, etc.) para la parte off-chain. Sin embargo, iniciativas como los DSLs Noir, Leo, Circom o el enfoque de RISC Zero están mejorando rápidamente la accesibilidad. Por ejemplo, RISC Zero proporciona plantillas e integración con Foundry de tal manera que un desarrollador puede simular su código off-chain localmente (para la corrección) y luego conectarlo sin problemas a las pruebas de Solidity a través de la devolución de llamada de Bonsai. Con el tiempo, podemos esperar frameworks de desarrollo que abstraigan si una pieza de lógica se ejecuta a través de una prueba ZK o on-chain; el compilador o las herramientas podrían decidir en función del costo.

FHE-VM vs Coprocesador ZK: Comparación​

Tanto las FHE-VMs como los coprocesadores ZK permiten una forma de “cómputo sobre datos privados con garantía on-chain”, pero difieren fundamentalmente en su arquitectura. La siguiente tabla resume las diferencias clave:

Aspecto	FHE-VM (Ejecución Cifrada On-Chain)	Coprocesador ZK (Prueba Off-Chain)
Dónde ocurre el cómputo	Directamente on-chain (todos los nodos ejecutan operaciones homomórficas sobre textos cifrados).	Off-chain (un probador o red ejecuta el programa; solo se verifica una prueba on-chain).
Confidencialidad de los datos	Cifrado completo: los datos permanecen cifrados en todo momento on-chain; los validadores nunca ven texto plano. Solo los poseedores de las claves de descifrado pueden descifrar las salidas.	Conocimiento cero: las entradas privadas del probador nunca se revelan on-chain; la prueba no revela secretos más allá de lo que está en las salidas públicas. Sin embargo, cualquier dato utilizado en el cómputo que deba afectar el estado on-chain debe codificarse en la salida o en un compromiso. Los secretos permanecen off-chain por defecto.
Modelo de confianza	Confianza en la ejecución por consenso y la criptografía: si la mayoría de los validadores sigue el protocolo, la ejecución cifrada es determinista y correcta. No se necesita confianza externa para la corrección del cómputo (todos los nodos lo recalculan). Se debe confiar en la seguridad del esquema FHE (generalmente basado en la dureza de los problemas de retículos) para la privacidad. En algunos diseños, también se confía en que no ocurra una colusión de suficientes validadores para hacer un mal uso de las claves de umbral.	Confianza en la seguridad del sistema de prueba (solidez de SNARK/STARK). Si la prueba se verifica, el resultado es correcto con certeza criptográfica. Los probadores off-chain no pueden engañar a las matemáticas. Hay una suposición de liveness sobre los probadores para que realmente hagan el trabajo. Si se utiliza una configuración de confianza (por ejemplo, SRS de SNARK), se debe confiar en que se generó honestamente o usar sistemas transparentes/sin configuración.
Costo on-chain y escalabilidad	Alto costo por transacción: Las operaciones homomórficas son extremadamente costosas computacionalmente, y cada nodo debe realizarlas. Los costos de gas son altos (por ejemplo, más de 100k de gas por una sola suma de 8 bits). Los contratos complejos están limitados por lo que cada validador puede calcular en un bloque. El rendimiento es mucho menor que el de los contratos inteligentes normales a menos que se emplee hardware especializado. La escalabilidad se mejora con criptografía más rápida y aceleración por hardware, pero fundamentalmente cada operación aumenta la carga de trabajo de la cadena.	Bajo costo de verificación: Verificar una prueba sucinta es eficiente y de tamaño constante, por lo que el gas on-chain es modesto (cientos de miles de gas para cualquier tamaño de cómputo). Esto desacopla la complejidad de los límites de recursos on-chain: los grandes cómputos no tienen un costo on-chain adicional. Por lo tanto, escala en términos de carga on-chain. Off-chain, el tiempo de prueba puede ser significativo (minutos o más para tareas enormes) y podría requerir máquinas potentes, pero esto no ralentiza directamente la blockchain. El rendimiento general puede ser alto siempre que las pruebas se puedan generar a tiempo (potenciales redes de probadores en paralelo).
Latencia	Los resultados están disponibles inmediatamente en la misma transacción/bloque, ya que el cómputo ocurre durante la ejecución. Sin viajes de ida y vuelta adicionales: operación síncrona. Sin embargo, un mayor tiempo de procesamiento de bloques podría aumentar la latencia de la blockchain si las operaciones FHE son lentas.	Inherente asíncrono. Típicamente requiere una transacción para solicitar y una transacción posterior (o devolución de llamada) para proporcionar la prueba/resultado. Esto introduce un retraso (posiblemente de segundos a horas dependiendo de la complejidad de la prueba y el hardware de prueba). No es adecuado para la finalidad instantánea de una sola transacción, más bien un modelo de trabajo asíncrono.
Garantías de privacidad	Fuerte: Todo (entradas, salidas, estado intermedio) puede permanecer cifrado on-chain. Puedes tener un estado cifrado de larga duración que múltiples transacciones actualizan sin revelarlo nunca. Solo las acciones de descifrado autorizadas (si las hay) revelan las salidas, y estas pueden controlarse mediante claves/ACLs. Sin embargo, consideraciones de canal lateral como el uso de gas o los registros de eventos deben gestionarse para que no filtren patrones (los diseños de fhEVM se esfuerzan por una ejecución ajena a los datos con gas constante para las operaciones para evitar fugas).	Selectiva: La prueba revela lo que sea que esté en las salidas públicas o sea necesario para verificar (por ejemplo, un compromiso con el estado inicial). Los diseñadores pueden asegurarse de que solo se revele el resultado previsto, y todas las demás entradas permanezcan ocultas con conocimiento cero. Pero a diferencia del FHE, la blockchain típicamente no almacena el estado oculto; la privacidad se logra manteniendo los datos completamente off-chain. Si se necesita un estado privado persistente, el contrato puede almacenar un compromiso criptográfico con él (de modo que las actualizaciones de estado aún revelan un nuevo compromiso cada vez). La privacidad está limitada por lo que eliges probar; tienes flexibilidad para probar, por ejemplo, que se cumplió un umbral sin revelar valores exactos.
Aplicación de la integridad	Por diseño, todos los validadores recalculan el siguiente estado homomórficamente, por lo que si un actor malicioso proporciona un resultado de texto cifrado incorrecto, otros detectarán una discrepancia: el consenso falla a menos que todos obtengan el mismo resultado. Por lo tanto, la integridad se aplica mediante la ejecución redundante (como en una blockchain normal, solo que con datos cifrados). A menudo se utilizan pruebas ZK adicionales para hacer cumplir las reglas de negocio (por ejemplo, que un usuario no pudo violar una restricción) porque los validadores no pueden verificar directamente las condiciones del texto plano.	La integridad es aplicada por el contrato verificador que comprueba la prueba ZK. Mientras la prueba se verifique, se garantiza que el resultado es consistente con alguna ejecución válida del programa off-chain. No se necesita una suposición de mayoría honesta para la corrección; incluso un solo verificador honesto (el propio código del contrato) es suficiente. El contrato on-chain simplemente rechazará cualquier prueba falsa o faltante (similar a como rechazaría una firma inválida). Una consideración: si el probador aborta o se retrasa, el contrato puede necesitar una lógica de respaldo (o los usuarios pueden necesitar intentarlo de nuevo más tarde), pero no aceptará resultados incorrectos.
Experiencia del desarrollador	Pros: Se pueden usar en gran medida lenguajes de contratos inteligentes familiares (Solidity, etc.) con extensiones. La confidencialidad es manejada por la plataforma; los desarrolladores se preocupan principalmente por qué cifrar y quién tiene las claves. La composición de contratos cifrados y normales es posible, manteniendo la componibilidad de DeFi (solo con variables cifradas). Contras: Deben entender las limitaciones de FHE, por ejemplo, no hay saltos condicionales directos sobre datos secretos sin un manejo especial, profundidad de circuito limitada (aunque el bootstrapping en TFHE permite una longitud de cómputo arbitraria a expensas del tiempo). Depurar la lógica cifrada puede ser complicado ya que no se pueden introspeccionar fácilmente los valores en tiempo de ejecución sin la clave. Además, la gestión de claves y los permisos agregan complejidad al diseño del contrato.	Pros: Potencialmente se puede usar cualquier lenguaje de programación para la parte off-chain (especialmente con una zkVM). Aprovechar código/bibliotecas existentes en el programa off-chain (con advertencias sobre la compatibilidad con ZK). No se necesita criptografía personalizada por parte del desarrollador si se usa una ZKVM general: escriben código normal y obtienen una prueba. Además, el cómputo pesado puede usar bibliotecas (por ejemplo, código de aprendizaje automático) que nunca se ejecutarían on-chain. Contras: Los desarrolladores deben orquestar la infraestructura off-chain o usar un servicio de prueba. Manejar flujos de trabajo asíncronos e integrarlos con la lógica on-chain requiere más trabajo de diseño (por ejemplo, almacenar un estado pendiente, esperar una devolución de llamada). Escribir circuitos eficientes o código zkVM puede requerir aprender nuevas restricciones (por ejemplo, sin punto flotante, usar punto fijo o primitivas especiales; evitar ramificaciones pesadas que disparan el tiempo de prueba; optimizar para el recuento de restricciones). También existe la carga de lidiar con fallos de prueba, tiempos de espera, etc., que no son preocupaciones en Solidity regular. El ecosistema de herramientas está creciendo, pero es un nuevo paradigma para muchos.

Ambos enfoques están siendo mejorados activamente, e incluso vemos convergencia: como se señaló, las ZKPs se utilizan dentro de las FHE-VMs para ciertas verificaciones, y a la inversa, algunos investigadores proponen usar FHE para mantener privadas las entradas del probador en ZK (para que un probador en la nube no vea tus datos secretos). Es concebible que los sistemas futuros los combinen, por ejemplo, realizando FHE off-chain y luego probando la corrección de eso en la cadena, o usando FHE on-chain pero probando con ZK a los clientes ligeros que las operaciones cifradas se realizaron correctamente. Cada técnica tiene sus fortalezas: la FHE-VM ofrece privacidad continua e interacción en tiempo real a costa de un cómputo pesado, mientras que los coprocesadores ZK ofrecen escalabilidad y flexibilidad a costa de latencia y complejidad.

Casos de Uso e Implicaciones​

La llegada de la privacidad programable desbloquea una gran cantidad de nuevas aplicaciones de blockchain en todas las industrias. A continuación, exploramos cómo las FHE-VMs y los coprocesadores ZK (o híbridos) pueden potenciar diversos dominios al permitir contratos inteligentes que preservan la privacidad y una economía de datos segura.

DeFi Confidencial y Finanzas​

En las finanzas descentralizadas, la privacidad puede mitigar el front-running, proteger las estrategias de trading y satisfacer el cumplimiento normativo sin sacrificar la transparencia donde sea necesario. El DeFi Confidencial podría permitir a los usuarios interactuar con protocolos sin revelar sus posiciones al mundo.

• Transacciones Privadas y Saldos Ocultos: Usando FHE, se pueden implementar transferencias de tokens confidenciales (saldos y transacciones ERC-20 cifrados) o pools protegidos en una L1 de blockchain. Ningún observador puede ver cuánto de un token tienes o transferiste, eliminando el riesgo de ataques dirigidos basados en las tenencias. Las pruebas ZK pueden asegurar que los saldos se mantengan sincronizados y que no ocurra un doble gasto (similar a Zcash pero en plataformas de contratos inteligentes). Un ejemplo es un AMM (Creador de Mercado Automatizado) confidencial donde las reservas del pool y las operaciones están cifradas on-chain. Los arbitrajistas o front-runners no pueden explotar el pool porque no pueden observar el deslizamiento de precios hasta después de que la operación se haya liquidado, reduciendo el MEV. Solo después de un cierto retraso o a través de un mecanismo de acceso controlado se podrían revelar algunos datos para auditoría.

• Subastas y Trading Resistentes al MEV: Los mineros y los bots explotan la transparencia de las transacciones para hacer front-running en las operaciones. Con el cifrado, se podría tener un mempool cifrado o subastas por lotes donde las órdenes se envían en texto cifrado. Solo después de que la subasta se liquida, las operaciones se descifran. Este concepto, a veces llamado Flujo Justo de Órdenes, se puede lograr con descifrado de umbral (múltiples validadores descifran colectivamente el lote) o probando los resultados de la subasta a través de ZK sin revelar las ofertas individuales. Por ejemplo, un coprocesador ZK podría tomar un lote de ofertas selladas off-chain, calcular el precio de liquidación de la subasta y generar solo ese precio y los ganadores con pruebas. Esto preserva la equidad y la privacidad de las ofertas perdedoras.

• Préstamos y Derivados Confidenciales: En los préstamos DeFi, los usuarios podrían no querer revelar el tamaño de sus préstamos o colateral (puede afectar el sentimiento del mercado o invitar a la explotación). Una FHE-VM puede mantener un libro de préstamos cifrado donde los detalles de cada préstamo están cifrados. La lógica del contrato inteligente aún puede hacer cumplir reglas como las condiciones de liquidación operando sobre factores de salud cifrados. Si el ratio de colateral de un préstamo cae por debajo del umbral, el contrato (con la ayuda de pruebas ZK) puede marcarlo para liquidación sin exponer nunca los valores exactos; podría simplemente producir una bandera de sí/no en texto plano. De manera similar, las posiciones secretas de derivados u opciones podrían gestionarse on-chain, revelando solo métricas de riesgo agregadas. Esto podría prevenir el copy trading y proteger estrategias propietarias, fomentando una mayor participación institucional.

• Privacidad Conforme a la Normativa: No todos los contextos financieros desean un anonimato total; a veces se necesita una divulgación selectiva para la regulación. Con estas herramientas, podemos lograr una privacidad regulada: por ejemplo, las operaciones son privadas para el público, pero un exchange regulado puede descifrar o recibir pruebas sobre ciertas propiedades. Se podría probar a través de ZK que “esta operación no involucró una dirección en la lista negra y ambas partes están verificadas por KYC” sin revelar las identidades a la cadena. Este equilibrio podría satisfacer las reglas Anti-Lavado de Dinero (AML) mientras se mantienen confidenciales las identidades y posiciones de los usuarios para todos los demás. El FHE podría permitir que un contrato de oficial de cumplimiento on-chain escanee transacciones cifradas en busca de señales de riesgo (con una clave de descifrado accesible solo bajo orden judicial, por ejemplo).

Identidad Digital y Datos Personales​

Los sistemas de identidad pueden beneficiarse significativamente de la tecnología de privacidad on-chain. Actualmente, poner credenciales o atributos personales en un registro público es impráctico debido a las leyes de privacidad y la renuencia de los usuarios. Con FHE y ZK, la identidad auto-soberana puede realizarse de una manera que preserve la privacidad:

• Credenciales de Conocimiento Cero: Usando pruebas ZK (ya comunes en algunos proyectos de identidad), un usuario puede probar afirmaciones como “Soy mayor de 18 años”, “Tengo una licencia de conducir válida” o “Gano más de $50k (para calificación crediticia)” sin revelar ninguna otra información personal. Los coprocesadores ZK pueden mejorar esto manejando verificaciones más complejas off-chain, por ejemplo, probando que la puntuación de crédito de un usuario está por encima de un umbral consultando una base de datos de crédito privada de manera similar a Axiom, y generando solo un sí/no para la blockchain.

• KYC Confidencial en DeFi: Imagina un protocolo DeFi que por ley debe asegurarse de que los usuarios estén verificados por KYC. Con FHE-VM, las credenciales de un usuario pueden almacenarse cifradas on-chain (o referenciadas a través de DID), y un contrato inteligente puede realizar un cómputo FHE para verificar que la información KYC cumple con los requisitos. Por ejemplo, un contrato podría verificar homomórficamente que el nombre y el SSN en un perfil de usuario cifrado coinciden con una lista de usuarios sancionados (también cifrada), o que el país del usuario no está restringido. El contrato solo obtendría un "aprobado/fallido" cifrado que puede ser descifrado por umbral por los validadores de la red a una bandera booleana. Solo se revela el hecho de que el usuario está permitido o no, preservando la confidencialidad de la PII y alineándose con los principios del GDPR. Esta divulgación selectiva garantiza el cumplimiento y la privacidad.

• Acceso Basado en Atributos y Divulgación Selectiva: Los usuarios podrían tener un conjunto de credenciales verificables (edad, ciudadanía, habilidades, etc.) como atributos cifrados. Pueden autorizar a ciertas dApps a ejecutar cómputos sobre ellos sin divulgar todo. Por ejemplo, una dApp de reclutamiento descentralizada podría filtrar candidatos realizando búsquedas en currículums cifrados (usando FHE), por ejemplo, contar años de experiencia, verificar una certificación, y solo si se encuentra una coincidencia, contactar al candidato off-chain. Los detalles privados del candidato permanecen cifrados a menos que elijan revelarlos. Las pruebas ZK también pueden permitir a los usuarios probar selectivamente que poseen una combinación de atributos (por ejemplo, mayor de 21 y dentro de un cierto código postal) sin revelar los valores reales.

• Verificación de Identidad Multipartita: A veces, la identidad de un usuario necesita ser verificada por múltiples partes (digamos, una verificación de antecedentes por la empresa A, una verificación de crédito por la empresa B). Con herramientas homomórficas y ZK, cada verificador podría contribuir con una puntuación o aprobación cifrada, y un contrato inteligente puede agregarlas a una decisión final sin exponer las contribuciones individuales. Por ejemplo, tres agencias proporcionan bits de "aprobado/fallido" cifrados, y el contrato emite una aprobación si las tres son aprobadas; el usuario o la parte que confía solo ve el resultado final, no qué agencia específica podría haberlos reprobado, preservando la privacidad del registro del usuario en cada agencia. Esto puede reducir el sesgo y el estigma asociados con, por ejemplo, una verificación fallida que revela un problema específico.

Salud y Compartición de Datos Sensibles​

Los datos de salud son altamente sensibles y regulados, sin embargo, combinar datos de múltiples fuentes puede desbloquear un valor enorme (para investigación, seguros, medicina personalizada). La blockchain podría proporcionar una capa de confianza para el intercambio de datos si se resuelve la privacidad. Los contratos inteligentes confidenciales podrían permitir nuevos ecosistemas de datos de salud:

• Intercambio Seguro de Datos Médicos: Los pacientes podrían almacenar referencias a sus registros médicos on-chain en forma cifrada. Un contrato habilitado para FHE podría permitir a una institución de investigación ejecutar análisis sobre una cohorte de datos de pacientes sin descifrarlos. Por ejemplo, un contrato podría calcular la eficacia promedio de un medicamento a través de los resultados cifrados de los pacientes. Solo los resultados estadísticos agregados salen descifrados (y quizás solo si se incluye un número mínimo de pacientes, para evitar la reidentificación). Los pacientes podrían recibir micropagos por contribuir con sus datos cifrados a la investigación, sabiendo que su privacidad se preserva porque incluso la blockchain y los investigadores solo ven texto cifrado o pruebas agregadas. Esto fomenta un mercado de datos para la salud que respeta la privacidad.

• Procesamiento de Reclamaciones de Seguros que Preserva la Privacidad: El procesamiento de reclamaciones de seguros de salud podría automatizarse a través de contratos inteligentes que verifican condiciones sobre datos médicos sin exponer los datos a la aseguradora. Una reclamación podría incluir un código de diagnóstico cifrado y un costo de tratamiento cifrado; el contrato, usando FHE, verifica las reglas de la póliza (por ejemplo, cobertura, deducible) sobre esos datos cifrados. Podría generar una aprobación y un monto de pago sin revelar nunca el diagnóstico real a la blockchain de la aseguradora (solo el paciente y el médico tenían la clave). Las pruebas ZK podrían usarse para demostrar que los datos del paciente provinieron de los registros de un hospital certificado (usando algo como Axiom para verificar la firma de un hospital o la inclusión de un registro) sin revelar el registro en sí. Esto garantiza la privacidad del paciente mientras previene el fraude.

• Cómputo de Datos Genómicos y Personales: Los datos genómicos son extremadamente sensibles (son literalmente el plano de ADN de una persona). Sin embargo, analizar genomas puede proporcionar valiosos conocimientos sobre la salud. Las empresas podrían usar FHE-VM para realizar cómputos sobre genomas cifrados subidos por los usuarios. Por ejemplo, un contrato inteligente podría ejecutar un modelo de riesgo gen-ambiente sobre datos genómicos cifrados y datos ambientales cifrados (quizás de wearables), generando una puntuación de riesgo que solo el usuario puede descifrar. La lógica (quizás un algoritmo de puntuación de riesgo poligénico) está codificada en el contrato y se ejecuta homomórficamente, por lo que los datos genómicos nunca aparecen en texto plano. De esta manera, los usuarios obtienen conocimientos sin dar a las empresas datos de ADN brutos, mitigando tanto las preocupaciones de privacidad como de propiedad de los datos.

• Epidemiología y Salud Pública: Durante situaciones como pandemias, compartir datos es vital para modelar la propagación de enfermedades, pero las leyes de privacidad pueden obstaculizar el intercambio de datos. Los coprocesadores ZK podrían permitir a las autoridades de salud pública enviar consultas como “¿Cuántas personas en la región X dieron positivo en las últimas 24h?” a una red de datos de hospitales a través de pruebas. Cada hospital mantiene los registros de pruebas de los pacientes off-chain pero puede probar al contrato de la autoridad el recuento de positivos sin revelar quiénes son. De manera similar, el rastreo de contactos podría hacerse haciendo coincidir rastros de ubicación cifrados: los contratos pueden calcular intersecciones de historiales de ubicación cifrados de pacientes para identificar puntos calientes, generando solo las ubicaciones de los puntos calientes (y quizás una lista cifrada de identificaciones afectadas que solo el departamento de salud puede descifrar). Los rastros de ubicación brutos de los individuos permanecen privados.

Mercados de Datos y Colaboración​

La capacidad de computar sobre datos sin revelarlos abre nuevos modelos de negocio en torno al intercambio de datos. Las entidades pueden colaborar en cómputos sabiendo que sus datos propietarios no serán expuestos:

• Mercados de Datos Seguros: Los vendedores pueden poner datos a disposición en forma cifrada en un mercado de blockchain. Los compradores pueden pagar para ejecutar análisis específicos o modelos de aprendizaje automático sobre el conjunto de datos cifrado a través de un contrato inteligente, obteniendo ya sea el modelo entrenado o resultados agregados. Los datos brutos del vendedor nunca se revelan al comprador ni al público; el comprador podría recibir solo un modelo (que aún podría filtrar algo de información en los pesos, pero técnicas como la privacidad diferencial o el control de la granularidad de la salida pueden mitigar esto). Las pruebas ZK pueden asegurar al comprador que el cómputo se realizó correctamente sobre el conjunto de datos prometido (por ejemplo, el vendedor no puede hacer trampa ejecutando el modelo sobre datos ficticios porque la prueba lo vincula al conjunto de datos cifrado comprometido). Este escenario fomenta el intercambio de datos: por ejemplo, una empresa podría monetizar los datos de comportamiento del usuario permitiendo que algoritmos aprobados se ejecuten sobre ellos bajo cifrado, sin entregar los datos en sí.

• Aprendizaje Federado e IA Descentralizada: En el aprendizaje automático descentralizado, múltiples partes (por ejemplo, diferentes empresas o dispositivos) quieren entrenar conjuntamente un modelo con sus datos combinados sin compartir datos entre sí. Las FHE-VMs sobresalen aquí: pueden habilitar el aprendizaje federado donde las actualizaciones del modelo de cada parte se agregan homomórficamente por un contrato. Debido a que las actualizaciones están cifradas, ningún participante aprende las contribuciones de los demás. El contrato podría incluso realizar partes del bucle de entrenamiento (como los pasos de descenso de gradiente) on-chain bajo cifrado, produciendo un modelo actualizado que solo las partes autorizadas pueden descifrar. ZK puede complementar esto probando que la actualización de cada parte se calculó siguiendo el algoritmo de entrenamiento (evitando que un participante malicioso envenene el modelo). Esto significa que se puede entrenar un modelo global con total auditabilidad on-chain, pero los datos de entrenamiento de cada contribuyente permanecen privados. Los casos de uso incluyen el entrenamiento conjunto de modelos de detección de fraude entre bancos o la mejora de asistentes de IA utilizando datos de muchos usuarios sin centralizar los datos brutos.

• Análisis Inter-Organizacional: Considera dos empresas que quieren encontrar su intersección de clientes para una campaña de asociación sin exponer sus listas completas de clientes entre sí. Podrían cifrar cada una sus listas de ID de clientes y subir un compromiso. Un contrato habilitado para FHE puede calcular la intersección en los conjuntos cifrados (usando técnicas como la intersección de conjuntos privados a través de FHE). El resultado podría ser una lista cifrada de IDs de clientes comunes que solo un tercero de confianza mutua (o los propios clientes, a través de algún mecanismo) puede descifrar. Alternativamente, un enfoque ZK: una parte prueba a la otra en conocimiento cero que “tenemos N clientes en común y aquí hay un cifrado de esos IDs” con una prueba de que el cifrado corresponde efectivamente a las entradas comunes. De esta manera, pueden proceder con una campaña para esos N clientes sin intercambiar nunca sus listas completas en texto plano. Escenarios similares: calcular métricas de la cadena de suministro entre competidores sin revelar detalles de proveedores individuales, o bancos que cotejan información crediticia sin compartir datos completos de clientes.

• Cómputo Seguro Multipartito (MPC) en Blockchain: FHE y ZK esencialmente traen conceptos de MPC on-chain. La lógica de negocio compleja que abarca múltiples organizaciones puede codificarse en un contrato inteligente de tal manera que las entradas de cada organización se compartan en secreto o se cifren. El contrato (como facilitador de MPC) produce salidas como divisiones de ganancias, cálculos de costos o evaluaciones de riesgo conjuntas en las que todos pueden confiar. Por ejemplo, supongamos que varias compañías de energía quieren liquidar un mercado de comercio de energía. Podrían alimentar sus ofertas y demandas cifradas en una subasta de contrato inteligente; el contrato calcula los precios de liquidación y las asignaciones sobre las ofertas cifradas, y genera la asignación y el costo de cada compañía solo para esa compañía (a través de cifrado a su clave pública). Ninguna compañía ve las ofertas de las demás, protegiendo la información competitiva, pero el resultado de la subasta es justo y verificable. Esta combinación de transparencia de blockchain y privacidad de MPC podría revolucionar los consorcios y las alianzas empresariales que actualmente dependen de terceros de confianza.

Aprendizaje Automático Descentralizado (ZKML y FHE-ML)​

Llevar el aprendizaje automático a las blockchains de una manera verificable y privada es una frontera emergente:

• Inferencia de ML Verificable: Usando pruebas ZK, se puede probar que “un modelo de aprendizaje automático f, cuando se le da la entrada x, produce la salida y” sin revelar ni x (si son datos privados) ni el funcionamiento interno de f (si los pesos del modelo son propietarios). Esto es crucial para los servicios de IA en blockchain, por ejemplo, un oráculo de IA descentralizado que proporciona predicciones o clasificaciones. Un coprocesador ZK puede ejecutar el modelo off-chain (ya que los modelos pueden ser grandes y costosos de evaluar) y publicar una prueba del resultado. Por ejemplo, un oráculo podría probar la afirmación “La imagen satelital proporcionada muestra al menos un 50% de cobertura arbórea” para respaldar un contrato de créditos de carbono, sin revelar la imagen satelital o posiblemente incluso el modelo. Esto se conoce como ZKML y hay proyectos trabajando en la optimización de redes neuronales amigables con los circuitos. Asegura la integridad de las salidas de IA utilizadas en los contratos inteligentes (sin trampas ni salidas arbitrarias) y puede preservar la confidencialidad de los datos de entrada y los parámetros del modelo.

• Entrenamiento con Privacidad y Auditabilidad: Entrenar un modelo de ML es aún más intensivo en cómputo, pero si se logra, permitiría mercados de modelos basados en blockchain. Múltiples proveedores de datos podrían contribuir al entrenamiento de un modelo bajo FHE para que el algoritmo de entrenamiento se ejecute sobre datos cifrados. El resultado podría ser un modelo cifrado que solo el comprador puede descifrar. A lo largo del entrenamiento, se podrían suministrar pruebas ZK periódicamente para probar que el entrenamiento seguía el protocolo (evitando que un entrenador malicioso inserte una puerta trasera, por ejemplo). Si bien el entrenamiento de ML completamente on-chain está lejos dados los costos, un enfoque híbrido podría usar cómputo off-chain con pruebas ZK para partes críticas. Se podría imaginar una competencia descentralizada tipo Kaggle donde los participantes entrenan modelos en conjuntos de datos privados y envían pruebas ZK de la precisión del modelo en datos de prueba cifrados para determinar un ganador, todo sin revelar los conjuntos de datos ni los datos de prueba.

• IA Personalizada y Propiedad de los Datos: Con estas tecnologías, los usuarios podrían retener la propiedad de sus datos personales y aun así beneficiarse de la IA. Por ejemplo, el dispositivo móvil de un usuario podría usar FHE para cifrar sus datos de uso y enviarlos a un contrato de análisis que calcula un modelo de IA personalizado (como un modelo de recomendación) solo para ellos. El modelo está cifrado y solo el dispositivo del usuario puede descifrarlo y usarlo localmente. La plataforma (quizás una red social) nunca ve los datos brutos ni el modelo, pero el usuario obtiene el beneficio de la IA. Si la plataforma quiere conocimientos agregados, podría solicitar pruebas ZK de ciertos patrones agregados del contrato sin acceder a los datos individuales.

Áreas Adicionales​

• Juegos: Los juegos on-chain a menudo tienen dificultades para ocultar información secreta (por ejemplo, manos de cartas ocultas, niebla de guerra en juegos de estrategia). FHE puede habilitar juegos de estado oculto donde la lógica del juego se ejecuta sobre un estado cifrado. Por ejemplo, un contrato de juego de póker podría barajar y repartir cartas cifradas; los jugadores obtienen descifrados de sus propias cartas, pero el contrato y los demás solo ven texto cifrado. La lógica de apuestas puede usar pruebas ZK para asegurar que un jugador no está mintiendo sobre una acción (o para revelar la mano ganadora al final de una manera verificablemente justa). De manera similar, las semillas aleatorias para la acuñación de NFT o los resultados de los juegos pueden generarse y probarse como justas sin exponer la semilla (evitando la manipulación). Esto puede mejorar enormemente los juegos de blockchain, permitiéndoles soportar la misma dinámica que los juegos tradicionales.

• Votación y Gobernanza: Las DAOs podrían usar tecnología de privacidad para votaciones secretas on-chain, eliminando la compra de votos y la presión. La FHE-VM podría contar los votos que se emiten en forma cifrada, y solo los totales finales se descifran. Las pruebas ZK pueden asegurar que cada voto fue válido (provino de un votante elegible, que no ha votado dos veces) sin revelar quién votó por qué. Esto proporciona verificabilidad (todos pueden verificar las pruebas y el recuento) mientras se mantienen secretos los votos individuales, lo cual es crucial para una gobernanza imparcial.

• Cadena de Suministro Segura e IoT: En las cadenas de suministro, los socios podrían querer compartir pruebas de ciertas propiedades (origen, métricas de calidad) sin exponer todos los detalles a los competidores. Por ejemplo, un sensor de IoT en un envío de alimentos podría enviar continuamente datos de temperatura cifrados a una blockchain. Un contrato podría usar FHE para verificar si la temperatura se mantuvo en un rango seguro durante todo el tránsito. Si se excedió un umbral, puede activar una alerta o una penalización, pero no tiene que revelar todo el registro de temperatura públicamente, quizás solo una prueba o un agregado como “temperatura del percentil 90”. Esto genera confianza en la automatización de la cadena de suministro mientras se respeta la confidencialidad de los datos del proceso.

Cada uno de estos casos de uso aprovecha la capacidad central: computar o verificar datos sin revelar los datos. Esta capacidad puede cambiar fundamentalmente la forma en que manejamos la información sensible en los sistemas descentralizados. Reduce el compromiso entre la transparencia y la privacidad que ha limitado la adopción de la blockchain en áreas que tratan con datos privados.

Conclusión​

La tecnología blockchain está entrando en una nueva era de privacidad programable, donde la confidencialidad de los datos y la funcionalidad de los contratos inteligentes van de la mano. Los paradigmas de FHE-VM y coprocesadores ZK, aunque técnicamente distintos, ambos se esfuerzan por expandir el alcance de las aplicaciones de blockchain al desacoplar lo que podemos computar de lo que debemos revelar.

Las Máquinas Virtuales de Cifrado Totalmente Homomórfico mantienen los cómputos on-chain y cifrados, preservando la descentralización y la componibilidad, pero exigiendo avances en eficiencia. Los coprocesadores de Conocimiento Cero trasladan el trabajo pesado off-chain, permitiendo un cómputo virtualmente ilimitado bajo garantías criptográficas, y ya están demostrando su valía en el escalado y la mejora de Ethereum. La elección entre ellos (y sus híbridos) dependerá del caso de uso: si se necesita una interacción en tiempo real con un estado privado, un enfoque FHE podría ser más adecuado; si se requiere un cómputo extremadamente complejo o la integración con código existente, un coprocesador ZK podría ser el camino a seguir. En muchos casos, son complementarios; de hecho, vemos pruebas ZK reforzando la integridad de FHE, y FHE potencialmente ayudando a ZK al manejar datos privados para los probadores.

Para los desarrolladores, estas tecnologías introducirán nuevos patrones de diseño. Pensaremos en términos de variables cifradas y verificación de pruebas como elementos de primera clase en la arquitectura de las dApps. Las herramientas están evolucionando rápidamente: lenguajes de alto nivel y SDKs están abstrayendo los detalles criptográficos (por ejemplo, las bibliotecas de Zama que hacen que los tipos FHE sean tan fáciles como los tipos nativos, o las plantillas de RISC Zero para solicitudes de prueba). En unos pocos años, escribir un contrato inteligente confidencial podría sentirse casi tan sencillo como escribir uno regular, solo que con la privacidad "incorporada" por defecto.

Las implicaciones para la economía de datos son profundas. Los individuos y las empresas estarán más dispuestos a poner datos o lógica on-chain cuando puedan controlar su visibilidad. Esto puede desbloquear colaboraciones inter-organizacionales, nuevos productos financieros y modelos de IA que antes eran inviables debido a preocupaciones de privacidad. Los reguladores también pueden llegar a adoptar estas técnicas, ya que permiten verificaciones de cumplimiento y auditorías a través de medios criptográficos (por ejemplo, probar que los impuestos se pagan correctamente on-chain sin exponer todas las transacciones).

Todavía estamos en los primeros días: los prototipos actuales de FHE-VM tienen límites de rendimiento, y las pruebas ZK, aunque mucho más rápidas que antes, todavía pueden ser un cuello de botella para tareas extremadamente complejas. Pero la investigación continua y los esfuerzos de ingeniería (incluido el hardware especializado, como lo demuestran empresas como Optalysys que impulsan la aceleración óptica de FHE) están erosionando rápidamente estas barreras. La financiación que fluye hacia este espacio (por ejemplo, el estatus de unicornio de Zama, la inversión de Paradigm en Axiom) subraya una fuerte creencia de que las características de privacidad serán tan fundamentales para la Web3 como lo fue la transparencia para la Web1/2.

En conclusión, la privacidad programable a través de FHE-VMs y coprocesadores ZK anuncia una nueva clase de dApps que son sin confianza, descentralizadas y confidenciales. Desde operaciones DeFi que no revelan detalles, hasta investigaciones de salud que protegen los datos de los pacientes, pasando por modelos de aprendizaje automático entrenados en todo el mundo sin exponer datos brutos, las posibilidades son vastas. A medida que estas tecnologías maduren, las plataformas de blockchain ya no forzarán el compromiso entre utilidad y privacidad, permitiendo una adopción más amplia en industrias que requieren confidencialidad. El futuro de la Web3 es uno donde los usuarios y las organizaciones pueden transaccionar y computar con confianza datos sensibles on-chain, sabiendo que la blockchain verificará la integridad mientras mantiene sus secretos a salvo.

Fuentes: La información en este informe se extrae de la documentación técnica y blogs de investigación recientes de proyectos líderes en este espacio, incluyendo la documentación de FHEVM de Cypher y Zama, análisis detallados de Trail of Bits sobre los circuitos de Axiom, guías para desarrolladores y publicaciones de blog de RISC Zero, así como artículos de la industria que destacan casos de uso de la tecnología de blockchain confidencial. Estas fuentes y más han sido citadas a lo largo del texto para proporcionar lecturas adicionales y evidencia para las arquitecturas y aplicaciones descritas.

Una de las promesas centrales de la tecnología blockchain como Ethereum es un grado de anonimato. Los participantes, conocidos como validadores, se supone que operan detrás de un velo de seudónimos criptográficos, protegiendo su identidad en el mundo real y, por extensión, su seguridad.

Sin embargo, un artículo de investigación reciente titulado “Desanonimizando a los validadores de Ethereum: la red P2P tiene un problema de privacidad”, elaborado por investigadores de ETH Zurich y otras instituciones, revela una falla crítica en esta suposición. Demuestran un método simple y de bajo costo para vincular el identificador público de un validador directamente con la dirección IP de la máquina en la que se ejecuta.

En resumen, los validadores de Ethereum no son tan anónimos como muchos creen. Los hallazgos fueron lo suficientemente significativos como para que los investigadores recibieran una recompensa por errores de la Ethereum Foundation, reconociendo la gravedad de la fuga de privacidad.

Cómo funciona la vulnerabilidad: una falla en el gossip​

Para entender la vulnerabilidad, primero necesitamos una visión básica de cómo se comunican los validadores de Ethereum. La red está compuesta por más de un millón de validadores que constantemente “votan” sobre el estado de la cadena. Estas votaciones se denominan attestations y se difunden a través de una red peer‑to‑peer ($P2P$) a todos los demás nodos.

Con tantos validadores, hacer que todos difundan cada voto a todos los demás saturaría la red al instante. Para resolver esto, los diseñadores de Ethereum implementaron una solución de escalado ingeniosa: la red se divide en 64 canales de comunicación distintos, conocidos como subnets.

• Por defecto, cada nodo (la computadora que ejecuta el software del validador) se suscribe a solo dos de esos 64 subnets. Su tarea principal es retransmitir diligentemente todos los mensajes que vea en esos dos canales.
• Cuando un validador necesita emitir un voto, su attestation se asigna aleatoriamente a uno de los 64 subnets para su difusión.

Aquí es donde reside la vulnerabilidad. Imagina un nodo cuya tarea es gestionar el tráfico de los canales 12 y 13. Todo el día, reenvía fielmente los mensajes de esos dos canales. Pero de repente, te envía un mensaje que pertenece al canal 45.

Esto es una pista poderosa. ¿Por qué un nodo manejaría un mensaje de un canal del que no es responsable? La conclusión más lógica es que el propio nodo generó ese mensaje. Esto implica que el validador que creó la attestation para el canal 45 está ejecutándose en esa misma máquina.

Los investigadores explotaron este principio exacto. Configurando sus propios nodos de escucha, monitorizaron los subnets desde los que sus pares enviaban attestations. Cuando un par enviaba un mensaje desde un subnet al que no estaba oficialmente suscrito, podían inferir con alta confianza que ese par alojaba al validador origen.

El método resultó sorprendentemente efectivo. Usando solo cuatro nodos durante tres días, el equipo localizó con éxito las direcciones IP de más de 161 000 validadores, lo que representa más del 15 % de toda la red de Ethereum.

Por qué importa: los riesgos de la desanonimización​

Exponer la dirección IP de un validador no es un asunto trivial. Abre la puerta a ataques dirigidos que amenazan tanto a operadores individuales como a la salud de la red Ethereum en su conjunto.

1. Ataques dirigidos y robo de recompensas Ethereum anuncia qué validador está programado para proponer el próximo bloque con unos minutos de antelación. Un atacante que conozca la dirección IP de ese validador puede lanzar un Denial‑of‑Service (DDoS), inundándolo con tráfico y dejándolo fuera de línea. Si el validador pierde su ventana de cuatro segundos para proponer el bloque, la oportunidad pasa al siguiente validador en la fila. Si el atacante es ese siguiente validador, puede reclamar las recompensas del bloque y las tarifas de transacción (MEV) que deberían haber ido a la víctima.

2. Amenazas a la vivacidad y seguridad de la red Un atacante con recursos suficientes podría realizar estos ataques de “sniping” de forma repetida, ralentizando o incluso deteniendo toda la blockchain (un ataque de vivacidad). En un escenario más grave, el atacante podría usar esta información para lanzar ataques sofisticados de partición de red, provocando que diferentes partes de la red discrepen sobre la historia de la cadena y comprometiendo su integridad (un ataque de seguridad).

3. Revelación de una realidad centralizada La investigación también sacó a la luz algunas verdades incómodas sobre la descentralización de la red:

• Concentración extrema: El equipo encontró pares que alojaban una cantidad asombrosa de validadores, incluido un IP que ejecutaba más de 19 000. La falla de una sola máquina podría tener un impacto desproporcionado en la red.
• Dependencia de servicios en la nube: Aproximadamente 90 % de los validadores localizados operan en proveedores de nube como AWS y Hetzner, no en los equipos de stakers domésticos. Esto representa un punto significativo de centralización.
• Dependencias ocultas: Muchos pools de staking grandes afirman que sus operadores son independientes. Sin embargo, la investigación halló casos en los que validadores de diferentes pools competidores estaban ejecutándose en la misma máquina física, creando riesgos sistémicos ocultos.

Mitigaciones: ¿Cómo pueden protegerse los validadores?​

Afortunadamente, existen formas de defenderse contra esta técnica de desanonimización. Los investigadores propusieron varias mitigaciones:

• Crear más ruido: Un validador puede optar por suscribirse a más de dos subnets —incluso a los 64 completos—. Esto dificulta mucho que un observador distinga entre mensajes retransmitidos y los generados por el propio nodo.
• Usar múltiples nodos: Un operador puede separar las funciones del validador en diferentes máquinas con distintas IPs. Por ejemplo, un nodo podría manejar attestations mientras que otro nodo privado se use solo para proponer bloques de alto valor.
• Peering privado: Los validadores pueden establecer conexiones privadas y de confianza con otros nodos para retransmitir sus mensajes, ocultando su origen real dentro de un pequeño grupo confiable.
• Protocolos de difusión anónima: Soluciones más avanzadas como Dandelion, que ofuscan el origen de un mensaje al pasarlo por un “stem” aleatorio antes de difundirlo ampliamente, podrían implementarse.

Conclusión​

Esta investigación ilustra de manera contundente la compensación inherente entre rendimiento y privacidad en los sistemas distribuidos. En su afán por escalar, la red $P2P$ de Ethereum adoptó un diseño que comprometió el anonimato de sus participantes más críticos.

Al sacar a la luz esta vulnerabilidad, los investigadores han proporcionado a la comunidad de Ethereum el conocimiento y las herramientas necesarias para abordarla. Su trabajo constituye un paso crucial hacia la construcción de una red más robusta, segura y verdaderamente descentralizada para el futuro.

La industria de blockchain enfrenta un punto de inflexión crítico en 2024. Mientras que el mercado global de la tecnología blockchain se proyecta alcanzar los $469.49 mil millones para 2030, la privacidad sigue siendo un desafío fundamental. Los Entornos de Ejecución Confiables (TEE) han surgido como una solución potencial, con un mercado de TEE que se espera crezca de$1.2 mil millones en 2023 a $3.8 mil millones para 2028. ¿Pero este enfoque basado en hardware realmente resuelve la paradoja de privacidad de blockchain, o introduce nuevos riesgos?

La Base de Hardware: Entendiendo la Promesa de los TEE​

Un Entorno de Ejecución Confiable funciona como la bóveda de un banco dentro de tu computadora, pero con una diferencia crucial. Mientras que una bóveda simplemente almacena activos, un TEE crea un entorno de cómputo aislado donde las operaciones sensibles pueden ejecutarse completamente protegidas del resto del sistema, incluso si ese sistema está comprometido.

El mercado está actualmente dominado por tres implementaciones clave:

1. Intel SGX (Software Guard Extensions)

   • Cuota de mercado: 45 % de las implementaciones de TEE en servidores
   • Rendimiento: Hasta un 40 % de sobrecarga para operaciones encriptadas
   • Características de seguridad: Encriptación de memoria, atestación remota
   • Usuarios notables: Microsoft Azure Confidential Computing, Fortanix

2. ARM TrustZone

   • Cuota de mercado: 80 % de las implementaciones de TEE en dispositivos móviles
   • Rendimiento: < 5 % de sobrecarga para la mayoría de operaciones
   • Características de seguridad: Arranque seguro, protección biométrica
   • Aplicaciones clave: Pagos móviles, DRM, autenticación segura

3. AMD SEV (Secure Encrypted Virtualization)

   • Cuota de mercado: 25 % de las implementaciones de TEE en servidores
   • Rendimiento: 2‑7 % de sobrecarga para encriptación de máquinas virtuales
   • Características de seguridad: Encriptación de memoria de VM, protección de tablas de páginas anidadas
   • Usuarios notables: Google Cloud Confidential Computing, AWS Nitro Enclaves

Impacto en el Mundo Real: Los Datos Hablan​

Examinemos tres aplicaciones clave donde los TEE ya están transformando blockchain:

1. Protección MEV: Estudio de Caso Flashbots​

La implementación de TEE por parte de Flashbots ha demostrado resultados notables:

• Pre‑TEE (2022):

  • Extracción media diaria de MEV: $7.1 M
  • Extractores centralizados: 85 % del MEV
  • Pérdidas de usuarios por ataques sandwich: $3.2 M diarios

• Post‑TEE (2023):

  • Extracción media diaria de MEV: $4.3 M (‑39 %)
  • Extracción democratizada: Ninguna entidad supera el 15 % del MEV
  • Pérdidas de usuarios por ataques sandwich: $0.8 M diarios (‑75 %)

Según Phil Daian, cofundador de Flashbots: “Los TEE han cambiado fundamentalmente el panorama del MEV. Estamos viendo un mercado más democrático y eficiente con una reducción significativa del daño a los usuarios.”

2. Soluciones de Escalado: El Avance de Scroll​

El enfoque híbrido de Scroll, que combina TEE con pruebas de conocimiento cero, ha alcanzado métricas impresionantes:

• Rendimiento de transacciones: 3,000 TPS (comparado con los 15 TPS de Ethereum)
• Coste por transacción: $0.05 (vs.$2‑20 en la mainnet de Ethereum)
• Tiempo de validación: 15 segundos (vs. minutos para soluciones puras ZK)
• Garantía de seguridad: 99.99 % con verificación dual (TEE + ZK)

La Dra. Sarah Wang, investigadora de blockchain en UC Berkeley, comenta: “La implementación de Scroll muestra cómo los TEE pueden complementar soluciones criptográficas en lugar de reemplazarlas. Las ganancias de rendimiento son significativas sin comprometer la seguridad.”

3. DeFi Privado: Aplicaciones Emergentes​

Varios protocolos DeFi están aprovechando los TEE para transacciones privadas:

• Secret Network (usando Intel SGX):
  • Más de 500,000 transacciones privadas procesadas
  • $150 M en transferencias de tokens privados
  • Reducción del 95 % en front‑running

La Realidad Técnica: Desafíos y Soluciones​

Mitigación de Ataques de Canal Lateral​

Investigaciones recientes han revelado tanto vulnerabilidades como soluciones:

1. Ataques de Análisis de Potencia

   • Vulnerabilidad: 85 % de tasa de éxito en extracción de claves
   • Solución: La última actualización de SGX de Intel reduce la tasa de éxito a < 0.1 %
   • Coste: 2 % de sobrecarga de rendimiento adicional

2. Ataques de Cronometría de Caché

   • Vulnerabilidad: 70 % de tasa de éxito en extracción de datos
   • Solución: Tecnología de partición de caché de AMD
   • Impacto: Reduce la superficie de ataque en un 99 %

Análisis del Riesgo de Centralización​

La dependencia de hardware introduce riesgos específicos:

• Cuota de mercado de proveedores de hardware (2023):
  • Intel: 45 %
  • AMD: 25 %
  • ARM: 20 %
  • Otros: 10 %

Para abordar las preocupaciones de centralización, proyectos como Scroll implementan verificación de TEE multi‑proveedor:

• Acuerdo requerido de 2 + proveedores diferentes de TEE
• Validación cruzada con soluciones que no usan TEE
• Herramientas de verificación de código abierto

Análisis de Mercado y Proyecciones Futuras​

La adopción de TEE en blockchain muestra un fuerte crecimiento:

• Costes de Implementación Actuales:

  • Hardware TEE de nivel servidor: $2,000‑5,000
  • Coste de integración: $50,000‑100,000
  • Mantenimiento: $5,000/mes

• Reducción de Costes Proyectada:

  • 2024: ‑15 %
  • 2025: ‑30 %
  • 2026: ‑50 %

Los expertos de la industria pronostican tres desarrollos clave para 2025:

1. Evolución del Hardware

   • Nuevos procesadores específicos para TEE
   • Reducción de la sobrecarga de rendimiento (< 1 %)
   • Protección mejorada contra canales laterales

2. Consolidación del Mercado

   • Emergencia de estándares
   • Compatibilidad multiplataforma
   • Herramientas de desarrollo simplificadas

3. Expansión de Aplicaciones

   • Plataformas de contratos inteligentes privados
   • Soluciones de identidad descentralizada
   • Protocolos de privacidad cross‑chain

El Camino a Seguir​

Aunque los TEE ofrecen soluciones atractivas, el éxito requiere abordar varias áreas clave:

1. Desarrollo de Estándares

   • Grupos de trabajo de la industria en formación
   • Protocolos abiertos para compatibilidad entre proveedores
   • Marcos de certificación de seguridad

2. Ecología de Desarrolladores

   • Nuevas herramientas y SDKs
   • Programas de capacitación y certificación
   • Implementaciones de referencia

3. Innovación de Hardware

   • Arquitecturas TEE de próxima generación
   • Reducción de costos y consumo energético
   • Características de seguridad mejoradas

Panorama Competitivo​

Los TEE compiten con otras soluciones de privacidad:

Solución	Rendimiento	Seguridad	Descentralización	Coste
TEE	Alto	Medio‑Alto	Medio	Medio
MPC	Medio	Alto	Alto	Alto
FHE	Bajo	Alto	Alto	Muy Alto
Pruebas ZK	Medio‑Alto	Alto	Alto	Alto

Conclusión​

Los TEE representan un enfoque pragmático para la privacidad en blockchain, ofreciendo beneficios de rendimiento inmediatos mientras se trabaja en los problemas de centralización. La rápida adopción de la tecnología por proyectos importantes como Flashbots y Scroll, junto con mejoras medibles en seguridad y eficiencia, sugiere que los TEE jugarán un papel crucial en la evolución de blockchain.

Sin embargo, el éxito no está garantizado. Los próximos 24 meses serán críticos mientras la industria enfrenta dependencias de hardware, esfuerzos de estandarización y el persistente desafío de los ataques de canal lateral. Para desarrolladores y empresas de blockchain, la clave está en comprender las fortalezas y limitaciones de los TEE e implementarlos como parte de una estrategia de privacidad integral, en lugar de considerarlos una solución única.