Loading...
श्रृंखला: Zcash from First Principles . लेख 5 . Zero-Knowledge Proofs पाठक-वर्ग: नए पाठक। हम हर पिछले लेख (finite fields, curves, commitments, Merkle trees) पर आधारित हैं, लेकिन हर विचार को ज़रूरत पड़ने पर फिर से याद दिलाया गया है। आप क्या समझकर जाएंगे: zero-knowledge proof क्या है, यह कौन-सी तीन गारंटी देता है, मनमाने कथनों को कैसे सिद्ध किया जाता है, और Zcash के Sapling और Orchard को क्या शक्ति देता है—इन सबकी सहज और सही समझ।
यह वही लेख है जिसकी ओर पूरी श्रृंखला बढ़ती रही है। लेख 0 से आगे हम बार-बार कहते रहे कि एक भुगतान का सत्यापन "एक परदे के पीछे" किया जाता है—उसकी शुद्धता सिद्ध की जाती है, बिना कुछ उजागर किए। zero-knowledge proof वही परदा है। यही वह हिस्सा है जो आखिरकार उस विरोधाभास को सुलझाता है जिससे हमने शुरुआत की थी: जनता किसी ऐसी लेन-देन को कैसे सत्यापित कर सकती है जिसे उसे देखने की अनुमति ही नहीं है?
Zcash के केंद्र में मौजूद विरोधाभास को याद करें:
ये दोनों बातें एक-दूसरे के विपरीत लगती हैं। सत्यापन के लिए मानो देखना ज़रूरी हो। गोपनीयता देखने पर रोक लगाती है। अगर आप इन दोनों को साथ नहीं ला सकते, तो आपके पास ऐसा निजी धन नहीं हो सकता जिस पर कोई भी भरोसा करे।
एक zero-knowledge proof (ZKP) इस मेल-मिलाप का साधन है। यह एक prover को एक verifier को यह विश्वास दिलाने देता है कि कोई कथन सत्य है बिना इस सत्य के अलावा कुछ भी प्रकट किए। न राशि। न पहचान। न note। बस इतना: "यहाँ सब कुछ नियमों का पालन करता है।" किसी भी औपचारिक तंत्र से पहले इसकी सहज समझ बनाते हैं।
यह साबित करना कि आपको password पता है, बिना उसे बताए। कोई वेबसाइट यह जाँच सकती है कि आपको अपना password पता है, यदि वह आपको ऐसी चीज़ अनलॉक करते देखे जिसे सिर्फ वही password अनलॉक कर सकता है—बिना स्वयं password देखे। आप knowledge सिद्ध करते हैं, disclosure नहीं।
रंग-अंधे दोस्त और दो गेंदें। आपके पास एक लाल गेंद और एक हरी गेंद है, जो आपके रंग-अंधे दोस्त को एक जैसी दिखती हैं। आप उसे यह विश्वास दिलाना चाहते हैं कि वे अलग रंगों की हैं, बिना यह बताए कि कौन-सी कौन है। वह दोनों को अपनी पीठ के पीछे छिपाता है, चाहे तो उनकी जगह बदल देता है, और फिर एक दिखाता है। आप बताते हैं कि उसने बदला या नहीं। यदि गेंदें सचमुच अलग हैं, तो आप हमेशा सही होंगे। यदि वे एक जैसी होतीं, तो आप बस अनुमान लगा रहे होते, और आधी बार ही सही होते। 20 rounds के बाद आपकी लगातार सही पहचान उसे विश्वास दिला देती है कि वे अलग हैं, फिर भी उसे कभी पता नहीं चलता कि लाल गेंद कौन-सी है। उसे एक तथ्य पर विश्वास हो जाता है, बिना कुछ और जाने। यही लघु रूप में zero knowledge है।
गुफा। एक वलयाकार गुफा है जिसके पीछे एक जादुई दरवाज़ा है, जो केवल एक गुप्त शब्द से खुलता है। आप दावा करते हैं कि आपको वह शब्द पता है। उसे बताए बिना यह साबित करने के लिए: एक verifier बाहर इंतज़ार करता है, जबकि आप भीतर जाकर बाएँ या दाएँ रास्ते में से किसी एक को यादृच्छिक रूप से चुनते हैं। फिर verifier चिल्लाकर कहता है कि वह चाहता है कि आप किस तरफ से बाहर आएँ। अगर आपको सचमुच वह शब्द पता है, तो आप हमेशा ऐसा कर सकते हैं (ज़रूरत पड़ने पर आप दरवाज़ा खोलकर दूसरी तरफ जा सकते हैं)। अगर आप bluff कर रहे हैं, तो आप केवल किस्मत से सही तरफ निकल सकते हैं—हर round में 50/50। इसे 20 बार दोहराएँ, तो bluff करने वाले के बच निकलने की संभावना दस लाख में एक से भी कम रह जाती है।
गुफा की यह कहानी चुपचाप उन तीन गारंटियों को दिखाती है जो हर zero-knowledge proof को देनी ही चाहिए।
| गारंटी | गुफा की कहानी में | Zcash में |
|---|---|---|
| Completeness | यदि आपको शब्द पता है, तो आप हमेशा सही तरफ निकलते हैं | एक वैध transaction हमेशा स्वीकार्य proof बनाता है |
| Soundness | bluff करने वाला भारी संभावना के साथ पकड़ा जाता है | एक धोखाधड़ी वाला transaction (जाली पैसा, double-spend) स्वीकार्य proof नहीं बना सकता |
| Zero-knowledge | verifier कभी गुप्त शब्द नहीं सुनता | नेटवर्क कभी राशि, addresses, या कौन-सा note है—यह नहीं सीखता |
यदि इनमें से एक भी विफल हो जाए, तो प्रणाली टूट जाती है: completeness न हो तो ईमानदार उपयोगकर्ता अस्वीकृत हो जाते हैं; soundness न हो तो जालसाज़ पैसा छापते हैं; zero-knowledge न हो तो गोपनीयता गायब हो जाती है।
गुफा केवल एक प्यारा-सा तथ्य सिद्ध करती है। Zcash को एक समृद्ध कथन सिद्ध करना होता है: "मुझे tree में एक unspent note पता है, मैं उसे खर्च करने के लिए अधिकृत हूँ, उसका nullifier सही ढंग से compute किया गया है, और मेरे inputs मेरे outputs के बराबर हैं।" हम गेंदों और गुफाओं से वहाँ तक कैसे पहुँचते हैं?
उसका पुल एक ऐसा विचार है जो इस पूरी श्रृंखला को जोड़ता है:
ऐसा कोई भी कथन जिसे आप किसी computation से जाँच सकते हैं, उसे एक arithmetic circuit के रूप में फिर से लिखा जा सकता है: finite field पर additions और multiplications का एक network (लेख 1)।
circuit को arithmetic constraints की एक सूची समझिए, जो तभी पूरी तरह संतुष्ट होती है जब कथन सत्य हो। वे निजी inputs जिनसे सब कुछ सही निकलता है—आपका note, आपकी key, Merkle path—उन्हें witness कहा जाता है।
इसीलिए हमने लेख 1 finite fields पर और लेख 3 ZK-friendly hashes पर बिताया: circuit की भाषा field arithmetic है, इसलिए कथन के भीतर होने वाली हर क्रिया (जिसमें hashing और लेख 4 की Merkle climb भी शामिल है) उसी रूप में व्यक्त करनी पड़ती है। जितनी सस्ती किसी operation को इस रूप में व्यक्त करना होगा, proof उतना छोटा और तेज़ होगा।
गुफा में कई बार आगे-पीछे संवाद की ज़रूरत थी। blockchain के लिए यह अव्यावहारिक है, जहाँ एक proof को एक बार पोस्ट करना होता है और फिर सभी को उसे हमेशा के लिए जाँचना होता है। दो सुधार यह समस्या हल करते हैं।
Non-interactive (Fiat-Shamir विचार)। किसी live verifier के यादृच्छिक challenges चिल्लाने के बजाय, prover स्वयं "यादृच्छिक challenges" अपनी अब तक की proof को hash करके बनाता है। क्योंकि एक अच्छा hash अप्रत्याशित होता है (लेख 3), prover challenges को अपने पक्ष में तैयार नहीं कर सकता। इस तरह बातचीत-भरा संवाद सिमटकर एक अकेला self-contained proof बन जाता है, जिसे कोई भी बाद में बिना किसी interaction के जाँच सकता है।
Succinct। सबसे अच्छी प्रणालियाँ proof को बहुत छोटा और verify करने में तेज़ बनाती हैं, चाहे कथन कितना भी बड़ा क्यों न हो। यही वास्तव में आश्चर्यजनक हिस्सा है।
एक Groth16 proof (वही प्रणाली जिसका उपयोग Sapling करता है) लगभग 192 bytes का होता है और milliseconds में verify हो जाता है, चाहे वह जिस कथन को सिद्ध कर रहा हो वह छोटा हो या बहुत विशाल। कुछ सौ bytes हजारों constraints वाली computation का प्रमाण दे सकते हैं।
इन दोनों को साथ रखिए और आपको वह acronym मिलता है जो आप हर जगह देखेंगे:
zk-SNARK = zero-knowledge Succinct Non-interactive ARgument of Knowledge। Zero-knowledge (कुछ उजागर नहीं करता), succinct (छोटा और तेज़), non-interactive (एक ही बार में), argument of knowledge (prover वास्तव में एक वैध witness जानता है)।
कुछ भी मुफ्त नहीं मिलता। कई SNARKs को एक बार होने वाला setup चाहिए, जो circuit के लिए public parameters तैयार करता है। setup के दौरान एक उप-उत्पाद के रूप में secret randomness बनती है, और उस secret को नष्ट करना अनिवार्य है। अगर किसी ने उसे बचाकर रख लिया, तो वह proofs forge कर सकता है—यानी पैसा गढ़ सकता है (हालाँकि महत्वपूर्ण बात यह है कि फिर भी वह privacy नहीं तोड़ सकता)।
इस बची हुई secret को toxic waste कहा जाता है। इसे सुरक्षित रूप से नष्ट करने के लिए Zcash ने जटिल multi-party ceremonies चलाईं, जिनमें कई स्वतंत्र प्रतिभागियों ने randomness जोड़ी; जब तक उनमें से एक भी अपने हिस्से को ईमानदारी से नष्ट कर दे, toxic waste को वापस पाना असंभव हो जाता है।
नई प्रणालियाँ इस आवश्यकता को पूरी तरह हटा देती हैं, और यही सबसे बड़े कारणों में से एक है कि समय के साथ Zcash ने अपनी proof system को विकसित किया।
| डिज़ाइन | Proof system | Trusted setup? | Built on |
|---|---|---|---|
| Sprout (सबसे प्रारंभिक) | प्रारंभिक zk-SNARK | हाँ | मूल ceremony |
| Sapling | Groth16 | हाँ (multi-party "Powers of Tau" + Sapling ceremony) | BLS12-381 (लेख 2) |
| Orchard (वर्तमान) | Halo 2 | No trusted setup | Pallas / Vesta (लेख 2) |
Sprout से Sapling से Orchard तक की यात्रा काफी हद तक इस कहानी की यात्रा है कि proofs कैसे छोटे, तेज़, और trusted setup से मुक्त होते गए। Halo 2, जिसका उपयोग Orchard में होता है, किसी ceremony की ज़रूरत नहीं रखता और recursion (ऐसे proofs जो दूसरे proofs को verify करते हैं) को support करने के लिए बनाया गया है। यही कारण है कि Orchard लेख 2 के Pallas/Vesta curve cycle का उपयोग करता है: हर curve इस तरह अनुकूलित है कि वह दूसरे के ऊपर लिखे proofs को verify कर सके।
यह लेख 0 से शुरू हुए सबसे बड़े चक्र को पूरा करता है। "परदे के पीछे" वाला जादू एक zk-SNARK है: यह सिद्ध करता है कि आपका transaction उन सभी नियमों को encode करने वाले arithmetic circuit को संतुष्ट करता है, जबकि "valid" नामक एक bit के अलावा कुछ भी प्रकट नहीं करता।
Zero-knowledge proofs एक गहरा क्षेत्र हैं और हमने जानबूझकर सहज स्तर पर ही रुकना चुना। हमने soundness की सटीक probability bounds, arithmetic circuit के सटीक रूप (R1CS, PLONKish, आदि), polynomials और commitments किस तरह circuit को एक छोटे proof में बदलते हैं, या Groth16 और Halo 2 की वास्तविक internal संरचना—इनमें से कुछ भी परिभाषित नहीं किया। गुफा एक interactive proof है; production systems non-interactive होते हैं और कहीं अधिक जटिल। फिर भी मूल बात नहीं बदलती: यह सिद्ध करना कि एक circuit एक secret witness द्वारा संतुष्ट होता है—पूर्ण रूप से, sound ढंग से, और बिना कुछ उजागर किए। इसके पीछे का तंत्र अपने आप में पूरी एक अलग श्रृंखला का विषय है।
| शब्द | सरल अर्थ |
|---|---|
| Zero-knowledge proof | किसी को यह विश्वास दिलाना कि कोई कथन सत्य है, बिना और कुछ बताए |
| Prover / Verifier | जो proof बनाता है / जो उसे जाँचता है |
| Completeness | सत्य कथन हमेशा स्वीकार किए जाते हैं (एक ईमानदार prover से) |
| Soundness | असत्य कथन अस्वीकार किए जाते हैं (धोखेबाज़ सिर्फ किस्मत से ही जीत सकता है) |
| Witness | वे secret inputs जो कथन को सत्य बनाते हैं |
| Arithmetic circuit | एक कथन जिसे finite field पर additions और multiplications के रूप में फिर से लिखा गया हो |
| Non-interactive (Fiat-Shamir) | ऐसा one-shot proof जिसे किसी live back-and-forth की ज़रूरत न हो |
| Succinct | proof बहुत छोटा हो और कथन के आकार की परवाह किए बिना verify करने में तेज़ हो |
| zk-SNARK | Zero-knowledge Succinct Non-interactive ARgument of Knowledge |
| Trusted setup / toxic waste | parameters की one-time generation, जिसकी बची हुई secret को नष्ट करना ज़रूरी है |
अगर proof कुछ भी प्रकट नहीं करता, तो उसे जाँचने का कोई अर्थ कैसे हुआ? क्योंकि गणित को इस तरह व्यवस्थित किया जाता है कि सिर्फ एक वास्तविक, वैध witness ही passing proof बना सकता है। जाँच पास कर लेना स्वयं प्रमाण है; किसी disclosure की ज़रूरत नहीं।
क्या कोई नकली proof बना सकता है? Soundness इसे व्यवहारिक रूप से असंभव बनाती है। एकमात्र अपवाद वह SNARK है जिसकी trusted-setup toxic waste बचाकर रख ली गई हो; इसी कारण उसे नष्ट करने वाली ceremonies इतनी महत्वपूर्ण हैं।
क्या टूटा हुआ trusted setup मेरा निजी data लीक कर देता है? नहीं। इससे कोई हमलावर नया पैसा forge कर सकता है, लेकिन यह राशि, addresses, या notes प्रकट नहीं करता। Privacy और soundness अलग-अलग गारंटियाँ हैं।
समय के साथ Zcash ने proof systems क्यों बदलीं? ताकि proofs छोटे और तेज़ हों, और Halo 2 के साथ trusted setup को पूरी तरह हटाया जा सके तथा recursion को सक्षम किया जा सके।
गुफा वाली कहानी में यह क्यों आवश्यक है कि verifier बाहर निकलने वाली side तब चुने जब prover पहले ही अंदर जा चुका हो, बजाय इसके कि वह उसे पहले से बता दे? (उत्तर नीचे है।)
अगर verifier पहले ही side बता दे, तो bluff करने वाला व्यक्ति जिसे शब्द नहीं पता, शुरुआत से उसी तरफ चला जाएगा और फिर बस वापस बाहर आ जाएगा; उसे कभी दरवाज़े की ज़रूरत ही नहीं पड़ेगी। लेकिन जब prover किसी रास्ते पर commit कर चुका हो और उसके बाद challenge दिया जाए, तो bluff करने वाले को किस्मत पर निर्भर होना पड़ता है (हर round में 50/50)। यही repeated rounds को विश्वसनीय बनाता है। "पहले commit करो, फिर challenge लो" यही क्रम Fiat-Shamir भी बनाए रखता है, क्योंकि उसमें challenge prover की पहले से committed proof के hash से निकाला जाता है।
लेख 6 . shielded protocol, शुरू से अंत तक: समापन। हम notes, commitments, note commitment tree, nullifiers, value balance, और zero-knowledge proof—इन सभी हिस्सों को लेकर एक पूर्ण Zcash shielded transaction तैयार करेंगे, और लेख 0 में खोले गए हर चक्र को बंद करेंगे।
यह Zcash from First Principles श्रृंखला का हिस्सा है, ZecHub के लिए। Licensed CC BY-SA 4.0.