Hé

« Je sais quelque chose, mais je ne te dirai pas quoi et pourtant tu vas quand même me croire. » ✨

Imaginez ceci :

Vous prouvez que vous travaillez dans une certaine entreprise. ✅ Sans révéler votre e-mail. ✅ Sans doxxer votre identité Web2. ✅ Entièrement vérifiable en chaîne.

C'est le pouvoir des preuves à connaissance nulle (preuves zk) et vous n'avez plus besoin d'un doctorat en cryptographie pour commencer à construire avec elles. Bienvenue dans le monde de ZKApps : des applications alimentées par la magie cryptographique, mais conçues avec des outils qui ressemblent à l'écriture de code normal.

Qu'est-ce qu'une ZKApp (application à connaissance nulle) ?

Une ZKApp est une application où les utilisateurs peuventprouver quelque chose concernant leurs données privéessans révéler les données elles-mêmes. C'est comme si vous offriez des reçus... sans montrer votre portefeuille.

Ces applications offrent des fonctionnalités dont nous ne faisons souvent que rêver, comme vérifier l'identité d'une personne sans révéler son nom, ou permettre aux utilisateurs de voter en chaîne sans révéler leur vote réel.

Dans l'écosystème Sui, les ZKApps acquièrent un potentiel supplémentaire. Ils relient vos secrets hors chaîne à une logique en chaîne, en utilisant des outils tels queSP1 zKVMetSoundness Layerpour rendre la génération et la vérification de preuves plus pratiques que jamais.

Traditionnellement,l'écriture d'un circuit zk nécessitait une expertise cryptographique et des semaines d'efforts. Mais les zKVM tels que SP1, Risc0 et Nexus ont renversé la donne. Ces machines virtuelles permettent aux développeurs d'exprimer leur logique dans des langages de programmation normaux, de générer unepreuve zk**pour le résultat et de le soumettre à une vérification en chaîne.

Cette abstraction ne se contente pas d'accélérer le développement, elle élargit également les personnes qui peuvent créer ZKApps. Si vous pouvez écrire de la logique dans Rust, vous pouvez créer une ZKApp. Et si vous utilisezSoundness Layer, vous pouvez le vérifier sur Sui.

#ZKDomain : prouver la propriété d'un e-mail sans exposition

Prenons un scénario courant dans lequel un DAO souhaite envoyer des jetons aux employés d'une entreprise spécifique.

Mais au lieu de collecter les e-mails des utilisateurs et de les vérifier manuellement, ce qui expose l'identité Web2 et met en danger la confidentialité des utilisateurs, nous voulons que les utilisateursprouventqu'ils possèdent un e-mail à** @soundness .xyz**, sans jamais révéler l'adresse complète.

C'est là qu'intervient la magie du monde réel de zk.

Si vous avez accès à une adresse e-mail professionnelle qui utiliseGoogle Workspace, vous pouvez vous authentifier viaOpenID Connect (OIDC) et recevoir unJWT (JSON Web Token) signé de la part de Google. Ce jeton contient des métadonnées, y compris votre adresse e-mail.

Maintenant, au lieu d'envoyer ce JWT au DAO, vousgénérez une preuve zk qui dit : « J'ai un JWT valide émis par Google, etmon e-mail se termine par @soundness .xyz. » Cette preuve est vérifiée en chaîne. Personne ne voit jamais votre véritable e-mail. Le DAO voit seulement qu'une preuve est passée.

Accès accordé.

Toute la logique de vérification (analyse JWT, validation de signature, vérification de domaine) est exécutée dans un programme zKVM écrit en Rust, compilé par SP1.

Vous pouvez consulter la mise en œuvre complète ici :

👉 Exemple ZKDomain SP1

#![no_main]
sp1_zkvm::entrypoint!(main);

use lib::{split_email, split_jwt, pem_to_der};
use rsa::{pkcs8::DecodePublicKey, Pkcs1v15Sign, RsaPublicKey};
use sha2_v0_10_8::{Digest, Sha256};

