Ethereum के लिए गुमनाम बाध्यकारी मतदान की राह

गुमनामी मतदाता की गोपनीयता की रक्षा करती है और राय खुलकर रखने की गुंजाइश बनाती है, जिससे दबाव या बदले की कार्रवाई का खतरा घट जाता है। दूसरी तरफ़ सेंसरशिप-रोधकता यह पक्का करती है कि कोई अकेली इकाई मतदान के अधिकार में हेरफेर या उससे इनकार न कर सके, और इस तरह लोकतांत्रिक प्रक्रिया और ज़्यादा विकेंद्रित, निष्पक्ष और खुली बनती है।

Vocdoni में हमारा मुख्य मकसद ऐसी तकनीक तैयार करना है जिससे Ethereum blockchain के भीतर मतदान बिना किसी अड़चन और पूरी सुरक्षा के हो सके, खास तौर पर DAO (विकेंद्रित स्वायत्त संगठन) की दुनिया के लिए। हम off-chain, बिना gas वाले, गुमनाम मतदान की एक नई व्यवस्था बनाना चाहते हैं, जिसका निष्पादन बाध्यकारी हो।

यह दस्तावेज़ बताता है कि इस महत्वाकांक्षी मिशन से हम कैसे निपटना चाहते हैं। इसे नीचे दिए मुख्य हिस्सों में बाँटा गया है:

• पूरी मतदाता सूची बनाना और उसे सत्यापित करना
• ECDSA हस्ताक्षरों में nullifier के नियत न होने की समस्या सुलझाना
• off-chain वोट डालने की व्यवस्था
• वोट एग्रीगेटर की भूमिका और काम
• मतदान के परिणाम Ethereum पर चढ़ाने की प्रक्रिया

1. सत्यापित मतदाता सूची¶

किसी भी मतदान प्रणाली के मूल हिस्से के तौर पर मतदाता सूची का काम है पात्र मतदाताओं को गिनना और उनके वोट का वज़न तय करना। लेकिन Ethereum blockchain के डेटा से मतदाता सूची बनाने की अपनी अलग पेचीदगियाँ हैं। जैसे:

• डेटा संरचना: Ethereum blockchain का डेटा ऐसी शक्ल में नहीं रखा जाता जिससे मतदाता सूची बनाना आसान हो। मिसाल के लिए, किसी ERC20 टोकन के मामले में ऐसी कोई अलग डेटा संरचना नहीं है जो टोकन रखने वालों की पूरी सूची संभालकर रखे।
• क्रिप्टोग्राफ़ी की अनुकूलता: Ethereum की क्रिप्टोग्राफ़ी बुनियादी तौर पर zkSnarks के अनुकूल नहीं है, जिससे zero-knowledge प्रमाण बनाना और जाँचना और मुश्किल हो जाता है।

तो सबसे बड़ी चुनौती यह है कि टोकन पर आधारित, zkSnark के अनुकूल मतदाता सूची बिना किसी भरोसे की शर्त के बनाई जाए, ताकि off-chain मतदान हो सके। यह भी ध्यान में रखना ज़रूरी है कि ERC20 लेनदेन कभी भी हो सकते हैं, यानी मतदाता सूची एक ब्लॉक से दूसरे ब्लॉक के बीच काफ़ी बदल सकती है।

इन चुनौतियों से पार पाने के लिए हम यह तरीका सुझाते हैं:

• off-chain मतदाता सूची: zkSnark के अनुकूल off-chain मतदाता सूची बनाएँ।
• प्रमाण तैयार करना: मतदाता सूची के सही होने की पुष्टि के लिए zkSnark प्रमाण तैयार करें।
• on-chain पुष्टि: मतदाता सूची बनाने के प्रमाण की पुष्टि स्मार्ट कॉन्ट्रैक्ट से on-chain करें।
• मतदान की सुविधा: पुष्टि हो जाने पर उस मतदाता सूची का इस्तेमाल मतदान के लिए किया जा सकता है।

Ethereum पर मतदाता सूची की पुष्टि दो तरीकों से हो सकती है:

