शील्डेड कोल्ड साइनिंग
मुख्य विचार: कंपैनियन वॉलेट शील्डेड ट्रांज़ैक्शन बनाने और उसकी निगरानी करने के लिए आवश्यक सब कुछ देखता है। केवल हार्डवेयर वॉलेट के पास खर्च को अधिकृत करने का अधिकार होता है। यही विभाजन शील्डेड कोल्ड साइनिंग का पूरा उद्देश्य है।
Zcash में शील्डिंग में फंड को एक सार्वजनिक, पारदर्शी पते से एक निजी, शील्डेड पते पर ले जाना शामिल है, जिससे Zcash की गोपनीयता सुविधाओं का उपयोग करके ट्रांज़ैक्शन विवरण छिप जाते हैं।
जब आप ZEC को शील्ड करते हैं तो क्या बदलता है?
पारदर्शी Zcash ट्रांज़ैक्शन में, निम्न जैसी जानकारी:
- प्रेषक का पता
- प्राप्तकर्ता का पता
- हस्तांतरित राशि
blockchain पर देखी जा सकती है।
जब आप ZEC को शील्ड करते हैं, तो आपके फंड एक निजी पूल (जैसे Ironwood) में चले जाते हैं। blockchain आपके निजी ट्रांज़ैक्शन विवरण उजागर किए बिना सत्यापित कर सकती है कि कोई ट्रांज़ैक्शन वैध है। 28 जुलाई 2026 को NU6.3 अपग्रेड के बाद से, नए शील्ड किए गए फंड Ironwood पूल में जाते हैं, क्योंकि पुराना Orchard पूल अब नई जमा राशियाँ स्वीकार नहीं करता, लेकिन निकासी की अनुमति अभी भी देता है।
शील्डेड ट्रांज़ैक्शन के घटक
1. नोट (शील्डेड बैलेंस रिकॉर्ड)
नोट किसी उपयोगकर्ता के स्वामित्व वाली अप्रयुक्त ZEC राशि का एक निजी, क्रिप्टोग्राफ़िक रिकॉर्ड है।
सार्वजनिक blockchain के विपरीत, जहाँ बैलेंस स्पष्ट पाठ में सूचीबद्ध होते हैं, एक शील्डेड नोट मूल्य और स्वामित्व विवरण को एन्क्रिप्ट करता है ताकि ऑन-चेन पर्यवेक्षक यह न देख सकें कि फंड का मालिक कौन है।
ट्रांज़ैक्शन शुरू करते समय, कंपैनियन वॉलेट लेजर को स्कैन करता है, उपयोगकर्ता के अप्रयुक्त नोटों की पहचान करता है, और चुनता है कि कौन से नोट खर्च किए जाएँ।
2. नलिफ़ायर (डबल-स्पेंड पहचान तंत्र)
चूँकि नोट का विवरण सार्वजनिक लेजर से छिपा होता है, नेटवर्क को यह बताए बिना डबल-स्पेंडिंग पहचानने के लिए एक तंत्र चाहिए कि कौन सा नोट खर्च किया जा रहा है।
नलिफ़ायर एक विशिष्ट नोट से प्राप्त अद्वितीय क्रिप्टोग्राफ़िक चिह्न है। जब कोई नोट खर्च किया जाता है, उसका नलिफ़ायर blockchain पर प्रकाशित किया जाता है।
नेटवर्क सत्यापित करता है कि नलिफ़ायर पहले दर्ज नहीं किया गया है। यदि दर्ज नहीं किया गया है, तो खर्च स्वीकार किया जा सकता है। महत्वपूर्ण रूप से, कोई बाहरी पर्यवेक्षक नलिफ़ायर का उपयोग करके यह निर्धारित नहीं कर सकता कि वह किस विशिष्ट नोट से आया है।
कंपैनियन वॉलेट ट्रांज़ैक्शन डेटा को संयोजित करने के हिस्से के रूप में उपयुक्त नलिफ़ायर प्राप्त करता और निर्मित करता है।
कुंजियाँ
कुंजियाँ सूचना के क्रिप्टोग्राफ़िक भाग हैं जो आपके फंड तक पहुँच को नियंत्रित करते हैं और आपके वॉलेट को ZEC प्राप्त करने, देखने और खर्च करने जैसे कार्य करने देती हैं।
एक वॉलेट में कई अलग-अलग कुंजियाँ होती हैं, जिनमें से प्रत्येक का अलग उद्देश्य होता है, ठीक वैसे ही जैसे एक खाते में रीड एक्सेस और राइट एक्सेस के लिए अलग-अलग क्रेडेंशियल हो सकते हैं।
कंपैनियन वॉलेट और हार्डवेयर वॉलेट के संबंध में कुंजियाँ केंद्रीय हैं, क्योंकि अलग-अलग कुंजियाँ अलग-अलग उद्देश्य पूरे करती हैं और उनमें से केवल एक को सुरक्षित रूप से बंद रखे जाने की आवश्यकता होती है।
यह जानना महत्वपूर्ण है कि प्रत्येक शील्डेड पूल अपनी कुंजियाँ एक डेरिवेशन ट्री के रूप में बनाता है, जहाँ तीर किसी घटक से उस चीज़ की ओर संकेत करते हैं जो उससे प्राप्त की जा सकती है। जो उपयोगकर्ता शील्डेड भुगतान प्राप्त करना चाहते हैं, उनके पास एक शील्डेड भुगतान पता होना चाहिए, जो स्पेंडिंग कुंजी से उत्पन्न होता है।
कुंजी पदानुक्रम
1. स्पेंडिंग कुंजी
यह सुरक्षा की दृष्टि से सबसे संवेदनशील कुंजी है। यह ZEC खर्च को अधिकृत करने की क्रिप्टोग्राफ़िक क्षमता देती है।
जब भी इस रिपोर्ट में अन्यत्र "हार्डवेयर वॉलेट के पास कुंजी होती है" कहा जाता है, तो इसी कुंजी का उल्लेख होता है।
कोल्ड साइनिंग आर्किटेक्चर में, स्पेंडिंग कुंजी हार्डवेयर वॉलेट के भीतर रखी जाती है और कभी भी कंपैनियन वॉलेट के सामने उजागर नहीं होती। कंपैनियन वॉलेट को इस कुंजी का स्वामित्व बिल्कुल नहीं रखना चाहिए।
Sapling और Orchard दोनों में, कुंजी पदानुक्रम रूट स्पेंडिंग कुंजी से स्पेंड अधिकार और देखने की क्षमताएँ दो अलग शाखाओं के रूप में प्राप्त करते हैं:
- Sapling: एक विस्तारित स्पेंडिंग कुंजी (𝑎𝑠𝑘,𝑛𝑠𝑘,𝑜𝑣𝑘) प्रूफ-अथॉराइज़िंग कुंजियाँ (𝑎𝑘,𝑛𝑠𝑘) और पूर्ण व्यूइंग कुंजियाँ (𝑎𝑘,𝑛𝑘,𝑜𝑣𝑘) प्राप्त करती है, जिनसे आगे इनकमिंग व्यूइंग कुंजियाँ (𝑖𝑣𝑘) और विविधीकृत पते मिलते हैं।
- Orchard: एक रूट स्पेंडिंग कुंजी (𝑠𝑘) सीधे स्पेंड-अथॉराइज़िंग कुंजी (𝑎𝑠𝑘) और पूर्ण व्यूइंग कुंजी (𝑎𝑘,𝑛𝑘,𝑟𝑖𝑣𝑘) में विभाजित होती है।
यह संरचनात्मक विभाजन हार्डवेयर कुंजी आइसोलेशन के लिए औपचारिक क्रिप्टोग्राफ़िक आधार प्रदान करता है, जिसमें वॉलेट बैलेंस सिंक्रोनाइज़ेशन और ट्रांज़ैक्शन निर्माण के लिए व्यूइंग शाखा (UFVK) को होस्ट कंप्यूटर पर निर्यात करता है, जबकि स्पेंड-अथॉराइज़िंग शाखा को डिवाइस पर स्थायी रूप से लॉक रखता है।
कुंजी डेरिवेशन सख्ती से एकदिशीय है। इसका अर्थ है कि व्यूइंग कुंजियों को उलटकर स्पेंडिंग अधिकार का पुनर्निर्माण नहीं किया जा सकता। यह क्रिप्टोग्राफ़िक अपरिवर्तनीयता Unified Full Viewing Key (UFVK) को निर्यात करना सुरक्षित बनाती है क्योंकि यह डिवाइस पर मौजूद स्पेंडिंग रहस्यों को उजागर किए बिना संपूर्ण वॉलेट दृश्यता प्रदान करती है।
2. व्यूइंग कुंजियाँ
Zcash शील्डेड गतिविधि देखने की क्षमता को उसे खर्च करने की क्षमता से अलग करता है। व्यूइंग कुंजी किसी वॉलेट या अन्य अधिकृत पक्ष को खर्च करने का अधिकार दिए बिना शील्डेड ट्रांज़ैक्शन की जानकारी देखने देती है।
- Full Viewing Key (FVK), जिसे Unified Full Viewing Key (UFVK) के रूप में रैप किया गया है: स्पेंडिंग कुंजी से जानबूझकर प्राप्त की गई, यह सॉफ़्टवेयर को वॉलेट की शील्डेड गतिविधि पहचानने और डिक्रिप्ट करने देती है, जिससे ट्रांज़ैक्शन की पहचान होती है। यह उसे खर्च को अधिकृत किए बिना बैलेंस की गणना करने भी देती है। इसे सीड की कमजोर प्रति के बजाय स्पेंडिंग कुंजी का कम निजी डेरिवेटिव कहना अधिक उचित है।
Full Viewing Key (FVK) सख्त सुरक्षा विभाजन बनाए रखते हुए पूर्ण रीड-ओनली दृश्यता प्रदान करती है। इनकमिंग और आउटगोइंग दोनों नोट साइफरटेक्स्ट को डिक्रिप्ट करके (अपने आउटगोइंग-व्यूइंग-की घटक के माध्यम से), केवल-FVK वाला कंपैनियन वॉलेट केवल चलता हुआ बैलेंस नहीं, बल्कि पूर्ण, लेबल किया हुआ ट्रांज़ैक्शन इतिहास प्रस्तुत कर सकता है।
कई अनलिंकेबल विविधीकृत भुगतान पते समान FVK और इनकमिंग व्यूइंग कुंजी (IVK) साझा करते हैं, जिससे blockchain स्कैनिंग ओवरहेड बढ़ाए बिना असीमित पते उत्पन्न किए जा सकते हैं।
यह कार्यात्मक विभाजन कोल्ड साइनिंग वर्कफ़्लो की नींव बनाता है। निरंतर चेन स्कैनिंग, इतिहास ट्रैकिंग और पता प्रबंधन सभी होस्ट सॉफ़्टवेयर को सौंपे जाते हैं, जबकि स्पेंड अधिकार हार्डवेयर डिवाइस पर पृथक रहता है।
महत्वपूर्ण अंतर: UFVK बनाम स्पेंडिंग कुंजी
UFVK साझा किया जा सकता है। स्पेंडिंग कुंजी को हार्डवेयर वॉलेट पर ही रहना चाहिए।
कंपैनियन वॉलेट वॉलेट की निगरानी करने, आने वाले फंड पहचानने, नोटों की पहचान करने और ट्रांज़ैक्शन तैयार करने में सहायता के लिए व्यूइंग कुंजी का उपयोग करता है। इसके पास खर्च को अधिकृत करने के लिए आवश्यक निजी कुंजी नहीं होती।
जैसा कि पहले कहा गया है, कुंजियों का विभाजन कोल्ड साइनिंग आर्किटेक्चर की नींव है।
कंपैनियन वॉलेट फंड पर कभी नियंत्रण रखे बिना ट्रांज़ैक्शन तैयार करने के लिए आवश्यक अधिकांश काम कर सकता है। हार्डवेयर वॉलेट को केवल तैयार ट्रांज़ैक्शन प्राप्त करना और अंतिम साइनिंग ऑपरेशन करना होता है।
हार्डवेयर वॉलेट निर्माताओं को यह विभाजन स्वयं आविष्कार करने की आवश्यकता नहीं है। Zcash की कुंजी डिज़ाइन पहले से ही प्रोटोकॉल स्तर पर व्यूइंग क्षमताओं को स्पेंडिंग अधिकार से अलग करती है, और निर्माता बस उस मौजूदा संरचना के ऊपर अपने साइनिंग और निर्यात कार्य बनाते हैं। प्रोटोकॉल स्पेंडिंग कुंजी से शील्डेड पते या पूर्ण व्यूइंग कुंजी जैसी जानकारी प्राप्त करने की अनुमति देता है, जबकि स्पेंडिंग कुंजी स्वयं निजी रहती है। इससे Ledger, Keystone और Hito जैसे हार्डवेयर वॉलेट कंपैनियन सॉफ़्टवेयर को आवश्यक व्यूइंग जानकारी दे सकते हैं, बिना उस निजी कुंजी को कभी उजागर किए जो फंड खर्च कर सकती है।
कंपैनियन वॉलेट वास्तव में कुंजी जानकारी के साथ क्या करता है
व्यूइंग कुंजी सामग्री का उपयोग करके, कंपैनियन वॉलेट:
- आपके फंड और नोटों की पहचान कर सकता है
- निर्धारित कर सकता है कि कौन से नोट खर्च किए जा सकते हैं
- प्रासंगिक पते प्राप्त या पहचान सकता है
- ट्रांज़ैक्शन निर्मित कर सकता है
- आवश्यक प्रूफ उत्पन्न या समन्वित कर सकता है
- ट्रांज़ैक्शन को साइनिंग के लिए तैयार कर सकता है
यह जानना महत्वपूर्ण है कि ट्रांज़ैक्शन बनाने की आवश्यकता होना निजी स्पेंडिंग कुंजी की आवश्यकता होने के समान नहीं है। यही डी-कपलिंग हार्डवेयर वॉलेट एकीकरण के पीछे के मूल सुरक्षा विचारों में से एक है।
शील्डेड ट्रांज़ैक्शन निर्माण और प्राधिकरण
ये ट्रांज़ैक्शन बनाने और अधिकृत करने में शामिल प्रक्रियाएँ हैं। सरल शब्दों में, ये प्रक्रियाएँ वही हैं जो वॉलेट धन भेजने के लिए उस डेटा के साथ वास्तव में करता है:
ट्रांज़ैक्शन निर्माण (शील्डेड ट्रांज़ैक्शन को संयोजित करना)
ट्रांज़ैक्शन निर्माण उपयोगकर्ता के इच्छित भुगतान से वैध Zcash ट्रांज़ैक्शन बनाने के लिए आवश्यक जानकारी को संयोजित करने की प्रक्रिया है।
ट्रांज़ैक्शन निर्माण प्रक्रिया चयनित नोटों, प्राप्तकर्ताओं, राशियों, शुल्कों, नलिफ़ायरों और अन्य आवश्यक ट्रांज़ैक्शन डेटा को एक ट्रांज़ैक्शन संरचना में मिलाती है। शील्डेड ट्रांज़ैक्शन के लिए, यह आवश्यक ज़ीरो नॉलेज प्रूफ और हस्ताक्षरों के निर्माण के लिए आवश्यक जानकारी भी तैयार करती है।
कंपैनियन वॉलेट सामान्यतः यह चरण करता है। यह
- खर्च करने के लिए नोट चुनता है
- ट्रांज़ैक्शन के इनपुट और आउटपुट निर्धारित करता है
- आवश्यक मानों की गणना करता है
- उस ट्रांज़ैक्शन डेटा को तैयार करता है जिसे बाद में प्रूव और साइन किया जाएगा।
कोल्ड साइनिंग सेटअप में, परिणामी ट्रांज़ैक्शन डेटा को PCZT में पैकेज करके सुरक्षा-महत्वपूर्ण साइनिंग चरण के लिए हार्डवेयर वॉलेट को भेजा जा सकता है।
प्रूविंग (प्रोटोकॉल वैधता प्रदर्शित करना)
प्रूविंग ज़ीरो नॉलेज प्रूफ (जैसे Halo 2 या Groth16) के निर्माण को संदर्भित करता है, जो प्रदर्शित करते हैं कि कोई ट्रांज़ैक्शन Zcash प्रोटोकॉल नियमों का पालन करता है।
प्रूफ नेटवर्क को निम्न की गारंटी देने में सहायता करता है:
- खर्च करने वाला उपयोगकर्ता नोटों को खर्च करने के लिए अधिकृत है
- नोट वास्तव में मौजूद हैं
- संबंधित नलिफ़ायर अद्वितीय हैं
- कुल इनपुट कुल आउटपुट और शुल्क के बराबर हैं।
यह सब किसी भी अंतर्निहित निजी विवरण को उजागर किए बिना किया जाता है।
प्रूफ निर्माण कंप्यूटेशनल रूप से गहन है। इस ज़िम्मेदारी को कंपैनियन डिवाइस को सौंपने से हार्डवेयर वॉलेट रुकने या उसकी मेमोरी समाप्त होने से बचता है।
साइनिंग (खर्च को अधिकृत करना)
साइनिंग मूल रूप से प्रूविंग से भिन्न है। एक डिजिटल हस्ताक्षर निजी कुंजी धारक द्वारा निर्मित स्पष्ट प्राधिकरण चिह्न के रूप में कार्य करता है।
जहाँ ज़ीरो नॉलेज प्रूफ ट्रांज़ैक्शन की वैधता सत्यापित करता है, वहीं डिजिटल हस्ताक्षर स्पेंडिंग अधिकार सिद्ध करता है। हस्ताक्षर प्रमाणित करता है कि वास्तविक स्वामी विशिष्ट ट्रांसफ़र पैरामीटर को मंज़ूरी देता है।
साइनिंग के लिए न्यूनतम कंप्यूटिंग शक्ति चाहिए, जिससे यह हार्डवेयर वॉलेट के लिए आदर्श है।
शील्डेड कोल्ड साइनिंग क्या है?
शील्डेड कोल्ड साइनिंग इंटरनेट से जुड़े कंपैनियन वॉलेट से निजी स्पेंडिंग कुंजियों को पृथक रखते हुए Zcash शील्डेड ट्रांज़ैक्शन को अधिकृत करने की विधि है। ट्रांज़ैक्शन को ऑनलाइन कंप्यूटर पर बनाया और तैयार किया जा सकता है, जबकि अलग हार्डवेयर वॉलेट, जिसे ऑफ़लाइन या अन्यथा पृथक रखा जाता है, ट्रांज़ैक्शन को अधिकृत करने के लिए अपनी संरक्षित कुंजियों का उपयोग करता है।
प्रक्रिया को इस प्रकार सरल बनाया जा सकता है:
कंपैनियन वॉलेट संरचित ट्रांज़ैक्शन पैरामीटर हार्डवेयर डिवाइस को भेजता है, जो निजी स्पेंडिंग कुंजी को होस्ट मशीन को कभी जारी किए बिना पेलोड पर आंतरिक रूप से हस्ताक्षर करता है।
कंपैनियन और हार्डवेयर वॉलेट
शील्डेड ट्रांज़ैक्शन में कंपैनियन वॉलेट और हार्डवेयर वॉलेट दोनों शामिल हो सकते हैं, जिनमें से प्रत्येक अलग कार्य करता है।
कंपैनियन वॉलेट
कंपैनियन वॉलेट क्या है?
कंपैनियन वॉलेट कंप्यूटर या मोबाइल डिवाइस पर चलता है और ट्रांज़ैक्शन बनाने में शामिल अधिकांश कार्य करता है, जैसे:
- खर्च किए जाने वाले नोट चुनना
- ट्रांज़ैक्शन बनाना
- आवश्यक ट्रांज़ैक्शन डेटा की गणना करना
- आवश्यक ज़ीरो-नॉलेज प्रूफ के निर्माण का समन्वय करना।
कंपैनियन वॉलेट उपयोगी क्यों है?
कंपैनियन वॉलेट ट्रांज़ैक्शन निर्माण प्रक्रिया संभालता है, लेकिन यदि कंप्यूटर में malware आ जाए, तो हमलावर संभवतः:
- देख सकता है कि आप क्या कर रहे हैं,
- किसी अनसाइन्ड ट्रांज़ैक्शन को संशोधित कर सकता है,
- आपको किसी चीज़ को मंज़ूर करने के लिए धोखा देने का प्रयास कर सकता है।
कंपैनियन वॉलेट को हार्डवेयर वॉलेट में संग्रहीत निजी कुंजी तक पहुँच की आवश्यकता नहीं होती, इसलिए यह ट्रांज़ैक्शन निर्माण और अन्य कंप्यूटेशनल कार्य संभाल सकता है, जबकि हार्डवेयर वॉलेट निजी कुंजी के लिए सुरक्षा सीमा प्रदान करता है।
हार्डवेयर वॉलेट
हार्डवेयर वॉलेट एक ऑफ़लाइन भौतिक डिवाइस है जो आपकी निजी कुंजियों को जुड़े हुए फ़ोन या कंप्यूटर से पृथक रखता है और आपकी crypto संपत्तियों के लिए सुरक्षित तिजोरी की तरह काम करता है।
हार्डवेयर वॉलेट उपयोगी क्यों है?
यदि कंप्यूटर में malware आ जाए, तो हमलावर संभवतः:
- देख सकता है कि आप क्या कर रहे हैं,
- किसी अनसाइन्ड ट्रांज़ैक्शन को संशोधित कर सकता है,
- आपको किसी चीज़ को मंज़ूर करने के लिए धोखा देने का प्रयास कर सकता है।
निजी कुंजी को हार्डवेयर वॉलेट से आसानी से निकाला नहीं जा सकता, इसलिए डिवाइस सुरक्षा सीमा के रूप में कार्य कर सकता है।
कंपैनियन बनाम हार्डवेयर क्षमताओं की छवि
इन दो वॉलेटों के बीच का विभाजन शील्डेड ट्रांज़ैक्शन के लिए विशेष रूप से महत्वपूर्ण है क्योंकि वे पारदर्शी ट्रांज़ैक्शन की तुलना में अधिक जटिल होते हैं और उनमें शील्डेड नोट, नलिफ़ायर, कमिटमेंट, ज़ीरो नॉलेज प्रूफ और ट्रांज़ैक्शन हस्ताक्षर जैसे घटक शामिल होते हैं।
हार्डवेयर वॉलेट के लिए हर कंप्यूटेशनल ऑपरेशन करना अव्यावहारिक होगा। इसके बजाय, कंपैनियन वॉलेट ट्रांज़ैक्शन तैयार करता है और साइनिंग के लिए आवश्यक जानकारी हार्डवेयर वॉलेट को देता है, जबकि निजी स्पेंडिंग कुंजी हार्डवेयर डिवाइस के भीतर पृथक रहती है।
कुंजी पृथक्करण
कुंजी पृथक्करण का अर्थ है कि खर्च को अधिकृत करने वाली निजी कुंजियाँ कभी भी hardware wallet से बाहर नहीं जातीं। companion लेनदेन तैयार कर सकता है; वह उस पर हस्ताक्षर नहीं कर सकता।
कुंजी पृथक्करण से तात्पर्य किसी लेनदेन को अधिकृत करने के लिए आवश्यक निजी कुंजियों को companion wallet और उस डिवाइस से अलग रखने से है जिस पर वह चलता है। shielded cold signing सेटअप में, companion wallet लेनदेन बना सकता है और आवश्यक proofs का समन्वय कर सकता है, जबकि hardware wallet संवेदनशील निजी spending keys को पृथक रखता है।
यदि companion कंप्यूटर या फ़ोन से समझौता हो जाता है, तो हमलावर हस्ताक्षर किए जाने से पहले लेनदेन के साथ इंटरैक्ट कर सकता है, लेकिन आदर्श रूप से वह hardware wallet से निजी कुंजी निकाल नहीं सकता। इसलिए कुंजी hardware डिवाइस की सुरक्षा सीमा के भीतर ही रहती है।
यह पृथक्करण companion wallet को लेनदेन निर्माण और गणनात्मक कार्य करने देता है, बिना उसे लेनदेन को अधिकृत करने के लिए आवश्यक key material तक सीधी पहुँच दिए।
समझने योग्य मुख्य अंतर यह है कि "viewing key" का अर्थ यह नहीं है कि app को seed का कोई कमज़ोर संस्करण मिलता है।
Zcash में, एक Full Viewing Key (FVK/UFVK) जानबूझकर spending key से व्युत्पन्न की जाती है और धारक को प्रासंगिक shielded गतिविधि पहचानने और decrypt करने की क्षमता देती है, लेकिन खर्च अधिकृत करने की नहीं। FVK spending key का कम-गोपनीय derivative है।
एक महत्वपूर्ण गोपनीयता संबंधी चेतावनी:
इसलिए यह समझना चाहिए कि app केवल UFVK के साथ धनराशि चुरा नहीं सकता, लेकिन वह wallet की निजी shielded गतिविधि देख सकता है।
इसीलिए companion application को केवल "public information" वाला कहने के बजाय, उसे viewing authority वाला कहना अधिक सटीक है।
पूरे विचार को कहने का सबसे सरल तरीका यह है कि companion wallet को यह जानने के लिए पर्याप्त key material मिलता है कि wallet के साथ क्या हो रहा है, लेकिन wallet के धन के साथ क्या होगा उसे अधिकृत करने के लिए पर्याप्त key material नहीं मिलता। हालांकि hardware wallet spending authority को पृथक रखता है और उसका उपयोग केवल तभी करता है जब उपयोगकर्ता किसी लेनदेन को मंज़ूरी देता है।
यही इन shielded Zcash hardware wallet डिज़ाइनों के पीछे का मूल कुंजी-पृथक्करण मॉडल है और यही मॉडल, प्रत्येक implementation में, Ledger, Keystone, और Hito में भी दिखाई देता है, जिन पर शीघ्र ही चर्चा की जाएगी।
PCZT
PCZT का अर्थ Partially Created Zcash Transaction है। यह वह package है जो एक Zcash लेनदेन और उसे एक चरण से दूसरे चरण तक पूरा करने के लिए आवश्यक जानकारी वहन करता है।
यह Zcash लेनदेन के लिए एक मानकीकृत प्रारूप है, जब लेनदेन अभी बनाया जा रहा होता है। यह अलग-अलग प्रतिभागियों या डिवाइसों को लेनदेन-निर्माण प्रक्रिया के अलग-अलग हिस्से करने और आंशिक रूप से पूर्ण लेनदेन को उनके बीच भेजने की अनुमति देता है।
Zcash जैसे zero knowledge cryptocurrency protocols में एक साधारण सार्वजनिक transfer पर हस्ताक्षर करने की तुलना में लेनदेन बनाना काफी अधिक जटिल है। shielded लेनदेन को गणनात्मक रूप से गहन zero-knowledge proofs की आवश्यकता होती है, जैसे Halo 2 या Groth16 से उत्पन्न proofs। परिणामस्वरूप, hardware wallets जैसे कम-शक्ति वाले डिवाइसों में संपूर्ण लेनदेन workflow को संभालने के लिए आवश्यक मेमोरी और processing capacity नहीं हो सकती।
PCZT की शुरुआत shielded crypto architecture की कई मुख्य चुनौतियों का समाधान करती है। PCZT एक मानकीकृत मध्यवर्ती data format है, जो लेनदेन निर्माण को modular, स्वतंत्र भूमिकाओं में विभाजित करता है। यह एक शक्तिशाली companion कंप्यूटर को transaction assembly और proof generation संभालने देता है, जबकि offline hardware wallet को सख्ती से authorization और signing तक सीमित रखता है।
Hardware और Cold Storage सीमाएँ
यद्यपि hardware wallets निजी spending keys की सुरक्षा के लिए सुरक्षित वातावरण प्रदान करते हैं, फिर भी companion कंप्यूटरों की तुलना में उनमें सामान्यतः सीमित RAM, computing power और data transfer क्षमताएँ होती हैं। ये सीमाएँ उनके लिए गणनात्मक रूप से गहन zero knowledge proof generation करना या लेनदेन निर्माण प्रक्रिया के दौरान आवश्यक संपूर्ण transaction state बनाए रखना अव्यावहारिक बनाती हैं।
फलस्वरूप, companion wallet गणनात्मक रूप से मांग वाले कार्य संभाल सकता है, जबकि hardware wallet अपनी संरक्षित spending keys के साथ लेनदेन को अधिकृत करने के सुरक्षा-महत्वपूर्ण कार्य पर केंद्रित रहता है।
यह सोचने पर मजबूर करता है कि यदि डिवाइस इतना सीमित है, तो भरोसेमंद बनने के लिए वह फिर भी पर्याप्त सत्यापन कैसे करता है?
सरल शब्दों में, hardware wallet companion कंप्यूटर से कोई मनमाना मान स्वीकार करके उस पर हस्ताक्षर नहीं कर सकता। उसे यह स्थापित करने के लिए पर्याप्त जानकारी चाहिए कि जिस मान पर हस्ताक्षर हो रहे हैं वह उसी लेनदेन से मेल खाता है जिसे उपयोगकर्ता अधिकृत करना चाहता है। इससे एक कठिन संतुलन बनता है, क्योंकि डिवाइस को signing प्रक्रिया की सुरक्षा के लिए पर्याप्त parsing और verification करना पड़ता है, साथ ही मेमोरी, computation, firmware आकार और implementation complexity की कठोर सीमाओं के भीतर भी काम करना पड़ता है।
Ledger का Orchard PCZT handling इस चुनौती का एक उदाहरण है, जो बताता है कि विशेषीकृत circuit-dependent parsing सीमित डिवाइसों पर implementation को अधिक प्रबंधनीय बना सकता है, लेकिन समर्थित लेनदेन संरचनाओं या circuits के विकसित होने पर firmware बदलावों की आवश्यकता भी पड़ सकती है।
दो जारी प्रयास इसी बाधा के अलग-अलग उत्तरों को दर्शाते हैं।
open-source hardware wallet architectures और सामान्य कंप्यूटरों के लिए उपयुक्त पूरी तरह constant time proving pipeline पर एक शोध प्रस्ताव Grant #423 में प्रस्तुत किया गया था। लक्ष्य C या Rust जैसे वातावरणों में सुरक्षित रूप से लागू की जा सकने वाली cryptographic infrastructure की जाँच करना था, साथ ही shielded Zcash समर्थन की जटिलता और रखरखाव भार को कम करना था।
हालाँकि एक वैकल्पिक दृष्टिकोण प्रस्तावित Zcash SeedSigner द्वारा प्रदर्शित होता है, जो सस्ते और आसानी से उपलब्ध components से बना एक open-source, air-gapped signer है। इसका प्रस्तावित workflow companion कंप्यूटर को signing डिवाइस से अलग रखता है और on-device verification तथा signing के लिए एक PCZT को air gap के पार भेजता है।
https://forum.zcashcommunity.com/t/grant-application-research-on-a-fully-constant-time-proving-pipeline-for-open-source-hardware-wallet-architectures-reusable-for-standard-computers/57555
साथ मिलकर, ये दृष्टिकोण shielded hardware wallets के पीछे की व्यापक engineering चुनौती को दर्शाते हैं: लेनदेन निर्माण और proving सुरक्षा-महत्वपूर्ण डिवाइस के बाहर हो सकते हैं, लेकिन signer के पास फिर भी पर्याप्त जानकारी और verification क्षमता होनी चाहिए ताकि वह परिणामी लेनदेन को सुरक्षित रूप से अधिकृत कर सके।
PCZT विभाजित Architecture सक्षम करता है
Partially Created Zcash Transaction (PCZT) मानक वह औपचारिक data structure है जो companion wallet और hardware wallet को जोड़ता है।
एक companion wallet स्वयं note selection संभाल सकता है, nullifiers निकाल सकता है, और zero knowledge proof उत्पन्न कर सकता है। यह संभव है क्योंकि इन चरणों के लिए आवश्यक जानकारी, जिसमें nullifiers व्युत्पन्न करने के लिए उपयोग की जाने वाली कुंजी भी शामिल है, spending authority से जुड़ी किसी चीज़ के बजाय viewing key से आती है। फिर companion wallet इन तत्वों को एक PCZT container में पैक करता है।
PCZT को hardware wallet को दिया जाता है, जो लेनदेन संदर्भ पढ़ता है (जैसे राशियाँ और recipient addresses), अपनी संरक्षित spending keys से signature लागू करता है, और अद्यतन PCZT को companion डिवाइस को वापस देता है।
यह डिज़ाइन एक कठोर सुरक्षा सीमा स्थापित करता है: शक्तिशाली host hardware spending keys तक पहुँच के बिना जटिल zero knowledge गणित कर सकता है, जबकि कम-शक्ति वाले cold storage डिवाइस भारी cryptography की गणना किए बिना वित्तीय सुरक्षा लागू कर सकते हैं।
Prover गोपनीयता समझौते
हालाँकि zero knowledge proof generation को companion wallet या किसी अन्य prover को सौंपने से spending keys पृथक रहती हैं, फिर भी prover को संवेदनशील लेनदेन जानकारी, जैसे note values, recipient addresses और commitments, तक पहुँच की आवश्यकता होती है।
PCZT इस architectural separation को यह सुनिश्चित करके बनाए रखता है कि proving के लिए यह जानकारी दी जा सके, बिना authorization के लिए आवश्यक निजी spending keys हस्तांतरित किए।
यह सुनिश्चित करता है कि proving authority, spending authority से अलग है। prover उपयोगकर्ता के धन खर्च करने का cryptographic अधिकार पाए बिना गणनात्मक रूप से गहन proof generation कर सकता है।
PCZT Interoperability
जैसे-जैसे PCZT, Zcash hardware wallet, multisignature और air-gapped signing workflows का महत्वपूर्ण हिस्सा बनता है, स्वतंत्र implementations के बीच interoperability बढ़ती हुई महत्वपूर्ण होती जाती है।
AngryDavee के जून 2026 के एक प्रस्ताव में बताया गया कि PCZT implementations पहले से ही Ledger, Keystone, Hito, OneKey और librustzcash में reference implementation सहित projects में मौजूद थे। हालाँकि, प्रस्ताव ने यह पुष्टि करने के लिए साझा tests की कमी पहचानी कि ये implementations PCZTs की व्याख्या लगातार एक समान करते हैं।
प्रस्तावित समाधान एक open-source interoperability test suite था, जिसमें canonical PCZT test vectors और संपूर्ण create → sign → finalize workflow को कवर करने वाले cross-implementation tests शामिल थे। इसने Combiner जैसी role boundaries के परीक्षण का भी प्रस्ताव दिया, जहाँ अलग-अलग signers की आंशिक रूप से हस्ताक्षरित जानकारी को लेनदेन final होने से पहले जोड़ा जा सकता है।
यह hardware wallets के लिए विशेष रूप से प्रासंगिक है क्योंकि PCZT लेनदेन निर्माण और signing को अलग करने देता है: एक companion wallet लेनदेन बना सकता है और PCZT तैयार कर सकता है, जबकि hardware डिवाइस आवश्यक signing information प्राप्त करता है और सुरक्षा-महत्वपूर्ण signing operation करता है।
प्रस्ताव लागू नहीं हुआ क्योंकि Zcash Community Grants ने प्रस्ताव की समीक्षा और समुदाय की प्रतिक्रिया पर विचार करने के बाद grant को आगे न बढ़ाने का निर्णय लिया। परिणामस्वरूप, प्रस्तावित cross-implementation test suite इस grant के माध्यम से विकसित नहीं किया गया। इसलिए यह पहचानी गई PCZT interoperability चुनौती का प्रस्तावित उत्तर है, न कि ऐसा मानक जो वर्तमान में Zcash में मौजूद हो।
https://forum.zcashcommunity.com/t/pczt-interoperability-test-suite-feedback-before-at-grant-submission/55931
एक PCZT का Lifecycle
| # | चरण | विवरण |
|---|
| 1 | Creator | transaction versions, consensus branch IDs और pool flags सहित वैश्विक transaction metadata के साथ PCZT को प्रारंभ करता है। |
| 2 | Constructor | transparent, Sapling, Orchard या Ironwood pools में अपेक्षित inputs और outputs के साथ लेनदेन भरता है। |
| 3 | IO Finalizer | inputs और outputs के set को पूर्ण घोषित करता है, binding signature keys की गणना करता है और जहाँ आवश्यक हो वहाँ dummy spends पर हस्ताक्षर करता है। |
| 4 | Updater | बाद के प्रतिभागियों के लिए आवश्यक context data संलग्न करता है, जैसे full viewing keys, anchors और Merkle witnesses। |
| 5 | Prover और Signer | zero-knowledge proof generation और cryptographic signing निष्पादित करता है। आधुनिक PCZT versions में, ये दोनों कार्य पूरी तरह स्वतंत्र हैं और क्रमिक रूप से या समानांतर हो सकते हैं। |
| 6 | Combiner | यदि विभिन्न डिवाइस एक ही लेनदेन के पहलुओं पर एक साथ काम करते हैं, तो कई PCZT instances को निर्धारक रूप से merge करता है। आकस्मिक data loss रोकने के लिए merging rules में कठोर conflict resolution आवश्यक है। |
| 7 | Spend Finalizer & Extractor | सभी आवश्यक cryptographic elements को validate करता है, intermediate context metadata हटाता है और network broadcast के लिए तैयार finalized Zcash लेनदेन उत्पन्न करता है। |
वास्तविक दुनिया के Hardware Wallet Implementations
एक नज़र में
| डिवाइस | companion को क्या मिलता है | डिवाइस पर क्या रहता है | परिवहन |
|---|
| Ledger | UFVK / Orchard FVK, addresses | Spending authority | USB / BLE |
| Keystone | UFVK + Unified Address | Seed / spending keys | QR (air-gapped) |
| Hito | UFVK, Unified Address, seed fingerprint | Seed और निजी spending keys | QR / local |
संवेदनशील spending keys को companion wallet से पृथक रखते हुए Zcash shielded लेनदेन का समर्थन कैसे किया जा सकता है, यह जानने के लिए कई hardware wallet implementations विकसित किए गए हैं। Ledger, Keystone और Hito, hardware आधारित key protection को Zcash transaction workflow के साथ एकीकृत करने के अलग-अलग दृष्टिकोण दर्शाते हैं।
यह समझने के लिए कि वे shielded धन की सुरक्षा कैसे करते हैं, spending keys और viewing keys के बीच अंतर करना महत्वपूर्ण है। तीनों में विभाजन एक ही रूप का अनुसरण करता है:
| डिवाइस | companion app को क्या मिल सकता है | डिवाइस पर क्या सुरक्षित रहता है |
|---|
| Ledger | UFVK / Orchard FVK, addresses और public information | Spending authority / निजी key material |
| Keystone | UFVK + Unified Address | Seed / spending keys |
| Hito | UFVK, Unified Address, seed fingerprint और network information | Seed और निजी spending keys |
Hardware Signing Environment के रूप में Ledger
Ledger एक hardware wallet कंपनी है। उसके डिवाइस Secure Element के आधार पर बनाए गए हैं, जो निजी key material रखने और उसे डिवाइस के बाकी हिस्से तथा उससे जुड़े किसी भी उपकरण से भौतिक रूप से पृथक रखने के लिए डिज़ाइन की गई समर्पित chip है। वही Secure Element पूरा कारण है कि Ledger डिवाइस cold storage के लिए विश्वसनीय है। इसका अर्थ है कि भले ही उससे जुड़ा कंप्यूटर या फ़ोन compromise हो जाए, Secure Element के भीतर की कुंजियाँ निकाली नहीं जा सकतीं।
हालाँकि अकेले में, Ledger डिवाइस किसी विशिष्ट cryptocurrency के संदर्भ में रिक्त होता है। उस currency की विशिष्ट cryptography को संभालना जानने वाला application उस पर install होना आवश्यक है।
Ledger डिवाइस किसी विशिष्ट cryptocurrency के संदर्भ में रिक्त होता है, इसलिए उसे उस currency की cryptography जानने वाला application चाहिए। Zcash के लिए दो generations रहे हैं:
- मूल Zondax-निर्मित “Zcash Shielded” app, जिसका उपयोग Zkool जैसे companion wallets के साथ किया जाता था और जिसे 5 नवंबर 2026 को वापस लिया जा रहा है, और
- Ledger का नया Zcash app (3.9.4+), जिसे Ledger Wallet Desktop 4.21+ द्वारा Ironwood shielded ZEC के लिए native रूप से उपयोग किया जाता है।
नीचे दिया गया कुंजी-पृथक्करण मॉडल दोनों पर लागू होता है।
Zkool आपके फ़ोन या कंप्यूटर का companion wallet है जो उस app से बात करता है। वह लेनदेन बनाता है, उसे Ledger को भेजता है, डिवाइस पर मौजूद Zondax app फिर उस पर हस्ताक्षर करता है और signature वापस भेजता है।
अर्थात Zondax hardware पर चलने वाला software है, जबकि Zkool hardware के बाहर चलने वाला software है जो डिवाइस से संवाद के लिए Zondax के app का उपयोग करता है।
Ledger से क्या बाहर जाता है?
Ledger के Zcash software में wallet की viewing key export करने के लिए एक विशिष्ट function शामिल है, जो ऐसी कुंजी है जिससे software कुछ खर्च किए बिना balances और transactions देख सकता है।
यह function दो चीज़ों में से एक लौटा सकता है:
- एक Unified Full Viewing Key (UFVK), जो एक साथ Zcash के सभी shielded pools को कवर करने वाली full viewing key है, या
- एक Orchard Full Viewing Key (FVK)
किसी भी स्थिति में, जो बाहर आता है वह केवल viewing key होता है। चाहे आप कोई भी version माँगें, यह function उस एक जानकारी को लौटाने का कोई तरीका नहीं रखता जो वास्तव में किसी को धन स्थानांतरित करने देगी: spending key।
इसी तरह इसके निर्माण का पूरा उद्देश्य है: इसे ऐसे डिज़ाइन किया गया है कि यह केवल वही export कर सके जिसे companion app को सौंपना सुरक्षित है।
Zcash की key hierarchy इस प्रकार संरचित है कि प्रत्येक shielded pool के लिए spending key दो अलग चीज़ें व्युत्पन्न करती है:
- एक spend-authorizing key, और
- एक full viewing key
FVK फिर अपनी viewing-संबंधी अतिरिक्त क्षमताएँ व्युत्पन्न कर सकती है, लेकिन किसी भी बिंदु पर वह derivation path वापस spending authority तक नहीं पहुँचता। एक बार जब कुंजी hierarchy के viewing पक्ष में विभाजित हो जाती है, तो वह वहीं रहती है और उसे उस spending authority key को पुनर्निर्मित करने के लिए उपयोग नहीं किया जा सकता जिससे वह आई थी।
Ironwood इसी पैटर्न का अनुसरण करता है, क्योंकि वह Orchard की अंतर्निहित key और note construction का पुन: उपयोग करता है। हालांकि consensus स्तर पर वह अपना अलग pool है, अपनी commitment tree और nullifier set के साथ। इसका अर्थ है कि UFVK वास्तव में प्रति-pool viewing keys का bundle है (transparent, Sapling, Orchard, और अब Ironwood), न कि एक अकेली flat key।
Ironwood सक्रिय होने से पहले export की गई UFVK में Ironwood viewing key शामिल नहीं होगी, क्योंकि वह pool तब मौजूद ही नहीं था। यही कारण है कि NU6.3 upgrade के बाद wallets को Ironwood-capable UFVKs पहचानने और व्युत्पन्न करने के लिए update करना पड़ा।
Ledger पर क्या रहता है?
spending authority डिवाइस पर ही रहती है।
Ledger Signer host से एक transaction/PCZT प्राप्त करता है और उस pool के अनुसार spend authorization signature उत्पन्न करता है जिससे लेनदेन खर्च करता है (Ironwood pool, क्योंकि Ledger का वर्तमान integration केवल Ironwood का समर्थन करता है)। signature फिर डिवाइस पर बनाया जाता है और host को केवल signature मिलता है, निजी spending key नहीं।
यह Ledger के सामान्य सुरक्षा मॉडल के साथ भी संगत है। उसका Secure Element निजी key material को पृथक रखता है, और Ledger की application security requirements विशेष रूप से applications को उन secrets को host के सामने प्रकट करने से रोकती हैं।
Ledger का signer FVK/UFVK export कर सकता है और स्वतंत्र रूप से transaction signing भी कर सकता है। दोनों क्षमताएँ अलग-अलग functions के माध्यम से दी जाती हैं, एक साथ bundled नहीं।
व्यवहार में इसका क्या अर्थ है?
मान लीजिए कि आपके Ledger में 10 ZEC हैं।
companion wallet के पास UFVK हो सकती है और इसलिए वह निर्धारित कर सकता है: "इस wallet को 10 ZEC प्राप्त हुए हैं।" वह transactions और balances scan और display कर सकता है।
लेकिन यदि कोई companion wallet से समझौता कर ले, तो केवल UFVK उन्हें spend authorization signature बनाने की क्षमता नहीं देती।
अलग spend authorization signature का उद्देश्य hardware wallets जैसे सीमित डिवाइसों को पूरा zk-SNARK proof स्वयं किए बिना shielded खर्चों को अधिकृत करने देना है।
Zondax Ledger application; hardware wallet पक्ष
Zondax क्या है?
Zondax एक third-party development firm है जिसने Ledger Zcash app बनाया है। यह वास्तविक firmware application है जो Ledger hardware पर चलता है और डिवाइस को सबसे पहले Zcash लेनदेन समझने और process करने की क्षमता देता है।
Zondax एक बाहरी developer है। Ledger hardware में Zcash लेनदेन process करने की कोई अंतर्निहित क्षमता नहीं है, और वह क्षमता पूरी तरह Zondax के software से आती है।
मूल Zcash Ledger implementation
Zondax का Ledger Zcash app repository वह software है जो Ledger डिवाइस पर चलता है। app का प्रारंभिक ध्यान Sapling shielded लेनदेन पर था, Orchard के Zcash के प्राथमिक shielded pool के रूप में अस्तित्व में आने से पहले, इसलिए Sapling support ही वह सीमा थी जो Ledger डिवाइस shielded ZEC के साथ कर सकता था।
इसकी architecture इस पृथक्करण को दर्शाती है, जिसमें host/companion पक्ष transaction information तैयार करता है जबकि Ledger संवेदनशील key operations और signing संभालता है।
Zcash hardware wallet समर्थन के इस सबसे आरंभिक version में भी, मूल सिद्धांत—host पर construction और proving, फिर डिवाइस पर पृथक signing—पहले से ही डिज़ाइन का हिस्सा थे।
Orchard की ओर विकास
Ledger का कार्य Orchard + PCZT की ओर बढ़ा। यह एक छोटे update के बजाय महत्वपूर्ण परिवर्तन था, क्योंकि Orchard एक अलग proving system (Halo 2, जबकि Sapling का Groth16) और अलग note तथा key construction उपयोग करता है, इसलिए Sapling-only firmware को Orchard signing संभालने के लिए विस्तारित करने में डिवाइस पक्ष पर नई cryptographic groundwork की आवश्यकता थी, केवल firmware patch की नहीं।
हालाँकि, जैसे ही Zcash Ironwood की ओर बढ़ा, Zondax और Ledger ने Ironwood को सीधे support करने की दिशा में अपना development focus बदल दिया, बजाय Orchard implementation पूरा करने के और फिर उसे Ironwood के लिए पुनः डिज़ाइन करने के। यह Ledger implementation के विकास में एक और चरण दर्शाता है, क्योंकि Ironwood Orchard cryptographic architecture पर आधारित है और साथ ही एक अलग shielded pool तथा अतिरिक्त protocol changes प्रस्तुत करता है।
इस Ledger app के भीतर क्या होता है
परिणामी flow इस प्रकार बताया गया है:
- host एक PCZT बनाता है।
- host प्रासंगिक transaction information Ledger डिवाइस को भेजता है।
- डिवाइस Orchard spend-authorizing signatures उत्पन्न करता है।
- host उस सबके downstream कार्य संभालता है, जिसमें binding signature और final transaction assembly शामिल है।
Ledger के भीतर चलने वाला app spend authorization signature के अलावा कुछ भी नहीं देखता या उत्पन्न करता, और समस्त गणनात्मक रूप से भारी या data-intensive कार्य (proving, binding, assembly) host पर रहता है, जहाँ उसे key material सौंपकर भरोसेमंद बनाने की आवश्यकता नहीं होती।
Ledger का native shielded integration; Ledger Wallet Desktop
Ledger का नवीनतम Zcash integration यह ठोस उदाहरण देता है कि shielded लेनदेन निर्माण और सुरक्षा-महत्वपूर्ण signing को companion software और hardware wallet के बीच कैसे अलग किया जा सकता है।
Ledger Wallet Desktop 4.21+ और Zcash device app 3.9.4+ के साथ, उपयोगकर्ता Ledger Wallet Desktop के माध्यम से सीधे Ironwood shielded ZEC भेज और प्राप्त कर सकते हैं। integration private-to-private transfers, transparent pool से shielding, transparent pool में unshielding, private receiving addresses और memos का समर्थन करता है। लेनदेन केवल कंप्यूटर द्वारा प्रस्तुत जानकारी पर निर्भर रहने के बजाय Ledger डिवाइस पर verify और sign किए जाते हैं।
इस architecture का मुख्य हिस्सा viewing और spending क्षमताओं का पृथक्करण है। निजी balance synchronization के दौरान, Ledger एक Unified Full Viewing Key (UFVK) export करता है, जो कंप्यूटर पर स्थानीय रूप से संग्रहीत होती है। UFVK, Ledger Wallet Desktop को प्रासंगिक shielded transactions पहचानने और wallet का balance निर्धारित करने देती है, लेकिन वह धन खर्च करने का अधिकार नहीं देती। सुरक्षा-महत्वपूर्ण spending authority Ledger डिवाइस पर रहती है, जो अंतिम signing operation करता है। यह कंप्यूटर, जो wallet state प्रबंधित करता और लेनदेन बनाता है, तथा hardware डिवाइस, जो खर्च अधिकृत करने की आवश्यक क्षमता की सुरक्षा करता है, के बीच स्पष्ट सीमा बनाता है।
हालाँकि, वर्तमान integration विशेष रूप से केवल Ironwood के लिए है। वह Ledger Wallet Desktop के माध्यम से Orchard या Sapling धन display या manage नहीं करता। यह ऐतिहासिक रूप से महत्वपूर्ण है क्योंकि Ledger का पुराना Zcash development, implementation के Ironwood protocol की ओर विकसित होने से पहले, Orchard shielded support से जुड़ा था।
यह परिवर्तन key और account compatibility के महत्व को भी उजागर करता है। Ledger का Zondax द्वारा विकसित और YWallet तथा zkool जैसे integrations द्वारा उपयोग किया गया पुराना “Zcash Shielded” application है, जिसे अब retire किया जा रहा है। क्योंकि वह पुराना application shielded accounts के लिए अलग derivation scheme उपयोग करता था, उसके Sapling accounts को नए Ledger application द्वारा बस पुनः उत्पन्न नहीं किया जा सकता।
अतः यह integration shielded hardware wallet समर्थन की प्रगति और बची हुई सीमाएँ, दोनों दर्शाता है। Ledger अब पूरा Ironwood अनुभव दे सकता है, जिसमें companion software wallet synchronization और transaction preparation संभालता है, जबकि hardware डिवाइस खर्च के लिए सुरक्षा सीमा बना रहता है।
साथ ही, ऐतिहासिक account compatibility, केवल विशिष्ट shielded pools के लिए समर्थन, hardware transaction size limits, platform restrictions, और shielded लेनदेन को parse तथा verify करने में शामिल computational और firmware constraints दर्शाते हैं कि Zcash के लिए hardware wallet समर्थन केवल protocol capabilities पर नहीं, बल्कि प्रत्येक व्यक्तिगत implementation के डिज़ाइन और resources पर भी निर्भर करता है।
Zkool + Ledger — official Zondax app का उपयोग
Ywallet के successor के रूप में, Zkool को shielded cold signing का लक्ष्य विरासत में मिला, लेकिन उसे प्राप्त करने के लिए उसने अलग मार्ग अपनाया—ऐसा मार्ग जो सीधे इस तथ्य से आकार लेता है कि केवल cryptography किसी integration को उपयोगी नहीं बनाती यदि signing app को सुरक्षित रूप से वितरित न किया जा सके।
https://youtu.be/eagkCIv3BlQ?si=7w5YfLlRER77bASw
Zkool द्वारा Zondax application का उपयोग
Zkool, Ywallet के परित्यक्त proprietary Ledger application के बजाय, Zondax द्वारा विकसित official Ledger Zcash app के उपयोग की ओर बढ़ा। ऐसा custom app बनाए रखने के बजाय जिसे Ledger का store स्वीकार नहीं करता, Zkool ने उस app पर निर्माण किया जिसे पहले ही स्वीकार किया जा चुका था और Ledger के अपने ecosystem द्वारा वितरित किया जा रहा था।
इस परिवर्तन का अर्थ था कि उपयोगकर्ताओं को इस integration का उपयोग करने के लिए unsigned custom Ledger application install करने पर निर्भर नहीं रहना पड़ा, क्योंकि Zondax का app आधिकारिक रूप से Ledger के ecosystem के माध्यम से वितरित था।
हालाँकि, इस integration को 5 नवंबर 2026 को एक महत्वपूर्ण परिवर्तन का सामना करना है, जब Ledger द्वारा चरणबद्ध रूप से हटाए जाने पर legacy Zcash Shielded app का समर्थन समाप्त होने वाला है। क्योंकि Zkool का Ledger integration इस application पर निर्भर है, यह परिवर्तन मौजूदा connection की भविष्य उपलब्धता पर प्रश्न उठाता है। Zkool पर सटीक प्रभाव इस बात पर निर्भर करता है कि क्या वह Ledger Wallet के बाहर legacy app का उपयोग जारी रख सकता है या किसी compatible alternative में स्थानांतरित हो सकता है।
समर्थित shielded pools
Ywallet developer के अनुसार, Zkool का Ledger integration, Zondax द्वारा विकसित official Ledger application का उपयोग करता था और transparent तथा shielded दोनों Zcash को support करता था। हालाँकि, उसका shielded support Sapling तक सीमित था और Orchard को support नहीं करता था, साथ ही अन्य integration सीमाएँ भी थीं जैसे प्रत्येक type के अधिकतम पाँच inputs और outputs, और Ledger Live compatibility का अभाव।
यह सीमा उस समय अंतर्निहित Zondax Ledger कार्यान्वयन के दायरे को दर्शाती थी। Zondax के पहले के Ledger कार्य ने Sapling समर्थन प्रदान किया था, और 2024 में उसके Zcash Shielded Ledger ऐप के बाद के रिलीज़ में शुरू में Orchard और Unified Addresses शामिल नहीं थे। इसलिए, उस एप्लिकेशन के इर्द-गिर्द बनाया गया एकीकरण उस हार्डवेयर वॉलेट कार्यान्वयन की क्षमताओं और सीमाओं को विरासत में लेता था जिस पर वह निर्भर था।
नवंबर 2024 में समर्पित Zcash Shielded Ledger App के रिलीज़ के साथ स्थिति आगे विकसित हुई। Zondax ने कहा कि एप्लिकेशन को आधिकारिक रूप से Ledger Live के माध्यम से जारी किया गया था और बाद में अन्य वॉलेट्स को इसके साथ एकीकृत करने में सक्षम बनाने के लिए एकीकरण मार्गदर्शन तथा Rust और JavaScript पैकेज प्रकाशित किए गए। हालांकि, लॉन्च के समय एप्लिकेशन केवल Zecwallet Lite Desktop के साथ संवाद करता था, जबकि व्यापक वॉलेट एकीकरण अभी विकसित किए जा रहे थे।
अगला चरण Ledger के नए Rust-आधारित Zcash एप्लिकेशन का विकास था। जून 2026 तक, Ledger ने रिपोर्ट किया कि UFVK साझाकरण और Orchard Unified Address निर्माण लागू कर दिया गया था, जबकि Orchard लेनदेन हस्ताक्षर और ClearSign अभी विकासाधीन थे। Ledger ने यह भी कहा कि प्रोटोकॉल बदलने पर यह कार्य Ironwood पथ में आगे बढ़ेगा।
Ironwood के लिए Zcash वॉलेट पारिस्थितिकी तंत्र में अद्यतन आवश्यक हुए। Zkool ने संस्करण 6.24.0 से Orchard से Ironwood माइग्रेशन के लिए समर्थन जारी किया, और बाद के रिलीज़ों में माइग्रेशन तथा लेनदेन पाइपलाइन को लगातार परिष्कृत किया। अलग से, Ledger ने 27 जुलाई को अपने नए एप्लिकेशन में PCZT v2 हस्ताक्षर को मर्ज किया, हालांकि 20 अगस्त तक कार्यान्वयन ने Ledger की समीक्षा और Ledger Live रोलआउट पूरा नहीं किया था—यह मील का पत्थर तब से जारी हो चुका है, और Ledger Wallet Desktop 4.21+ अब सीधे मूल Ironwood समर्थन प्रदान करता है।
https://forum.zcashcommunity.com/t/a-path-forward-for-ledger-and-zcash/50951/177
इस प्रकार, इस विकास को एकल Zondax-से-Ironwood अपग्रेड के रूप में नहीं, बल्कि कई संबंधित विकासों के रूप में समझना बेहतर है: मूल Sapling-केंद्रित Zondax कार्यान्वयन, 2024 का Zcash Shielded Ledger App, Orchard और PCZT समर्थन वाला नया Ledger Rust एप्लिकेशन, Ledger Wallet Desktop में Ledger का अपना मूल एकीकरण, और पारिस्थितिकी तंत्र के Ironwood में स्थानांतरित होने के साथ Zkool जैसे वॉलेट्स के समानांतर अद्यतन।
Zcash के लिए वर्तमान Ledger डिवाइस और प्लेटफ़ॉर्म समर्थन
Ledger पर Zcash समर्थन निम्न पर निर्भर करता है
- डिवाइस मॉडल
- इंस्टॉल किया गया एप्लिकेशन
- उसे प्रबंधित करने के लिए उपयोग किया गया प्लेटफ़ॉर्म, और
- क्या लेनदेन पारदर्शी है या shielded।
21 जुलाई 2026 तक (Ledger के अंतिम अद्यतन), Zcash Shielded ऐप Nano S Plus, Stax और Flex पर समर्थित है, लेकिन अभी Nano X या Nano Gen5 पर नहीं।
Nano X और मूल Nano S को छोड़कर अन्य मॉडल अभी भी क्लासिक Zcash ऐप का उपयोग कर सकते हैं, जो पारदर्शी लेनदेन और shielded धन को पारदर्शी पतों पर खर्च करने (deshielding) का समर्थन करता है, लेकिन shielded-से-shielded हस्ताक्षर का नहीं। मूल Nano S किसी भी ऐप का समर्थन नहीं करता, क्योंकि Ledger डिवाइस के लिए समर्थन समाप्त कर रहा है और उसका नवीनतम Zcash ऐप उस पर उपलब्ध नहीं है। डिवाइस Ledger Wallet (पूर्व में Ledger Live), Ledger के सहायक एप्लिकेशन, से जुड़ते हैं, जो डेस्कटॉप पर Windows, macOS और Linux के लिए तथा मोबाइल पर iOS और Android के लिए उपलब्ध है।
Ledger ने Ironwood pool पर निर्मित Ledger Wallet Desktop में मूल shielded Zcash जोड़ा है, जिससे अलग सहायक वॉलेट की आवश्यकता समाप्त हो जाती है। iOS और Android के लिए Ledger के मोबाइल ऐप पर shielded ZEC अभी समर्थित नहीं है, हालांकि मोबाइल समर्थन भविष्य के रिलीज़ के लिए योजनाबद्ध है।
Ledger के अपने सॉफ़्टवेयर के बाहर, shielded उपयोग एक संगत सहायक वॉलेट और उसके समर्थित प्लेटफ़ॉर्मों पर निर्भर करता है। जैसे-जैसे Ledger Ironwood समर्थन का विस्तार करता रहता है, संगतता डिवाइस मॉडल, फर्मवेयर, ऐप संस्करण और ऑपरेटिंग सिस्टम पर निर्भर करती है, इसलिए सामान्य Zcash समर्थन अनिवार्य रूप से संगतता की गारंटी नहीं देता।
https://www.youtube.com/watch?v=VhkhfG0LCFs
YWallet cold signing; एक पूर्ववर्ती तरीका
Ywallet एक सहायक वॉलेट है, जो Ledger और Zondax दोनों से अलग है, जिसने shielded cold signing की दिशा में अपना रास्ता अपनाया।
ऐतिहासिक रूप से Ywallet महत्वपूर्ण है क्योंकि उसने Zcash के लिए cold signing का परीक्षण किया था, अर्थात हस्ताक्षर करने वाले डिवाइस को ऑनलाइन वॉलेट से अलग रखा जा सकता था।
Ledger हार्डवेयर पर उस संरचना को साकार करने के लिए, Ywallet ने अपना Ledger एप्लिकेशन बनाया, जो एक स्वामित्व वाला ऐप था और पिछले अनुभाग में शामिल Zondax ऐप से भिन्न था। इसका अर्थ था कि Ywallet, Zondax के मौजूदा Sapling कार्यान्वयन पर निर्भर नहीं था; संबंध के हस्ताक्षर पक्ष को चलाने के लिए उसका अपना फर्मवेयर था।
एकीकरण क्यों महत्वपूर्ण था
क्रिप्टोग्राफी और हस्ताक्षर कोड होना पर्याप्त नहीं है। हार्डवेयर वॉलेट एकीकरण केवल क्रिप्टोग्राफ़िक समस्या नहीं है, बल्कि यह अनिवार्य रूप से वितरण और प्लेटफ़ॉर्म की समस्या भी है। न्यूनतम रूप से, इसमें शामिल हैं:
- एप्लिकेशन अनुमोदन/वितरण — क्या हार्डवेयर निर्माता का आधिकारिक ऐप स्टोर ऐप को स्वीकार और वितरित करेगा
- फर्मवेयर/एप्लिकेशन सुरक्षा — क्या ऐप key material संभालने के लिए निर्माता की सुरक्षा आवश्यकताओं को पूरा करता है
- संचार प्रोटोकॉल — सहायक वॉलेट और डिवाइस वास्तव में लेनदेन डेटा का आदान-प्रदान कैसे करते हैं
- वॉलेट के साथ संगतता — क्या हस्ताक्षर ऐप के डेटा प्रारूप और प्रवाह सहायक वॉलेट की अपेक्षाओं से मेल खाते हैं
- समर्थित shielded pools — ऐप वास्तव में Sapling, Orchard (और अब Ironwood) में से किनके लिए हस्ताक्षर कर सकता है
Ywallet के स्वामित्व वाले Ledger ऐप ने क्रिप्टोग्राफ़िक और स्थापत्य आवश्यकताओं को पूरा किया; वह shielded Zcash लेनदेन पर हस्ताक्षर कर सकता था, लेकिन उसे Ledger के आधिकारिक ऐप स्टोर में स्वीकार नहीं किया गया।
स्वामित्व वाले Ledger ऐप से संक्रमण
चूंकि ऐप को आधिकारिक रूप से स्वीकार नहीं किया गया था, इसलिए Ywallet को इसका उपयोग करने के लिए उपयोगकर्ताओं से unsigned फर्मवेयर इंस्टॉल करने को कहना पड़ता। यह उपयोगकर्ताओं के लिए वास्तविक सुरक्षा समझौता है, और Ywallet ने उनसे ऐसा करने को न कहने का निर्णय लिया। इसलिए Ywallet ने अंततः उस रास्ते पर जाने के बजाय उस विशेष एकीकरण को छोड़ दिया।
स्वामित्व वाले ऐप को पुनर्जीवित करने के बजाय, बाद का विकास (Zkool के माध्यम से, जो Ywallet का उत्तराधिकारी है) इसके बजाय आधिकारिक Zondax-निर्मित Ledger ऐप की ओर बढ़ा, जिससे एक कस्टम, अस्वीकृत कार्यान्वयन के बदले ऐसा मानकीकृत कार्यान्वयन आया जो पहले से ही Ledger के वितरण पारिस्थितिकी तंत्र में स्वीकार किया जा चुका था। इसी बदलाव ने अंततः फिर से एक कार्यशील Ledger एकीकरण को संभव बनाया।
Ywallet की विरासत
सक्रिय विकास से Ywallet के हट जाने के बाद भी, इसके निर्माता Hanh, जो ZCG के सदस्य भी हैं, पारिस्थितिकी तंत्र में एक प्रासंगिक आवाज़ बने रहे, विशेषकर जब Ironwood के माइग्रेशन के दौरान उन धनराशियों के बारे में रिपोर्ट किए गए मुद्दे सामने आए जो गायब दिखाई दे रही थीं।
ZODL: एक वास्तविक उपयोगकर्ता ने Orchard → Ironwood माइग्रेशन के बाद गायब धनराशि का अनुभव किया
एक उपयोगकर्ता, Jmo0615, ने रिपोर्ट किया कि उनके ZODL वॉलेट में पहले दिखाई देने वाली धनराशि Orchard-से-Ironwood माइग्रेशन के बाद दिखाई नहीं दी। उन्होंने कहा कि उन्होंने मूल seed पुनर्स्थापित किया, वॉलेट रीसेट और रिकवर किया, और ZODL संस्करण 3.14.1 (1) को पूरी तरह सिंक्रनाइज़ होने दिया। उन्होंने यह भी पुष्टि की कि कोई Keystone हार्डवेयर वॉलेट शामिल नहीं था।
यह स्थापित नहीं हुआ है कि धन वास्तव में खो गया था। बल्कि, संदेह है कि यह वॉलेट खोज या माइग्रेशन से संबंधित समस्या है, जिसमें पहले दिखाई देने वाली धनराशि Ironwood में संक्रमण के बाद प्रदर्शित नहीं हुई। जो धनराशि पहचानी या प्रदर्शित नहीं होती, उसे स्वतः स्थायी रूप से खोई हुई धनराशि नहीं कहा जाना चाहिए, और माइग्रेशन समस्याओं को समझते समय यह अंतर महत्वपूर्ण है।
https://forum.zcashcommunity.com/t/funds-not-showing-since-ironwood/57792
Zkool: "locked notes" स्पष्ट रूप से अनुपलब्ध धनराशि की व्याख्या कर सकते हैं
shielded वॉलेट्स का एक और महत्वपूर्ण पहलू यह है कि वॉलेट स्थिति उस धनराशि को कैसे प्रभावित कर सकती है जिसे उपयोगकर्ता वास्तव में खर्च कर सकता है। Hanh ने समझाया कि उपयोगकर्ता coin control के माध्यम से गलती से किसी note को लॉक कर सकता है। यह एक ऐसी सुविधा है जो उपयोगकर्ताओं को यह चुनने देती है कि खर्च के लिए किन notes का उपयोग किया जाए। इस स्थिति में, कोई note वॉलेट में मौजूद रह सकता है लेकिन खर्च के लिए अनुपलब्ध चिह्नित हो सकता है।
यह वॉलेट समस्याओं की जांच करते समय एक महत्वपूर्ण अंतर दर्शाता है। वॉलेट में मौजूद ZEC की मात्रा हमेशा वर्तमान में खर्च के लिए उपलब्ध राशि के समान नहीं होती। note चयन, सिंक्रनाइज़ेशन, माइग्रेशन स्थिति, वॉलेट रिकवरी और coin control सेटिंग्स जैसे कारक प्रदर्शित या खर्च योग्य शेषराशि को प्रभावित कर सकते हैं। इसलिए, “गायब धनराशि” की रिपोर्टों में ऐसी धनराशि के बीच सावधानी से अंतर किया जाना चाहिए जो पहचानी या प्रदर्शित नहीं होती, जो पहचानी जाती है लेकिन खर्च के लिए अनुपलब्ध है, और जो वास्तव में खो गई है।
https://youtube.com/shorts/eAOMRVYJFTA?si=xytBs-wZKn8hmu8D
2. Keystone
Keystone क्या है?
Keystone एक air gapped hardware wallet है। हस्ताक्षर प्रक्रिया के दौरान इसके signing device का सहायक ऐप से कोई प्रत्यक्ष वायर्ड या वायरलेस कनेक्शन नहीं होता; इसके बजाय यह QR codes के माध्यम से संवाद करता है। यहां इसे Zashi (अब Zodl के रूप में पुनर्ब्रांड किया गया) के साथ जोड़ा गया है, जो Zcash का मूल सहायक वॉलेट है, और यह जोड़ी key isolation सिद्धांत को असाधारण रूप से स्पष्ट और अनुरेखित करने में आसान बनाती है।
Keystone/Zashi प्रवाह
Zashi के साथ Keystone का Zcash एकीकरण इस अलगाव को विशेष रूप से स्पष्ट बनाता है। जब आप Keystone को Zashi से जोड़ते हैं, तो Unified Full Viewing Key को Keystone से Zashi में स्थानांतरित किया जाता है।
इसलिए प्रवाह है:
Zashi UFVK के साथ क्या कर सकता है?
Zashi इसका उपयोग निम्न के लिए कर सकता है:
- आने वाले shielded लेनदेन पहचानना
- शेषराशि निर्धारित करना
- shielded गतिविधि के बारे में जानकारी प्राप्त करना
लेकिन यह केवल UFVK होने के कारण धनराशि खर्च नहीं कर सकता।
UFVK एक "viewing capability" है जो शेषराशि और लेनदेन की जानकारी लेने देती है, लेकिन खर्च करने की अनुमति नहीं देती।
Keystone के भीतर क्या रहता है?
seed/खर्च प्राधिकार Keystone पर ही रहता है। Zashi को seed, spending key या spend authorization private key नहीं मिलती। इसे UFVK, address जानकारी और केवल देखने के संचालन के लिए आवश्यक जानकारी मिलती है।
साथ मिलकर, ये दोनों हिस्से पूरी तस्वीर बनाते हैं। डिवाइस से बाहर जाने वाली जानकारी, जैसे UFVK, addresses और watch only जानकारी, Zashi के लिए खाते की निगरानी हेतु पर्याप्त है, लेकिन डिवाइस से बाहर जाने वाली कोई भी चीज़ उससे धनराशि बाहर ले जाने के लिए पर्याप्त नहीं है।
इसीलिए Zashi और Keystone एकीकरण shielded cold storage प्रदान कर सकता है। वॉलेट एप्लिकेशन खाते की निगरानी कर सकता है, लेकिन उसके पास उससे खर्च करने के लिए आवश्यक प्राधिकार नहीं होता। यह एकीकरण विशेष रूप से shielded ZEC का cold storage सक्षम करने के लिए लॉन्च किया गया था।
जब आप खर्च करना चाहते हैं:
3. Hito
Hito, Keystone के समान ही key isolation मॉडल अपनाता है, लेकिन इसका कार्यान्वयन नया है। Zashi जैसे मौजूदा सहायक वॉलेट के साथ जोड़ी बनाने के बजाय, Hito अपने स्वयं के Android वॉलेट के साथ आता है, और हार्डवेयर डिवाइस तथा उस Android ऐप के बीच onboarding प्रक्रिया को Hito के विकास मील के पत्थरों में प्रलेखित किया गया है।
Onboarding: Hito ऐप को क्या मिलता है
Android वॉलेट उपयोग करता है:
- Unified Full Viewing Key (UFVK)
- Unified Address
- ZIP-32 seed fingerprint
- नेटवर्क जानकारी
हार्डवेयर खाते को onboard करते समय।
ध्यान दें कि Android एप्लिकेशन को कभी भी हार्डवेयर वॉलेट का seed या निजी spending keys नहीं मिलते।
Hito ऐप को क्या मिलता है?
प्रलेखित onboarding जानकारी में शामिल हैं:
- UFVK
- Unified Address
- ZIP-32 seed fingerprint
- नेटवर्क
UFVK, Android वॉलेट को seed प्राप्त किए बिना खाते को view-capable wallet के रूप में संचालित करने हेतु आवश्यक जानकारी देता है। seed fingerprint, seed से व्युत्पन्न एक निश्चित लंबाई वाला पहचानकर्ता है, जिसका उपयोग यह पहचानने के लिए किया जाता है कि कौन-सा खाता कौन-सा है; वह स्वयं seed नहीं है और कोई खर्च क्षमता प्रदान नहीं करता। इसीलिए उसकी मौजूदगी ऊपर दिए गए "कभी seed प्राप्त नहीं करता" दावे का विरोध नहीं करती।
Hito पर क्या रहता है?
वास्तविक seed, निजी spending keys और signing authority हार्डवेयर डिवाइस पर रहते हैं। इसके बाद Hito offline हस्ताक्षर करता है।
वर्तमान Hito मील का पत्थर बताता है कि संपूर्ण निर्माण, निर्यात, offline हस्ताक्षर और आयात कार्यप्रवाह परिचालित है, जिसमें BLE transport और हस्ताक्षरित PCZT का BBQr QR निर्यात शामिल है।
उस कार्यप्रवाह को स्पष्ट रूप से नाम देना उचित है, क्योंकि यह इस रिपोर्ट में पहले शामिल पूर्ण चक्र का ठोस उदाहरण है: Android वॉलेट अहस्ताक्षरित PCZT बनाता है, उसे Hito में निर्यात करता है, Hito अपनी अलग-थलग key material के साथ offline हस्ताक्षर करता है, और हस्ताक्षरित PCZT को वापस Android वॉलेट में आयात किया जाता है।
किसी भी बिंदु पर seed या spending key उस सीमा को किसी भी दिशा में पार नहीं करती।
Orchard से Ironwood: Hardware Wallet समर्थन का विकास
Orchard, Zcash प्रोटोकॉल में एक shielded pool है जो उपयोगकर्ताओं को बेहतर गोपनीयता के साथ ZEC को संग्रहीत करने और लेन-देन करने में सक्षम बनाता है। Network Upgrade 5 (NU5) में पेश किया गया, Orchard संवेदनशील लेन-देन जानकारी, जैसे भेजने वाले, प्राप्तकर्ता या राशि, प्रकट किए बिना shielded लेन-देन का समर्थन करने के लिए Halo 2 proving system और एक पुनःडिज़ाइन की गई cryptographic architecture का उपयोग करता है।
Ironwood एक shielded pool है, जिसे Zcash के NU6.3 network upgrade में Orchard pool के उत्तराधिकारी के रूप में पेश किया गया था। यह Orchard cryptographic protocol का उपयोग करता है और साथ ही shielded funds की दीर्घकालिक सुरक्षा बेहतर बनाने के लिए डिज़ाइन किए गए बदलाव लाता है, जिनमें quantum recoverability और supply integrity के बारे में मजबूत आश्वासन शामिल हैं।
शुरुआत में, यह स्पष्ट करना आवश्यक है कि Ironwood ने Orchard प्रोटोकॉल को पूरी तरह नई cryptographic system से प्रतिस्थापित नहीं किया। Ironwood को मौजूदा Orchard प्रोटोकॉल से निर्मित एक नए shielded pool के रूप में पेश किया गया था। इसका अर्थ है कि इनमें समान Action structure, समान Halo 2 proving system, और समान note व key constructions हैं।
Ironwood का अपना note commitment tree, nullifier set, anchor और value pool है, इसलिए consensus स्तर पर यह वास्तव में एक अलग pool है। लेकिन cryptographically, यह पुनर्निर्माण के बजाय Orchard का विस्तार है।
इसे इस प्रकार डिज़ाइन किया गया था:
- Supply integrity. 29 मई, 2026 को सुरक्षा शोधकर्ता Taylor Hornby ने निजी रूप से Orchard के zero knowledge proof system में एक गंभीर soundness flaw का खुलासा किया, जो बिना on-chain trace छोड़े नकली ZEC बनाए जाने की अनुमति दे सकता था। क्योंकि Orchard का लेन-देन डेटा निजी है, कोई भी स्वतंत्र रूप से सत्यापित नहीं कर सकता कि सुधार से पहले कोई नकली ZEC नहीं बनाया गया था। पुराने pool को seal करना और शून्य से नया शुरू करना इस समस्या को ऐसे हल करता है, जैसा Orchard को वहीं patch करके नहीं किया जा सकता था।
- Quantum recoverability सुनिश्चित करना। Ironwood को इस प्रकार डिज़ाइन किया गया था कि यदि अंतर्निहित discrete log assumptions कभी टूट जाएँ, तो उसके funds भविष्य की recovery mechanism में भाग ले सकें।
- Implementation बदलाव को न्यूनतम करना। पूरी तरह नया shielded protocol डिज़ाइन करने के बजाय, Orchard की सिद्ध architecture को पुनः इस्तेमाल किया गया। इसका मतलब था कि बहुत कम नया transaction, proving, wallet और hardware wallet code शुरुआत से लिखना पड़ा।
सार्वजनिक समयरेखा
- 29 मई: Orchard vulnerability का खुलासा होता है।
- जून: शुरुआती सुधार NU6.2 के माध्यम से जारी किए जाने तक Orchard लेन-देन अस्थायी रूप से प्रतिबंधित किए जाते हैं। 12 जून को, एक core developer पूर्ण upgrade के लिए 21 जुलाई का लक्ष्य निर्धारित करता है; बाद में यह एक सप्ताह आगे खिसक जाता है। समुदाय में यह चिंता उठी कि Keystone मालिक सबसे अंत में migrate कर पाएँगे, जिस पर एक core developer ने जवाब दिया कि Keystone पहले दिन से Ironwood का समर्थन करेगा, और firmware का लक्ष्य 3 जुलाई था, जो अंतिम signing constants और Zcash core से Orchard API बदलावों पर निर्भर था।
- जुलाई की शुरुआत: NU6.3 testnet तक पहुँचता है; Zebra 6.0.0 10 जुलाई को जारी होता है।
- 27–28 जुलाई: Ledger का Ironwood PCZT v2 signing कार्य एक integration branch में merge होता है। Ironwood (NU6.3) 28 जुलाई को block 3,428,143 पर सक्रिय होता है, जो मूल Orchard pool को एक turnstile के पीछे seal कर देता है। यह उस मात्रा को सीमित करता है जितनी ZEC, Orchard से बाहर जा सकती है, उस मात्रा तक जो वैध रूप से उसमें जमा की गई थी, और एक नया transaction format पेश करता है।
Zebra आवश्यक नोड बन जाता है, क्योंकि zcashd नए consensus rules का समर्थन नहीं करता। Addresses नहीं बदलते क्योंकि Ironwood, Orchard के receiver structure को पुनः उपयोग करता है, इसलिए wallets मौजूदा addresses को स्वचालित रूप से नए pool में route करते हैं। हालाँकि wallets को migration functionality की आवश्यकता होती है, क्योंकि Orchard funds को अंततः उनके मालिकों द्वारा Ironwood में स्थानांतरित किया जाना चाहिए, और Orchard प्राप्त करने वाले नए outputs अब consensus द्वारा पूरी तरह अवरुद्ध हैं।
तकनीकी रूप से क्या बदला
Transaction formats version 5 से version 6 में चले गए, इसलिए एक लेन-देन मौजूदा Sapling/Orchard/transparent components के साथ एक Ironwood component रख सकता है। PCZT को क्रमिक रूप से विस्तारित किया गया:
- Encoding, PCZT v1 से v2 में चला गया।
- अब एक अलग Ironwood bundle, Sapling और Orchard वाले bundles के साथ मौजूद है।
- v6 transactions और नए v6 sighash का समर्थन किया गया है।
- Note plaintexts में एक नया version (V3) जोड़ा गया।
sighash बदलाव विशेष रूप से hardware wallets के लिए सबसे महत्वपूर्ण है। v6 में, Orchard और Ironwood anchors को signature hash से बाहर रखा जाता है और वे केवल authorizing data digest में शामिल होते हैं। यह वास्तविक firmware बदलाव है, केवल version bump नहीं। किसी device को नया sighash सही ढंग से implement करना होगा और companion app द्वारा यह कहे जाने पर भरोसा करने के बजाय स्वयं उसे recompute करना होगा कि वह किसे approve कर रहा है।
Isolation contract स्वयं नहीं बदला: device अभी भी केवल spend authorization signature लौटाता है, कभी alpha नहीं, और binding signature भी कभी नहीं बनाता; host अभी भी proving और बाकी सब संभालता है।
हालाँकि v6 के साथ एक signer rule बदल गया: dummy padding spends पर device के बजाय IO Finalizer हस्ताक्षर करता है, क्योंकि device के पास उन्हें वास्तविक note data के विरुद्ध सत्यापित करने का कोई तरीका नहीं है। Device की Signer role उन्हें sign करने के लिए कहे जाने के बजाय छोड़ देती है, क्योंकि वह ऐसी चीज़ की जाँच नहीं कर सकता। प्रदर्शित fees भी अब Orchard और Ironwood दोनों value balances का योग करती हैं, क्योंकि v6 लेन-देन एक ही transaction में किसी भी pool से spend कर सकता है।
उस pool accounting को सही रखना व्यवहार में मायने रखता है, केवल सिद्धांत में नहीं। Brave के अपने Zcash wallet में हाल का एक bug उपयोगी उदाहरण है: इसकी fee calculation ने मान लिया था कि सभी shielded inputs legacy Orchard pool से संबंधित हैं, जिससे किसी लेन-देन में वास्तव में Ironwood शामिल होने पर duplicated actions और गलत fee estimates बनते थे। यह ठीक उसी प्रकार की त्रुटि है जिसे hardware wallet signing के पीछे का “इसे स्वयं recompute करो, host पर भरोसा मत करो” सिद्धांत पकड़ने के लिए मौजूद है। एक companion wallet ने pool accounting गलत की थी और केवल अपना गणित स्वतंत्र रूप से जाँचने वाला device ही हस्ताक्षर करने से पहले उसे चिह्नित कर सकता था।
प्रत्येक signer की स्थिति
Ledger ने पूरी तस्वीर बदल दी है। 23 सितंबर, 2026 को, Ledger ने Ledger Wallet Desktop के भीतर सीधे native shielded Zcash support जारी किया; अब अलग companion app की आवश्यकता नहीं है। आपकी spending key device पर रहती है, कंप्यूटर transaction math करता है, और हस्ताक्षर होने से पहले आप स्क्रीन पर सब कुछ approve करते हैं। यह केवल Ironwood को support करता है, पुराने Orchard या Sapling pools को नहीं। कमी यह है कि Zondax द्वारा बनाया गया legacy “Zcash Shielded” app, जिसे काम करने के लिए Zkool जैसे companion wallet की आवश्यकता होती थी, बंद किया जा रहा है। Ledger 5 नवंबर को उस पुराने app को उपलब्धता से हटा रहा है, इसलिए जो कोई अब भी इसका उपयोग कर रहा है उसे उससे पहले अपने funds स्थानांतरित करने होंगे।
Keystone अच्छी स्थिति में है। Firmware 3.0.2 ने जुलाई में पूर्ण Ironwood support जोड़ा था, और वही अब भी वर्तमान, स्थिर आवश्यकता है। हालाँकि किसी भी चीज़ पर हस्ताक्षर करने के लिए वह version या नया version आवश्यक है।
Hito प्रारंभिक testnet milestone से आगे बढ़ चुका है। इसने physical hardware पर अपने पहले वास्तविक Orchard-से-Ironwood transaction पर सफलतापूर्वक हस्ताक्षर किए और उसे submit किया (शुरुआत में testnet पर)। बाद के updates ने production hardware पर mainnet flows (Ironwood→Ironwood, Ironwood→Transparent, और अन्य) की पुष्टि की। Stable firmware और व्यापक release पर काम जारी है।
Zondax और Zkool वर्तमान में परिवर्तनशील स्थिति में हैं। Zondax का app वही है जिसे Ledger पर हटाया जा रहा है। Zkool, जो Ledger devices से बात करने के लिए उस app पर निर्भर था, ने यह संकेत नहीं दिया है कि पुराने app के गायब हो जाने के बाद उस भूमिका का क्या होगा। यह अस्पष्ट है कि आगे भी यह Ledger उपयोगकर्ताओं के लिए प्रासंगिक रहेगा या इसका भविष्य मुख्यतः अन्य devices के साथ है।
Migration स्वयं सबसे बड़ा प्रभाव है। क्योंकि pools को पार करने वाली राशि सार्वजनिक होती है, wallets किसी balance को एक दिखाई देने वाले हिस्से में स्थानांतरित करने के बजाय समय के साथ standard denominations में transfers फैलाते हैं, जिसका अर्थ है प्रत्येक migration के लिए sign किए जाने वाले कई transactions। इसी कारण batch PCZT signing hardware wallets के लिए इतना महत्वपूर्ण था।
Ledger के firmware कार्य को hardware limits का भी सामना करना पड़ा: एक वास्तविक note spend एक ही command में हज़ारों cryptographic syscalls तक पहुँच सकता था, जिससे device watchdog trigger हो जाता था। समाधान ने field arithmetic को software में स्थानांतरित किया और Nano X की stack constraints के भीतर फिट होने के लिए shared scratch state की आवश्यकता पड़ी।
https://forum.zcashcommunity.com/t/ironwood-is-here-updated-wallets-libraries-aug-20/56557/40
एक चित्र में विकास
