Les projets du hackathon Midnight démontrent la prise en charge de données web privées et la vérification d'attestations

Des développeurs du hackathon Midnight à Buenos Aires ont présenté deux prototypes fonctionnels axés sur la confidentialité, conçus autour de données externes et d'attestations numériques.

Le premier combine ZK Fetch et des attestations Reclaim avec Midnight Compact afin d'établir l'origine des données web. KEEP adopte une approche différente au moyen de Ward, une application mobile conçue pour émettre et valider des attestations sans transférer l'intégralité du dossier personnel du détenteur.

ZK Fetch apporte des données web prouvées dans Compact

Le premier projet traite un problème courant lorsque des contrats intelligents s'appuient sur des informations récupérées depuis des API externes.

HTTPS sécurise la communication entre un client et un serveur, mais le contrat qui reçoit ces informations ne faisait pas partie de la connexion initiale. Les développeurs ont donc utilisé ZK Fetch et Reclaim Protocol pour créer une preuve cryptographique que l'interaction HTTPS a bien eu lieu avec la source indiquée.

Le système de preuve de Reclaim et Midnight Compact n'étaient pas directement compatibles, l'équipe a donc ajouté une couche de notarisation entre les deux. Les notaires vérifient la preuve et la signent, tandis qu'une implémentation de signature Schnorr à l'intérieur de Compact exige la confirmation d'au moins deux notaires avant que l'information puisse être acceptée comme entrée du contrat.

L'architecture a été démontrée avec des données Strava. Deux comptes ont soumis des résultats de course d'environ 3,5 kilomètres et 15 kilomètres, ce qui a permis à l'application de déterminer un vainqueur sans rendre public l'ensemble plus large des données.

L'équipe a indiqué que le processus de preuve externe prenait environ trois à quatre secondes, suivi du temps habituel requis pour une transaction Midnight. L'implémentation Compact reste un MVP et est prévue pour d'autres refactorisations.

KEEP stocke les attestations sur l'appareil du détenteur

KEEP applique la confidentialité aux attestations délivrées par des institutions telles que des universités, des écoles ou des organismes publics.

Son application mobile Ward prend en charge les rôles de détenteur et de vérificateur. Au lieu de répartir des dossiers personnels entre plusieurs systèmes, l'attestation reste sur le téléphone de l'utilisateur et le détenteur peut ne divulguer que les informations nécessaires à une vérification spécifique.

Le système utilise un arbre de Merkle pour une divulgation sélective, permettant de révéler un élément d'une attestation tout en préservant l'intégrité cryptographique. Les développeurs ont également intégré des signatures Schnorr et Capacity Exchange pour des transactions sponsorisées destinées à réduire la complexité blockchain visible par les utilisateurs finaux.

Dans la démonstration, un téléphone faisait office de vérificateur et affichait un défi QR, tandis qu'un second téléphone détenait l'attestation. Après que le détenteur a scanné le défi, le processus a transité par Midnight et a renvoyé la confirmation que l'attestation était valide.

L'équipe a signalé un temps de traitement d'environ 20 secondes. Le vérificateur a reçu le résultat sans recevoir le dossier d'attestation complet du détenteur.

Deux prototypes axés sur la confidentialité ciblent des problèmes de données différents

Les deux projets traitent des sources d'information différentes.

L'implémentation ZK Fetch se concentre sur les données provenant de services web existants, offrant aux contrats Compact une méthode pour établir qu'une affirmation externe provient bien de la source HTTPS attendue.

KEEP se concentre sur les attestations émises directement aux individus, permettant au détenteur de conserver l'enregistrement localement et de ne divulguer que ce dont un vérificateur a besoin.

Les deux restent à l'état de prototypes issus d'un hackathon. L'équipe KEEP a indiqué que sa réalisation en vingt-quatre heures ne pouvait pas être entièrement décentralisée et utilise actuellement un nœud Capacity Exchange centralisé dans une certaine mesure. Selon les développeurs, ce nœud ne possède pas la clé du détenteur requise pour signer la transaction Midnight de l'utilisateur.

Ces démonstrations laissent à Midnight deux prototypes distincts et opérationnels: l'un peut transmettre des informations HTTPS prouvées à un contrat Compact, tandis que l'autre peut émettre une attestation vers un appareil mobile et confirmer une revendication sans remettre au vérificateur le dossier personnel complet.