Эй

«Я кое-что знаю, но не скажу, но вы все равно мне поверите. » ✨

Представьте себе следующее:

Вы доказываете, что работаете в определенной компании. ✅ Не раскрывая свой адрес электронной почты. ✅ Без сокрытия вашей личности в Web2. ✅ Полностью проверяемый в сети.

В этом сила доказательств с нулевым уровнем разглашения (zk proofs), и вам больше не нужно иметь докторскую степень в области криптографии, чтобы начать их использовать. Добро пожаловать в мир zkApps: приложений, основанных на криптографической магии, но созданных с использованием инструментов, напоминающих написание обычного кода.

Что такое ZKApp (приложение с нулевым уровнем знаний)?

ZkApp — это приложение, в котором пользователи могутдоказать свои личные данные, не раскрывая сами данные. Думайте об этом как о сгибании чеков... без предъявления кошелька.

В этих приложениях реализованы функции, о которых мы часто только мечтаем. Например, можно подтвердить личность человека, не называя его имени, или разрешить пользователям голосовать в сети, не раскрывая фактического голоса.

В экосистеме Sui ZkApps раскрывают дополнительный потенциал. Они объединяют ваши секреты вне сети с внутрисетевой логикой, используя такие инструменты, какSP1 zKVMиSoundness Layer, чтобы сделать генерацию и проверку доказательств еще более практичными, чем когда-либо.

Традиционно для написания схемы zk требовались криптографические знания и недели приложенийрт. Но ZKVM, такие как SP1, Risc0 и Nexus, перевернули игру. Эти виртуальные машины позволяют разработчикам выражать свою логику на обычных языках программирования, генерировать полученный результатzk proof**и отправлять его на проверку в блокчейне.

Эта абстракция не только ускоряет разработку, но и расширяет круг тех, кто может создавать ZKApps. Если вы умеете писать логику на Rust, вы можете создать ZkApp. А если вы используетеSoundness Layer, вы можете проверить это на Sui.

#zkDomain: подтверждение права собственности на электронную почту без раскрытия

Рассмотрим распространенный сценарий, когда DAO хочет раздать токены сотрудникам определенной компании.

Но вместо того, чтобы собирать электронные письма пользователей и проверять их вручную, что раскрывает личность Web2 и ставит под угрозу конфиденциальность пользователей, мы хотим, чтобы пользователидоказывали, что они владеют электронной почтой по адресу @soundness .xyz**, не раскрывая полный адрес.

Вот тут-то и появляется реальная магия zk.

Если у вас есть доступ к корпоративной электронной почте, использующейGoogle Workspace, вы можете пройти аутентификацию с помощьюOpenID Connect (OIDC) и получить от Googleподписанный JWT (веб-токен JSON). Этот токен содержит метаданные, включая вашу электронную почту.

Теперь вместо того, чтобы отправлять этот JWT в DAO, выгенерируете zk-доказательство, в котором говорится: «У меня есть действительный JWT, выпущенный Google, имое электронное письмо заканчивается на @soundness .xyz». Это доказательство проверено в сети. Никто так и не увидит ваш настоящий адрес электронной почты. DAO видит только то, что доказательство уже получено.

Доступ предоставлен.

Вся логика верификации, парсинг JWT, проверка подписи, проверка домена выполняются в программе zKVM, написанной на Rust и скомпилированной SP1.

Ознакомиться с полной реализацией можно здесь:

👉 Пример ZK-домена 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);
}

Только домен и действительность JWT. Вот и все. Полный адрес электронной почты пользователя, оригинальный JWT и любая другая личная информация остаются скрытыми и криптографически запечатаны в доказательстве.

##Верификация в сети: от zKVM до Move

Конечно, получение доказательств — это только одна сторона медали. Настоящая польза вступает в силу, когда вы сможете проверить это доказательство в сети и на его основе принять меры.

Именно здесь слойSoundnessменяет правила игры. Созданный для Sui, он служит слоем верификации zk, который может обрабатывать сгенерированные SP1 доказательства, преобразованные в формат Groth16, который Sui изначально поддерживает. Вам не нужно возиться с криптографическими примитивами. Вы просто пишете смарт-контракт в Move, передаете доказательство и общедоступные входные данные (например, ожидаемый домен), а логика верификатора сделает все остальное.

Это означает, что ваш смарт-контракт DAO теперь может отправлять заказы в зависимости от владения доменом электронной почты, даже не затрагивая конфиденциальные данные. Верификацию выполняет слой Soundness Layer. Ваш смарт-контракт отвечает за логику. Остальное — волшебство.

Узнайте больше о слое Soundness здесь:

🔗 soundness.xyz/блог/слой звука

Вы можете создавать потоки аутентификации без паролей. Можно разработать системы голосования, гарантирующие анонимность. Вы можете предоставлять доступ к DAO, событиям или вознаграждениям на основе полностью конфиденциальных критериев.

И самое главное, все это можно сделать с помощьюRust + Sui + SP1 + Soundness Layer, не записывая вручную ни одного криптографического ограничения.

Мы больше не говорим о теоретических задачах. Мы говорим о zk, который вы можете отправить. Потому что конфиденциальность — это не просто функция, это основа. А с помощью zk его наконец-то можно компоновать.