Loading...
यह लेख Proof Street से मिरर किया गया है, जो privacy-preserving computation पर केंद्रित एक स्वतंत्र प्रकाशन है: ZK, FHE, MPC, TEEs, और decentralized identity। मूल रूप से "गोपनीयता की तुलना: चार privacy architectures क्या वादा करती हैं" के रूप में 12 अगस्त, 2026 को प्रकाशित। लेखक की अनुमति से Zcash Community Grant #339 के हिस्से के रूप में मिरर किया गया। Stephen Webber द्वारा।
जुलाई के अंतिम दिनों में, Zama ने Ethereum mainnet पर एक confidential swap venue शुरू किया, जो सितंबर में सार्वजनिक लॉन्च से पहले private beta में था, और जो एक trader को ऐसा encrypted intent जमा करने की सुविधा देता है जिसमें amount, slippage tolerance, और trade की direction छिपी रहती है।
इसके लिए यह एक छोटी-सी संरचित प्रक्रिया पर निर्भर करता है। Trader दो confidential transfers जमा करता है, एक जिसमें वास्तविक assets होते हैं और एक विपरीत leg के लिए zero amount के साथ, ताकि कोई observer छिपे हुए आकार की द्विदिशीय movement देखे और buy तथा sell में अंतर न कर सके। Whitelisted market makers intent को decrypt करते हैं, size देखते हैं लेकिन direction नहीं, और दोनों पक्षों के quote देते हैं। एक sealed-bid auction chain पर settle होता है, और केवल winning maker को पता चलता है कि trade किस दिशा में गया। अंतिम परिणाम यह है कि public chain पर बड़े आकार का swap execute होता है, जहाँ trade के बाहर कोई भी एकल पक्ष पूरी तस्वीर कभी नहीं जोड़ पाता।
Zama इस product को end-to-end confidential बताता है, लेकिन यह confidentiality वास्तव में किस चीज़ को समेटती है? यहाँ confidentiality के लिए actions की पूरी श्रृंखला में confidentiality चाहिए, ताकि public एक चीज़ देखे, हारने वाले bidders उससे अधिक देखें, क्योंकि quote देने के लिए उन्हें trade का size decrypt करना पड़ता है, और winning bidder उससे भी अधिक देखता है। सरल शब्दों में कहें तो sequence का हर चरण ऐसा इसलिए है क्योंकि किसी ने यह तय किया कि किसे क्या और कब जानना चाहिए। अच्छा होता अगर confidentiality को "कोई कुछ नहीं देखता" कहकर समेटा जा सकता, लेकिन व्यवहार में तब कुछ भी काम नहीं करेगा। Confidentiality को संरचित होना पड़ता है, और उसे एक sequence का पालन करना पड़ता है।
दिलचस्प बात यह है कि उस launch से लगभग दस साल पहले, Zcash ने public blockchain पर पहला confidential settlement layer दिया था, जहाँ zero-knowledge proofs का उपयोग करके transaction के sender, receiver, और amount को छिपाया गया, जबकि सभी को यह सिद्ध किया गया कि transaction मान्य था। उसके बाद के दशक में, "confidential" कम से कम चार अलग-अलग technology families के लिए एक विशेषण बन चुका है: shielded transactions, fully homomorphic encryption, multi-party computation, और trusted execution environments। इन चारों families के products अब production में चल रहे हैं, जिनमें से कई एक ही chain पर हैं। तो फिर इस डिब्बे के अंदर वास्तव में क्या है?
ये चार families चार अलग-अलग समस्याओं के लिए अलग-अलग, और कभी-कभी आपस में मिलते-जुलते, उत्तर देती हैं, और चूँकि अब हर उत्तर एक product के रूप में पैक होकर आता है, असली काम यह समझना है कि आपके पास वास्तव में कौन-सी समस्या है।
किसी भी confidentiality claim को यदि उसकी बुनियादी परत तक उतार दें, तो उसे चार सवालों का जवाब देना पड़ता है। कौन-सा data छिपा है? किससे? Data के जीवन के किस चरण में? और इस guarantee के टिके रहने के लिए किन चीज़ों पर trust करना पड़ता है?
उदाहरण के लिए, swap venue को लें। उसे amount, direction, और slippage छिपाना होता है। Asset pair क्यों नहीं? Zama कहता है कि future version उसे भी छिपाएगा। किससे: public और front-running bots से पूरी तरह, quoting market makers से आंशिक रूप से, और winning maker से सबसे कम। किस चरण में: quoting और auction के दौरान, settlement पर नियोजित disclosure के साथ। और किस पर trust करना पड़ेगा: guarantee FHE पर, smart contracts पर, और threshold key-management system पर टिकी है, जिसके operators को threshold से अधिक स्तर पर मिलीभगत नहीं करनी चाहिए। litepaper के अनुसार, कोई एकल पक्ष कभी भी decryption keys तक पहुँच नहीं सकता।
यह बिना strategy broadcast किए size execute करने का एक design है। Market makers size देखते हैं क्योंकि उसके बिना वे quote की कीमत तय नहीं कर सकते। Winner direction सीखता है क्योंकि, आखिरकार, settlement के लिए इसकी आवश्यकता होती है।
यह उदाहरण दिखाता है कि जो दावा ऊपर से binary लगता है, मानो कोई चीज़ confidential है या नहीं, वह वास्तव में exclusions की एक schedule में टूट जाता है। एक जैसे सुनाई देने वाले दावों तक पहुँचने के बहुत अलग-अलग रास्ते होते हैं।
एक shielded Zcash transaction sender, receiver, और amount को छिपाता है। जो public रहता है वह proof है: एक zero-knowledge argument, जिसे कोई भी व्यक्ति जो एक नोड चला रहा है जाँच सकता है, कि छिपा हुआ transaction नियमों का पालन करता है। Shielded funds encrypted notes के रूप में मौजूद होते हैं, जिनमें से हर एक amount और उसके owner का निजी record होता है, जो chain पर केवल एक cryptographic commitment के रूप में दिखाई देता है। किसी note को spend करने पर एक nullifier प्रकाशित होता है, ऐसा value जो उसी note को दोबारा spend होने से रोकता है, बिना यह बताए कि वह कौन-सा note था। इसका मतलब है कि network double-spends को यह जाने बिना reject कर सकता है कि कौन-से funds moved हुए, इसलिए spending एक transaction को दूसरे से जोड़ने वाला कोई trail नहीं छोड़ती। Proof का काम यह स्थापित करना है कि spender note का owner था, transaction के values balance करते हैं, और कोई ZEC बनाया या नष्ट नहीं किया गया, यह सब शामिल मात्राओं का खुलासा किए बिना।
इस design की विशिष्ट विशेषता सबसे स्पष्ट तब होती है जब हम यह देखते हैं कि किन चीज़ों पर trust करना पड़ता है। कोई committee नहीं है जो shielded transaction को decrypt कर सके, कोई operator set नहीं है जिसकी collusion threshold मायने रखती हो, कोई hardware vendor नहीं है जिसकी attestation पर विश्वास करना पड़े। Trust base में जो बचता है वह है mathematics और उन circuits की correctness जो नियमों को encode करते हैं। जिन लोगों के threat model में infrastructure स्वयं शामिल है, ऐसे operators जिन्हें दबाव में लाया जा सकता है, ऐसे vendors जिन्हें compromise किया जा सकता है, उनके लिए यही छोटी सूची product है।
वास्तव में, इस trust base की production में अभी परीक्षा हुई। 29 मई को, Shielded Labs के लिए audit कर रहे security researcher Taylor Hornby ने Orchard pool के proof circuit में एक soundness flaw खोजा, जो pool के 2022 launch से मौजूद था, और जो Shielded Labs की disclosure के अनुसार Orchard के भीतर असीमित counterfeit ZEC mint करने की अनुमति दे सकता था, बिना किसी on-chain trace के।
Emergency fix पाँच दिनों में भेज दिया गया: 2 जून को Orchard pause किया गया, फिर 3 जून को corrected circuit के साथ बहाल कर दिया गया। ZODL की remediation post ने प्रभाव को Shielded Labs की तुलना में अधिक संकीर्ण रूप में पेश किया, और counterfeit supply की बजाय pool के भीतर double-spending के risk का वर्णन किया, साथ ही user privacy और total supply cap को अप्रभावित बताया।
Verifiability rebuild बाद में जारी किया गया। Ironwood, जो 28 जुलाई को NU6.3 के रूप में activate हुआ, Orchard pool को स्थायी रूप से seal करता है, corrected circuit पर एक fresh pool खोलता है, जिसे independent audits और formal verification work का समर्थन प्राप्त है, और बाहर जाने वाले सभी funds को ऐसे turnstile से गुजारता है जो withdrawals को उसी सीमा तक बाँधता है जो सत्यापन योग्य रूप से भीतर आया, जिससे हर user की यह क्षमता बहाल होती है कि वह किसी के transactions देखे बिना circulating supply को स्वतंत्र रूप से जाँच सके। यह प्रकरण trust-base ledger के व्यवहार में काम करने का उदाहरण है। जब circuit correctness विफल हुई, remedy mathematics और migration थी, किसी committee का discretion नहीं, और blast radius उस auditability से सीमित रहा जिसे इस architecture ने pool boundary पर वर्षों पहले ही निर्मित कर दिया था।
इतने न्यूनतम trust base के बदले shielding जो प्रदान करता है, वह जानबूझकर सीमित है। Hidden state एक payment है, value का एक पक्ष से दूसरे पक्ष तक जाना। ऐसा कोई shared encrypted state नहीं है जिस पर कई पक्ष मिलकर compute करें, कोई confidential contract logic नहीं, और कोई encrypted order book नहीं।
FHE ciphertext पर computation चलाने देता है। Zama के protocol में, जो version अभी Ethereum पर live है, balances और transfer amounts chain पर encrypted handles के रूप में draft ERC-7984 standard के तहत मौजूद रहते हैं, coprocessors off chain encrypted arithmetic करते हैं, और decryption के लिए independent key-management operators का quorum चाहिए होता है, mainnet launch पर तेरह organizations, जिन्हें reputation और operational stakes के आधार पर चुना गया, ताकि कोई एकल पक्ष data को पढ़ न सके। यही वह चीज़ है जो encrypted order book या confidential lending pool को संभव बनाती है: कई पक्षों का hidden state, shared contract logic के भीतर compose होता हुआ।
लेकिन key-management committee का क्या? किसी को decrypt करने में सक्षम होना ही पड़ेगा, नहीं तो data उपयोगी नहीं रहेगा। Design का उत्तर यह है कि उस "किसी" को एक single custodian की जगह independent operators का threshold बनाया जाए, और contracts में ही लिखे access control के माध्यम से यह नियंत्रित किया जाए कि कौन किन values को decrypt कर सकता है, जिसे auditors जैसी designated parties तक बढ़ाया जा सकता है, एक delegation mechanism जिसके compliance implications इस series के अगले भाग का विषय हैं। Solutions का मूल्यांकन करने वाले व्यक्ति के लिए सवाल यह है कि क्या committee की composition, incentives, और threshold उसके threat model से मेल खाते हैं।
Multi-party computation data को shares में बाँट देता है जो independent नोडों में वितरित रहते हैं, और ये नोड inputs को reconstruct किए बिना मिलकर result compute करते हैं। Soda Labs के co-founder और CEO Avishay Yanai, जिनकी garbled-circuit virtual machine COTI network पर production में encrypted values के ऊपर EVM-compatible contract logic execute करती है, production में अच्छे MPC design को इस रूप में वर्णित करते हैं कि कोई भी single party, चाहे वह observer हो, computation चलाने वाला नोड हो, या vendor, कभी plaintext inputs या intermediate state न देखे, और हर व्यक्ति केवल वही देखे जो disclosure policy उसे देखने देती है। Guarantee केवल non-collusion पर निर्भर करती है, और यह ऐसा assumption है जिसके चारों ओर engineering और contracts किए जा सकते हैं, जैसे अलग-अलग jurisdictions में, अलग-अलग clouds पर, independent audits के तहत operators, जहाँ collusion पर कानूनी exposure हो। यहाँ cryptography का काम, जैसा वे कहते हैं, trust elimination नहीं बल्कि tremendous trust reduction है, ताकि clearinghouses में institutions जो trust रखते हैं उसके समतुल्य पहुँचा जा सके। Threshold से अधिक collusion privacy तोड़ देती है, correctness नहीं, क्योंकि public auditability वाले designs में external validators computation में शामिल हुए बिना भी जाँच सकते हैं कि reported results सही हैं।
यहाँ caveat बस इतना है कि ऐसा observer फिर भी यह देखता है कि transaction हुआ, कब हुआ, किस contract के विरुद्ध हुआ, उसे किसने submit किया, साथ ही batch sizes और fees भी। एक भाग लेने वाला नोड यह सीख सकता है कि कौन-सा function चला और उसके throughput patterns क्या थे। Timing correlation भी एक विचारणीय पहलू है, क्योंकि activity levels amount न दिखाई देने पर भी leak हो सकते हैं। और जो भी application plaintext में output देती है, छोटी-छोटी बार-बार disclosures मिलकर ऐसे potential patterns बना सकती हैं जिन्हें कोई पक्ष खोज रहा हो। "यही वादे की सीमा है," वे स्पष्ट करते हैं, इसलिए evaluators को vendors से कहना चाहिए कि वे इसे साफ-साफ रेखांकित करें। कोई भी computation model उस स्थिति को ठीक नहीं करता जहाँ plaintext, उदाहरण के लिए, किसी compromised client द्वारा submit किया गया हो। Protocol उसे जो दिया जाता है, उसी पर faithfully compute करता है। कौन किससे बात करता है, यह transport problem है, और compliance mechanism नहीं बल्कि policy है: "कोई cryptography आपके लिए वह निर्णय नहीं लेती।"
Garbled-circuit designs constant rounds में चलते हैं, जहाँ भारी cryptographic material inputs के अस्तित्व में आने से पहले precompute कर लिया जाता है, और यही कारण है कि वे transaction-rate workloads को संभव बनाते हैं, जबकि secret-sharing protocols प्रति operation network round trips चुकाते हैं। और जहाँ, Yanai के अनुसार, कुछ MPC families values की रक्षा करती हैं लेकिन computation के तथ्य की नहीं, वहीं garbled-circuit designs counterparty addresses और asset types तक भी cover बढ़ा सकती हैं। फिर भी इस तुलना के लिए family की सबसे महत्वपूर्ण विशेषता यह है कि MPC स्वयं में एक architecture है, और साथ ही दूसरी families के भीतर एक ingredient भी है: FHE deployment के नीचे मौजूद threshold key committee स्वयं एक multi-party computation है। Yanai की framing में evaluator का प्रश्न है, "मेरी committee क्या करती है, और उसके ऊपर मैं क्या अतिरिक्त कीमत चुकाता हूँ?" यदि committee किसी भी स्थिति में मौजूद है, तो computation को स्वयं MPC में चलाने से एक महँगी outer layer हट सकती है।
यह स्पष्ट करना उचित होगा कि एक ही acronym के अंतर्गत दो बहुत अलग products पर चर्चा होती है। Custody MPC एक signing key को कई parties में बाँटता है ताकि उनमें से कोई भी अकेले sign न कर सके; यह एक secret की रक्षा करता है, और इसमें शामिल joint computation एक single fixed operation होती है, जो एक signature उत्पन्न करती है। Compute MPC उस data पर general program logic चलाता है जो पूरे समय hidden रहता है, और इसमें कई parties के inputs, arbitrary contract logic, और continuous operation शामिल होते हैं। दोनों में समानता mathematics की है। लेकिन operational दृष्टि से, एक key management के लिए उपयोग होता है और दूसरा confidential execution environment होता है।
TEE processor का एक hardware-isolated region होता है जो memory में data को encrypted और operating system, hypervisor, तथा machine के operator से shielded रखता है, और remote attestation किसी बाहरी पक्ष को यह verify करने देती है कि अंदर कौन-सा code चल रहा है। यह design उन दो चीज़ों को प्रदान करता है जिनके लिए cryptographic families बहुत महँगी कीमत चुकाती हैं: generality और speed। एक enclave साधारण programs को लगभग साधारण cost पर चला सकता है, और यही कारण है कि major clouds की अधिकांश confidential-compute offerings तथा chain infrastructure का बढ़ता हुआ हिस्सा TEEs पर आधारित है।
Trust base ही यहाँ सौदा है, क्योंकि guarantee उतनी ही मजबूत है जितनी hardware vendor की design और supply chain, attestation infrastructure, और side-channel extraction के प्रति enclave की resistance, जो हमलों का एक ऐसा वर्ग है जिसका लंबा प्रकाशित इतिहास है। TEE designers इस ledger को अपने आलोचकों से बेहतर जानते हैं। इस architecture को चुनने का अर्थ है यह सोच-समझकर दांव लगाना कि hardware trust plus attestation ही real speed पर real workloads चलाने की सही कीमत है, और कई deployments के लिए ऐसा है।
क्या shielded Zcash confidential trading venue वाले use case को serve कर सकता है? नहीं, लेकिन यह कोई कमी नहीं है। एक RFQ venue contract logic के अधीन shared encrypted state है, जहाँ कई parties के hidden intents ऐसे auction के भीतर compose होते हैं जो स्वयं blind चलती है। यह MPC जैसी किसी चीज़ के लिए अधिक उपयुक्त है, जहाँ shared private state frequent interaction के अधीन होती है, जैसे order book, netting cycle। Shielding के पास इसके लिए कोई substrate नहीं है; उसका hidden state दो parties के बीच payment है। Venue स्वयं FHE या MPC के लिए उपयुक्त है, और यह ध्यान देने योग्य है कि जब Zama ने इसे बनाया, तो उसकी दी गई confidentiality whitelisted, identified market makers के लिए disclosures की एक schedule है, जो institutional trading के लिए आवश्यक है। लेकिन यह उस product से अलग है जो एक shielded transaction प्रदान करती है, जो whitelist के बिना और ऐसे किसी पक्ष के बिना confidentiality देती है जो अंततः आपकी direction जान ले।
Corporate payments और payroll का क्या? यह वह market है जिसे अब हर FHE और MPC vendor target कर रहा है, और यह ठीक वही समस्या है जिसके लिए shielding बनाया गया था: amounts hidden, counterparties hidden, validity public। सिद्धांततः एक shielded chain सबसे मजबूत-trust-base वाला उपलब्ध उत्तर है, कोई committee नहीं, कोई vendor नहीं, कोई operator set नहीं। व्यवहार में corporate-payments market rails, ERC-20 integration, existing custodians, existing compliance tooling, stablecoin denominations पर जीता जा रहा है, और shielded Zcash एक अलग chain पर एक अलग asset प्रदान करता है। लेकिन problem shape के स्तर पर यह एक मजबूत fit है और बस integration की प्रतीक्षा कर रहा है। Cryptography यह कर सकती है, इसलिए व्यावहारिक चिंताएँ इस बात से जुड़ी हैं कि आसपास का stack किन चीज़ों से connect होता है।
यह भी देखने लायक है कि बाकी तीन families क्या offer करती हैं, और shielding क्या नहीं करती: ऐसा पक्ष जिस पर दबाव डाला जा सके। एक threshold committee को court order मिल सकता है, एक enclave vendor को उसकी signing keys के लिए subpoena किया जा सकता है, और एक operator set किसी jurisdiction के अंतर्गत होता है। जिसे compliance path चाहिए, ऐसी institution committee को ही product मान सकती है। दूसरी ओर से देखें तो वही vulnerability भी है।
यदि हम ऊपर देखे गए मामलों को फिर से देखें, तो हमें एक-दूसरे पर चढ़ी हुई तस्वीर दिखाई देती है। अधिकांश FHE deployments के नीचे decryption layer के रूप में threshold MPC होता है। Zero-knowledge proofs encrypted inputs को FHE द्वारा consume किए जाने से पहले certify करते हैं, और garbled-circuit systems में उन्हें बाद में certify भी कर सकते हैं, जिससे users को ऐसा forced exit मिलता है जो network की availability पर निर्भर नहीं करता, यह practice rollup architectures से ली गई है। MPC नोडों के भीतर TEEs defense in depth के रूप में दिखाई देते हैं, Zama के key-management नोड hardware enclaves के भीतर computation का अपना share चलाते हैं, और TEEs तेजी से उन systems के provers और builders को host कर रहे हैं जिनकी अंतिम guarantees cryptographic हैं। पाँच साल बाद लिखी गई तुलना में शायद इन सीमाओं को पहचानना कठिन हो। लेकिन composition केवल एक दिशा में चलती है।
इसीलिए evaluator के प्रश्न का स्थायी रूप "कौन-सी technology" के बारे में है ही नहीं। देखने वाली चीज़ यह है कि confidentiality को किस तरह sequence किया गया है, क्या exclude किया गया है, और exclusion को कौन enforce करता है, चाहे वह mathematics और circuit correctness हो, किसी committee की non-collusion, honest नोडों का threshold, या किसी vendor का silicon। किसी भी confidentiality claim को इस तरह पढ़िए: क्या छिपा है, किससे, कब तक, और किसके भरोसे, तब आपको पता चल जाएगा।
Disclosure: इस लेख को एक Zcash Community Grant का समर्थन प्राप्त था। प्रकाशन से पहले ZCG ने इस लेख की समीक्षा या स्वीकृति नहीं दी। Proof Street की funding commitments funding page पर सूचीबद्ध हैं।
संबंधित पेज: Shielded Pools (Using_Zcash) · Viewing Keys · Start_Here में "कौन क्या देख सकता है" पेज — सटीक wiki paths से बदलें