zkTLS frente a oráculos tradicionales: ¿qué datos web se integran mejor en la cadena?

Esta comparación está dirigida a lectores de productos y riesgos que deben elegir entre campos de páginas privadas y fuentes públicas. El mecanismo en sí se explica en zkTLS; el término general para los puentes de datos fuera de la cadena se incluye en oráculos de blockchain. Las secciones siguientes comparan origen, privacidad, confianza y latencia, e incluyen el límite entre capturas de pantalla o PDF y procedencia criptográfica.

A continuación se presentan las dimensiones y una lista de «Elegir si», incluido el punto en el que terminan las capturas de pantalla o los PDF y comienza la procedencia criptográfica. Los contenedores con forma de protocolo incluyen el oráculo zkTLS de zkPass; las explicaciones de fuentes de conocimiento cero se presentan junto a zkOracle y zkCoprocessor.

Puntos clave

• zkTLS optimiza la prueba de qué servidor vinculado a un dominio proporcionó un campo de una sesión HTTPS; los oráculos tradicionales optimizan la escritura continua de hechos públicos en cadena con resistencia a la manipulación.
• Las páginas privadas posteriores al inicio de sesión sin API públicas firmadas son adecuadas para zkTLS; los precios continuos de mercado y la agregación de múltiples fuentes son adecuados para redes de oráculos consolidadas.
• La divulgación selectiva es una ventaja habitual de zkTLS; las fuentes tradicionales normalmente publican valores agregados para todos los observadores en cadena.
• Las capturas de pantalla y las cargas de PDF pueden servir para operaciones, pero no tienen procedencia de sesión verificable; las afirmaciones criptográficas prueban la procedencia y la integridad, no la veracidad del origen.
• Elige mediante una lista de «Elegir si» e incluye los riesgos relacionados con el notario o conjunto de nodos, así como los errores del origen, en el modelo de amenazas.

La tabla resume la elección en dimensiones fáciles de revisar: el origen y el acceso determinan quién puede ver los datos; la privacidad y las raíces de confianza determinan el coste de aceptar datos falsos; la latencia y el tipo de datos determinan qué ruta resulta más económica de implementar. Las capturas de pantalla tienen su propia fila porque las operaciones suelen tratar las imágenes como «pruebas», aunque no pertenecen a la misma clase de evidencia que la procedencia criptográfica.

Figura 1. Comparación lado a lado de zkTLS y los oráculos tradicionales en acceso al origen, privacidad, supuestos de confianza y latencia.

¿Qué es zkTLS?

zkTLS, como familia de técnicas, convierte los campos dentro de una sesión TLS/HTTPS en afirmaciones que un tercero puede verificar: vincula el dominio y el certificado y, opcionalmente, divulga solo el resultado de un predicado (por ejemplo, que un saldo supera un umbral) sin entregar el texto sin formato completo.

zkTLS no sustituye HTTPS ni determina automáticamente si los hechos empresariales del origen son correctos; proporciona evidencia de procedencia e integridad. La seguridad de la capa de transporte es el protocolo HTTPS que permite el intercambio seguro de datos entre un cliente y un servidor. Los equipos utilizan MPC, una ruta Proxy o un TEE como rutas habituales de integridad; «zk» suele ser una etiqueta general y el protocolo de enlace TLS puede no ejecutar nunca un circuito de conocimiento cero, aunque una prueba de conocimiento cero sea una capa opcional dentro de la familia de protocolos más amplia.

En la práctica, el cliente abre una sesión TLS con el servidor de origen. Como la clave de sesión se comparte entre cliente y servidor, un cliente individual puede cifrar bytes arbitrarios y posteriormente «descifrarlos», por lo que otras partes no pueden tratar una transcripción sin procesar como una salida honesta del servidor. Por ello, los diseños zkTLS añaden un testigo: un notario MPC que ejecuta conjuntamente el protocolo con el cliente, un Proxy que certifica la dirección del texto cifrado o un TEE que mantiene la clave dentro de un entorno de computación sellado. La prueba resultante permite a los verificadores utilizar la afirmación sin conocer la página completa ni la clave de sesión.

¿Qué es un oráculo tradicional?

