प्रोग्रामेबल प्राइवेसी: Aztec और Garbled Circuits

प्राइواसी आर्किटेक्चर का विकास: मिक्सेर से प्रोग्रामेबल प्रोटोकॉल तक

Tornado Cash या Sinbad जैसे क्लासिक मिक्सर रेगुलेटर्स के दबाव, OFAC (विदेशी संपत्ति नियंत्रण कार्यालय) के प्रतिबंधों और ह्यूरिस्टिक क्लस्टर ट्रैकिंग के जरिए ट्रांजैक्शन ग्राफ एनालिसिस के चलते अब आउटडेटेड हो रहे हैं। लिक्विडिटी पूल के स्तर पर नेटिव एनॉनिमीडेशन को लीडिंग प्रोवाइडर्स (Infura, Alchemy) के RPC नोड्स में इंटीग्रेटेड हाई-रिस्क एड्रेस लिस्ट्स (Chainalysis, Elliptic) के माध्यम से स्मार्ट कॉन्ट्रैक्ट लेयर पर ब्लॉक किया जा रहा है।

इंडस्ट्री प्रोग्रामेबल प्राइवेसी (Programmable Privacy) के कॉन्सेप्ट की तरफ शिफ्ट हो रही है। पूल में डिपॉजिट्स को धुंधला करके ट्रांजैक्शन के फैक्ट को छिपाने के बजाय, नए प्रोटोकॉल-लेवल सॉल्यूशंस एन्क्रिप्टेड डेटा पर मनचाहा बिजनेस लॉजिक और स्मार्ट कॉन्ट्रैक्ट्स एग्जीक्यूट करने की अनुमति देते हैं। इस बदलाव में लीड करने वाली zk-rollup आर्किटेक्चर वाली नेटवर्क हैं जो Programmable Privacy को सपोर्ट करती हैं, जैसे Aztec (Noir), और COTI 2.0 जैसी स्पेशलाइज्ड कॉन्फिडेंशियल L1 नेटवर्क, जो अगली जनरेशन के हार्डवेयर और क्रिप्टोग्राफिक प्रिमिटिव्स का उपयोग करती हैं।

ब्लॉकचेन में गार्बल्ड सर्किट (Garbled Circuits)

