Zcash के Shielded Pools, Unified Address और Viewing Keys की व्याख्या
जानें कि पारदर्शी pool, Sapling और Orchard में क्या अंतर है, Unified Address से wallet receiver कैसे चुनता है और viewing key कौन-सी जानकारी दिखा सकती है।
इस गाइड मेंPool ledger की स्थिति है, कोई custodian नहीं
संक्षिप्त सारांश
Zcash हर हस्तांतरण को अपने आप छिपाता नहीं है। पारदर्शी pool के पते और मूल्य प्रवाह सार्वजनिक होते हैं; Sapling और Orchard के shielded pools note विवरण को encrypt करते हैं और consensus जाँच के लिए सार्वजनिक commitments तथा nullifiers का उपयोग करते हैं। एक Unified Address में कई तरह के receiver हो सकते हैं। किसी भुगतान की गोपनीयता इस बात पर निर्भर करती है कि भेजने वाला wallet कौन-सा receiver चुनता है और मूल्य किन pools से गुजरता है।
Pool ledger की स्थिति है, कोई custodian नहीं
Zcash में pool कोई exchange या जमा रखने वाली कंपनी नहीं है, बल्कि consensus नियमों के अधीन मूल्य की स्थिति है। पारदर्शी pool सार्वजनिक UTXO का उपयोग करता है। कोई भी chain पर देख सकता है कि कौन-सा output बनाया गया, बाद में किस transaction ने उसे खर्च किया और कौन-सी राशि दिखाई देती है। पता अपने आप कानूनी पहचान नहीं बताता, लेकिन सार्वजनिक इतिहास पते के उपयोग और मूल्य के संबंध दिखाता है।
Shielded pools मूल्य को दिखाई देने वाले UTXO की जगह notes के रूप में दिखाते हैं। Network encrypted note डेटा और commitment trees दर्ज करता है और pool balance की जाँच करता है। Proofs consensus को वैधता, मूल्य संरक्षण और double-spend रोकने की जाँच करने देते हैं, जबकि सामान्य पर्यवेक्षक recipient और note राशि को transparent output की तरह नहीं पढ़ पाता। Zcash Protocol Specification दोनों प्रणालियों का वर्णन करती है।
मौजूदा Sapling और Orchard को Sprout से अलग समझें
Sapling और Orchard अलग shielded pools हैं, जिनके protocol और note-commitment trees अलग हैं; उनके balance एक ही अदल-बदल योग्य स्थिति नहीं हैं। Sprout Zcash का पहला shielded protocol था। ZIP 211 सक्रिय होने के बाद Sprout pool में नया मूल्य जोड़ना संभव नहीं है, हालाँकि पुराने Sprout transactions chain इतिहास में बने रहते हैं।
Network की स्थिति तारीख के साथ बतानी चाहिए। आधिकारिक ZIP index के अनुसार NU6.2 नवीनतम पूर्ण Mainnet upgrade है; यह 3 जून 2026 को block 3,364,600 पर सक्रिय हुआ। अस्थायी vulnerability mitigation के बाद NU6.2 ने सुधारे गए circuit नियमों के साथ Orchard actions फिर चालू किए। NU6.3 और Ironwood pool अभी draft प्रस्ताव हैं, मौजूदा Mainnet नियम नहीं। ZIP 257, ZIP index और draft ZIP 258 देखें।
Encrypted note डेटा और सार्वजनिक commitment अलग काम करते हैं
एक shielded note pool में मूल्य को प्राप्तकर्ता की खर्च करने की अनुमति से जोड़ता है। मूल्य, recipient विवरण और memo encrypt किए जाते हैं, ताकि सही receiving जानकारी वाला wallet उन्हें पढ़ सके। Chain note का plaintext नहीं, encrypted डेटा और note का commitment रखती है। Commitment सामग्री सार्वजनिक किए बिना जाँच करने देता है।
जब note खर्च होती है, transaction उससे जुड़ा nullifier प्रकट करता है। खर्च करने वाला note का ज्ञान साबित करता है और nullifier प्रकाशित करता है; network जाँचता है कि उसका पहले उपयोग नहीं हुआ। पर्यवेक्षक nullifier और commitment tree देख सकते हैं, लेकिन उन्हें यह नहीं पहचानना चाहिए कि nullifier किस पुराने commitment से जुड़ा है। इससे double spending रुकती है, जबकि सभी consensus डेटा गुप्त नहीं हो जाते। Sapling और Orchard इसी व्यापक विचार को अलग cryptography और proofs से लागू करते हैं; खर्च के लिए संबंधित निजी अधिकार चाहिए।
Unified Address कई प्रकार के receiver को जोड़ता है
Unified Address (UA) एक encoded string है जिसमें Orchard, Sapling, transparent P2SH और transparent P2PKH receiver शामिल हो सकते हैं। सक्रिय Revision 0 UA में कम से कम एक shielded receiver होना चाहिए। String जानबूझकर अपारदर्शी है, इसलिए देखकर नहीं जाना जा सकता कि उसमें कौन-से receiver हैं। ZIP 316 सक्रिय Revision 0 और प्रस्तावित Revision 2 को अलग करता है।
भेजने वाला wallet सभी receivers को भुगतान नहीं करता। Revision 0 में प्राथमिकता Orchard, फिर Sapling, transparent P2SH और अंत में transparent P2PKH की है। Sender को wallet द्वारा समर्थित सबसे ऊँची प्राथमिकता वाला receiver इस्तेमाल करना होता है। Orchard समर्थित हो तो वही चुना जाता है; Orchard न हो, लेकिन Sapling समर्थित हो, तो Sapling चुना जा सकता है। इसलिए वास्तविक pool भेजने वाले wallet की क्षमता पर निर्भर करता है, केवल दिखाए गए पते पर नहीं।
Revision 2 draft में केवल shielded पते के लिए zu और transparent receivers शामिल कर सकने वाले प्रारूप के लिए tu prefix प्रस्तावित हैं। आधिकारिक ZIP index अभी भी Revision 2 को draft बताता है; इन prefixes को सामान्य live Mainnet UA प्रारूप न मानें। भेजने से पहले wallet में पता प्रकार, network और चुना गया receiver देखें।
Pool सीमा पार करने पर मूल्य प्रवाह फिर दिख सकता है
Transparent से shielded transfer (t→z) सार्वजनिक UTXO खर्च करके Sapling या Orchard notes बना सकता है। Chain पर्यवेक्षक transparent inputs, transparent pool में बदलाव और shielded pool में जाने वाला शुद्ध मूल्य देख सकता है। वह shielded प्राप्तकर्ता पता और प्रत्येक note राशि को transparent UTXO की तरह नहीं पढ़ सकता। Shielding से pool की सीमा पर जानकारी फिर भी दिखती है।
उल्टी दिशा (z→t) में transparent output पते और राशि सार्वजनिक होते हैं और shielded pool के मूल्य में संबंधित बदलाव देखा जा सकता है। एक pool के भीतर notes बनाने वाला shielded भुगतान recipient और राशि छिपा सकता है; Sapling और Orchard के बीच transfer प्रत्येक pool के balance में बदलाव को जानकारीपूर्ण बना सकता है। केवल सार्वजनिक सीमा मूल्य किसी व्यक्ति या पुराने note की पहचान नहीं करता, लेकिन इसकी तुलना राशि, समय और बाहरी रिकॉर्ड से की जा सकती है।
इसलिए सिर्फ यह न पूछें कि पता shielded है या नहीं; यह भी देखें कि मूल्य कहाँ से आया और किन pools से गुज़रा। Exchange withdrawal, merchant भुगतान या ज्ञात समय/राशि वाला निजी transfer सार्वजनिक boundary जानकारी से मिलाया जा सकता है। इससे हर note का मालिक या अंदरूनी रास्ता अपने आप नहीं खुलता, लेकिन संभावनाएँ कम हो सकती हैं।
Viewing keys पढ़ने की अनुमति देती हैं, खर्च करने की नहीं
ZIP 316 Viewing Key को उस जानकारी के रूप में परिभाषित करता है जो किसी पते पर आए भुगतान देखने के लिए चाहिए। Full Viewing Key (FVK) उस पते से हुए भुगतान की जानकारी भी दिखा सकती है। FVK से Incoming Viewing Key (IVK) बनाई जा सकती है और IVK से पता निकाला जा सकता है। Unified Viewing Keys कई protocol की viewing-key जानकारी जोड़ती हैं।
सिर्फ viewing key से खर्च पर हस्ताक्षर नहीं किया जा सकता; उसके लिए अलग spending key या signing प्रणाली चाहिए। फिर भी viewing key सार्वजनिक जानकारी नहीं है। Key का प्रकार और wallet implementation तय करते हैं कि कौन-से transactions देखे जा सकते हैं; account-level key एक receive address से अधिक जानकारी दिखा सकती है। Auditor या सेवा के साथ साझा करने से पहले दायरा, रखने की अवधि, हटाने का विकल्प और अन्य पते से जुड़ाव समझें।
Viewing key उन संकेतों को नहीं हटाती जो पहले से सार्वजनिक हैं: transparent inputs/outputs, राशि और समय का विश्लेषण बिना key भी हो सकता है। दूसरी ओर, जिस explorer या wallet में सही सहायता नहीं है, वह ऐसी shielded transaction नहीं दिखा सकता जिसे chain ने दर्ज किया हो। “ऐप में नहीं दिख रहा” का अर्थ “chain पर मौजूद नहीं” नहीं है।
Shielded transactions हर संबंध नहीं छिपातीं
क्या दिखाई देता है यह pool और receiver प्रकार पर निर्भर करता है। पूरी तरह transparent प्रवाह में पते, राशि और UTXO संबंध दिखते हैं। Shielded भुगतान note recipients और मूल्य encrypt करता है, लेकिन commitments, nullifiers, समय और protocol डेटा chain पर बने रहते हैं। Pool boundary, wallet की pool support, ज्ञात भुगतान समय, exchange रिकॉर्ड और साझा viewing keys अलग-अलग संकेत दे सकते हैं।
Unified Address हर भुगतान को Orchard में नहीं भेजता। चुना गया receiver wallet के version, settings, implementation और transaction path पर निर्भर हो सकता है। सिर्फ पता paste करके privacy का अनुमान न लगाएँ; preview या transaction result जाँचें। [Monero privacy guide](/hi/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) अलग design बताती है, जबकि [Bitcoin address reuse guide](/hi/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) transparent ledger से तुलना करती है।
Network privacy एक अलग परत है। RPC provider, light-wallet server, exchange या payment सेवा transaction बनाने या relay करने की request देख सकती है और IP, account या समय की जानकारी chain के बाहर रख सकती है। Cryptographic proofs सेवा के logs अपने आप नहीं मिटाते। पूर्ण anonymity का दावा करने के बजाय पूछें कि metadata किसने लिया और वह उसे कैसे रखता है।
पता और transaction परिणाम साथ जाँचें
पहले पुष्टि करें कि wallet इच्छित Mainnet या Testnet से जुड़ा है। Payment review में देखें कि recipient ने Unified Address दिया है और wallet कौन-सा receiver चुनेगा। UA string से receiver प्रकार दिखाई नहीं देते, इसलिए wallet में pool, राशि, memo और fee देखें। यदि recipient shielded भुगतान चाहता है लेकिन preview transparent output दिखाता है, तो भेजने से पहले दोनों wallets की protocol support जाँचें।
मौजूदा transaction की जाँच में उसका ID और network मिलाएँ, फिर inputs और outputs में आने वाले pools देखें। Transparent पते और राशियाँ सार्वजनिक explorers में दिखती हैं; shielded note विवरण ऐसे tool में न दिखें जिसमें उसका समर्थन नहीं है। Viewing key की आवश्यकता हो तो कारण और डेटा का दायरा तय करें; spending key या viewing key किसी अपरिचित website में paste न करें। Custodial और non-custodial wallet guide signing की जिम्मेदारी भी समझाती है।
“मैंने shielded address इस्तेमाल किया, इसलिए भुगतान पूरी तरह निजी है” या “explorer मूल्य नहीं दिखाता, इसलिए transfer हुआ ही नहीं” जैसे निष्कर्ष न निकालें। Wallet history, network, transaction ID, chain status, confirmations और viewing authority अलग बातें हैं। यदि recipient को receipt की पुष्टि चाहिए, तो यह भी जाँचें कि उसका wallet संबंधित pool को support करता है और sync हो चुका है।
काल्पनिक भुगतान में receiver चयन और दिखने वाला डेटा देखें
मान लें Lee एक transparent UTXO से 1.25 ZEC उस Unified Address Revision 0 पर भेजता है जिसमें Orchard, Sapling और transparent receivers हैं। यह राशि केवल उदाहरण है; यह fee rate या wallet default नहीं बताती। Lee का wallet Orchard support करता है तो ZIP 316 की preference rule Orchard चुनती है। सार्वजनिक chain transparent input और boundary डेटा, जैसे shielded pool में जाने वाला net मूल्य, दिखाती है; लेकिन recipient का shielded note पता और राशि सामान्य सार्वजनिक output की तरह नहीं।
यदि Lee का wallet Orchard support नहीं करता लेकिन Sapling करता है, तो वह Sapling चुन सकता है। कोई भी shielded pool support न करने वाला wallet transparent receiver इस्तेमाल कर सकता है, यदि वह receiver और payment format उपलब्ध हों। Revision 0 UA में shielded receiver होना आवश्यक है, पर sender वही receiver चुनता है जिसे wallet support करे। इसलिए एक ही UA अलग-अलग wallets में अलग pools और सार्वजनिक सीमा डेटा दे सकती है।
अंत में, यदि recipient अलग से accounting सेवा के साथ viewing key साझा करता है, तो सेवा key के दायरे में आने वाली shielded गतिविधि देख सकती है। Wallet की receipt, explorer में note विवरण न दिखना और consensus के अनुसार chain पर transaction दर्ज होना तीन अलग तथ्य हैं। Unified Address कई protocol पीढ़ियों के बीच compatibility आसान करती है, लेकिन पूर्ण privacy की गारंटी नहीं देती और receiver चयन, key management या network exposure की जिम्मेदारी नहीं हटाती।
प्राथमिक protocol संदर्भ
आम सवाल
Q1क्या हर Zcash transaction में पता और राशि छिपे होते हैं?
नहीं। Transparent pool के transactions सार्वजनिक UTXO, पते और राशियाँ दिखाते हैं। Unified Address में कई receivers हो सकते हैं, इसलिए sender wallet का चयन जाँचें।
Q2यदि Unified Address में Orchard है तो क्या भुगतान हमेशा Orchard से होगा?
यदि sender wallet Orchard support करता है और उस receiver वाली Revision 0 UA को process करता है, तो ZIP 316 Orchard चुनने को कहता है। Wallet support अलग हो सकती है; preview देखें।
Q3क्या मैं Viewing Key से धन भेज सकता हूँ?
नहीं। यह अपने दायरे में transaction जानकारी पढ़ने के लिए है। खर्च के लिए अलग spending key या signing authority चाहिए; Viewing Key भी सुरक्षित रखें क्योंकि वह निजी जानकारी दिखा सकती है।
स्रोत और आगे पढ़ें
समस्या की रिपोर्ट करें
हम इस लेख का लिंक जोड़कर ईमेल तैयार करेंगे। भेजने के बाद ही Mark को आपकी रिपोर्ट मिलेगी
त्वरित जाँच
गाइड पढ़ने के बाद 3 सवालों से खुद को जाँचें
सवाल 01
Shielded note chain पर दर्ज होने पर सामान्य पर्यवेक्षक क्या देखता है?
व्याख्या देखने के लिए एक उत्तर चुनें
विकल्प शब्दावली
एक्सरसाइज नोटिस के बाद कॉन्ट्रैक्ट पूरा करने की जिम्मेदारी ऑप्शन विक्रेता को देने की प्रक्रिया, जिससे शेयर देने या खरीदने का दायित्व बन सकता है।
विस्तृत गाइड पढ़ेंबिड-आस्क स्प्रेडकिसी अनुबंध के सबसे ऊँचे बिड और सबसे निचले आस्क मूल्य का अंतर। यह स्थिति में प्रवेश और निकास की अप्रत्यक्ष लागत है और बाजार में तरलता कम होने पर फैल सकता है।
विस्तृत गाइड पढ़ें0DTEAn option that expires on the current trading day; little time remains for the thesis to work, while gamma and execution risk can change quickly.
विस्तृत गाइड पढ़ें