• बैलेंस जाँच: स्मार्ट कॉन्ट्रैक्ट balanceOfAt() फ़ंक्शन चलाकर सभी (या कुछ चुने हुए) टोकन रखने वालों के सही होने की पुष्टि करता है। लेकिन इस तरीके में भेजने वाले पर लेनदेन की लागत ज़्यादा पड़ सकती है।
• स्टोरेज प्रूफ़: मतदाता सूची का zkProof स्टोरेज प्रूफ़ से बनाया जाता है, और कॉन्ट्रैक्ट पिछले Ethereum State Root के हिसाब से उसकी जाँच करता है। मतदाता सूची बनाने वाले के लिए यह तरीका कंप्यूटेशन के लिहाज़ से महँगा पड़ सकता है, लेकिन यह मज़बूत हल देता है।

हमें लगता है कि बैलेंस जाँच वाला तरीका छोटे DAO (100-200 सदस्य) के लिए ज़्यादा ठीक बैठता है। वहीं स्टोरेज प्रूफ़ उन बड़े संगठनों के लिए बेहतर रहेगा जो ज़्यादा बड़े कंप्यूटेशनल इन्फ़्रास्ट्रक्चर का खर्च उठा सकते हैं।

2. nullifier के नियत न होने की दिक्कत¶

क्रिप्टोग्राफ़िक प्रणालियों के साथ काम करते समय नियतता (determinism) बेहद ज़रूरी है - एक ही इनपुट से हमेशा एक ही आउटपुट निकलना चाहिए। लेकिन Ethereum के हस्ताक्षरों के साथ यहीं अड़चन आ जाती है।

ECDSA हस्ताक्षरों में एक मनमाना nonce होता है - ऐसा नंबर जो एक ही बार या बहुत कम बार इस्तेमाल होता है। हस्ताक्षर करने वाला इस nonce को बदलकर एक ही payload से अलग-अलग हस्ताक्षर बना सकता है। नतीजा? आउटपुट नियत नहीं रहता - एक ही इनपुट से अलग-अलग आउटपुट।

आउटपुट का यही नियत न होना तब रुकावट बन जाता है जब nullifier निकालना हो, जो दोहरा वोट रोकने का बुनियादी ज़रिया है। nullifier हर वोट की एक अलग पहचान होती है। जब वोट डाला जाता है, तो nullifier blockchain पर एक सार्वजनिक सूची में दर्ज हो जाता है।

नियत nullifier बनाने के लिए नियत हस्ताक्षर व्यवस्था चाहिए। और चूँकि ECDSA हस्ताक्षर अनियत होते हैं, वे nullifier बनाने के काम में ठीक से नहीं बैठते। यानी Ethereum पर गुमनाम बाध्यकारी मतदान प्रणाली में दोहरा वोट रोकने की कोशिश में हम अटक जाते हैं।

हम कमिटमेंट कुंजियों की एक वैश्विक रजिस्ट्री (Global Registry of Commitment Keys) का विचार सामने रखते हैं। इस रजिस्ट्री को एक स्मार्ट कॉन्ट्रैक्ट संभालता है, जो Ethereum पते को कमिटमेंट कुंजी से जोड़ने वाले नक्शे का काम करता है। इसकी बुनियादी संरचना यह है: Ethereum Address => hash(secret)।

कमिटमेंट कुंजी उपयोगकर्ता के गुप्त मान से बनती है और Ethereum पते को एक नियत आउटपुट से बाँधने में मदद करती है, जिससे नियतता बनी रहती है, और हमारे इस्तेमाल के लिए यही सबसे ज़रूरी है।

कुंजी और पते का यह नक्शा Ethereum blockchain पर Snark-अनुकूल Merkle ट्री के रूप में रखा जाता है। इस काम के लिए Merkle ट्री खास तौर पर मुफ़ीद हैं, क्योंकि इनसे बड़ी मात्रा में डेटा रखने और जाँचने की ऐसी व्यवस्था बनती है जो छेड़छाड़-रोधी भी है और तेज़ भी, और हमारे मामले में यह ज़रूरी शर्त है।

वोट डालते समय उपयोगकर्ता को एक zkSNARK प्रमाण देना होता है। यह प्रमाण दिखाता है कि उपयोगकर्ता को कमिटमेंट कुंजी का गुप्त मान पता है, और वह कुंजी Ethereum पर रखे Commitment-Key Merkle ट्री का हिस्सा है। इससे हम ऐसी मतदान प्रणाली बना पाते हैं जो सुरक्षित हो, गुमनाम हो और दोहरे वोट को रोक सके, और इसके लिए ECDSA हस्ताक्षरों में नियतता की ज़रूरत नहीं पड़ती।

3. off-chain वोट डालना¶