Los oráculos tradicionales escriben hechos fuera de la cadena en el estado en cadena para que un contrato inteligente pueda acceder a datos externos procedentes de fuentes fuera de la cadena o del mundo real. Las salidas habituales son fuentes de precios, tasas, resultados deportivos o resultados de eventos públicos, y estas redes son más eficaces con datos públicos o disponibles públicamente que con registros privados de usuarios. El enfoque de diseño suele centrarse en la agregación de múltiples fuentes, la disponibilidad de nodos y la resistencia a la manipulación, no en demostrar qué campo HTML apareció en la sesión iniciada de un usuario.

Los contratos leen actualizaciones de fuentes, no transcripciones del navegador. Los datos continuos de mercados públicos encajan de forma natural en esta ruta; los campos de páginas posteriores al inicio de sesión privadas suelen carecer de una API pública firmada y las redes de fuentes no reproducen por defecto la sesión HTTPS de cada usuario. Por esta razón, las aplicaciones descentralizadas suelen usar oráculos para datos externos compartidos, no para evidencia de sesiones personales. Las partes de un oráculo suelen operar servidores que consultan puntos de conexión públicos; no se sitúan dentro del canal TLS del cliente de un usuario, por lo que no pueden utilizar sin más una página bancaria privada como puede hacerlo un protocolo zkTLS de cliente más testigo.

¿En qué se diferencian las fuentes de datos y las vías de acceso?

La división principal es la siguiente: zkTLS sigue sesiones que el usuario ya puede abrir con un origen; los oráculos tradicionales siguen fuentes públicas que los nodos operadores pueden obtener.

En una ruta zkTLS, el cliente completa HTTPS con el servidor de dominio objetivo y la prueba puede generarse desde cualquier sitio web HTTPS sin requerir acceso previo a una API. Algunos diseños utilizan un modelo Proxy, en el que un intermediario presencia o reenvía el intercambio entre cliente y servidor en lugar de usar procesamiento de sesión de tipo MPC. Otros enfoques basados en MPC ejecutan conjuntamente el protocolo de enlace TLS, el paso del protocolo que establece la clave segura de sesión, para que ninguna parte pueda falsificar por sí sola el texto cifrado del servidor. Un notario, Proxy o TEE deja evidencia verificable y, después, se genera una prueba de la afirmación. En una ruta de oráculo tradicional, los nodos obtienen datos de mercados, índices o API públicas, los agregan en una fuente y los contratos leen dicha fuente. Esto hace que zkTLS sea útil para verificar datos de Web2 de sistemas existentes cuando no hay una fuente pública sencilla. De lo contrario, la validación tradicional de datos u otro proceso de confirmación requeriría que una parte independiente obtuviera directamente la misma fuente. Sin una sesión de usuario, zkTLS no puede sustituir una fuente pública; sin fuentes públicas que se puedan obtener, los nodos no pueden consumir de forma segura campos privados posteriores al inicio de sesión. Los enfoques compatibles con el servidor también dependen de que los servidores de origen permitan la exportación, por lo que los operadores pueden limitar lo que se comparte. Por ello, los productos que utilizan Web Proofs tratan al cliente, al servidor y a las partes testigo como una única ruta de protocolo. Las explicaciones públicas del mecanismo, como la explicación de Oasis sobre zkTLS y la página de patrones zk-TLS de EthSystems, describen la misma ruta de sesión a prueba.

¿En qué se diferencian la privacidad, los datos privados y la divulgación selectiva?

Una capacidad habitual de zkTLS es la divulgación selectiva: demostrar que se cumple un umbral sin publicar el importe exacto, o extraer un campo ocultando el resto. También puede demostrar afirmaciones sobre dichos datos sin revelar el contenido completo. Esto hace que zkTLS sea útil cuando se deben demostrar datos privados o sensibles sin exponer el registro completo. Una vez que una fuente de oráculo tradicional está en cadena, el valor agregado suele ser visible para todos los observadores; los objetivos de privacidad suelen entrar en conflicto con una fuente totalmente legible.

Si un producto necesita controles de elegibilidad sin estados de cuenta completos, zkTLS se ajusta a esa finalidad. Esto es especialmente relevante al demostrar datos personales o sensibles, como identidad legal o registros financieros, mediante divulgación selectiva. Si un producto necesita que todos liquiden con el mismo precio público, las fuentes tradicionales se ajustan a esa finalidad. Ambos enfoques también pueden combinarse: precios públicos mediante oráculos y atributos privados de usuarios mediante afirmaciones zkTLS. Esto ayuda a incorporar datos privados de internet en cadena sin una divulgación amplia; algunos sistemas lo describen como un modelo que permite verificar en cadena datos privados de internet procedentes de sitios web HTTPS sin exponer el registro completo.

