La transparencia de Ethereum ha sido durante mucho tiempo una de sus mayores fortalezas, pero para muchas aplicaciones del mundo real, también se ha convertido en una limitación estructural. Desde las ineficiencias comerciales impulsadas por MEV hasta la fuga de datos en DeFi, juegos y flujos de trabajo impulsados por IA, la suposición de que todo debe ser público para ser verificable es cada vez más cuestionada.
El Protocolo TEN se basa en una premisa diferente: que la computación puede seguir siendo demostrablemente correcta sin obligar a los usuarios, desarrolladores y empresas a exponer entradas, estrategias o lógica sensibles a todo el mercado.
En estas preguntas y respuestas de journalscrypto, el equipo detrás del Protocolo TEN explica su concepto de “computación confidencial” y por qué creen que la ejecución prioritaria de la privacidad es una primitiva que falta en la hoja de ruta de escalamiento de Ethereum.
En lugar de lanzar un ecosistema de privacidad separado, TEN está diseñado como un entorno EVM completo anclado a la liquidación y liquidez de Ethereum, lo que permite a los desarrolladores elegir selectivamente qué debe permanecer público y qué debe ejecutarse de forma confidencial.
La discusión explora cómo este modelo híbrido remodela la experiencia del usuario, mitiga el MEV, permite mercados de ofertas cerradas y flujos de órdenes ocultos, y desbloquea nuevas categorías de aplicaciones, desde agentes de IA verificables hasta iGaming demostrablemente justo.
También aborda las ventajas y desventajas de la seguridad y la gobernanza del uso de entornos de ejecución confiables, y cómo la arquitectura de TEN está diseñada para hacer que las fallas sean detectables, contenidas y recuperables en lugar de silenciosamente catastróficas.
En conjunto, las preguntas y respuestas ofrecen una visión detallada de cómo la confidencialidad selectiva podría redefinir la confianza, la componibilidad y la usabilidad en todo el ecosistema Ethereum. 
Para los lectores que son nuevos en el Protocolo TEN, ¿cómo se explica en términos simples qué significa “calcular con confianza” y qué problema está resolviendo realmente TEN y que los Ethereum L2 existentes no resuelven?
En su forma más simple, “calcular con confianza” significa que puede usar una dapp sin transmitir su intención, su estrategia o sus datos confidenciales a todos los que miran la cadena.
En la mayoría de los Ethereum L2 actuales, la transparencia es la opción predeterminada. Cada transacción, sus parámetros, los pasos intermedios de ejecución y, a menudo, incluso el “por qué” detrás de una acción son visibles. Ese nivel de apertura es poderoso para la verificación, pero en la práctica crea problemas muy reales. Las operaciones se adelantan o se intercalan. Las billeteras y las dapps filtran datos económicos y de comportamiento. Los juegos y las subastas luchan por ser justos y privados. Y muchos flujos de trabajo empresariales o del mundo real simplemente no pueden funcionar si las entradas y la lógica tienen que ser públicas por diseño.
Esta es la principal limitación estructural que aborda TEN. Ethereum se construyó bajo el supuesto de que los datos deben ser visibles para poder ser verificables. TEN mantiene intacta la verificabilidad, pero elimina la idea de que los datos en sí deben estar expuestos. Con la tecnología de privacidad adecuada, puede demostrar que el cálculo es correcto sin revelar las entradas o la lógica subyacentes.
Lo que eso significa en la práctica es confianza. Confianza en que los operadores de nodos no podrán adelantarse. Que los juegos no están amañados silenciosamente. Que las ofertas no se copien en tiempo real. Que los competidores no estén espiando la estrategia. Que las dapps no extraen ni monetizan las entradas privadas de los usuarios.
Aún obtienes seguridad y verificación de nivel Ethereum. Simplemente no es necesario exhibir todo para conseguirlo.
Hay otros proyectos en criptografía centrados en la privacidad y orientados a TEE; ¿Qué es concretamente diferente entre la arquitectura y el modelo de amenazas de TEN en comparación con aspectos como los L1 de privacidad, los paquetes acumulativos con pruebas fuera de la cadena o los enfoques basados en MPC?
TEN se construye como una ejecución de Ethereum que prioriza la privacidad, no como un ecosistema paralelo. El objetivo es muy limitado y muy intencionado: ejecutar aplicaciones de estilo EVM con confidencialidad selectiva, manteniendo al mismo tiempo la liquidación, la componibilidad y la liquidez ancladas al propio Ethereum.
Esa elección de diseño es lo que realmente distingue a TEN en la práctica.
Si nos fijamos en los L1 de privacidad, a menudo piden a los desarrolladores que se muden a un mundo nuevo. Son comunes nuevas herramientas, nueva semántica de ejecución y diferentes suposiciones sobre la componibilidad. TEN adopta el enfoque opuesto. Está destinado a sentirse como Ethereum, no a reemplazarlo. Los desarrolladores conservan el EVM, los estándares que ya utilizan y el acceso a la liquidez existente, al tiempo que obtienen confidencialidad sólo cuando realmente importa.
La ejecución privada basada en ZK ofrece garantías de privacidad extremadamente sólidas, pero esas garantías generalmente conllevan compensaciones para aplicaciones de propósito general. La complejidad de los circuitos, las limitaciones de rendimiento y la fricción de los desarrolladores pueden hacer que el desarrollo diario de aplicaciones sea más difícil de lo necesario. En su lugar, TEN utiliza TEE, dirigidos a computación confidencial de uso general con un perfil de rendimiento y experiencia de desarrollador muy diferente.
Los enfoques basados en MPC evitan confiar en los proveedores de hardware, lo cual es una ventaja real, pero presentan sus propios desafíos. Los gastos generales de coordinación, la latencia y la complejidad operativa pueden traducirse rápidamente en una experiencia de usuario deficiente para las aplicaciones normales. TEN acepta un supuesto de confianza basado en el hardware y luego se centra en mitigarlo mediante gobernanza, redundancia e ingeniería de seguridad rigurosa.
En esencia, el diferenciador es este modelo híbrido. Las cosas que deberían ser públicas, como la finalidad, la auditabilidad y la liquidación, siguen siendo públicas. Las cosas que deben ser privadas, como las entradas, el flujo de pedidos, las estrategias y el estado secreto, siguen siendo confidenciales.
Hablas de que TEN hace que las criptomonedas se sientan como “aplicaciones normales” para los usuarios finales, privadas, simples y confiables; ¿Cómo se ve eso desde una perspectiva de UX y en qué se diferenciará el uso de una dapp con tecnología TEN de una dapp típica de Ethereum hoy en día?
A nivel de usuario, elimina la sensación constante de que todo lo que haces es visible y potencialmente explotable.
En una dapp impulsada por TEN, eso se muestra de maneras pequeñas pero significativas. No hay ansiedad por el mempool y no hay que ver cómo sus operaciones se intercalan en tiempo real. La intención es privada de forma predeterminada, ya sean ofertas, estrategias o umbrales de ejecución. Los usuarios no tienen que depender de soluciones defensivas como RPC privados o trucos de deslizamiento manual solo para sentirse seguros al usar una aplicación.
Lo que queda es un modelo mental mucho más limpio, más cercano a Web2. Usted asume que sus entradas y la lógica de negocios de la aplicación no son automáticamente públicas, porque en la mayoría del software no lo son.
El cambio en sí es sutil, pero fundamental. La privacidad deja de ser una característica adicional o una configuración avanzada que solo los usuarios avanzados entienden y, en cambio, se convierte en una primitiva central del producto que simplemente está ahí de forma predeterminada.
Los entornos de ejecución confiables introducen un tipo diferente de suposición de confianza, a saber, la dependencia de los proveedores de hardware y la seguridad del enclave; ¿Cómo aborda las preocupaciones sobre ataques de canal lateral, puertas traseras o fallas a nivel de proveedor en su modelo de seguridad y gobernanza?
Ése es exactamente el tipo correcto de escepticismo. La posición de TEN no es que las ETE sean mágicas o estén libres de riesgos. Se trata de ser explícito sobre el modelo de amenaza y diseñar el sistema de modo que un compromiso nunca sea silenciosamente catastrófico.
TEN asume que los enclaves brindan confidencialidad e integridad dentro de límites definidos, y luego construye alrededor de esa suposición en lugar de fingir que no existe. El objetivo es hacer que las fallas sean detectables, contenidas y recuperables, no invisibles.
Desde una perspectiva de seguridad, esto se presenta como una defensa en profundidad. Existen estrictos requisitos de certificación remota, medición controlada de código y compilaciones reproducibles, y prácticas estrictas de administración de claves, incluidas claves selladas, rotación y permisos de alcance estricto. La superficie de ataque del enclave se minimiza deliberadamente, ejecutándose en su interior la menor cantidad de código privilegiado posible.
La redundancia y el diseño a prueba de fallos son igualmente importantes. TEN evita arquitecturas donde un enclave gobierna efectivamente el sistema. Cuando es posible, se basa en suposiciones de múltiples operadores y estructura protocolos para que ni siquiera un enclave comprometido pueda reescribir la historia o forjar un acuerdo en Ethereum.
La gobernanza y la preparación operativa completan el panorama. La seguridad no se trata sólo de criptografía; también se trata de la rapidez y transparencia con la que un sistema puede responder. Esto incluye parches, revocaciones, fijación de versiones de enclave y guías de incidentes claras que se pueden ejecutar sin ambigüedad.
La conclusión es la siguiente: TEN no pide a los usuarios que “no confíen en nada”. Se trata de reducir la confianza práctica que se necesita depositar en los operadores y las contrapartes, y concentrar la confianza restante en una superficie mucho más estrecha y auditable.
Por el lado de DeFi, ¿cómo funcionan realmente en la práctica las subastas de ofertas selladas, los libros de órdenes ocultos y el enrutamiento resistente a MEV en TEN, y cómo pueden los usuarios o reguladores ganar confianza en sistemas donde la lógica comercial central y el flujo de órdenes están encriptados intencionalmente?
En un nivel alto, TEN funciona cambiando lo que es público por defecto.
Realice subastas con ofertas cerradas. En lugar de transmitir las ofertas de forma clara, los usuarios las envían de forma cifrada. La lógica de la subasta se ejecuta dentro de un TEE, por lo que las ofertas individuales nunca quedan expuestas durante la ejecución. Dependiendo de cómo esté diseñada la subasta, es posible que las ofertas solo se revelen en el momento de la liquidación, o no se revelen en absoluto, y solo se publique el resultado final en la cadena. Ese único cambio elimina las pujas, el copy-trading y las filtraciones estratégicas que plagan las subastas abiertas hoy en día.
La misma idea se aplica a los libros de pedidos ocultos. Las órdenes no son visibles de una manera que permita a otros reconstruir la intención o la estrategia en tiempo real. Los comerciantes están protegidos de ser copiados o explotados sistemáticamente, mientras que el sistema aún produce resultados de ejecución que pueden verificarse después del hecho.
El enrutamiento resistente a MEV se desprende naturalmente de este modelo. Debido a que la intención del usuario nunca se transmite a un mempool público, el canal MEV clásico de ver, copiar y emparedar simplemente no existe. En primer lugar, no hay nada que adelantar.
Naturalmente, esto plantea la cuestión de la confianza. Si la lógica central y el flujo de órdenes están cifrados, ¿cómo pueden los usuarios o los reguladores estar seguros de que el sistema se está comportando correctamente?
La respuesta es que TEN separa la privacidad de los insumos de la verificabilidad de los resultados. Incluso cuando las entradas son privadas, las reglas no lo son. Cualquiera puede comprobar que el motor de comparación siguió el algoritmo publicado, que los precios de compensación se calcularon correctamente y que no se produjo ninguna preferencia o manipulación oculta.
Además de eso, existen superficies de auditoría claras y mecanismos para la divulgación selectiva. A los reguladores o auditores se les puede otorgar acceso bajo condiciones definidas, mientras que el público aún ve compromisos criptográficos y pruebas en cadena de que la ejecución fue correcta.
El resultado es una combinación poco común en el DeFi actual: confidencialidad del flujo de órdenes junto con responsabilidad de los resultados.
Los agentes de IA verificables son uno de sus casos de uso emblemáticos; ¿Puedes explicar un ejemplo concreto de un agente de IA ejecutándose en TEN, qué permanece privado, qué es públicamente verificable dentro de la cadena y por qué eso es mejor que ejecutar el mismo agente completamente fuera de la cadena?
Una forma sencilla de pensar en esto es un reequilibrador de tesorería impulsado por IA para un protocolo.
Cuando ese agente se ejecuta en TEN, gran parte de lo que lo hace valioso permanece privado por diseño. Los pesos o indicaciones del modelo, que a menudo son la propiedad intelectual central, nunca tienen que exponerse. Las señales patentadas y los flujos de datos pagos permanecen confidenciales. Los límites de riesgo internos, el razonamiento intermedio y la lógica de decisión no se filtran al mercado. Incluso la intención de ejecución permanece privada hasta el momento en que se confirma.
Al mismo tiempo, hay un conjunto claro de cosas que son públicamente verificables en la cadena. Cualquiera puede comprobar que el código aprobado realmente se ejecutó mediante una certificación. Pueden verificar que un módulo de política autorizado aplicó las restricciones relevantes y que las acciones resultantes respetaron las invariantes definidas. Las transiciones de estado finales y la liquidación todavía ocurren en Ethereum, al aire libre, como de costumbre.
Esa combinación es lo que hace que esto sea significativamente mejor que ejecutar el mismo agente completamente fuera de la cadena. En última instancia, los agentes fuera de la cadena piden a los usuarios que confíen en registros, operadores o afirmaciones no verificables de que “el bot siguió las reglas”. DIEZ elimina esa confianza ciega. Permite a los agentes mantener en privado su ventaja competitiva y, al mismo tiempo, demostrar a los usuarios, DAO y contrapartes que actuaron estrictamente dentro de su mandato.
Históricamente, el iGaming ha estado plagado de problemas de confianza, bots y RNG opaco; ¿Cómo TEN permite juegos demostrablemente justos y al mismo tiempo mantiene en privado las semillas RNG, la lógica antibot y las estrategias de juego, y cómo cree que esto encaja en los marcos regulatorios existentes para los juegos en línea?
El iGaming siempre se ha construido en torno a un conflicto fundamental: se requiere transparencia para demostrar justicia, pero el secreto es esencial para proteger los sistemas RNG, los controles de seguridad y la lógica anti-bot. Si se expone demasiado, el sistema se verá afectado. Ocultar demasiado y la confianza colapsa.
TEN resuelve ese conflicto mediante la confidencialidad selectiva. Los componentes sensibles siguen siendo privados, mientras que las reglas y los resultados siguen siendo demostrables.
En cuanto a la aleatoriedad, esto permite que “probablemente justo” sea literal en lugar de aspiracional. Los juegos pueden usar esquemas de aleatoriedad verificable y de confirmación-revelación en los que la aleatoriedad se compromete de antemano, los jugadores pueden verificar los resultados de forma independiente y las semillas de RNG permanecen privadas hasta que sea seguro revelarlas o solo se revelen parcialmente. Los jugadores obtienen confianza en la justicia sin que los atacantes obtengan un plano utilizable.
El mismo principio se aplica a los controles de riesgos y anti-bots. Las heurísticas de detección de bots y los sistemas de fraude se ejecutan de forma confidencial, lo cual es importante porque una vez que estos mecanismos se hacen públicos, los actores sofisticados se adaptan de inmediato. Mantenerlos privados preserva su eficacia y al mismo tiempo permite que el sistema produzca resultados verificables.
En términos más generales, esto permite una integridad demostrable del juego. Los jugadores pueden verificar que un juego siguió las reglas publicadas y que los resultados no fueron manipulados, sin exponer elementos internos sensibles como la lógica de seguridad, los umbrales o los parámetros estratégicos.
Desde una perspectiva regulatoria, esto se corresponde claramente con los marcos existentes. Los reguladores normalmente se preocupan por la auditabilidad, las garantías de equidad y los controles ejecutables, no por obligar a que todos los mecanismos internos salgan a la luz. El modelo de TEN de resultados verificables combinados con divulgación selectiva se alinea naturalmente con esos requisitos.
Desde el punto de vista de un desarrollador, ¿cómo se ve la creación de un contrato inteligente “selectivamente privado” en TEN, cómo marcan funciones para la ejecución de TEE y cómo prueban y depuran la lógica que no pueden simplemente cerrar sesión en un mempool público?
Desde el punto de vista de un desarrollador, la forma más fácil de pensar en DIEZ es que estás construyendo con dos zonas de ejecución.
Hay una zona pública, que se siente como un desarrollo normal de Ethereum: lógica EVM estándar, estado público y contratos componibles que se comportan de la manera esperada en cualquier L2.
Luego está la zona confidencial, donde funciones y partes de estado específicas se ejecutan dentro de los TEE, con entradas cifradas y divulgación estrictamente controlada.
En la práctica, los desarrolladores deciden explícitamente qué debería funcionar “confidencialmente” y qué debería permanecer público. El lado confidencial es donde se colocarían cosas como el emparejamiento comercial, el RNG, la evaluación de estrategias o el almacenamiento secreto, mientras que todo lo demás permanece abierto para la componibilidad y la liquidación.
El cambio en el flujo de trabajo se muestra más en las pruebas y la depuración, porque no se puede tratar el mempool público como su consola de depuración siempre activa. En cambio, las pruebas y la depuración normalmente se apoyan en devnets locales con ejecución tipo enclave, vectores de prueba deterministas y modos de depuración controlados durante el desarrollo. Y en lugar de depender de registros públicos, se valida el comportamiento mediante compromisos e invariantes verificables, lo que demuestra que el sistema se mantuvo dentro de las reglas incluso cuando las entradas son privadas.
El cambio clave es alejarse de la introspección de mempool como muleta de depuración y diseñar para una corrección demostrable desde el principio.
Destaca la componibilidad entre componentes públicos y privados como un diferenciador clave; ¿Qué nuevos patrones de aplicación espera que surjan de este modelo híbrido y cómo pueden los protocolos Ethereum existentes integrar TEN sin reescribir completamente su pila?
El modelo híbrido de TEN desbloquea patrones de aplicación que son extremadamente difíciles o simplemente imposibles en cadenas que son transparentes de forma predeterminada.
Un patrón obvio es la ejecución privada con acuerdo público. La lógica sensible como el emparejamiento comercial, la evaluación de estrategias, el RNG o los controles de riesgo pueden ejecutarse de forma confidencial, mientras que los resultados finales aún se resuelven públicamente en Ethereum. Obtiene privacidad donde importa, sin renunciar a la verificabilidad o la componibilidad.
Otra área es el descubrimiento de precios protegidos y la liquidez oscura. Las ofertas selladas, los libros de pedidos ocultos y el enrutamiento privado hacen posible gestionar mercados más justos y, al mismo tiempo, producir resultados verificables en la cadena. El mercado obtiene integridad sin convertir la intención de cada participante en datos públicos.
Los juegos y los agentes de IA son otra opción natural. Las manos, las estrategias, las indicaciones o los aspectos internos del modelo pueden permanecer privados, mientras que la equidad, la corrección y la solución siguen siendo demostrables. Esa combinación es muy difícil de lograr en un entorno de ejecución totalmente transparente.
También se empiezan a ver surgir aplicaciones de divulgación selectiva. Cosas como las verificaciones de identidad, reputación, cumplimiento o elegibilidad pueden permanecer privadas y, al mismo tiempo, hacer cumplir las reglas públicas y producir resultados auditables.
Lo que distingue a TEN es que nada de esto requiere abandonar Ethereum. TEN es un EVM completo, por lo que los contratos inteligentes de Ethereum existentes se implementan en TEN de forma inmediata y se comportan exactamente como esperan los desarrolladores. La diferencia es que inmediatamente obtienen la opción de ejecutar partes de su lógica de forma confidencial.
Para muchos protocolos, la integración puede ser sencilla. Los equipos pueden implementar los mismos contratos en TEN junto con Ethereum, mantener la versión pública sin cambios y luego habilitar progresivamente la ejecución confidencial donde agregue el mayor valor.
Naturalmente, eso crea dos caminos de adopción. Algunos equipos tomarán la ruta del mínimo esfuerzo, implementarán los contratos existentes sin cambios y obtendrán una instancia pública y confidencial casi sin trabajo adicional. Otros adoptarán un enfoque progresivo, moviendo selectivamente flujos de alto valor, como el flujo de órdenes, subastas, juegos o lógica de agentes, hacia una ejecución confidencial a lo largo del tiempo.
El punto clave es que TEN no obliga a los desarrolladores a elegir entre componibilidad y confidencialidad. Les permite mantener el ecosistema, la liquidez y las herramientas de Ethereum, al tiempo que hace de la privacidad una capacidad de primera clase en lugar de algo complementario.
¿Quién opera los enclaves y la infraestructura que impulsan TEN, cómo se evita la centralización en torno a un pequeño conjunto de operadores y cómo es la hoja de ruta para descentralizar la red, impulsar el ecosistema y atraer las primeras aplicaciones emergentes en TEN?
Como la mayoría de las redes nuevas, TEN comienza con una fase práctica de arranque. Al principio, eso significa un conjunto más pequeño y mejor seleccionado de operadores e infraestructura, centrándose directamente en la confiabilidad y la seguridad. El objetivo en esta etapa no es la máxima descentralización desde el primer día, sino asegurarse de que el sistema funcione de manera predecible y segura a medida que los desarrolladores comiencen a crear aplicaciones reales en él.
Evitar la centralización a largo plazo es donde la arquitectura y los incentivos realmente importan. La hoja de ruta se basa en la incorporación de operadores sin permiso, junto con estrictos requisitos de certificación para que los operadores puedan demostrar que están ejecutando el código correcto en el entorno correcto. Los incentivos económicos están diseñados para alentar a muchos operadores independientes en lugar de un pequeño cártel, y hay un énfasis explícito en la diversidad geográfica y organizacional. Además de eso, los criterios de rendimiento y seguridad son transparentes y el protocolo en sí está estructurado para evitar que un solo operador domine la ejecución.
En términos de cómo se desarrolla la hoja de ruta, la primera fase consiste en poner en marcha la confiabilidad y las herramientas del desarrollador. Una vez que esa base sea sólida, la atención se centrará en el envío de aplicaciones emblemáticas que realmente necesitan confidencialidad, como iGaming, flujos de trabajo DeFi protegidos y agentes de IA verificables. A partir de ahí, la participación de los operadores se expande, la gobernanza se descentraliza y la postura de seguridad continúa fortaleciéndose a medida que fluye más valor a través de la red y aumentan los riesgos.
Eso es lo que configura el volante del ecosistema. Los constructores no acuden a TEN sólo porque es otra EVM; Vienen porque ofrece capacidades que no pueden conseguir en ningún otro lugar.
La tesis de la aplicación de ruptura es sencilla. La primera aplicación nativa de las RTE verdaderamente exitosa será algo que no puede existir o no puede ser competitivo en cadenas transparentes por defecto. En ese caso, la confidencialidad no es una característica de casilla de verificación. Es el producto en sí.
