Entrevista exclusiva: TEN Protocol sobre privacidad, verificabilidad y la próxima fase de las aplicaciones de Ethereum
P1. Para los lectores que solo conocen TEN por los titulares recientes, ¿cómo explicarías la misión principal de TEN Protocol y el problema que está fundamentalmente diseñado para resolver dentro del panorama de ejecución de Ethereum?
Ethereum hizo algo radical: convirtió la computación en verificable globalmente haciendo todo público. Ese compromiso desbloqueó las finanzas sin confianza, pero también rompió silenciosamente una gran clase de aplicaciones reales.
Hoy, cuando usas la mayoría de los L2 de Ethereum, no solo estás ejecutando una transacción. Estás transmitiendo tu intención, tu estrategia, tu timing y, a menudo, tu razonamiento económico a cada bot, competidor y adversario que observa la cadena. Esa visibilidad permite la verificación, pero también posibilita el front-running, la extracción de estrategias, la vigilancia del comportamiento y mercados de ataques completos basados en copiar la intención más rápido de lo que los humanos pueden reaccionar.
TEN existe para romper esa falsa dicotomía.
Nuestra misión es simple de enunciar pero difícil de ejecutar: permitir que las personas usen aplicaciones de Ethereum sin revelar lo que intentan hacer, mientras se preserva la verificabilidad al nivel de Ethereum. Con la criptografía adecuada y un modelo de ejecución, puedes demostrar que la computación fue correcta sin revelar las entradas, pasos intermedios o lógica privada detrás de ella.
En la práctica, esto cambia todo. Los operadores de nodos no pueden hacer front-running. Los agentes de IA pueden mantener secretos de forma segura. Los juegos pueden existir en la cadena sin exponer estados ocultos. Las ofertas no se copian. Las aplicaciones no tienen que filtrar información sensible solo para ser verificables.
TEN trata de restaurar algo que las cadenas de bloques eliminaron accidentalmente: la capacidad de computar con confianza.
P2. TEN posiciona “computar con confianza” como un primitive faltante en la pila actual de blockchain. ¿Por qué la confidencialidad selectiva es cada vez más necesaria para casos de uso reales en DeFi, IA, juegos y empresas?
Cada sistema de software exitoso en el mundo depende del control de acceso. En Facebook, no ves cada publicación, solo lo que tienes permitido ver. En banca, tu saldo no es público. En juegos, los oponentes no ven tu mano. En negocios, la lógica interna y los datos están protegidos porque la exposición destruye valor.
Las cadenas de bloques invirtieron este modelo. Hicieron que la transparencia total fuera la norma, lo cual es genial para la auditoría, pero catastrófico para muchas aplicaciones reales.
En DeFi, los usuarios filtran estrategias y se vuelven presas previsibles. En juegos, la información oculta, la aleatoriedad y el juego limpio son imposibles de implementar correctamente. En IA y empresas, exponer datos, modelos o lógica de decisiones internas viola regulaciones o elimina ventajas competitivas por completo.
Lo que falta no es confianza, sino confidencialidad programable con garantías criptográficas. No privacidad añadida mediante servidores centralizados o promesas legales, sino control de acceso aplicado por el propio protocolo.
Eso es lo que “computar con confianza” restablece: la capacidad de decidir quién puede ver qué, manteniendo el sistema verificable.
P3. Tu arquitectura se basa en Entornos de Ejecución Confiables en lugar de enfoques solo ZK o MPC. ¿Qué compromisos hiciste al elegir este diseño y cómo mitigas las suposiciones de confianza asociadas?
Desde el primer día, nuestra restricción fue clara: los constructores deberían poder desplegar aplicaciones EVM reales sin tener que reescribir todo.
Ejecutar la EVM completa dentro de un Entorno de Ejecución Confiable permite a los desarrolladores usar los mismos lenguajes, herramientas y modelos mentales que ya conocen, mientras obtienen confidencialidad selectiva. La liquidación, la liquidez y la composabilidad permanecen ancladas a Ethereum.
Los enfoques ZK y MPC son poderosos y mejoran rápidamente, pero hoy en día a menudo imponen compromisos serios: complejidad de circuitos, cuellos de botella en rendimiento, programación limitada o sobrecarga operativa que hace difícil construir aplicaciones de propósito general y aún más difícil escalar.
Usar TEEs introduce una suposición de confianza basada en hardware, y somos explícitos al respecto. TEN la mitiga mediante un diseño en capas: alojamiento solo en la nube para reducir vectores de ataque físicos, attestación remota obligatoria, redundancia, restricciones de gobernanza y una ingeniería de seguridad rigurosa.
El resultado es un modelo híbrido. Público donde debe ser público: liquidación, auditoría, resultados. Confidencial donde debe serlo: entradas, flujo de órdenes y estado sensible. No es una pureza ideológica; es pragmatismo en ingeniería.
P4. ¿Cómo preserva TEN la verificabilidad y la composabilidad al nivel de Ethereum, permitiendo al mismo tiempo que partes de la ejecución, como entradas, flujo de órdenes o estrategias, permanezcan confidenciales?
TEN separa lo que debe ser demostrable de lo que debe ser visible.
Las reglas del contrato inteligente permanecen públicas. Cualquiera puede inspeccionarlas. La ejecución ocurre dentro de un TEE atestiguado, y la red puede verificar criptográficamente que el código correcto se ejecutó con entradas válidas, incluso si esas entradas estaban encriptadas.
Como Layer 2, TEN aún publica rollups y transiciones de estado de regreso a Ethereum. La finalización, la liquidación y la composabilidad permanecen exactamente donde los usuarios esperan que estén.
Lo que desaparece es la exposición innecesaria. Estrategias intermedias, umbrales privados y lógica sensible no necesitan filtrarse solo para demostrar corrección.
La confidencialidad se convierte en una capacidad de primera clase, no en una solución alternativa.
P5. Desde el punto de vista de la experiencia del usuario, ¿cómo difiere interactuar con una aplicación impulsada por TEN en comparación con usar un L2 típico de Ethereum hoy en día?
La mayor diferencia es psicológica, y es inmediata.
Los usuarios ya no se sienten observados. No hay ansiedad por mempool, ni configuraciones defensivas de slippage, ni gimnasia RPC privada solo para evitar ser explotados. La intención es privada por defecto.
Envías una oferta, una estrategia o un movimiento asumiendo que no será copiado en tiempo real, porque no lo será. Ese cambio único hace que Web3 se sienta más cercano a cómo funciona realmente el software normal.
La privacidad deja de ser una característica avanzada para usuarios expertos y se convierte en una propiedad invisible de la propia aplicación.
P6. Una de las narrativas principales de TEN es reducir MEV y la explotación del mercado. ¿Cómo funcionan en la práctica mecanismos como ofertas selladas, flujo de órdenes oculto o enrutamiento privado, y qué mejoras medibles permiten?
TEN cambia lo que es visible durante la ejecución.
En una subasta de oferta sellada, las ofertas están encriptadas y se procesan dentro de un TEE. Nadie ve las ofertas individuales en tiempo real. Dependiendo del diseño, las ofertas pueden nunca ser reveladas, solo el resultado final.
El flujo de órdenes oculto sigue el mismo principio. Las estrategias no se transmiten al mundo, por lo que no hay nada que copiar, simular o sandwichear. El MEV no necesita ser “combatido”: simplemente no tiene nada en qué alimentarse.
Lo crucial es que esto no sacrifica la confianza. Las reglas son públicas, la ejecución está attestada y los resultados son verificables. Puedes demostrar equidad sin exponer la intención.
P7. TEN ha destacado casos de uso como agentes de IA verificables y juegos de azar justos y verificables. ¿Cuáles ves como los primeros impulsores de adopción real y por qué son más adecuados para TEN que para cadenas transparentes por defecto?
El juego con dinero real es la opción más clara a corto plazo.
El juego requiere información oculta, aleatoriedad rápida y baja latencia. Las cadenas transparentes rompen esas suposiciones. En la testnet de TEN, vimos decenas de miles de carteras únicas y más de un millón de apuestas, mucho más engagement que las testnets típicas.
House of TEN, un primer en el mundo con poker en cadena jugado por agentes de IA, resultó ser un gran éxito durante el período en que lo lanzamos en beta.
Los agentes de IA verificables son igualmente transformadores, pero con un ciclo de desarrollo ligeramente más largo. Permiten gestión confidencial de tesorería, toma de decisiones privada y sistemas de IA que pueden demostrar cumplimiento de reglas sin exponer modelos o datos propietarios.
Ambas categorías se benefician directamente de la confidencialidad selectiva, y ambas son imposibles de hacer correctamente en cadenas transparentes por defecto.
P8. El hardware confiable introduce una clase diferente de riesgo operacional. ¿Cómo está diseñado TEN para asegurar que las fallas sean detectables, contenidas y recuperables en lugar de sistémicas?
El hardware confiable cambia el modo de fallo, no lo elimina.
TEN asume que pueden ocurrir errores y diseña para que sean detectables y contenibles. La attestación remota asegura que la ejecución incorrecta sea observable. Los operadores redundantes previenen que fallos en un solo nodo se vuelvan sistémicos. Los mecanismos de gobernanza permiten aislar o reemplazar componentes comprometidos.
El objetivo no es confiar ciegamente, sino confiar con límites y garantías fuertes.
P9. Cambiando brevemente a operaciones de red: ¿cómo es el modelo actual de operadores y cómo avanza la hoja de ruta desde una fase de arranque hacia una mayor descentralización y resiliencia?
TEN comienza con un conjunto restringido de operadores para garantizar seguridad y rendimiento, y luego expande progresivamente la participación a medida que las herramientas, la monitorización y la gobernanza maduran.
La descentralización no es una casilla que marcar, sino una secuencia. Cada fase aumenta la resiliencia sin comprometer las garantías de confidencialidad.
P10. Las lanzamientos de tokens a menudo se confunden con la preparación del producto. ¿Cómo separas internamente los eventos de mercado del desarrollo del protocolo, y qué hitos son los más importantes para evaluar el progreso técnico de TEN en los próximos 6–12 meses?
De manera muy deliberada.
Los eventos de tokens no definen la preparación. Lo que importa es la entrega.
Internamente, el progreso se mide por lanzamientos auditados, aplicaciones en vivo, expansión de operadores, actividad de desarrolladores y casos de uso que generan ingresos reales y requieren confidencialidad.
En los próximos 6–12 meses, el éxito se mide por las capacidades entregadas, no por las narrativas mantenidas.
P11. Mirando en retrospectiva, ¿qué lecciones operativas ha aprendido el equipo al lanzar un protocolo de infraestructura complejo en un entorno de mercado altamente reflexivo?
Que la tecnología por sí sola no es suficiente.
La ejecución, la comunicación y el timing se combinan, especialmente en mercados donde la percepción influye directamente en la realidad. Incluso los sistemas fuertes sufren si las expectativas no están alineadas.
La lección es simple pero implacable: la confianza se reconstruye con entregas, no con explicaciones. Una infraestructura funcional supera siempre a un mensaje perfecto.
P12. Mirando hacia adelante, ¿cómo sería el éxito de TEN en un año en términos de capacidades entregadas, adopción por desarrolladores y aplicaciones reales en producción?
El éxito significa aplicaciones en producción que simplemente no podrían existir en cadenas transparentes.
Juegos en vivo con dinero real. Flujos de trabajo DeFi protegidos. Agentes de IA verificables que gestionan valor real. Desarrolladores que usan la confidencialidad como un primitive de diseño central, no como un añadido.
En ese momento, TEN no será “un proyecto de privacidad”. Será una infraestructura fundamental, la capa faltante que finalmente permitirá a Ethereum soportar todo el espectro de aplicaciones reales.