Hallo

„Ich weiß etwas, aber ich sage dir nicht was und trotzdem wirst du mir glauben. „✨

Stell dir das vor:

Sie beweisen, dass Sie in einem bestimmten Unternehmen arbeiten. ✅ Ohne deine E-Mail-Adresse preiszugeben. ✅ Ohne deine Web2-Identität zu verlieren. ✅ Vollständig verifizierbar in der Kette.

Das ist die Stärke von Zero-Knowledge-Beweisen (zk-Proofs) und Sie benötigen keinen Doktortitel in Kryptografie mehr, um mit ihnen zu bauen. Willkommen in der Welt von zkApps: Anwendungen, die auf kryptografischer Magie basieren, aber mit Tools ausgestattet sind, die sich so anfühlen, als würde man normalen Code schreiben.

Was ist eine ZkApp (Zero-Knowledge-App)?

Eine ZKapp ist eine App, mit der Benutzeretwas über ihre privaten Daten beweisen können, ohne die Daten selbst preiszugeben. Stellen Sie sich das wie das Einlegen von Quittungen vor... ohne Ihr Portemonnaie vorzuzeigen.

Diese Apps ermöglichen Funktionen, von denen wir oft nur träumen — wie die Überprüfung der Identität einer Person, ohne ihren Namen preiszugeben, oder es Nutzern zu ermöglichen, online abzustimmen, ohne ihre tatsächliche Stimme preiszugeben.

Im Sui-Ökosystem bieten zkApps ein zusätzliches Potenzial. Sie verbinden Ihre Off-Chain-Geheimnisse mit On-Chain-Logik und verwenden Tools wieSP1 zKVMundSoundness Layer, um die Generierung und Überprüfung von Beweisen praktischer als je zuvor zu machen.

Traditionell erforderte das Schreiben einer ZK-Schaltung kryptografisches Fachwissen und wochenlangen Arbeitsaufwand. Aber zKVMs wie SP1, Risc0 und Nexus haben das Spiel umgedreht. Diese virtuellen Maschinen ermöglichen es Entwicklern, ihre Logik in normalen Programmiersprachen auszudrücken,einen ZK-Prooffür das Ergebnis zu generieren und es zur On-Chain-Überprüfung einzureichen.

Diese Abstraktion beschleunigt nicht nur die Entwicklung, sie erweitert auch, wer zkApps erstellen kann. Wenn Sie Logik in Rust schreiben können, können Sie eine zkApp erstellen. Und wenn duSoundness Layerverwendest, kannst du das auf Sui verifizieren.

#ZKDomain: Nachweis der E-Mail-Inhaberschaft ohne Offenlegung von

Stellen wir uns ein übliches Szenario vor, in dem eine DAO Tokens per Airdrop an Mitarbeiter eines bestimmten Unternehmens verteilen möchte.

Aber anstatt Benutzer-E-Mails zu sammeln und sie manuell zu verifizieren, was die Identität von Web2 preisgibt und die Privatsphäre der Benutzer gefährdet, möchten wir, dass Benutzerbeweisen, dass sie eine E-Mail unter**@soundness .xyz**besitzen, ohne jemals die vollständige Adresse preiszugeben.

Hier kommt die reale Magie von zk ins Spiel.

Wenn Sie Zugriff auf eine Unternehmens-E-Mail haben, dieGoogle Workspaceverwendet, können Sie sich überOpenID Connect (OIDC) authentifizieren und erhalten einsigniertes JWT (JSON Web Token) von Google. Dieses Token enthält Metadaten, einschließlich Ihrer E-Mail.

Anstatt das JWT nun an das DAO zu senden,generieren Sie einen ZK-Proof, der besagt: „Ich habe ein gültiges, von Google ausgestelltes JWT, undmeine E-Mail endet mit @soundness .xyz.“ Dieser Beweis wird in der Kette verifiziert. Niemand sieht jemals Ihre tatsächliche E-Mail. Die DAO sieht nur, dass ein Beweis bestanden wurde.

Zugriff gewährt.

Die gesamte Überprüfungslogik, das JWT-Parsing, die Signaturvalidierung und die Domainüberprüfung werden in einem in Rust geschriebenen zKVM-Programm ausgeführt, das von SP1 kompiliert wurde.

Sie können hier einen Blick auf die vollständige Implementierung werfen:

👉 SP1 ZKDomain-Beispiel

#![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);
}

Nur die Domain und ob das JWT gültig war oder nicht. Das war's. Die vollständige E-Mail-Adresse des Benutzers, das ursprüngliche JWT und alle anderen persönlich identifizierbaren Informationen bleiben im Proof versteckt und kryptografisch versiegelt.

##Onchain Verification: Von zKVM zu Move

Natürlich ist das Generieren des Beweises nur eine Seite der Medaille. Der eigentliche Nutzen kommt zum Tragen, wenn Sie diesen Nachweis in der Kette verifizieren und auf dieser Grundlage Maßnahmen ergreifen können.

An dieser Stelle wird derSoundness Layerzu einem entscheidenden Faktor. Sie wurde für Sui entwickelt und fungiert als ZK-Verifikationsebene, die von SP1 generierte Proofs verarbeiten kann — konvertiert in das Groth16-Format, das Sui nativ unterstützt. Sie müssen sich nicht mit kryptografischen Primitiven herumschlagen. Sie schreiben einfach einen Smart Contract in Move, übergeben den Proof und die öffentlichen Eingaben (wie die erwartete Domain) und lassen die Verifier-Logik den Rest erledigen.

Das bedeutet, dass Ihr DAO-Smart Contract jetzt Airdrops auf der Grundlage der Inhaberschaft einer E-Mail-Domain steuern kann — ohne jemals sensible Daten zu berühren. Soundness Layer kümmert sich um die Überprüfung. Ihr Smart Contract kümmert sich um die Logik. Der Rest ist Magie.

Erfahre hier mehr über Soundness Layer:

🔗 soundness.xyz/blog/soundness-layer

Sie können Authentifizierungsabläufe ohne Passwörter erstellen. Sie können Wahlsysteme entwerfen, die Anonymität garantieren. Du kannst den Zugang zu DAOs, Events oder Prämien anhand von Kriterien einschränken, die absolut vertraulich bleiben.

Und vor allem können Sie all dies mitRust + Sui + SP1 + Soundness Layertun — ohne eine einzige kryptografische Beschränkung von Hand schreiben zu müssen.

Wir sprechen nicht mehr über theoretisches ZK. Wir sprechen über ZK, das Sie versenden können. Weil Datenschutz nicht nur eine Funktion ist, sondern eine Grundlage. Und mit zk ist es endlich zusammensetzbar.