सत्यापित मतदाता सूची और वैश्विक रजिस्ट्री का Merkle root तैयार हो जाने के बाद मतपत्र डालने की प्रक्रिया शुरू हो सकती है।

वोट डालने के लिए उपयोगकर्ता को दो बातें साबित करनी होती हैं:

• मतदाता सूची में शामिल होना: उपयोगकर्ता का पता और बैलेंस मतदाता सूची का हिस्सा हैं।
• गुप्त कुंजी की जानकारी: वैश्विक रजिस्ट्री में उसके पते से जुड़े कमिटमेंट की गुप्त कुंजी उपयोगकर्ता को पता है।

इसके बाद उपयोगकर्ता zkSnark प्रमाण बनाता है, जिससे उसकी पहचान गुमनाम हो जाती है और एक nullifier तैयार होता है। यह nullifier गुप्त कुंजी को प्रस्ताव की अलग पहचान के साथ हैश करके नियत तरीके से निकाला जाता है।

ध्यान दें कि इस व्यवस्था में, चूँकि वैश्विक रजिस्ट्री खुद zkSnark के अनुकूल Merkle ट्री है, हमें सर्किट के भीतर Ethereum की क्रिप्टोग्राफ़ी (secp256k1) इस्तेमाल नहीं करनी पड़ती। नतीजा यह कि मतपत्र बनाना ज़्यादा तेज़ हो जाता है और ब्राउज़र में भी आसानी से चल जाता है।

मतपत्र और प्रमाण को एक पैकेट में बाँधकर एग्रीगेटरों के peer-to-peer (p2p) नेटवर्क में बाँट दिया जाता है। सेंसरशिप-रोधकता हासिल करने के लिए विकेंद्रित p2p नेटवर्क बुनियादी शर्त है, क्योंकि इससे कोई अकेली इकाई मतदान प्रक्रिया पर काबू नहीं पा सकती और न ही उसमें हेरफेर कर सकती है।

4. वोट जोड़ने की प्रक्रिया¶

वोट डल जाने के बाद उन्हें जोड़कर एक समग्र zkSnark प्रमाण बनाना होता है। यह जोड़ एक ही बार में भी हो सकता है और बैच में भी। इस दौरान बनने वाला प्रमाण इन बातों की पुष्टि करता है:

• मतदाता सूची का एक तय root हैश
• वैश्विक रजिस्ट्री का एक ही root हैश
• मान्य वोट nullifier की सूची
• मतदान के परिणामों का सही होना

चूँकि मूल वोट खुद zkSnark प्रमाण होते हैं, इसलिए जोड़ने की प्रक्रिया में एक स्तर की रिकर्शन ज़रूरी हो जाती है, यानी एक zkSnark दूसरे zkSnark के सही होने को साबित करता है।

लेकिन आज की तकनीक जहाँ है, और Ethereum की elliptic curve के साथ सीमित अनुकूलता को देखते हुए, इस रिकर्सिव तरीके से प्रमाण बनाना बड़ी चुनौती है। इसमें जो पेचीदगियाँ हैं, उनका मतलब है कि शायद हमें zkSnark के ढाँचों में और Ethereum में zkSnark क्रिप्टोग्राफ़ी के बेहतर समर्थन का इंतज़ार करना पड़े।

5. परिणाम Ethereum पर चढ़ाना¶

वोट जुड़ जाने के बाद कोई भी उपयोगकर्ता आखिरी प्रमाण Ethereum के स्मार्ट कॉन्ट्रैक्ट को भेज सकता है। स्मार्ट कॉन्ट्रैक्ट की ज़िम्मेदारी इन बातों की पुष्टि करना है:

• परिणामों का प्रमाण: परिणामों का प्रमाण सही है।
• मतदाता सूची का root: मतदाता सूची का root वही है जिसकी पहले पुष्टि हुई थी।
• वैश्विक रजिस्ट्री का root: वैश्विक रजिस्ट्री का root सही है।
• मतदान की समय-सीमा: मतदान की अवधि पहले से तय समय-सीमा के मुताबिक है।

इन सब बातों की पुष्टि हो जाने पर स्मार्ट कॉन्ट्रैक्ट Ethereum पर मतदान प्रक्रिया से जुड़े पहले से तय काम कर सकता है। यह प्रक्रिया वोटों की वैधता और विश्वसनीयता पक्की करती है और उन पर अमल करना आसान बनाती है।