pub fn main() {
    // Read input values: JWT token, RSA public key, and the expected domain
    let token = sp1_zkvm::io::read::<String>();
    let rsa_public_key = sp1_zkvm::io::read::<String>();
    let domain = sp1_zkvm::io::read::<String>();

    // Commit the domain to the zk proof (so it’s publicly known)
    sp1_zkvm::io::commit(&domain);

    // Split the JWT into its components: header, payload, and signature
    let (header, payload, signature) = split_jwt(&token)
        .expect("Failed to decode JWT"); // Panic if JWT parsing fails
    
    // Convert the PEM public key into DER format for RSA verification
    let pk_der = pem_to_der(&rsa_public_key);
    let public_key = RsaPublicKey::from_public_key_der(&pk_der).unwrap();

    // Reconstruct the signing input (header + payload) as a string
    let signing_input = format!(
        "{}.{}",
        token.split('.').collect::<Vec<&str>>()[0], // First part: header
        token.split('.').collect::<Vec<&str>>()[1]  // Second part: payload
    );

    // Hash the signing input using SHA256
    let mut hasher = Sha256::new();
    hasher.update(signing_input);
    let hashed_msg = hasher.finalize();

    // Verify the JWT signature using the provided RSA public key
    let verification_result = match public_key.verify(Pkcs1v15Sign::new::<Sha256>(), &hashed_msg, &signature) {
        Ok(_) => true,  // Signature is valid
        Err(_) => false, // Signature is invalid
    };

    // Commit the verification result (proof that the JWT is authentic)
    sp1_zkvm::io::commit(&verification_result);

    // Extract and split the email address from the JWT payload
    let email_parts = split_email(payload.get("email").unwrap().to_string()).unwrap();

    // Check if the email domain matches the expected domain
    let verified = email_parts.domain == domain;

    // Commit the verification result (proof that the email domain is correct)
    sp1_zkvm::io::commit(&verified);
}

Seul le domaine, et si le JWT était valide ou non. C'est ça. L'e-mail complet de l'utilisateur, le JWT original et toute autre information personnelle identifiable restent cachés et scellés cryptographiquement à l'intérieur de la preuve.

##Vérification en chaîne : de zKVM à Move

Bien entendu, générer la preuve n'est qu'un côté de la médaille. La véritable utilité entre en jeu lorsque vous pouvez vérifier cette preuve en chaîne et prendre des mesures en fonction de celle-ci.

C'est là que laSoundness Layerchange la donne. Conçu pour Sui, il agit comme une couche de vérification zk capable de traiter les preuves générées par le SP1, converties au format Groth16, que Sui prend en charge de manière native. Vous n'avez pas besoin de jouer avec les primitives cryptographiques. Il vous suffit d'écrire un contrat intelligent dans Move, de transmettre la preuve et les entrées publiques (comme le domaine attendu), et de laisser la logique du vérificateur faire le reste.

Cela signifie que votre contrat intelligent DAO peut désormais gérer les airdrops en fonction de la propriété du domaine de messagerie, sans jamais toucher à des données sensibles. Soundness Layer gère la vérification. Votre contrat intelligent gère la logique. Le reste est magique.

Pour en savoir plus sur Soundness Layer, cliquez ici :

🔗 soundness.xyz/blog/soundness-layer

Vous pouvez créer des flux d'authentification sans mot de passe. Vous pouvez concevoir des systèmes de vote qui garantissent l'anonymat. Vous pouvez accéder aux DAO, aux événements ou aux récompenses en fonction de critères qui restent totalement privés.

Et surtout, vous pouvez faire tout cela en utilisantRust + Sui + SP1 + Soundness Layer, sans écrire une seule contrainte cryptographique à la main.

Nous ne parlons plus de zk théorique. Nous parlons de zk que vous pouvez expédier. Parce que la confidentialité n'est pas qu'une fonctionnalité, c'est un fondement. Et avec zk, c'est enfin composable.