COTI 2.0 जैसी प्लेटफॉर्म्स के कोर में क्लासिक क्रिप्टोग्राफिक प्रिमिटिव याओ का प्रोटोकॉल (Yao's Garbled Circuits) है, जिसे डिसेंट्रलाइज्ड ब्लॉकचेन एनवायरनमेंट के अनुसार अडॉप्ट किया गया है। zk-SNARKs के विपरीत, जो डेटा को उजागर किए बिना किसी स्टेटमेंट की वैलिडिटी साबित करते हैं, Garbled Circuits दो या दो से अधिक अनट्रस्टेड पक्षों को कॉन्फिडेंशियल इनपुट्स पर एक मनमाना बुलियन फ़ंक्शन कैलकुलेट करने की अनुमति देते हैं ताकि कोई भी पक्ष दूसरे का डेटा न देख सके।

गार्बल्ड सर्किट की मैकेनिक्स

• 1. बुलियन सर्किट के रूप में लॉजिक का रिप्रेजेंटेशन: कोई भी कैलकुलेशन (टोकन ट्रांसफर, बैलेंस चेक, क्रेडिट स्कोरिंग) एक डायरेक्टेड एसाइक्लिक ग्राफ में कंपाइल होती है, जो लॉजिक गेट्स (AND, XOR, NOT) से मिलकर बनता है।
• 2. गार्बलिंग (Garbling): सर्किट क्रिएटर (गार्बलर) प्रत्येक गेट के हर इनपुट और आउटपुट के लिए रैंडम 128-बिट कीज़ जनरेट करता है। गेट्स की ट्रूथ टेबल को रैंडम ऑर्डर में इन कीज़ से एन्क्रिप्ट किया जाता है।
• 3. ओब्लिवियस ट्रांसफर (Oblivious Transfer, OT): सर्किट इवेल्यूएटर (इवेल्यूएटर) OT क्रिप्टोग्राफिक प्रोटोकॉल के जरिए गार्बलर से अपने इनपुट कीज़ प्राप्त करता है। इवेल्यूएटर को केवल अपने वास्तविक इनपुट के लिए कीज़ मिलती हैं बिना उन्हें गार्बलर को उजागर किए, और उसे बाकी कीज़ का एक्सेस नहीं मिलता।
• 4. एलिमेंट-बाय-एlement कैलकुलेशन: इवेल्यूएटर सर्किट में नीचे से ऊपर की ओर एन्क्रिप्टेड ट्रूथ टेबल्स को डिक्रिप्ट करता है, और इंटरमीडिएट वेरिएबल वैल्यूज को जाने बिना रिजल्ट कैलकुलेट कर लेता है।

ब्लॉकचेन के लिए इंजीनियरिंग ऑप्टिमाइजेशन

रॉ Garbled Circuits के लिए भारी मात्रा में नेटवर्क कम्युनिकेशन की आवश्यकता होती है। ब्लॉकचेन एनवायरनमेंट में इंटीग्रेट करने के लिए डेवलपर्स दो मुख्य ऑप्टिमाइजेशन का उपयोग करते हैं:

• Free-XOR तकनीक: एन्क्रिप्शन और डेटा ट्रांसमिशन के बिना XOR गेट्स को एग्जीक्यूट करने की अनुमति देती है, जिससे मेमोरी लोड और बस बैंडविड्थ कई गुना कम हो जाती है।
• Point-and-permute: बिट-मास्किंग मेथड, जो इवेल्यूएटर को सभी डिक्रिप्शन ऑप्शंस को ब्रूट-फोर्स किए बिना एन्क्रिप्टेड ट्रूथ टेबल में सही पंक्ति को तुरंत खोजने की अनुमति देती है।

कॉन्फिडेंशियलिटी क्रिप्टोग्राफिक स्टैक्स की तुलना

डेटा-प्रोटेक्टेड डिसेंट्रलाइज्ड एप्लीकेशंस को डिज़ाइन करते समय सही टेक स्टैक चुनने के लिए मॉडर्न प्रोटोकॉल्स के प्रमुख मेट्रिक्स का मिलान किया जाता है।

प्रैक्टिस: सेलेक्टिव डिस्क्लोजर (Selective Disclosure) और स्टेबलकॉइन्स

मॉडर्न कंप्लायंस की मांग है कि "पूर्ण अंधकार" (absolute shadow) की अवधारणा से हटकर सेलेक्टिव डिस्क्लोजर (Selective Disclosure) के सिद्धांत को अपनाया जाए। यूजर के पास अपने कैपिटल हिस्ट्री का पूरा कंट्रोल रहता है, लेकिन जरूरत पड़ने पर वह वॉलेट का पूरा बैलेंस और दूसरे एड्रेस के साथ संबंधों का पूरा मैट्रिक्स उजागर किए बिना किसी काउंटरपार्टी, रेगुलेटर या टैक्स अथॉरिटी को फंड्स की लीगल होने का प्रमाण दे सकता है।

Aztec आर्किटेक्चर में इसे अलग-अलग कीज़ के सिस्टम और Private Execution Environment (PXE) में क्लाइंट-साइड एग्जीक्यूशन के जरिए लागू किया जाता है।

Aztec में की आर्किटेक्चर

हर यूजर अकाउंट स्मार्ट कॉन्ट्रैक्ट से जुड़ी कीज़ के एक डिटरमिनिस्टिक सेट को मैनेज करता है:

• Nullifier Keys ($nhk$): इनका उपयोग इस बात की जानकारी लीक किए बिना फंड खर्च करने के प्रूफ (nullifier) जनरेट करने के लिए किया जाता है कि कौन सा बैलेंस या नोट (note) खर्च किया जा रहा है।
• Incoming Viewing Keys ($ivsk$): विशिष्ट इनकमिंग ट्रांजैक्शन तक ऑडिट एक्सेस प्रदान करने की अनुमति देते हैं। आप किसी काउंटरपार्टी या रेगुलेटर को एन्क्रिप्टेड व्यूइंग की पास कर सकते हैं, जिससे उन्हें केवल टारगेट स्टेबलकॉइन ट्रांजैक्शन (जैसे L2-wrapped USDT/USDC) की ही विजिबिलिटी मिलती है जबकि अन्य एसेट्स छिपे रहते हैं।

इम्प्लीमेंटेशन का उदाहरण: Noir पर स्टेबलकॉइन्स का प्राइवेट ट्रांसफर

नीचे Noir भाषा (Aztec में सर्किट लिखने के लिए बेसिक DSL) में production-ready कोड का एक स्निपेट दिया गया है, जो पब्लिक लेजर पर अमाउंट पब्लिश किए बिना प्राइवेट बैलेंस वेरिफिकेशन और टोकन ट्रांसफर कमिटमेंट जनरेट करने का काम करता है।

कोड स्निपेट

// Nargo.toml में डिपेंडेंसी: poseidon = { tag = "...", git = "https://github.com/noir-lang/poseidon" }
use poseidon::poseidon::bn254::{hash_2, hash_3};
global TREE_DEPTH: u32 = 32;
struct Note {
    owner: Field,
    amount: u64,
    randomness: Field,
}
fn commit(note: Note) -> Field {
    hash_3([note.owner, note.amount as Field, note.randomness])
}
fn merkle_root(leaf: Field, index: u32, path: [Field; TREE_DEPTH]) -> Field {
    let bits: [u1; TREE_DEPTH] = (index as Field).to_le_bits();
    let mut node = leaf;
    for i in 0..TREE_DEPTH {
        node = if bits[i] == 0 {
            hash_2([node, path[i]])
        } else {
            hash_2([path[i], node])
        };
    }
    node
}
fn main(
    // पब्लिक इनपुट्स: अमाउंट और एड्रेस के बारे में कुछ नहीं
    merkle_root_pub: pub Field,
    nullifier: pub Field,
    recipient_commitment: pub Field,
    change_commitment: pub Field,
    // प्राइवेट इनपुट्स
    sender_sk: Field,
    sender_note: Note,
    path: [Field; TREE_DEPTH],
    leaf_index: u32,
    transfer_amount: u64,
    recipient_owner: Field,
    recipient_randomness: Field,
    change_randomness: Field,
) {
    // 1. नोट ओनरशिप (डोमेन टैग के साथ)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. पब्लिक रूट के संबंध में ट्री मेंबरशिप
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. फंड्स की पर्याप्तता (कमी होने पर u64 घटाना भी फेल हो जाएगा)
    assert(sender_note.amount >= transfer_amount);
    let change_amount = sender_note.amount - transfer_amount;
    // 4. Nullifier
    assert(hash_3([sender_commitment, sender_sk, 2]) == nullifier);
    // 5. दोनों नए नोट्स पब्लिक कमिटमेंट्स से बंधे हैं
    assert(commit(Note {
        owner: recipient_owner,
        amount: transfer_amount,
        randomness: recipient_randomness,
    }) == recipient_commitment);
    assert(commit(Note {
        owner: sender_note.owner,
        amount: change_amount,
        randomness: change_randomness,
    }) == change_commitment);
}

सर्किट से बाहर रहने वाली चीजें: प्राप्तकर्ता के लिए नोट्स का एन्क्रिप्शन, कॉन्ट्रैक्ट पर ट्री का स्टोरेज और अपडेट, nullifier की यूनीकनेस की जांच और ज्ञात रूट के साथ merkle_root_pub का मिलान।

डेवलपर्स के लिए इंटीग्रेशन रिकमेंडेशंस

• 1. सर्वर-साइड प्रूफ जनरेशन से बचें: थर्ड-पार्टी रिमोट API सर्वर पर ZK-proofs जनरेट करने पर कभी भरोसा न करें। पूरा कैलकुलेशन साइकिल (Aztec में PXE या क्लाइंट स्क्रिप्ट्स) यूजर के डिवाइस पर या आइसोलेटेड नोड में स्थानीय रूप से चलना चाहिए।
• 2. ऐप-साइलोड की मैनेजमेंट (App-Siloed Keys): हर डिसेंट्रलाइज्ड एप्लिकेशन के लिए आइसोलेटेड डिराइव्ड कीज़ का उपयोग करें। इससे यह सुनिश्चित होता है कि एक प्रोटोकॉल में की compromise होने पर अन्य स्मार्ट कॉन्ट्रैक्ट्स में यूजर की ट्रांजैक्शन हिस्ट्री डी-अनानिमाइज नहीं होगी।