Reenviar el título original ‘¿Cómo podemos hacer que el uso de datos web2 en web3 sea realmente privado y verificable?’

Muchas personas que afirman que web3 es el nuevo internet lo definen con la frase “leer, escribir, poseer”. Las partes “leer” y “escribir” son claras, pero cuando se trata de “poseer” en términos de datos, hoy en día apenas poseemos nada.

Los datos de los usuarios a menudo son robados por las corporaciones y utilizados de manera que los benefician; Realmente no poseemos nada en Internet.

Sin embargo, no podemos simplemente pasar a un mundo donde solo exista web3 sin compartir nada. No, todavía necesitamos compartir, pero solo lo necesario.

Como alguien con un pasaporte más débil, me veo obligado a solicitar visas electrónicas y a presentar interminables detalles sobre mí mismo para demostrar que soy elegible para visas específicas. Y siempre termino preguntándome:

• ¿Por qué debería compartir mi estado de cuenta bancario completo cuando solo necesitan confirmar un nivel de ingresos específico?

• ¿Por qué debería proporcionar la reserva exacta del hotel en lugar de simplemente demostrar que he reservado un hotel en este país?

• ¿Por qué tengo que enviar los detalles completos de mi pasaporte cuando lo único que necesitan es verificar mi residencia permanente en mi país actual?

Aquí hay dos preocupaciones principales: los servicios saben mucho más de lo necesario, y los datos que estás proporcionando no son privados. Pero, ¿cómo se relaciona esto con la seguridad y la privacidad en las criptomonedas?

1. La Web3 no va a funcionar sin los datos de la Web2.

Como la mayoría de ustedes saben, los contratos inteligentes básicamente no tienen idea de cuánto cuesta BTC, ETH, SOL, u otro activo. Esta tarea es delegada a los oráculos, que constantemente publican datos públicos del mundo exterior al contrato inteligente.

En el mundo Ethereum, este rol está casi monopolizado por @chainlinkcon sus redes de oráculos para asegurarnos de que no dependemos de un solo nodo. Así que realmente necesitamos datos de web2 para más casos de uso más allá de simplemente conocer el precio de ciertos activos.

Sin embargo, esto solo se aplica a datos públicos. ¿Qué pasa si quiero conectar de forma segura mi cuenta bancaria o cuenta de Telegram y compartir información sensible que no está disponible públicamente pero es privada para mí?

La primera idea es: ¿cómo podemos llevar estos datos a una cadena de bloques con la prueba de que los datos privados están seguros?

Desafortunadamente, no funciona así porque los servidores no firman las respuestas que envían, por lo que no se puede verificar de manera confiable algo así en contratos inteligentes.

El protocolo que asegura la comunicación en una red informática se llama TLS: Seguridad de la Capa de Transporte. Incluso si no has oído hablar de él, lo usas a diario. Por ejemplo, mientras lees este artículo, verás el “https://“ en la barra de direcciones de tu navegador.

Si intentaste acceder al sitio web con una conexión “http://“ (sin la “s”), tu navegador te advertiría que la conexión no es segura. La “s” en el enlace representa TLS, que asegura tu conexión, garantizando privacidad y evitando que alguien robe los datos que estás transmitiendo.

2. La conexión ya es segura, ¿no podemos simplemente transportarla y usarla en el web3?

Como mencioné antes, enfrentamos un problema de verificabilidad: los servidores no firman las respuestas que envían, por lo que realmente no podemos verificar los datos.

Incluso si una fuente de datos acepta compartir sus datos, el protocolo estándar TLS no puede demostrar su autenticidad a otros. Simplemente pasar una respuesta no es suficiente: los clientes pueden modificar fácilmente los datos localmente, compartir esas respuestas los expone por completo, poniendo en riesgo la privacidad del usuario.

Un enfoque para el problema de verificabilidad es una versión mejorada de TLS llamada zkTLS.

El mecanismo de trabajo de zkTLS es similar al TLS pero ligeramente diferente, así es como funciona:

• Usted visita un sitio web a través de una conexión segura TLS y envía la solicitud requerida.

• zkTLS genera una prueba zk que verifica los datos mientras revela solo los detalles específicos que el usuario quiere demostrar, manteniendo todo lo demás privado.

• La prueba zk generada es luego utilizada por otras aplicaciones para confirmar y verificar que la información proporcionada es correcta.

Cuando digo zkTLS, me refiero a proyectos que utilizan zkTLS, pero hay diferentes enfoques para la verificabilidad de los datos utilizando varias soluciones:

1. TEE (Entorno de Ejecución Confiado)
2. MPC (Multi-Party Computation)
3. Proxy

Curiosamente, cada enfoque introduce su propio conjunto de casos de uso únicos. Entonces, ¿en qué se diferencian?

3. ¿Por qué no hay un estándar único para zkTLS? ¿En qué se diferencian?

zkTLS no es una sola tecnología porque verificar datos web privados sin exponerlos puede abordarse desde múltiples ángulos, cada uno con sus propias compensaciones. La idea principal es extender TLS con pruebas, pero cómo generar y validar esas pruebas depende del mecanismo subyacente.

Como mencioné antes, tres enfoques principales son usar TEE-TLS, MPC-TLS o Proxy-TLS.

TEE se basa en hardware especializado, como Intel SGX o AWS Nitro Enclaves, para crear una “caja negra” segura donde se pueden procesar los datos y generar pruebas. El hardware garantiza que los datos permanezcan privados y que los cálculos sean a prueba de manipulaciones.

En una configuración de zkTLS basada en TEE, el TEE ejecuta el protocolo, demostrando la ejecución y el contenido de la sesión TLS. El verificador es el propio TEE, por lo que la confianza depende del fabricante del TEE y de su resistencia a los ataques. Este enfoque es eficiente con una sobrecarga computacional y de red baja.

Sin embargo, tiene una falla importante: debes confiar en el fabricante de hardware, y las vulnerabilidades en TEEs (como los ataques de canal lateral) pueden romper todo el sistema.

Proxy-TLS y MPC-TLS son los enfoques más ampliamente adoptados debido a su amplia gama de casos de uso. Proyectos como @OpacityNetworky @reclaimprotocol, que están construidos en @eigenlayer, aproveche estos modelos para garantizar la seguridad y privacidad de los datos junto con una capa adicional de seguridad económica.

Veamos qué tan seguras son estas soluciones, qué casos de uso permiten los protocolos zkTLS y qué ya está en funcionamiento hoy.

4. ¿Qué tienen de especial MPC-TLS y Opacity Network?

Durante el TLS Handshake (donde un cliente y un servidor acuerdan cómo comunicarse de forma segura compartiendo claves de encriptación), el papel del sitio web permanece sin cambios, pero el proceso del navegador hace algo diferente.

En lugar de generar su propia clave secreta, utiliza una red de nodos para crear una clave secreta multiparte a través de MPC. Esta clave realiza el saludo para el navegador, asegurando que ninguna entidad única conozca la clave compartida.

La encriptación y desencriptación requieren la cooperación de todos los nodos y el navegador, con cada uno añadiendo o eliminando su parte de la encriptación secuencialmente antes de que los datos lleguen o salgan del sitio web. MPC-TLS proporciona una seguridad sólida y puede distribuirse para que ningún grupo tenga todo el poder.

La red de opacidad mejora el clásico@tlsnotarymarco mediante la adición de salvaguardias para minimizar los problemas de confianza. Emplea múltiples medidas de seguridad como:

1. Verificación en cadena de los ID de cuenta web2
2. Esquema de compromiso
3. Esquema de revelación
4. Muestreo aleatorio de redes de MPC
5. Registro verificable de intentos

Los ID de cuenta, al ser estáticos en los sistemas web2, permiten la prueba por comité donde diez nodos diferentes deben confirmar la propiedad. Esto vincula la cuenta a una billetera única, evitando intentos repetidos con diferentes billeteras para encontrar un nodo coludido.

Puedes ver cómo funciona la Opacidad en detalle más abajo:

