# NI-DKG का परिचय: zkSNARK पर आधारित नॉन-इंटरैक्टिव Distributed Key Generation प्रोटोकॉल

थ्रेशोल्ड होमोमॉर्फिक एन्क्रिप्शन [DAVINCI](https://davinci.vote) मतदान प्रोटोकॉल का एक अहम बुनियादी हिस्सा है। इससे यह पक्का होता है कि कोई भी एक पक्ष अकेले वोट के परिणाम डिक्रिप्ट न कर सके: डिक्रिप्शन कुंजी कई स्वतंत्र नोड में बँटी रहती है, और परिणाम तभी डिक्रिप्ट हो पाते हैं जब उनमें से पर्याप्त नोड मिलकर काम करें।

लेकिन डिक्रिप्शन से पहले उन नोड को मिलकर वह कुंजी बनानी होती है। इसी प्रक्रिया को **Distributed Key Generation (DKG)** कहते हैं। हम DKG का ऐसा रूप बना रहे हैं जो खास तौर पर blockchain के माहौल के लिए डिज़ाइन किया गया है, जहाँ हर प्रतिभागी को on-chain स्वीकार होने से पहले यह साबित करना होता है कि उसका योगदान सही है।

**DAVINCI** मतदान प्रक्रिया की **गोपनीयता** **थ्रेशोल्ड होमोमॉर्फिक एन्क्रिप्शन** स्कीम से पक्की करता है। खास तौर पर, elliptic curve पर [threshold ElGamal cryptosystem](https://github.com/tompetersen/threshold-crypto) इस्तेमाल होता है। एन्क्रिप्टेड संदेशों को आपस में मिलाकर मूल plaintext के योग का एन्क्रिप्शन पाया जा सकता है, और इसके लिए उन्हें डिक्रिप्ट करने की ज़रूरत नहीं पड़ती। इस स्कीम से किसी खास ciphertext को डिक्रिप्ट किया जा सकता है और थ्रेशोल्ड गुप्त कुंजी कभी उजागर नहीं होती, यानी आखिरी गिनती डिक्रिप्ट हो जाती है जबकि हर मतपत्र गोपनीय बना रहता है।

### **प्रोटोकॉल का खाका**

NI-DKG एक blockchain-नेटिव प्रोटोकॉल है, जिसे पूरी तरह **नॉन-इंटरैक्टिव** रखने के लिए इस तरह बनाया गया है कि सही होने की जाँच जमा करने के वक्त ही ZK प्रमाण से हो जाए।

शिकायत के चरणों और विवाद के दौरों के बजाय, **हर प्रतिभागी को जमा करते ही यह साबित करना होता है कि उसका योगदान सही है**। स्मार्ट कॉन्ट्रैक्ट प्रमाण की जाँच तुरंत करता है: वैध सबमिशन स्वीकार होते हैं, गलत वहीं खारिज हो जाते हैं। न कोई आगे-पीछे की बातचीत होती है, न बाद में चुनौती देने की गुंजाइश। और चूँकि पूरा ट्रांसक्रिप्ट on-chain दर्ज रहता है, इसलिए हमें **सार्वजनिक सत्यापन क्षमता** भी मिलती है।

डिज़ाइन से ही नॉन-इंटरैक्टिव होने के अलावा, NI-DKG प्रोटोकॉल **व्यवहार में संचालन के स्तर पर एसिंक्रोनस** भी है। इसके चरण नाज़ुक जवाबी समय-सीमाओं के बजाय ब्लॉक नंबर से तय होते हैं।

### **यह क्यों मायने रखता है**

आज के blockchain-आधारित DKG प्रोटोकॉल विवाद के चरणों पर टिके हैं: अगर किसी नोड को खराब डेटा मिले, तो वह on-chain शिकायत दर्ज कराता है, और आरोपित को तय समय-सीमा में जवाब देना होता है। इससे और दौर जुड़ते हैं, gas की लागत बढ़ती है और हमले की सतह चौड़ी होती है: ईमानदार नोड सिर्फ़ देर से जवाब देने पर बाहर हो सकते हैं, और बदनीयत लोग प्रक्रिया अटकाने के लिए बेमतलब शिकायतें दर्ज करा सकते हैं। पूरी तरह एसिंक्रोनस DKG पर हाल के अकादमिक काम ने प्रभावशाली सैद्धांतिक नतीजे दिए हैं, लेकिन वे प्रोटोकॉल बहुत पेचीदा हैं।

सबसे अहम बात, NI-DKG पूरी तरह जाने-पहचाने **मानक क्रिप्टोग्राफ़िक प्रिमिटिव** से बना है। हम कोई नई धारणा नहीं जोड़ते, बल्कि जमी-जमाई तकनीकों को ज़्यादा व्यावहारिक तरीके से इस्तेमाल करते हैं। यह प्रोटोकॉल एक **व्यावहारिक और ज़मीनी बीच का रास्ता** अपनाता है: पूरी तरह एसिंक्रोनस रचनाओं से सरल, फिर भी सीधे-सादे सिंक्रोनस स्कीमों से ज़्यादा मज़बूत। यह अपने नीचे चल रही blockchain का टाइमिंग मॉडल अपनाता है, जो on-chain एप्लिकेशन के लिए स्वाभाविक है, और उसके साथ पहले से तैयार zero-knowledge प्रमाण जोड़कर शिकायत की इंटरैक्टिव प्रक्रिया हटा देता है, जो मौजूदा ढाँचों की एक आम कमज़ोरी है। नतीजा एक ज़्यादा सुरक्षित प्रोटोकॉल है, जो असल दुनिया में इस्तेमाल के लिए खूब जँचता है।

### **NI-DKG प्रोटोकॉल के चरण**

**_जनरेशन_**

1. **शुरुआत:** आयोजक पैरामीटर `(n, t)` पोस्ट करता है।
2. **हाज़िरी:** पात्र नोड अपनी तैयारी का संकेत देते हैं (चाहें तो stake के साथ)।
3. **नोड का चयन**: chain की रैंडमनेस से `n` नोड चुने जाते हैं, और अगर नीति पूरी न हो तो प्रक्रिया रोक दी जाती है।
4. **मुख्य DKG प्रक्रिया:** हर नोड polynomial कमिटमेंट और एन्क्रिप्टेड कुंजी-टुकड़े पोस्ट करता है, साथ में सही होने का ZK प्रमाण।
5. **समापन:** आयोजक सार्वजनिक कुंजी `PK` और निजी टुकड़ों के कमिटमेंट निकालता है, और इन्हें सही होने के ZK प्रमाण के साथ blockchain पर पोस्ट करता है।

![सिलसिलेवार चित्र, जिसमें तीन खड़ी रेखाएँ हैं: बाईं ओर आयोजक, बीच में प्रतिभागी और दाईं ओर blockchain। वक्त ऊपर से नीचे बढ़ता है और ऊपर गिनाए पाँचों चरण अलग-अलग पट्टियों में बँटे हैं। काले तीर blockchain पर लिखे जाने वाले लेन-देन दिखाते हैं, हरी बिंदीदार रेखाएँ उससे पढ़ी गई जानकारी, और किनारे के छोटे लूप वे हिसाब जो हर पक्ष अपने पास करता है।](/blog/images/2026/03/dkg-process.webp)

**_डिक्रिप्शन_**

1. **ciphertext का प्रकाशन:** एक ciphertext `(C1, C2)` राउंड की पहचान के साथ प्रकाशित होता है। नोड को पता रहता है कि ऐसे ciphertext कब प्रकाशित होते हैं।
2. **आंशिक डिक्रिप्शन का प्रकाशन:** नोड `C1` का आंशिक डिक्रिप्शन प्रकाशित करते हैं, साथ में discrete logarithm की बराबरी का प्रमाण।
3. **डिक्रिप्शन:** जब `t` या उससे ज़्यादा आंशिक डिक्रिप्शन प्रकाशित हो जाएँ, तो संदेश वापस पाने के लिए स्मार्ट कॉन्ट्रैक्ट कॉल किया जा सकता है।

![सिलसिलेवार चित्र, जिसमें तीन खड़ी रेखाएँ हैं: बाईं ओर भेजने वाला, बीच में प्रतिभागी और दाईं ओर blockchain। वक्त ऊपर से नीचे बढ़ता है और ऊपर गिनाए तीनों चरण अलग-अलग पट्टियों में बँटे हैं। काले तीर blockchain पर जाने वाले लेन-देन दिखाते हैं, जिनमें आखिरी पर completeDecryption लिखा है, और हरी बिंदीदार रेखाएँ blockchain से पढ़ी गई जानकारी दिखाती हैं।](/blog/images/2026/03/dkg-decryption.webp)

**_कुंजी का वैकल्पिक खुलासा_**

ध्यान दें कि कुंजी का खुलासा DAVINCI प्रोटोकॉल का हिस्सा नहीं है। आम तौर पर इसकी ज़रूरत नहीं पड़ती, क्योंकि गुप्त कुंजी प्रकाशित किए बिना भी डिक्रिप्शन चरण को साबित किया जा सकता है।

1. **शुरुआत**: गुप्त कुंजी के खुलासे का अनुरोध आयोजक भेज सकता है या यह अपने आप शुरू हो सकता है, बशर्ते नीति के पैरामीटर इसकी इजाज़त दें।
2. **गुप्त कुंजी के टुकड़े प्रकाशित करना:** हर प्रतिभागी नोड गुप्त कुंजी का अपना टुकड़ा प्रकाशित करता है।
3. **गुप्त कुंजी निकालना:** जब `t` या उससे ज़्यादा मान जमा हो जाएँ, तो कोई भी गुप्त कुंजी निकाल सकता है।

![सिलसिलेवार चित्र, जिसमें तीन खड़ी रेखाएँ हैं: बाईं ओर आयोजक, बीच में प्रतिभागी और दाईं ओर blockchain। वक्त ऊपर से नीचे बढ़ता है और ऊपर गिनाए तीनों चरण अलग-अलग पट्टियों में बँटे हैं। आखिरी तीर पर computeSecretKey लिखा है। किनारे पर लगा एक नोट बताता है कि टुकड़ों की तय संख्या on-chain आते ही कोई भी कुंजी बना सकता है, और आखिरी चरण उसे बस सार्वजनिक करता है।](/blog/images/2026/03/dkg-sk-disclosure.webp)

### **भीतर क्या चलता है**

यह प्रोटोकॉल पूरे जीवनचक्र को समेटता है: कुंजी जनरेशन, थ्रेशोल्ड डिक्रिप्शन और कुंजी का वैकल्पिक खुलासा। हर चरण पर स्मार्ट कॉन्ट्रैक्ट तालमेल और सत्यापन की परत का काम करता है, जबकि zero-knowledge प्रमाण भारी क्रिप्टोग्राफ़िक जाँचें off-chain ले जाते हैं। ज़िम्मेदारियों का बँटवारा साफ़ है: blockchain क्रम और सार्वजनिक रिकॉर्ड संभालती है। प्रमाण प्रणाली सही होने की गारंटी देती है।

इसके क्रिप्टोग्राफ़िक बुनियादी हिस्से ये हैं:

- **Shamir + Feldman VSS**: सार्वजनिक coefficient कमिटमेंट वाले polynomial।
- टुकड़े एन्क्रिप्ट करने के लिए **Hashed ElGamal**।
- **Chaum-Pedersen DLOG** बराबरी का प्रमाण, जो आंशिक डिक्रिप्शन के लिए इस्तेमाल होता है।
- on-chain सत्यापन के लिए **zk-SNARKs** (Groth16, FFLONK, …)।

**सर्किट:**

| चरण                                                          | मकसद                                             | आउटपुट / क्या साबित होता है                                                        |
| ------------------------------------------------------------ | ------------------------------------------------ | ---------------------------------------------------------------------------------- |
| जनरेशन चरण 4: मुख्य DKG                                      | हर प्रतिभागी के योगदान का प्रमाण                 | हर प्रतिभागी का DKG योगदान वैध है।                                                 |
| जनरेशन चरण 5: गुप्त टुकड़े और सार्वजनिक कुंजी निकालना        | समापन                                            | आखिरी सार्वजनिक कुंजी और टुकड़ों के कमिटमेंट सही तरीके से निकाले गए हैं।           |
| डिक्रिप्शन चरण 2: आंशिक डिक्रिप्शन का प्रकाशन                | आंशिक डिक्रिप्शन + DLEQ प्रमाण (हर नोड के लिए)   | हर नोड का आंशिक डिक्रिप्शन सही है और उसके साथ सही होने का DLEQ प्रमाण रहता है।     |
| डिक्रिप्शन चरण 3: डिक्रिप्शन                                 | आंशिक डिक्रिप्शन जोड़कर → plaintext              | वैध आंशिक डिक्रिप्शन जोड़ने पर सही plaintext मिलता है।                             |
| कुंजी का वैकल्पिक खुलासा, चरण 2: गुप्त कुंजी के टुकड़े देना  | टुकड़े बनाम कमिटमेंट की जाँच (हर नोड के लिए)     | हर नोड साबित करता है कि उसका उजागर किया टुकड़ा पहले प्रकाशित कमिटमेंट से मेल खाता है।     |
| कुंजी का वैकल्पिक खुलासा, चरण 3: गुप्त कुंजी निकालना         | _t_ टुकड़ों से गुप्त कुंजी दोबारा बनाना          | थ्रेशोल्ड (_t_) टुकड़ों से गुप्त कुंजी दोबारा बनाना सही है।                        |

### **सीमाएँ**

चूँकि चरण ब्लॉक नंबर से बँधे हैं, इसलिए प्रोटोकॉल अपनी host chain की आंशिक सिंक्रोनी अपना लेता है। on-chain सत्यापन भी स्केलिंग की पाबंदियाँ लगाता है, फिर भी पेपर में बताई गई इनपुट घटाने की रणनीतियों के साथ हम व्यावहारिक तौर पर **40-50 प्रतिभागियों की समितियाँ संभाल सकते हैं**। ज़्यादातर व्यावहारिक इस्तेमाल के लिए जितना दायरा चाहिए, यह उससे कहीं ज़्यादा है।

हालाँकि यह DKG लचीला है और दूसरी एन्क्रिप्शन स्कीमों के मुताबिक ढाला जा सकता है, BN254 पर Groth16 इस्तेमाल करने का मतलब है कि सबसे कारगर विकल्प वही एन्क्रिप्शन स्कीम है जो BN254 scalar field पर बनी हो, यानी BabyJubJub curve वाली।

### **हम कहाँ तक पहुँचे**

**प्रोटोकॉल का डिज़ाइन पूरा हो चुका है**। एक ड्राफ़्ट रिसर्च पेपर पूरी रचना बताता है, सर्किट का विस्तृत ब्यौरा देता है और on-chain लागत घटाने की रणनीतियों का विश्लेषण करता है। अगला कदम तय EVM चेन पर **इंप्लीमेंटेशन और बेंचमार्किंग** है।\
\
बुनियादी स्कीमा जाँचने के लिए एक Golang PoC [यहाँ](https://github.com/vocdoni/davinci-node/tree/main/crypto/elgamal/dkg) है।

पूरा पेपर [यहाँ](https://eprint.iacr.org/2026/552) उपलब्ध है।

यह open source है। अगर आप योगदान देना चाहें, तो हमसे संपर्क करें, चाहे डेवलपमेंट से, विचारों से, संसाधनों से या आर्थिक मदद से।

[संपर्क करें](https://chat.vocdoni.io)

---