Proyectos del Hackathon de Midnight demuestran datos web privados y verificación de credenciales
Dos proyectos presentados tras Hack Buenos Aires mostraron cómo las aplicaciones de Midnight pueden trabajar con información del mundo real y a la vez limitar la exposición de datos privados. Uno conecta datos HTTPS probados criptográficamente con contratos de Compact, mientras que KEEP utiliza credenciales móviles que permanecen bajo el control del titular.
By SongMarketCap
Desarrolladores del hackathon de Midnight en Buenos Aires presentaron dos prototipos funcionales centrados en la privacidad, construidos en torno a datos externos y credenciales digitales.
El primero combina ZK Fetch y atestaciones de Reclaim con Midnight Compact para establecer de dónde se originaron los datos web. KEEP adopta un enfoque diferente mediante Ward, una aplicación móvil diseñada para emitir y validar credenciales sin transferir el registro personal completo del titular.
ZK Fetch lleva datos web verificados a Compact
El primer proyecto aborda un problema común cuando los contratos inteligentes dependen de información obtenida de APIs externas.
HTTPS asegura la comunicación entre un cliente y un servidor, pero el contrato que recibe esa información no formó parte de la conexión original. Por ello, los desarrolladores utilizaron ZK Fetch y Reclaim Protocol para crear evidencia criptográfica de que la interacción HTTPS ocurrió con la fuente indicada.
El sistema de pruebas de Reclaim y Midnight Compact no eran directamente compatibles, por lo que el equipo añadió una capa de notarios entre ambos. Los notarios verifican la prueba y la firman, mientras que una implementación de firmas Schnorr dentro de Compact requiere la confirmación de al menos dos notarios antes de que la información pueda aceptarse como entrada del contrato.
La arquitectura se demostró con datos de Strava. Dos cuentas enviaron resultados de carrera de aproximadamente 3,5 kilómetros y 15 kilómetros, lo que permitió que la aplicación determinara un ganador sin hacer público el conjunto de datos más amplio.
El equipo indicó que el proceso de prueba externa tomó alrededor de tres a cuatro segundos, seguido del tiempo normal requerido para una transacción de Midnight. La implementación en Compact sigue siendo un MVP y está planificada para una mayor refactorización.
KEEP almacena las credenciales en el dispositivo del titular
KEEP aplica privacidad a credenciales emitidas por instituciones como universidades, escuelas u organismos públicos.
Su aplicación móvil Ward admite tanto el rol de titular como el de verificador. En lugar de distribuir los registros personales entre múltiples sistemas, la credencial permanece en el teléfono del usuario y el titular puede revelar solo la información requerida para una verificación específica.
El sistema utiliza un árbol de Merkle para divulgación selectiva, lo que permite revelar un elemento de una credencial preservando la integridad criptográfica. Los desarrolladores también incorporaron firmas Schnorr y Capacity Exchange para transacciones patrocinadas destinadas a reducir la complejidad de blockchain visible para los usuarios finales.
En la demostración, un teléfono actuó como verificador y mostró un desafío QR, mientras que un segundo teléfono contenía la credencial. Después de que el titular escaneó el desafío, el proceso se ejecutó a través de Midnight y devolvió la confirmación de que la credencial era válida.
El equipo informó un tiempo de procesamiento de aproximadamente 20 segundos. El verificador recibió el resultado sin recibir el registro completo de credenciales del titular.
Dos prototipos de privacidad abordan diferentes problemas de datos
Los dos proyectos abordan diferentes fuentes de información.
La implementación de ZK Fetch se centra en datos que provienen de servicios web existentes, proporcionando a los contratos de Compact un método para establecer que una afirmación externa provino de la fuente HTTPS esperada.
KEEP se enfoca en credenciales emitidas directamente a las personas, lo que permite al titular conservar el registro localmente y revelar solo lo que necesita un verificador.
Ambas siguen siendo implementaciones en etapa de hackathon. El equipo de KEEP señaló que su construcción de 24 horas no pudo hacerse totalmente descentralizada y actualmente utiliza un nodo de Capacity Exchange que está centralizado en cierto grado. Según los desarrolladores, ese nodo no posee la clave del titular necesaria para firmar la transacción de Midnight del usuario.
Las demostraciones dejan a Midnight con dos prototipos funcionales distintos: uno puede introducir información HTTPS verificada en un contrato de Compact, mientras que el otro puede emitir una credencial a un dispositivo móvil y confirmar una afirmación sin entregar al verificador el registro personal completo.