Oye

«Sé una cosa, pero no te diré qué y aun así me creerás. » ✨

Imagina esto:

¡

Demuestra que trabaja en una determinada empresa. ✅ Sin revelar tu correo electrónico. ✅ Sin dañar tu identidad de Web2. ✅ Totalmente verificable en cadena.

Ese es el poder de las pruebas de conocimiento cero (pruebas zk) y ya no es necesario tener un doctorado en criptografía para empezar a crear con ellas. Bienvenido al mundo de zkApps: aplicaciones impulsadas por la magia criptográfica, pero diseñadas con herramientas que dan la misma sensación que escribir código normal.

¿Qué es una ZkApp (aplicación de conocimiento cero)?

Una zkApp es una aplicación en la que los usuarios puedenprobar algo sobre sus datos privadossin revelar los datos en sí. Piense en ello como flexionar recibos... sin mostrar su cartera.

Estas aplicaciones permiten funciones con las que a menudo solo soñamos, como verificar la identidad de alguien sin revelar su nombre o permitir a los usuarios votar en cadena sin revelar su voto real.

En el ecosistema Sui, las zkApps adquieren un potencial adicional. Usan sus secretos fuera de la cadena con la lógica interna, y utilizan herramientas comoSP1 zKVMySoundness Layerpara hacer que la generación de pruebas y la verificación sean más prácticas que nunca.

Tradicionalmente,escribir un circuito zk requería conocimientos criptográficos y semanas de efectivort. Pero los zKVM como SP1, Risc0 y Nexus han cambiado las reglas del juego. Estas máquinas virtuales permiten a los desarrolladores expresar su lógica en lenguajes de programación normales, generaruna prueba zkpara el resultado y enviarlo para su verificación en cadena.

Esta abstracción no solo acelera el desarrollo, sino que amplía la capacidad de crear zkApps. Si puedes escribir lógica en Rust, puedes construir una ZkApp. Y si usasSoundness Layer, puedes verificarlo en Sui.

#ZkDomain: demostrar la propiedad del correo electrónico sin exposición

Consideremos un escenario común en el que una DAO quiere enviar tokens desde el aire a los empleados de una empresa específica.

Pero en lugar de recopilar los correos electrónicos de los usuarios y verificarlos manualmente, lo que expone la identidad de Web2 y pone en riesgo la privacidad de los usuarios, queremos que los usuariosdemuestraque son propietarios de un correo electrónico en** @soundness .xyz**, sin revelar nunca la dirección completa.

Aquí es donde entra en juego la magia del mundo real de zk.

Si tienes acceso al correo electrónico de una empresa que utilizaGoogle Workspace, puedes autenticarte medianteOpenID Connect (OIDC) y recibir unJWT (JSON Web Token) firmado por Google. Este token contiene metadatos, incluido tu correo electrónico.

Ahora, en lugar de enviar ese JWT a la DAO,generas una prueba zk que diga: «Tengo un JWT válido emitido por Googleymi correo electrónico termina en @soundness .xyz». Esa prueba se verifica en cadena. Nadie ve tu correo electrónico real. La DAO solo ve que se ha aprobado una prueba.

Acceso concedido.

Toda la lógica de verificación (el análisis de JWT, la validación de firmas y la verificación de dominios) se ejecuta dentro de un programa zKVM escrito en Rust y compilado por el SP1.

Puedes ver la implementación completa aquí:

👉 Ejemplo de zkDomain para el 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);
}

Solo el dominio y si el JWT era válido o no. Eso es todo. El correo electrónico completo del usuario, el JWT original y cualquier otra información de identificación personal permanecen ocultos y sellados criptográficamente dentro de la prueba.

##Verificación en cadena: de zKVM a Move

Por supuesto, generar la prueba es solo una cara de la moneda. La verdadera utilidad se activa cuando puedes verificar esa prueba en cadena y tomar medidas en función de ella.

Aquí es donde laSoundness Layercambia las reglas del juego. Creada para Sui, actúa como una capa de verificación zk que puede procesar las pruebas generadas por el SP1 y convertirlas al formato Groth16, que Sui admite de forma nativa. No necesita meterse con las primitivas criptográficas. Solo tienes que escribir un contrato inteligente en Move, pasar la prueba y las entradas públicas (como el dominio esperado) y dejar que la lógica del verificador se encargue del resto.

Esto significa que tu contrato inteligente DAO ahora puede controlar los lanzamientos aéreos en función de la propiedad del dominio del correo electrónico, sin tocar nunca datos confidenciales. Soundness Layer se encarga de la verificación. Su contrato inteligente se encarga de la lógica. El resto es mágico.

Obtén más información sobre Soundness Layer aquí:

🔗 soundness.xyz/blog/soundness-layer

Puede crear flujos de autenticación sin contraseñas. Puede diseñar sistemas de votación que garanticen el anonimato. Puedes restringir el acceso a las DAO, los eventos o las recompensas en función de criterios que permanecen completamente privados.

Y lo que es más importante, puedes hacer todo esto conRust + Sui + SP1 + Soundness Layer, sin escribir ni una sola restricción criptográfica a mano.

Ya no hablamos del zk teórico. Estamos hablando de los zk que puedes enviar. Porque la privacidad no es solo una característica, es una base. Y con zk, por fin es componible.