zkTLS está destinado a quienes necesitan llevar valores de una página web o de una API autenticada a un contrato o contraparte, no es un nuevo transporte que sustituya HTTPS. Frente a las capturas de pantalla o las declaraciones propias, convierte «la sesión accedió al sitio objetivo» y «el campo cumple un predicado» en evidencia verificable. Los flujos continuos de mercados públicos suelen depender de oráculos de blockchain; la comparación con los flujos aparece más abajo.
Las secciones siguientes abordan la definición, los pasos de sesión a prueba, las diferencias entre MPC, Proxy y TEE, los casos de uso, el contraste con los oráculos y los riesgos, junto con explicaciones públicas de los mecanismos, como la explicación de zkTLS de Oasis y la página sobre el patrón zk-TLS de EthSystems.
Puntos clave:
- zkTLS convierte una sesión HTTPS en una afirmación verificable: vincula el dominio y el certificado y, opcionalmente, revela solo el resultado de un predicado.
- El nombre suele inducir a error: no todos los diseños usan pruebas de conocimiento cero durante el protocolo de enlace, MPC, Proxy y TEE son las tres rutas más habituales.
- Como TLS termina en una clave de sesión simétrica compartida, un cliente por sí solo puede falsificar una demostración de transcripción, de ahí la necesidad de notarios, proxies o TEE.
- La procedencia no equivale a veracidad: si el origen devuelve un campo incorrecto, una prueba puede seguir siendo formalmente válida.
- Los verificadores deben comprobar la vinculación con el dominio/certificado, el predicado y la firma de atestación o raíz de confianza en la ruta de prueba.
¿Qué es zkTLS y qué problema resuelve?
zkTLS aborda una carencia del TLS convencional: Transport Layer Security sustenta las conexiones HTTPS de los navegadores, cifrando y autenticando el canal entre cliente y servidor. Sin embargo, después de que finalice la sesión, resulta difícil convencer a un tercero de que el servidor realmente devolvió ese contenido sin entregar material de descifrado susceptible de abuso o depender de capturas de pantalla. Por ello, los contratos tienen dificultades para consumir campos posteriores al inicio de sesión.
Un protocolo de enlace TLS estándar genera una clave de sesión simétrica: tanto el navegador como el servidor pueden cifrar y descifrar. Si un usuario muestra por sí solo el texto cifrado junto con esa clave, otras partes no pueden descartar que el usuario haya cifrado texto sin formato falso y después lo haya descifrado a petición. Por tanto, un cliente individual no puede ser un testigo fiable. Esta limitación motiva el uso de notarios, proxies o TEE.
Lo que zkTLS proporciona es evidencia de procedencia e integridad, no un dictamen final sobre la veracidad empresarial. Demostrar que un campo de saldo procede de la sesión TLS de un sitio no descarta una introducción de datos incorrecta ni una página manipulada. Es un ámbito próximo a las narrativas sobre flujos de conocimiento cero de zkOracle y zkCoprocessor, pero corresponde a un dominio de problemas distinto.
¿Cómo funciona zkTLS? De una sesión HTTPS a una afirmación verificable
A grandes rasgos, zkTLS pasa de una sesión HTTPS normal a una prueba verificable: el usuario abre una sesión con el origen, una ruta mediante notario MPC, Proxy o TEE deja evidencia verificable y, después, se genera y comprueba una prueba de revelación selectiva.
- Abrir la sesión: inicia TLS con el dominio objetivo. La vinculación con el certificado y el dominio pasa a formar parte de la afirmación posterior.
- Ser testigo conjunto o delegar: un notario participa en el protocolo de enlace/descifrado (MPC), un proxy da fe de la dirección del texto cifrado (Proxy) o un TEE realiza la solicitud, de modo que un cliente individual no pueda falsificar fácilmente texto cifrado enviado por el servidor. Algunos diseños lo tratan como un protocolo multipartito, en lugar de un flujo de cliente individual.
- Obtener el campo objetivo: dentro de la sesión, solicita la página de cuenta o la API y recibe la respuesta cifrada.
- Crear la afirmación: genera una prueba, o firmas de ruta, sobre compromisos de transcripción, identidad del servidor y un predicado como saldo > umbral. Las rutas basadas en circuitos convierten las restricciones de la transcripción en resultados de prueba.
- Enviar para su verificación: un contrato o contraparte comprueba la prueba y las raíces de confianza, y luego acepta o rechaza.
La revelación selectiva es una segunda capa habitual: demostrar que un saldo supera un umbral sin revelar la cantidad exacta, o extraer un campo mientras se oculta el resto. Según la nota de Reclaim sobre el «zk» de zkTLS, el conocimiento cero para la privacidad suele ser una mejora. El requisito más básico es convencer a un tercero de que la respuesta procede realmente del origen.
Figura 1. zkTLS pasa de una sesión HTTPS del cliente, a través de una ruta de atestación MPC/Proxy/TEE, a una prueba de revelación selectiva comprobada por un verificador o contrato inteligente.
Una lista de comprobación para verificadores debe incluir al menos cuatro elementos: vinculación del dominio y certificado con el origen declarado, un predicado alineado con las reglas empresariales, firma de la ruta de prueba o raíz de confianza incluida en una lista de permitidos, y si los cambios en la estructura del origen romperían el analizador. Omitir cualquiera de estos elementos convierte «verificable» en «parece una prueba», aunque el objetivo sea generar datos verificables para contratos inteligentes o contrapartes.
¿Por qué se llama zkTLS? ¿En qué se diferencian MPC, Proxy y TEE?
«zkTLS» es un término general popular que sugiere que las pruebas de conocimiento cero deben ejecutarse durante el protocolo de enlace, pero no siempre es así. La etiqueta suele utilizarse de forma amplia para un protocolo híbrido, aunque no todas las implementaciones se ajustan realmente a esa descripción. Muchos diseños se parecen más a las pruebas web o las atestaciones TLS: el objetivo es la verificabilidad, no la obligatoriedad de ZK dentro del protocolo de enlace.
| Ruta |
Mecanismo principal |
Notas sobre confianza y coste |
| MPC / 2PC (notario de estilo TLSNotary) |
La clave de sesión se mantiene conjuntamente, por lo que ni el usuario ni el notario pueden falsificar por sí solos la transcripción. |
Depende de la honestidad y disponibilidad del notario, mayor latencia. |
| Proxy |
Un proxy HTTPS da fe de si el texto cifrado procede del navegador o del servidor. El usuario demuestra mediante ZK el descifrado sin revelar la clave. |
Menor sobrecarga, presupone que el proxy no colabora para mentir sobre la dirección. |
| TEE |
Las solicitudes se ejecutan en entornos de ejecución de confianza que dan fe de la integridad de la respuesta. |
Menor sobrecarga, depende del proveedor del chip, las raíces de atestación TEE y el aislamiento de hardware resistente a manipulaciones. |
Las tres rutas responden a la misma pregunta: cómo convencer a un tercero de que el texto cifrado procede del servidor sin entregar la clave simétrica para un uso indebido. Los proxies pueden observar la dirección de transferencia de datos sin ver el texto sin formato. Los diseños MPC/2PC, de estilo TLSNotary, utilizan claves conjuntas para impedir la falsificación unilateral. Los diseños Proxy combinan atestaciones de dirección con una prueba de descifrado del lado del usuario. Los diseños TEE alojan la sesión en aislamiento de hardware. El conocimiento cero para privacidad puede añadirse encima para ocultar campos, pero TEE y la mayoría de los protocolos de enlace MPC no usan ZK en la capa de protocolo de enlace.
Elegir una ruta es una decisión de modelo de amenazas y coste: si un único notario, proxy o TEE es aceptable, si las sesiones deben mantener una latencia baja y si el origen solo admite determinadas versiones de TLS. Las rutas MPC también garantizan que ningún nodo individual tenga nunca la clave completa. Interpreta «zk» como una etiqueta para datos web verificables, no como una taxonomía criptográfica estricta.
¿Para qué se puede utilizar zkTLS?
Un caso de uso clásico consiste en demostrar que una cuenta fuera de la cadena cumple un umbral sin publicar el extracto completo: límites de saldo para la elegibilidad crediticia, comprobaciones de saldo bancario en flujos financieros sin revelar la cantidad exacta, campos de empleo o reputación de un portal con sesión iniciada y confirmación de actividad fuera de la cadena para reglas de misiones. El patrón común son datos alojados detrás de HTTPS sin una API pública firmada y preparada.
Los casos de uso de identidad y atributos incluyen la verificación de identidad y credenciales verificadas, junto con rangos de edad, niveles de membresía o calificaciones resumidas: el verificador ve el resultado de un predicado, no una página completa de datos privados. Productos estructurados como protocolos, como el oráculo zkTLS de zkPass, presentan datos privados verificables en cadena. Distingue la forma en que un protocolo encapsula las pruebas de lo que garantiza el patrón zkTLS.
Otra categoría son los flujos de datos que preservan la privacidad: las aplicaciones necesitan campos de sitios web en aplicaciones en cadena sin exponer el texto sin formato completo extraído a todos los observadores. En este caso, zkTLS proporciona una prueba de campo con procedencia. Aun así, debe distinguirse de los flujos continuos de precios y la agregación de múltiples fuentes utilizados en las finanzas descentralizadas y en flujos de trabajo más amplios entre web y cadena.
¿En qué se diferencia zkTLS de los oráculos tradicionales?
Los oráculos tradicionales se centran en escribir hechos fuera de la cadena, como precios y resultados de eventos, en las cadenas, normalmente mediante conjuntos de nodos o flujos de múltiples fuentes. Esta diferencia forma parte del problema de los oráculos: introducir datos fiables fuera de la cadena o de la web en los contratos. zkTLS se centra en demostrar que los campos de una sesión HTTPS proceden de un origen específico, opcionalmente con revelación selectiva. Los flujos optimizan la disponibilidad y la resistencia a la manipulación. zkTLS optimiza la conversión de una sesión web en una afirmación verificable.
Para comparar la arquitectura de los flujos, los supuestos de confianza y los modos de fallo, consulta zkTLS frente a los oráculos tradicionales. Regla breve: los flujos continuos de mercados públicos siguen encajando con redes de oráculos consolidadas. Los campos privados posteriores al inicio de sesión que requieren una revelación mínima encajan mejor con zkTLS, mientras que algunos sistemas también tratan la portabilidad de datos como un objetivo de diseño independiente. Ambos pueden combinarse, pero ninguno sustituye al otro.
¿Cuáles son las ventajas y riesgos de utilizar o depender de zkTLS para datos sensibles?
Entre las ventajas se incluye exportar campos verificables siempre que el usuario pueda completar HTTPS con el origen, sin esperar a una API de flujo dedicada. La revelación selectiva permite que los contratos verifiquen un hecho sin exponer el registro privado completo. Las afirmaciones pueden comprobarse mediante programación en contratos.
Los riesgos son igualmente concretos. La honestidad y disponibilidad de notarios, proxies o TEE constituyen raíces de confianza: la colusión, la negativa o el tiempo de inactividad generan aceptaciones falsas o fallos. Los diseños basados en TEE también conllevan riesgos de seguridad vinculados al fabricante de hardware o a la raíz de atestación. La honestidad del origen queda fuera del alcance del protocolo: las páginas incorrectas pueden seguir generando pruebas formalmente válidas. Los cambios en las rutas de los campos rompen los predicados. Algunas pilas de notarios cubren solo determinadas versiones de TLS.
Quienes dependan de estas soluciones también deben evaluar el coste de las pruebas, la latencia de las sesiones y el riesgo de retención de las transcripciones de sesión. zkTLS mejora la procedencia verificable, no convierte páginas web arbitrarias en fuentes de verdad sin auditoría.
Resumen
zkTLS convierte sesiones HTTPS cotidianas en afirmaciones verificables y con revelación mínima, para que los contratos puedan verificar de qué servidor vinculado a un dominio procede un campo, en lugar de confiar en capturas de pantalla. «zk» no garantiza conocimiento cero durante el protocolo de enlace. MPC, Proxy y TEE logran integridad bajo distintos supuestos de confianza.
Antes de implementarlo, acepta que un cliente individual con la clave simétrica puede montar una demostración de sesión falsa. Las listas de comprobación de verificadores deben cubrir el dominio/certificado, el predicado y las raíces de confianza. La procedencia no equivale a la veracidad del contenido. Los oráculos tradicionales y zkTLS dividen los flujos continuos y las pruebas de campos de páginas privadas. Elige la ruta según el modelo de amenazas e incorpora al modelo los riesgos del origen y de la atestación.
Preguntas frecuentes
¿Qué es zkTLS?
zkTLS es una familia de diseños basados en TLS/HTTPS estándar que generan afirmaciones que un tercero puede comprobar: que datos específicos proceden de un servidor vinculado a un dominio y certificado, revelando opcionalmente solo el resultado de un predicado. Conecta campos privados de Web2 con la verificación mediante contratos sin sustituir HTTPS.
¿Cómo convierte zkTLS una sesión HTTPS en una afirmación verificable?
El cliente y el origen abren una sesión. Un notario MPC, Proxy o TEE actúa como testigo conjunto o delegado para que un cliente individual no pueda falsificar el texto cifrado del servidor. Se crea una prueba de revelación selectiva. El verificador comprueba la vinculación con el dominio, el predicado y las raíces de confianza antes de aceptar o rechazar.
¿Debe zkTLS utilizar pruebas de conocimiento cero durante el protocolo de enlace TLS?
No. Muchos sistemas etiquetados como zkTLS usan MPC, Proxy o TEE para la integridad. Las pruebas de conocimiento cero suelen aparecer después para la revelación selectiva o las pruebas de descifrado de estilo Proxy. Es posible que el protocolo de enlace nunca ejecute un circuito ZK. «zk» es una etiqueta común.
¿En qué se diferencia zkTLS de los oráculos tradicionales?
Los oráculos tradicionales suministran continuamente hechos fuera de la cadena a los contratos con objetivos de múltiples fuentes y disponibilidad. zkTLS demuestra la procedencia, y predicados opcionales, de campos HTTPS a nivel de sesión. Los flujos públicos y los campos de páginas privadas con inicio de sesión son problemas distintos. Consulta el tema de comparación: ambos pueden combinarse.
¿Cuáles son los principales riesgos al depender de zkTLS?
Los principales riesgos incluyen notarios, proxies o TEE comprometidos o no disponibles; orígenes que sirven datos incorrectos mientras las pruebas siguen siendo formalmente válidas; cambios en la estructura de las páginas que inutilizan los analizadores; y limitaciones de versión de TLS. Omitir las comprobaciones de vinculación con el dominio y de raíces de confianza aumenta el riesgo de aceptación falsa.