Los nodos de opacidad operan dentro de un TEE, lo que hace que la colusión sea casi imposible si el TEE es seguro. Más allá de los TEE, Opacity también utiliza Eigenlayer para aprovechar un AVS, lo que requiere que los nodos vuelvan a apostar 32 stETH, con recortes inmediatos por mala conducta, evitando retrasos asociados con los enfriamientos.

Puedes ver que Opacity utiliza tanto MPC como TEE, pero porque MPC se utiliza para zkTLS mientras que TEE se utiliza básicamente para la seguridad del nodo, todavía se llama MPC-TLS.

Sin embargo, si los TEE fallaran, podrían permitir que un nodo participe en colusión dentro del MPC. Esa es una de las razones por las que se necesita una capa de seguridad económica adicional para prevenir este comportamiento.

Eso también es por qué Opacity está desarrollando un mecanismo de denuncia donde los usuarios que puedan demostrar que un notario ha actuado incorrectamente serán recompensados con una parte de la penalización impuesta a la participación del notario.

Debido a su simplicidad de integración, seguridad y privacidad que ofrece, Opacity ha atraído varios protocolos para integrarlo en sus productos en los sectores de agentes de consumo, DeFi e IA.

El equipo de @earnos_ioestá desarrollando una plataforma donde las marcas pueden recompensar a los usuarios por su participación o la finalización de tareas. EarnOS utiliza la tecnología de Opacity para demostrar rasgos a través de aplicaciones populares sin revelar información personal, permitiendo a las marcas dirigirse a sus audiencias mientras los usuarios mantienen su privacidad y obtienen recompensas.

La opacidad también está integrada en el @daylightenergy_protocol, desarrollando una red eléctrica descentralizada donde los usuarios pueden ganar recompensas por contribuir a soluciones de energía limpia. Gracias a Opacity, los usuarios pueden demostrar la propiedad de dispositivos de energía en cadena sin hardware especializado.

La opacidad incluso puede integrarse con agentes de IA, aportando más verificabilidad y transparencia a un campo que actualmente enfrenta desafíos significativos. zkTLS fue integrado recientemente en @elizaOS, permitiendo interacciones de IA verificables sin pérdida de privacidad.

Sin embargo, TEE-TLS y MPC-TLS son solo dos variaciones de zkTLS, también hay una tercera llamada Proxy-TLS, siendo la Red Reclaim la representación más famosa de este modelo. Entonces, ¿en qué se diferencia en términos tecnológicos de las otras dos variaciones y qué casos de uso puede habilitar Proxy-TLS?

5. ¿Qué tiene de especial el Protocolo Proxy-TLS y Reclaim?

Proxies de HTTPS, comunes en internet, reenvían el tráfico cifrado sin acceder a su contenido. En el modelo de proxy zkTLS, funciona casi de la misma manera con ligeras adiciones:

• El navegador envía solicitudes al sitio web a través de un proxy, que también maneja las respuestas del sitio web.

• El proxy ve todos los intercambios encriptados y atestigua su autenticidad, anotando si cada uno es una solicitud o una respuesta.

• El navegador luego genera una prueba zk que afirma que puede cifrar estos datos con una clave compartida sin revelar la clave y muestra el resultado.

• Esto funciona porque es casi imposible crear una clave falsa que convierta los datos en algo coherente, por lo que simplemente demostrar que puedes descifrarlo es suficiente.

Revelar la clave comprometería todos los mensajes anteriores, incluidos datos sensibles como nombres de usuario y contraseñas. Proxy-TLS es bastante rápido, asequible y maneja grandes volúmenes de datos de manera eficaz, lo que lo hace ideal para entornos de alto rendimiento.

La mayoría de los servidores no restringen el acceso basado en direcciones IP variables, lo que hace que este método sea bastante ampliamente aplicable.

El Protocolo Reclaim utiliza Proxy-TLS para una verificación eficiente de datos y emplea proxies para evitar los firewalls de Web2 que impiden el bloqueo de proxies a gran escala.