La divulgación selectiva normalmente se sitúa sobre la prueba de transcripción TLS. El cliente sigue comunicándose con el servidor de origen; las partes testigo ayudan a vincular la respuesta y, después, un circuito o protocolo de redacción genera una prueba más pequeña que pueden utilizar otras partes. En un diseño MPC, la clave de sesión puede dividirse para que ninguna parte individual pueda abusar de ella. En un diseño Proxy, el Proxy certifica el texto cifrado mientras el cliente conserva la clave de descifrado y demuestra el conocimiento del texto sin formato dentro de una computación. En ambos casos, el objetivo es utilizar campos privados sin enviarlos a todos los servidores verificadores.

¿En qué se diferencian los supuestos de confianza, la integridad de los datos y los modos de fallo?

La confianza en zkTLS se basa en la vinculación de dominio o certificado y en que la ruta del notario, Proxy o TEE sea honesta y esté disponible. Si el servidor de origen devuelve un campo incorrecto, una prueba formalmente válida puede seguir siendo aceptada: la procedencia no equivale a la veracidad del contenido. Cuando la divulgación de conocimiento cero se implementa correctamente, el verificador no conoce la información personal del probador. Los revisores deben seguir preguntando qué partes poseen el material de claves, qué partes ejecutan el protocolo MPC o Proxy y qué certificado de servidor fija el punto de conexión TLS.

La confianza en los oráculos tradicionales se basa en la composición del conjunto de nodos, las reglas de múltiples fuentes y los incentivos económicos. Los fallos se manifiestan más a menudo como manipulación de fuentes, colusión de nodos o fuentes obsoletas o sesgadas. Los registros privados también introducen riesgos de seguridad adicionales y preocupaciones por filtración de datos si un verificador u operador debe inspeccionarlos directamente. Las listas de verificación son diferentes: zkTLS prioriza comprobaciones de vinculación, predicado, autenticidad de los datos, integridad de los datos y raíz de confianza; los oráculos priorizan la actualidad, los umbrales de desviación y las fuentes de agregación. Omitir las comprobaciones de cualquiera de los dos enfoques convierte «parece utilizable» en una falsa sensación de verificación. La falsificación del lado del cliente sigue siendo un modo de fallo principal si no hay testigo; un testigo comprometido es un modo de fallo principal si las partes del protocolo colaboran entre sí.

¿Cómo se deben equilibrar la latencia, el coste y los tipos de datos?

Tres reglas prácticas: los datos continuos de mercados públicos favorecen los oráculos tradicionales; las pruebas puntuales o de baja frecuencia sobre datos específicos de usuarios o datos financieros favorecen zkTLS; las capturas de pantalla y los PDF son adecuados para registros operativos, no para procedencia criptográfica.

zkTLS implica costes por sesión y por generación de pruebas, normalmente con una latencia mayor que una ruta de fuente activa, y resulta adecuado para umbrales de saldo, niveles de membresía y campos laborales o de reputación. Esto incluye demostrar que una cuenta bancaria o el saldo de una cuenta bancaria supera un umbral requerido sin exponer las credenciales subyacentes ni el extracto completo. Una ruta TLS con MPC puede requerir mucha comunicación; una ruta Proxy puede utilizar una computación menos interactiva, pero sigue necesitando un servidor testigo activo; las rutas TEE trasladan la gestión de claves a hardware sellado. Los oráculos tradicionales mantienen actualizaciones continuas y son adecuados para precios, tasas y eventos públicos, diseñados para datos de mercado de baja latencia que muchas aplicaciones cliente utilizan en cada bloque.

Las capturas de pantalla, los PDF o las cargas manuales pueden mostrar «algo que parece una página», pero un tercero no puede verificar criptográficamente que una sesión TLS llegó al servidor de dominio objetivo ni que los campos no fueron editados por el cliente. Las afirmaciones de tipo zkTLS pueden garantizar la autenticidad de los datos y preservar su procedencia para este tipo de entrada privada, pero no demuestran que los hechos empresariales del origen sean verdaderos. Incluso así, páginas de origen incorrectas, fallos de DOM e inactividad del notario pueden afectar a la corrección o disponibilidad. Tratar las capturas de pantalla como único control implica confiar en quien las carga y quien las revisa; tratar las pruebas como «verdad» ignora que los errores del origen pueden seguir siendo formalmente válidos. Los equipos que utilicen tanto capturas de pantalla como pruebas criptográficas deben indicar qué clase de evidencia acepta cada control.

