DAVINCI पेपर IACR ePrint Archive पर आ गया है। मतपत्रों का प्रमाण फ़ोन के ब्राउज़र में ही बनता है, सीक्वेंसर अब ZisK zkVM के लिए लिखा गया एक Rust प्रोग्राम है, हमने ZisK के मुख्य कोडबेस में एक BabyJubJub precompile का योगदान दिया है, और एक GPU हर सेकंड करीब 6 वोट सेटल करता है।
Pau Escrich
· पढ़ने में 17 मिनट
हमने अभी-अभी DAVINCI पेपर IACR Cryptology ePrint Archive पर प्रकाशित किया है: eprint.iacr.org/2026/2282। पहली बार पूरा प्रोटोकॉल एक ही जगह लिखा गया है, जिसमें सुरक्षा विश्लेषण के साथ एक चालू इंप्लीमेंटेशन और उससे निकले असली आँकड़े भी हैं। इसे Pau Escrich ने Marta Bellés-Muñoz (Universitat Pompeu Fabra), Roger Baig (Universitat Politècnica de Catalunya) और Jordi Piñana (Vocdoni) के साथ मिलकर लिखा है।
अगर आप यह ब्लॉग पढ़ते आए हैं, तो आइडिया आप जानते हैं: चुनाव एक ZK rollup है। मतदाता अपने मतपत्र एन्क्रिप्ट करते हैं, कोई भी सीक्वेंसर चला सकता है जो उन्हें बैच में समेटता है और साबित करता है कि बैच नियमों के मुताबिक प्रोसेस हुआ, और Ethereum चुनाव की नई स्टेट तभी मानता है जब प्रमाण सही निकले। प्रमाण नहीं, तो स्टेट अपडेट नहीं, और नकली नतीजा भी नहीं।
पेपर में नया है इसका इंजीनियरिंग पक्ष। यह पोस्ट उसी हिस्से के बारे में है: फ़ोन के ब्राउज़र में किसी वोट का प्रमाण कैसे बनता है, सीक्वेंसर को ZisK zkVM के प्रोग्राम के रूप में दोबारा कैसे लिखा गया, इसे तेज़ बनाने के लिए हमने ZisK के मुख्य कोडबेस में कौन-सा precompile जोड़ा, और इस सबकी लागत कितनी है।
DAVINCI में प्रमाण बनाने के दो बिल्कुल अलग काम हैं, इसलिए यह दो बिल्कुल अलग प्रूवर इस्तेमाल करता है।
मतदाता का काम छोटा है और उसे कहीं भी चल पाना चाहिए। मतपत्र सर्किट Circom में लिखा गया है, और प्रमाण ब्राउज़र में snarkjs से बनता है, BN254 पर एक Groth16 प्रमाण के रूप में। सर्किट जाँचता है कि:
इसमें करीब 65K कंस्ट्रेंट हैं और यह 16 तक एन्क्रिप्टेड फ़ील्ड संभालता है, जो एकल विकल्प, बहुविकल्प, अनुमोदन, वरीयता-क्रम और क्वाड्रैटिक मतपत्रों को एन्कोड करने के लिए काफ़ी है।
इस हिस्से के लिए हम जानबूझकर Circom और snarkjs पर टिके हैं। snarkjs किसी भी आधुनिक ब्राउज़र में WebAssembly पर चलता है, काम को कई web workers में बाँटकर समानांतर चलाता है, और Groth16 के लिए हमें अब तक मिला सबसे परिपक्व ब्राउज़र प्रूवर है। पूरी चीज़ एक स्टैटिक वेब पेज के रूप में चलती है: किसी को नेटिव प्रूवर इंस्टॉल नहीं करना पड़ता, और किसी को अपना बिना एन्क्रिप्ट किया वोट किसी प्रूविंग सेवा को नहीं भेजना पड़ता। मतदान ऐप के लिए यह बात प्रमाण में एक सेकंड बचाने से ज़्यादा मायने रखती है।
एक मतपत्र का प्रमाण बनाने में लैपटॉप (AMD Ryzen AI 5 340, Brave) पर करीब 3 सेकंड लगते हैं, और Chrome चला रहे Google Pixel 7a पर करीब 6.4 सेकंड। यह 35.5 MiB की प्रूविंग कुंजी और 6.5 MiB के witness जनरेटर को एक बार डाउनलोड करने के बाद की बात है। फ़ोन के लिए यह बस एक प्रोग्रेस बार है, कोई समस्या नहीं।
सीक्वेंसर का काम बड़ा है और सर्वर पर चलता है। हर बैच के लिए उसे:
ZisK यहीं काम आता है।
अब तक सीक्वेंसर का लॉजिक हाथ से लिखे सर्किटों में रहता था। सर्किट अपना काम बढ़िया करते हैं, पर बदलाव के मामले में बेहद खराब हैं: नियम में हर छोटे बदलाव का मतलब है कंस्ट्रेंट दोबारा निकालना, setup दोबारा चलाना और ऑडिट दोबारा कराना। जिस प्रोटोकॉल के बारे में हमें उम्मीद है कि वह आगे भी बदलता रहेगा, उसके लिए यह हर सुधार पर लगने वाला टैक्स है।
ZisK एक ओपन-सोर्स zkVM है, यानी एक zero-knowledge वर्चुअल मशीन, जिसे प्रमाण बनाने को तेज़ और सस्ता करने के लिए बनाया गया है। आप गहरी क्रिप्टोग्राफ़िक विशेषज्ञता के बिना Rust (या C++ या Go जैसी दूसरी उच्च-स्तरीय भाषाओं) में प्रोग्राम लिखते हैं, और इसकी आर्किटेक्चर 128-बिट सुरक्षा के साथ कम लेटेंसी और कम लागत पर केंद्रित है। यह Polygon Labs में एक प्रोजेक्ट के रूप में शुरू हुआ, जिसे Polygon zkEVM के पीछे वाली टीम ने बनाया; जून 2025 में उस टीम ने इसे स्वतंत्र रूप से आगे बढ़ाया, और अब इसे SilentSig एक ओपन-सोर्स, समुदाय-संचालित प्रोजेक्ट के रूप में सँभालता है।
हमारे लिए यह ऐसे काम करता है: आप सामान्य Rust लिखते हैं, उसे RISC-V के लिए कंपाइल करते हैं, और ZisK एक STARK प्रमाण बनाता है कि प्रोग्राम दिए गए इनपुट पर सही चला। STARK ऐसा प्रमाण है जिसे किसी trusted setup की ज़रूरत नहीं होती और जो जल्दी बनता है, पर बदले में उसका आकार बड़ा होता है। DAVINCI का स्टेट ट्रांज़िशन अब एक ही Rust प्रोग्राम है, जो प्रोटोकॉल का हर नियम लागू करता है, और पेपर के बेंचमार्क ZisK v1.3.0-alpha पर चले हैं।
इसे व्यावहारिक बनाने वाली चीज़ है ZisK के precompile। zkVM हर उस निर्देश (instruction) की कीमत चुकाता है जिसे वह साबित करता है, और क्रिप्टोग्राफ़ी में निर्देश बहुत होते हैं। इसलिए ZisK महँगे प्रिमिटिव को निर्देशों के बजाय अलग, खास सर्किटों में संभालता है:
ट्रांज़िशन प्रोग्राम Keccak को छोड़कर इन सब पर टिका है, और Keccak फिर भी क्यों मायने रखता है, इस पर हम आगे लौटेंगे। उदाहरण के लिए, ब्राउज़र में बने Groth16 प्रमाण एक-एक करके नहीं जाँचे जाते: प्रोग्राम पूरे बैच को एक ही pairing जाँच में समेट देता है, ZisK के BN254 pairing precompile की मदद से, जिसमें हर प्रमाण को ऐसे रैंडम गुणांकों से भार दिया जाता है जो प्रोग्राम खुद प्रमाणों से निकालता है।
STARK इतना बड़ा होता है कि उसे सीधे Ethereum पर नहीं भेजा जा सकता। ZisK उसे रिकर्सिव ढंग से छोटा करता है और नतीजे को BN254 पर एक PLONK प्रमाण में लपेट देता है, जिसे सेटलमेंट कॉन्ट्रैक्ट उन pairing precompile से जाँचता है जो Ethereum में Byzantium से मौजूद हैं। सिर्फ़ वही आखिरी प्रमाण प्रकाशित होता है, और वह zero-knowledge है, इसलिए सीक्वेंसर का witness छिपा रहता है।
STARK को किसी trusted setup की ज़रूरत नहीं; PLONK रैपर Hermez का सार्वभौमिक powers-of-tau इस्तेमाल करता है। पूरी प्रणाली में किसी खास सर्किट के लिए बची एकमात्र ceremony ब्राउज़र वाले मतपत्र सर्किट की है, और वह सभी चुनावों में दोबारा इस्तेमाल होती है।
एक बोनस भी है जो हमें बहुत पसंद है। PLONK रैपर सर्किट ZisK तय करता है; हमारा प्रोग्राम उसमें सिर्फ़ एक कोड कमिटमेंट के रूप में आता है, जिसे सेटलमेंट कॉन्ट्रैक्ट पक्के तौर पर दर्ज रखता है। ट्रांज़िशन प्रोग्राम को अपग्रेड करने का मतलब है एक संग्रहीत कमिटमेंट बदलना, न कि नया वेरिफ़ायर डिप्लॉय करना या नया setup चलाना। प्रोटोकॉल बेहतर होता रहता है और on-chain ढाँचा अपनी जगह टिका रहता है।
DAVINCI मतपत्रों को BabyJubJub पर ElGamal से एन्क्रिप्ट करता है, जो circomlib वाला कर्व है। ब्राउज़र की तरफ़ यह स्वाभाविक विकल्प है: BabyJubJub का बेस फ़ील्ड ही BN254 का स्केलर फ़ील्ड है, इसलिए Circom सर्किट के भीतर एन्क्रिप्शन सीधा नेटिव अंकगणित होता है।
सीक्वेंसर को मतदाता से कहीं ज़्यादा BabyJubJub अंकगणित करना पड़ता है। किसी मतपत्र को दोबारा एन्क्रिप्ट करने में हर ciphertext पर एक स्केलर गुणा होता है, जो पॉइंट जोड़ों की एक लंबी कड़ी है, और एन्क्रिप्टेड गिनती ciphertexts का एक बड़ा, लगातार बढ़ता जोड़ है। यह सब आम RISC-V निर्देशों के रूप में साबित करना ही अड़चन थी।
तो हमने एक precompile लिखा। PR #1152 BabyJubJub पर complete affine पॉइंट जोड़ को एक खास ZisK प्रिमिटिव के रूप में जोड़ता है (वही फ़ॉर्मूला doubling भी संभालता है), और यह circomlib के कर्व पैरामीटर के साथ संगत है। ZisK टीम ने इसकी समीक्षा की, इसे अपनी अंदरूनी परिपाटियों के मुताबिक ढाला, और 27 अगस्त को मर्ज कर दिया। यह 21 सितंबर को ZisK v1.3.0-alpha में रिलीज़ हुआ, जहाँ रिलीज़ नोट्स में इसका ज़िक्र "a dedicated BabyJubJub point-add precompile compatible with circomlib" के रूप में है। Héctor Masip और ZisK टीम के बाकी सदस्यों का शुक्रिया कि उन्होंने हमें किसी फ़ोर्क पर छोड़ने के बजाय इसे ZisK के मुख्य कोडबेस में शामिल किया।
यही वह कड़ी है जिससे DAVINCI के दोनों हिस्से एक ही क्रिप्टोग्राफ़ी की भाषा बोल पाते हैं। ब्राउज़र Circom सर्किट के भीतर BabyJubJub पर एन्क्रिप्ट करता है; सीक्वेंसर ZisK के भीतर BabyJubJub पर दोबारा एन्क्रिप्ट करता है और जोड़ता जाता है; और दोनों को जोड़ने वाले Groth16 प्रमाण ZisK के BN254 pairing से जाँचे जाते हैं। किसी भी चीज़ को एक कर्व से दूसरे कर्व में बदलना नहीं पड़ता, और circomlib के कर्व पर काम करने वाले बाकी सभी लोगों को भी यही प्रिमिटिव मुफ़्त में मिल जाता है।
DAVINCI के मतदाता अपने वोट आइडेंटिफ़ायर पर उसी ECDSA कुंजी से हस्ताक्षर करते हैं जो उनके Ethereum पते के पीछे है। ZisK यह हस्ताक्षर नेटिव ढंग से जाँचता है, इसलिए पात्रता सादे Ethereum पतों पर एक Merkle प्रमाण भर है, और मतदाता का वॉलेट ही उसका क्रेडेंशियल है, किसी अलग रजिस्ट्रेशन कुंजी की ज़रूरत नहीं।
Keccak वह है जिसे लेकर हम सबसे ज़्यादा उत्साहित हैं। ZK मतदान प्रणालियाँ, DAVINCI समेत, अपनी मतदाता सूची के Merkle ट्री Poseidon से बनाती आई हैं, क्योंकि Poseidon को साबित करना सस्ता है और Keccak को नहीं था। इसकी कीमत on-chain चुकानी पड़ती है: Solidity में एक Poseidon हैश keccak256 से कई गुना महँगा है, जो सिर्फ़ एक opcode है। जो प्रोजेक्ट Poseidon ट्री on-chain रखते हैं, वे हर नई एंट्री पर यह लागत झेलते हैं।
Ethereum पर पहले से मौजूद ज़्यादातर रजिस्ट्री, टोकन स्नैपशॉट और multisig सदस्य सूचियाँ Keccak से हैश करती हैं, इसलिए अब तक ZK मतदान की कोई मतदाता सूची उन्हें बिना रूपांतरण के सीधे इस्तेमाल नहीं कर सकती थी। अब जब ZisK Keccak को नेटिव ढंग से साबित करता है, तो सीक्वेंसर किसी Keccak ट्री में सदस्यता जाँच सकता है, उस लागत के बिना जिसकी वजह से पहले यह रास्ता बंद था। कोई DAO अपनी मतदाता रजिस्ट्री on-chain उसी हैश से रख सकता है जो वह पहले से इस्तेमाल करता है, और DAVINCI उसे सीधे इस्तेमाल कर सकता है।
पेपर का प्रोटोटाइप अभी भी मतदाता सूची के लिए Poseidon Merkle ट्री और स्टेट ट्री के लिए SHA-256 इस्तेमाल करता है, इसलिए Keccak वाली मतदाता सूचियों को बेंचमार्क किया हुआ कदम नहीं, अगला कदम समझिए। पर यह बदलाव जितना लगता है उससे सस्ता है: मतदाता सूची का प्रमाण सीक्वेंसर जाँचता है, मतपत्र सर्किट नहीं, इसलिए Keccak मतदाता सूची के लिए बदलाव Rust प्रोग्राम में करना होगा, ब्राउज़र सर्किट या उसकी ceremony में नहीं।
सीक्वेंसर के सारे आँकड़े एक ही मशीन से हैं: NVIDIA RTX 5090 (32 GiB), 16-कोर AMD Ryzen 9 9950X3D और 64 GiB RAM। मापा गया समय सीक्वेंसर का क्रिटिकल पाथ है, यानी जॉब भेजे जाने से लेकर जाँचे हुए PLONK प्रमाण तक, जिसमें रिकर्शन, रैपिंग और प्रूवर की अपनी जाँच शामिल है। मतदाता का प्रमाण उसके अपने डिवाइस पर बनता है और इसमें शामिल नहीं है।
लागत दो चीज़ों से तय होती है:
n, यानी सक्रिय मतपत्र फ़ील्ड की संख्या, चुनाव के मतपत्र मोड में। दो विकल्पों में से एक चुनना n = 2 है; कई विकल्पों वाला वरीयता-क्रम या क्वाड्रैटिक मतपत्र सभी 16 इस्तेमाल कर सकता है।तालिका के हर बैच में हर मतपत्र के साथ एक चुपचाप होने वाला रिफ़्रेश भी है (इस पर आगे और), इसलिए ये स्थिर स्थिति के आँकड़े हैं, सबसे अच्छी स्थिति के नहीं।
| बैच | n = 2 समय | n = 2 वोट/s | n = 2 blob | n = 16 समय | n = 16 वोट/s | n = 16 blob |
|---|---|---|---|---|---|---|
| 2 | 15.6 s | 0.1 | 1 | 15.7 s | 0.1 | 1 |
| 64 | 22.5 s | 2.8 | 1 | 30.3 s | 2.1 | 2 |
| 128 | 30.1 s | 4.3 | 1 | 45.7 s | 2.8 | 3 |
| 256 | 46.2 s | 5.5 | 1 | 76.7 s | 3.3 | 5 |
| 512 | 84.3 s | 6.1 | 2 | 164.3 s | 3.1 | 9 |
| 1024 | 171.2 s | 6.0 | 3 | 363.9 s | 2.8 | 17 |
इसे कैसे पढ़ें: हर बैच पर करीब 16 सेकंड की एक तय लागत है, जिसका लगभग सारा हिस्सा रिकर्शन, रैपिंग और जाँच में जाता है। इसके अलावा हर मतपत्र पर n = 2 में करीब 0.11 s और n = 16 में 0.23 s लगते हैं।
बड़े बैच तय लागत को ज़्यादा मतपत्रों में बाँट देते हैं, इसीलिए सादे मतपत्रों के लिए 512 मतपत्रों पर थ्रूपुट करीब 6 वोट प्रति सेकंड तक पहुँचता है, और 16 फ़ील्ड वाले मतपत्रों के लिए 256 मतपत्रों पर 3.3 वोट प्रति सेकंड तक। उसके बाद मतदाता सूची के प्रमाण गहरे होते जाते हैं, और 512 मतपत्रों से ऊपर प्रूवर RAM बचाने के लिए कुछ प्रतिशत रफ़्तार छोड़ देता है; 1024 इंप्लीमेंटेशन की ऊपरी सीमा है, जो होस्ट मेमोरी से तय होती है (उस आकार पर करीब 41 GB), इसीलिए तालिका वहीं रुक जाती है।
एक आम उपभोक्ता GPU पर छह वोट प्रति सेकंड का मतलब है एक ही सीक्वेंसर से हर घंटे 21,000 से ज़्यादा वोट। एक चुनाव के भीतर बैच स्टेट रूटों की एक कड़ी होते हैं और कॉन्ट्रैक्ट उन्हें क्रम से सेटल करता है, इसलिए अगर दो सीक्वेंसर एक ही रूट पर होड़ करें तो उनमें से एक का प्रमाण बेकार जाता है; ये आँकड़े प्रति चुनाव, प्रति सीक्वेंसर हैं। अलग-अलग चुनावों में सीक्वेंसर अनुमति-मुक्त और स्वतंत्र हैं, इसलिए लोग जितनी मशीनें जोड़ते हैं, क्षमता उतनी बढ़ती है।
हर स्लॉट अपडेट EIP-4844 blob में प्रकाशित होता है ताकि कोई भी स्टेट दोबारा बना सके, और EIP-7594 एक ट्रांज़ैक्शन में ज़्यादा से ज़्यादा छह blob की सीमा लगाता है। n = 16 वाले कॉलमों की नीचे की दो पंक्तियाँ (9 और 17 blob) यह सीमा तोड़ देती हैं, इसलिए वे सिर्फ़ प्रूविंग के आँकड़े हैं; mainnet पर सेटल करने वाला सीक्वेंसर n के हिसाब से बैच का आकार चुनता है, और सबसे अच्छे थ्रूपुट वाले कॉन्फ़िगरेशन आराम से सीमा में आ जाते हैं।
एक बैच सेटल करने में एक blob के साथ करीब 498K gas, और हर अतिरिक्त blob पर करीब 56K और लगती है, बैच का आकार चाहे जो हो। PLONK प्रमाण जाँचने का काम उतना ही है चाहे बैच में 2 मतपत्र हों या 1024, इसलिए प्रति वोट लागत बैच की लागत को बैच के आकार से भाग देकर निकलती है। बड़े बैच प्रति वोट सस्ते पड़ते हैं; ज़्यादा मतपत्र फ़ील्ड का मतलब है ज़्यादा blob और थोड़ा महँगा बैच।
नीचे की तालिका बेंचमार्क के हर सेटल हो सकने वाले कॉन्फ़िगरेशन की कीमत mainnet के लिए 1 gwei और 2,500 USD प्रति ETH पर लगाती है, जो जानबूझकर सतर्क अनुमान है: जिस दिन हमने यह लिखा, Etherscan का औसत 0.12 gwei था, और पिछले एक साल का मीडियन 0.74 gwei था। Gnosis Chain के लिए हम उसका मीडियन 5.2 gwei लेते हैं, जो 1 USD वाले xDAI में चुकाया जाता है। लागत gas की कीमत के सीधे अनुपात में बदलती है, इसलिए आज के 0.12 gwei पर mainnet वाले कॉलम को आठ से भाग दीजिए, और 5 gwei के उछाल पर पाँच से गुणा कीजिए।
| मतपत्र फ़ील्ड | बैच | Blob | प्रति बैच gas | Mainnet, प्रति बैच | Mainnet, प्रति वोट | Gnosis, प्रति वोट |
|---|---|---|---|---|---|---|
| 2 | 64 | 1 | 498K | 1.25 USD | 1.9 सेंट | 0.004 सेंट |
| 2 | 128 | 1 | 498K | 1.25 USD | 1.0 सेंट | 0.002 सेंट |
| 2 | 256 | 1 | 498K | 1.25 USD | 0.5 सेंट | 0.001 सेंट |
| 2 | 512 | 2 | 554K | 1.39 USD | 0.27 सेंट | 0.0006 सेंट |
| 2 | 1024 | 3 | 612K | 1.53 USD | 0.15 सेंट | लागू नहीं (नीचे देखें) |
| 16 | 64 | 2 | 554K | 1.39 USD | 2.2 सेंट | 0.0045 सेंट |
| 16 | 128 | 3 | 612K | 1.53 USD | 1.2 सेंट | लागू नहीं (नीचे देखें) |
| 16 | 256 | 5 | ~722K | ~1.80 USD | 0.7 सेंट | लागू नहीं (नीचे देखें) |
1 gwei पर, 1024 मतपत्रों वाले बैचों में 10 लाख सादे मतपत्र वाले वोट करीब 1,500 USD में सेटल होते हैं, और आज की gas कीमत पर 200 USD से कम में। पेपर में मापे गए सेटलमेंट आँकड़े चार blob तक जाते हैं; पाँच blob वाली पंक्ति उसी 56K के कदम से आगे का अनुमान है।
Gnosis Chain पर यही जाँच करीब 500 गुना सस्ती है, क्योंकि वहाँ gas डॉलर से बँधे टोकन में चुकाई जाती है, और कीमतें ऐसी हैं कि पूरा बैच करीब चौथाई सेंट में निपट जाता है। वहाँ सीमा अलग है: Gnosis का एक ब्लॉक ज़्यादा से ज़्यादा दो blob ले जाता है, जिससे एक ट्रांज़िशन दो फ़ील्ड वाले चुनावों में 744 मतपत्रों और सोलह फ़ील्ड वालों में 121 मतपत्रों तक सीमित हो जाता है।
इन सीमाओं के भीतर Gnosis पर 10 लाख सादे मतपत्र वाले वोट 5 USD से कम में सेटल होते हैं, यानी हर वोट करीब 0.0004 सेंट। ज़्यादातर संगठनों के लिए Gnosis पर सेटलमेंट की लागत GPU समय के आगे नाममात्र की है।
blob फ़ीस एक अलग बाज़ार है और तालिका में शामिल नहीं है; mainnet पर हमारे मापने के दौरान वह जाँच की लागत से कहीं कम थी, और Gnosis पर 1 gwei की न्यूनतम blob फ़ीस हर blob पर करीब 0.0001 USD जोड़ती है।
इन बेंचमार्क में रिफ़्रेश इसलिए शामिल हैं क्योंकि DAVINCI हर बैच पर दबाव-रोधकता की कीमत चुकाता है, और हम असली लागत मापना चाहते थे, दिखावटी नहीं।
मतदाता कभी भी दोबारा वोट डाल सकता है, और सबसे नया मतपत्र पुराने की जगह ले लेता है। पर स्टेट ट्री में मतदाता का स्लॉट सार्वजनिक है, इसलिए blob पर नज़र रखने वाला कोई भी व्यक्ति उस स्लॉट को बदलते देख सकता है और जान सकता है कि दोबारा वोट डाला गया।
इसे छिपाने के लिए हर स्टेट ट्रांज़िशन बाकी संग्रहीत मतपत्रों के एक रैंडम सेट को री-रैंडमाइज़ भी करता है। री-रैंडमाइज़ किया गया मतपत्र on-chain बिल्कुल अलग दिखता है, पर डिक्रिप्ट होने पर वही वोट निकलता है। ओवरराइट और रिफ़्रेश एक ही फ़ॉर्मेट में, क्रम से छाँटकर और बिना किसी लेबल के प्रकाशित होते हैं। देखने वाले को स्लॉटों का एक बैच बदलता दिखता है, और प्रकाशित डेटा से वह नहीं बता सकता कि इनमें से कौन-से दोबारा डाले गए वोट हैं।
तालिका में इसकी लागत n = 2 पर हर 128 मतपत्र वाले बैच में करीब 1.6 सेकंड और n = 16 पर करीब 5 सेकंड है। बदले में यह मिलता है कि वोट खरीदने वाला यह पक्का नहीं कर सकता कि जिस वोट के उसने पैसे दिए, वह अपनी जगह बना रहा। हमें यह सौदा सस्ता लगता है।
पेपर eprint.iacr.org/2026/2282 पर है। सेक्शन 6 में इंप्लीमेंटेशन का ब्योरा और बेंचमार्क हैं; सेक्शन 5 में सुरक्षा विश्लेषण है, जिसमें यह औपचारिक कथन भी शामिल है कि चुपचाप वोट बदलना क्या-क्या छिपाता है।
कोड खुला है:
अगर छात्र सिर्फ़ अपने विश्वविद्यालय के पहचान पत्र से किसी बाध्यकारी चुनाव में वोट डाल सकें, वह भी पूरी गोपनीयता और सत्यापन क्षमता के साथ और बिना कुछ डाउनलोड किए, तो कैसा हो? UPC और DAVINCI प्रोटोकॉल ने ठीक यही कर दिखाया। पूरा केस स्टडी अब उपलब्ध है।
Lucas
पढ़ने में 6 मिनट
Vocdoni ने एक नया DKG प्रोटोकॉल तैयार किया है, जो डिज़ाइन से ही नॉन-इंटरैक्टिव है, व्यवहार में संचालन के स्तर पर एसिंक्रोनस है, और मानक क्रिप्टोग्राफ़िक प्रिमिटिव से बना है।
Jordi Pinyana
पढ़ने में 7 मिनट
पिछले कुछ सालों से Vocdoni ने मतदान Vochain पर चलाया है, जो खास मतदान के लिए गढ़ी गई हमारी L1 blockchain है। हर blockchain की तरह इसने भी हमें एक बड़ी ताकत दी:…
Pau Escrich
पढ़ने में 5 मिनट