Así es como funciona:

El problema principal aquí es la colusión: si el usuario y el atestiguador coluden, pueden firmar básicamente cualquier cosa y actuar maliciosamente. Para mitigar esto, Reclaim incorpora un subconjunto de validadores elegidos para introducir aleatoriedad y bloquear tales exploits.

Reclaim utiliza AVS de Eigen para descentralizar la validación de los datos. Los operadores de EigenLayer pueden actuar como atestiguadores, pero necesitarán implementar su propio AVS para especificar la lógica de atestación para su servicio.

Reclaim es una plataforma que permite casos de uso únicos como la importación de datos de uso compartido de viajes para aplicaciones de transporte, la conexión de datos fuera de la cadena para la economía blockchain, la verificación de identidades con datos de identificación nacional, la creación de soluciones de datos personalizadas a través de herramientas para desarrolladores, y más.

El ecosistema Reclaim alberga más de 20 proyectos, pero me gustaría destacar 4 de ellos en los mercados financieros, identidad digital, consumidor y sectores de contratación.

@3janexyzes el primer mercado de dinero basado en créditos en Base, que ofrece líneas de crédito garantizadas a usuarios de criptomonedas mediante la evaluación de su solvencia y flujos de efectivo futuros, utilizando datos financieros tanto on-chain como off-chain.

3Jane utiliza el modelo de proxy de Reclaim para verificar los datos de crédito de VantageScore, Cred, Coinbase y Plaid, asegurando la privacidad de estos datos.

Otro uso de los puntajes de crédito con zkTLS es a través de @zkme_, zkCreditScore. Utiliza Reclaim Protocol para obtener su puntaje de crédito de EE. UU. de forma segura con zkTLS. Esto permite a zkMe verificar el puntaje de crédito de un usuario y crear tokens únicos vinculados al alma (SBT) para almacenar estos datos.

¿Puede haber otros casos de uso además de los puntajes de crédito? Por supuesto que las hay.

Podemos tomar @zkp2pcomo ejemplo, que es un mercado de bienes de consumo que aprovecha Reclaim para verificar los datos de los usuarios de Ticketmaster, así como verificar los pagos de los usuarios.

Al mismo tiempo, @bondexapp, que es uno de los tableros de trabajo más populares en criptomonedas, utiliza Reclaim para obtener pruebas de trabajo de perfiles, verificando que los datos son reales, privados y verificables.

Al observar los casos de uso posibles a través de zkTLS, la capacidad de verificar transcripciones de TLS en cadena ya está desbloqueando numerosas nuevas funcionalidades, lo que permite a los usuarios controlar sus propios datos sin necesidad de permiso de grandes corporaciones.

Más importante aún, zkTLS se encarga de garantizar que tus datos personales no se utilicen en tu contra. Entonces, ¿hacia dónde se dirige esto?

6. ¿Está zkTLS aquí para quedarse?

Todavía hay trabajo por hacer, pero diferentes protocolos zkTLS ya están introduciendo nuevos casos de uso que redistribuyen el poder de vuelta a los usuarios.

@Tim_RoughgardenEn el podcast de a16z crypto se destacó que las pruebas zk, propuestas en 1985, solo ganaron popularidad con las aplicaciones de blockchain, gracias a cientos de desarrolladores que trabajaron para reducir el tamaño y los costos de las pruebas.

Y ahora, las contribuciones de la industria blockchain se están utilizando en otras áreas más allá de la criptomoneda en sí misma.

Espero que se desarrolle una historia similar con zkTLS, comenzando con la implementación en Web3 y luego extendiéndose más allá, porque, como dije antes, actualmente, “leemos” y “escribimos”, pero apenas estamos protegidos y apenas “poseemos” ni siquiera nuestros propios datos.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [gatePavel Paramonov]. Todos los derechos de autor pertenecen al autor original [Pavel Paramonov]. If there are objections to this reprint, please contact the Gate Learn equipo, y lo manejarán con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. El equipo de Learn de gate hace traducciones del artículo a otros idiomas. Queda prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.