¿Deberías elegir zkTLS o un oráculo tradicional?

Prefiere zkTLS si: los datos se encuentran detrás de una página HTTPS con inicio de sesión o una API privada que un cliente puede abrir con un servidor de origen; se requiere una divulgación mínima a nivel de predicado; no existe una fuente pública preparada de múltiples fuentes; son aceptables la latencia de generación de pruebas por solicitud y una raíz de confianza basada en notario, Proxy o TEE. Esta suele ser la mejor ruta para la verificación de identidad u otras pruebas sobre registros privados de usuarios cuando la divulgación completa no es aceptable. Elige MPC cuando la computación conjunta entre partes sea más importante que la comodidad del navegador; elige Proxy cuando quieras utilizar funciones Proxy existentes del cliente; elige TEE cuando la custodia sellada de claves sea el principal control.

Prefiere un oráculo tradicional si: se requieren precios continuos de mercados públicos o resultados de eventos; los contratos deben liquidar sobre una fuente legible por la red; ya existen agregación consolidada de múltiples fuentes y supervisión de desviaciones; la privacidad no es la principal restricción del campo. Estas fuentes suelen impulsar decisiones de contratos inteligentes a partir de sistemas externos compartidos, no de registros personales. Las redes de oráculos están diseñadas para que muchos contratos cliente puedan utilizar la misma fuente pública sin que cada usuario tenga que abrir una sesión TLS privada.

Combina ambos si: los precios públicos pasan por un oráculo y los atributos privados de usuarios pasan por zkTLS. Esta combinación es habitual cuando las aplicaciones necesitan fuentes públicas y afirmaciones privadas para flujos de trabajo de activos del mundo real o lógica empresarial sensible. En cualquier caso, incluye «procedencia ≠ verdad» en las reglas: los errores del servidor de origen, la colusión de nodos, la corrupción del notario, una gestión deficiente de claves y los rediseños de páginas son riesgos de primer nivel, no notas al pie. La elección del protocolo debe indicar qué partes deben mantenerse honestas para que la prueba conserve su significado.

Resumen

zkTLS y los oráculos tradicionales responden a preguntas diferentes en cadena: los oráculos tradicionales sirven principalmente para datos externos compartidos, mientras que zkTLS ayuda a hacer verificables los registros web privados preservando la privacidad. Históricamente, esta diferencia ha hecho que las fuentes públicas fueran más fáciles de utilizar, dejando los datos privados relativamente infrautilizados. Tras comparar el acceso al origen, la privacidad, las raíces de confianza y la latencia, los campos de páginas privadas posteriores al inicio de sesión y las fuentes públicas rara vez son sustitutos entre sí.

En resumen: utiliza un oráculo tradicional cuando muchos contratos necesiten la misma fuente pública; utiliza zkTLS cuando un cliente deba demostrar una respuesta TLS privada de un servidor de origen mediante una prueba de divulgación selectiva. MPC, Proxy y TEE siguen siendo los principales estilos de testigo para esa ruta de protocolo, y cada uno modifica qué partes poseen el material de claves y cuánta computación interactiva debe ejecutar el cliente. Las capturas de pantalla y los PDF no pueden cubrir una carencia de procedencia criptográfica; una prueba TLS no puede garantizar automáticamente que el contenido del origen sea correcto. Elegir mediante una lista de «Elegir si», e incluir los modos de fallo de notario o nodo y del origen en el modelo de amenazas, es mejor que debatir sobre etiquetas.

Preguntas frecuentes

¿Cuál es la diferencia entre zkTLS y los oráculos tradicionales?

Los oráculos tradicionales entregan principalmente datos públicos a un contrato inteligente, mientras que los productos utilizan zkTLS cuando se debe demostrar la autenticidad de los datos de una sesión HTTPS en poder de un usuario. Esto también afecta a si el verificador ve el registro subyacente o solo una prueba sobre él. zkTLS demuestra que los campos de una sesión TLS proceden de un servidor vinculado a un dominio y certificado. Algunos diseños utilizan MPC (computación segura multipartita) durante el protocolo de enlace TLS entre el cliente y las partes notarias, mientras que otros dependen de testigos basados en Proxy o TEE. Los oráculos tradicionales escriben continuamente hechos públicos fuera de la cadena, como precios, en contratos mediante conjuntos de nodos y agregación de múltiples fuentes. Uno optimiza la procedencia de la sesión; el otro optimiza la disponibilidad de las fuentes y la resistencia a la manipulación. En los diseños basados en Proxy o testigos, el servidor de origen normalmente no necesita cambiar y el cliente sigue conservando o compartiendo la clave de sesión conforme a las reglas del protocolo.

¿Cuándo deberías utilizar zkTLS en lugar de un oráculo tradicional?

Utiliza zkTLS para campos privados posteriores al inicio de sesión que necesiten una divulgación mínima y no cuenten con una API pública firmada, especialmente cuando un producto necesite compartir datos verificables desde una fuente privada mediante un token de acceso o credenciales de sesión. Esto permite que el cliente se autentique directamente con el servidor de origen en lugar de entregar registros sin procesar a un intermediario. Algunas implementaciones ejecutan localmente la computación de pruebas de conocimiento cero para demostrar atributos seleccionados sin cargar el registro completo. Utiliza oráculos tradicionales para precios continuos de mercados públicos o resultados de eventos que requieran liquidación legible por la red; esto puede mantener los registros privados fuera de una fuente pública de oráculo y permitir al mismo tiempo que los contratos utilicen precios compartidos. Las fuentes públicas y los atributos privados pueden combinarse en un mismo producto cuando distintas partes necesitan diferentes clases de evidencia.

¿Pueden las capturas de pantalla o las cargas de PDF sustituir una prueba zkTLS?

No de forma fiable. Las capturas de pantalla y los PDF de una página web pueden parecer convincentes desde el punto de vista operativo, pero carecen de procedencia verificable de sesión TLS y no contienen una prueba criptográfica del origen o la integridad de la sesión. Por ello, un tercero no puede descartar fácilmente imágenes editadas o páginas incorrectas. En cambio, un testigo HTTP Proxy puede observar o enrutar el intercambio para preservar una procedencia verificable de una forma que una captura de pantalla o un PDF no puede. Las afirmaciones de tipo zkTLS proporcionan rutas de comprobación de vinculación de dominio e integridad, pero si el origen devuelve datos incorrectos, una prueba puede seguir siendo formalmente válida.

¿Una verificación zkTLS superada significa que los datos del origen son verdaderos?

No. Una validación superada normalmente significa que la afirmación cumple los requisitos de procedencia e integridad bajo los supuestos de confianza indicados. La prueba puede incluir comprobaciones de integridad, como un código de autenticación de mensajes sobre los datos de respuesta. Puede demostrar procedencia e integridad mientras que la información sensible subyacente aún puede reflejar un campo incorrecto o una entrada errónea del lado del origen. Los errores de introducción de datos en el origen, las páginas manipuladas o los campos de API incorrectos pueden seguir generando pruebas formalmente válidas. Algunos diseños también derivan una clave de cifrado durante la sesión para que el usuario pueda descifrar la respuesta mientras el verificador no puede ver el registro subyacente. La procedencia verificable y la veracidad del contenido son capas diferentes.

¿Pueden los oráculos tradicionales consumir directamente los campos de una página web posterior al inicio de sesión de un usuario?

Normalmente no como una sesión HTTPS personal. Los nodos tradicionales suelen obtener fuentes públicas de API u otros puntos de conexión públicos, no la transcripción de la sesión privada posterior al inicio de sesión de un usuario ni Web Proofs. Algunos diseños más recientes de oráculos de privado a privado envían datos TLS autenticados a servidores de computación ciega en lugar de publicarlos como una fuente estándar. Este modelo se centra en proporcionar procedencia de datos para entradas privadas, puede mantener privados los datos cifrados para el cumplimiento normativo y puede combinar datos de múltiples clientes para computaciones conjuntas. Plataformas como los oráculos de privado a privado de Nillion utilizan computación ciega para preservar la privacidad, mientras que Reclaim Protocol es un ejemplo de estilo Proxy distinto de ese enfoque. Esto también puede mejorar la seguridad al trasladar datos de sesión sensibles a una computación privada en lugar de exponer el contenido sin procesar de la página. Cuando las páginas privadas posteriores al inicio de sesión no tienen una API abierta firmada, las Web Proofs de tipo zkTLS o las alianzas de datos especializadas son más adecuadas que una tarea de fuente predeterminada.