ZK Color Sort ज़ीरो-नॉलेज प्रूफ़ से दैनिक पहेली स्कोर को ऑन-चेन सत्यापित करता है

2026-08-19

gaming · zero-knowledge · smart-contracts · mainnet · puzzle · discovery · web · updated

ZK Color Sort ज़ीरो-नॉलेज प्रूफ़ से दैनिक पहेली स्कोर को ऑन-चेन सत्यापित करता है

क्रिप्टोग्राफिक स्कोरबोर्ड वाली एक दैनिक पहेली

ZK Color Sort उस कलर-पोरिंग पहेली जैसा दिखता है जिसे आप कॉफी का इंतज़ार करते हुए फोन पर खेलते हैं: बारह ट्यूब, दस रंग, तब तक डालते रहें जब तक हर ट्यूब में एक ही रंग न हो जाए। असली मोड़ वह है जो पूरा होने के बाद पेज मांगता है। 'इस सुविधा को अनलॉक करने के लिए अपना Algorand वॉलेट कनेक्ट करें,' यह 'Scores' बटन और मूव काउंटर के बगल में लिखा होता है। यह कोई पेवॉल नहीं है। एक समर्थित वॉलेट — फिलहाल Lute या Pera — कनेक्ट करना गेम के असली मकसद का प्रवेश द्वार है: अपना स्कोर एक Algorand मेननेट स्मार्ट कॉन्ट्रैक्ट पर ज़ीरो-नॉलेज प्रूफ़ के साथ जमा करना, यानी एक क्रिप्टोग्राफिक प्रमाणपत्र जो बिना पीछे के डेटा उजागर किए किसी दावे की सच्चाई साबित करता है। यहाँ दावा है 'मैंने इस विशिष्ट पहेली को N चालों में हल किया,' और निजी रखा गया डेटा स्वयं चालों का क्रम है। पहेली खेलने के लिए किसी वॉलेट की ज़रूरत नहीं है; प्रूफ़-गेटेड स्कोरबोर्ड ऑन-चेन परत है।

दिन की पहेली खुद चेन से ली जाती है। फ्रंटएंड Algorand इंडेक्सर से UTC मध्यरात्रि के बाद पहला ब्लॉक हेडर पूछता है और उस हेडर के सीड से बोर्ड को नियतात्मक रूप से निकालता है, इसलिए चुनौती सार्वजनिक होती है और चेन के इतिहास से पुनरुत्पादित की जा सकती है, न कि किसी डेवलपर द्वारा चुनी गई। नियम मानक Color Sort प्रारूप का पालन करते हैं, जिन्हें प्रोजेक्ट के README में सटीक रूप से दर्ज किया गया है: चार की क्षमता वाली बारह ट्यूब; दस रंग जिनमें से प्रत्येक ठीक चार बार आता है; डालने के लिए दो खाली ट्यूब; एक वैध चाल एक ही रंग की अधिकतम सन्निहित श्रृंखला को खाली ट्यूब या उस ट्यूब पर डालती है जिसका ऊपरी रंग मेल खाता है; पहेली हल हो जाती है जब हर गैर-खाली ट्यूब पूरी तरह से एकरंगी हो। स्कोर चालों की संख्या है, कम बेहतर है, और स्थानीय सर्वश्रेष्ठ स्कोर अपने पूर्ण चाल इतिहास के साथ ब्राउज़र localStorage में रहते हैं। ऑन-चेन रजिस्ट्री कभी भी ऐसा स्कोर स्वीकार नहीं करती जो खिलाड़ी के स्वयं के दर्ज सर्वश्रेष्ठ से बेहतर न हो।

ज़ीरो-नॉलेज प्रूफ़ वास्तव में क्या साबित करता है

किसी भी कौशल-आधारित गेम के ऑन-चेन लीडरबोर्ड के लिए एक विश्वसनीयता समस्या है: एक कॉन्ट्रैक्ट जो एक संख्या स्वीकार करता है, वह कोई भी संख्या स्वीकार करेगा। एक विश्वसनीय सर्वर जो खेल को मान्य करता है, वह केंद्रीकरण को फिर से लाता है, और विजेता समाधान प्रकाशित करने से उस रणनीति का पता चल जाता है जिसने उसे बनाया। ZK Color Sort तीसरा रास्ता आज़माता है — इसे साबित करो, दिखाओ मत।

जब कोई खिलाड़ी सबमिट करता है, तो ब्राउज़र snarkjs (ओपन-सोर्स JavaScript प्रूफ़िंग लाइब्रेरी) के माध्यम से Circom सर्किट चलाता है और एक Groth16 प्रूफ़ तैयार करता है, जो सबसे व्यापक रूप से उपयोग की जाने वाली ज़ीरो-नॉलेज योजनाओं में से एक है। पहली सबमिशन पर लगभग 55 MB की प्रूफ़िंग की डाउनलोड होती है, जिसे गेम एक स्टैटिक एसेट के रूप में देता है; इसके बाद पूरी प्रक्रिया क्लाइंट-साइड चलती है, गेम के पीछे कोई प्रूफ़िंग सर्वर नहीं होता। स्टैक का चुनाव जानबूझकर है: snarkjs-algorand लाइब्रेरी का README नोट करता है कि gnark, जो वैकल्पिक AlgoPlonk वेरिफायर के पीछे का कंपाइलर है, WebAssembly का समर्थन नहीं करता, जो ब्राउज़र में प्रूफ़ जनरेशन को असंभव बना देता — snarkjs TypeScript में है और वहीं चलता है जहाँ खिलाड़ी है।

सर्किट इस गेम के सटीक प्रोफ़ाइल के अनुरूप है — बारह ट्यूब, चार की क्षमता, अधिकतम 120 चालें, दस रंग, दो खाली ट्यूब — और पूर्ण गेम शब्दार्थ लागू करता है: एक वैध प्रारंभिक बोर्ड, उपरोक्त डालने के नियमों के तहत वैध चालें, हर चाल के बाद सही अवस्था परिवर्तन, पूरी तरह से हल किया गया अंतिम बोर्ड, और सक्रिय चालों की संख्या के बराबर चाल गणना। क्या सार्वजनिक है और क्या निजी रहता है, यही पूरा डिज़ाइन है:

अवधारणा	वास्तविक दुनिया में मतलब
सार्वजनिक: प्रारंभिक बोर्ड	कोई भी पुष्टि कर सकता है कि स्कोर किस पहेली से संबंधित है
सार्वजनिक: चाल गणना	रजिस्ट्री में संग्रहीत संख्या और लीडरबोर्ड रैंकिंग
सार्वजनिक: पहेली पहचान और वॉलेट पता	प्रूफ़ में बंधे होते हैं, इसलिए एक पहेली या एक खाते के लिए जारी प्रूफ़ को दूसरे के लिए दोबारा इस्तेमाल नहीं किया जा सकता
निजी: पूर्ण चाल अनुक्रम	पर्यवेक्षक विजेता रणनीति की नकल किए बिना दावे को सत्यापित कर सकते हैं — यह ऑन-चेन पहेली लीडरबोर्ड की सामान्य मौत है

ऑन-चेन स्कोर रजिस्ट्री

प्राप्त करने वाला पक्ष PuzzleScores नाम का एक स्मार्ट कॉन्ट्रैक्ट है, जो Algorand TypeScript में लिखा गया है — यह आधुनिक Puya-संकलित कॉन्ट्रैक्ट भाषा है जिसने पुराने PyTeal की जगह ली है। यह प्रत्येक (पहेली, वॉलेट) जोड़ी के लिए एक स्कोर ऐप बॉक्स स्टोरेज में रखता है — यानी कॉन्ट्रैक्ट से जुड़ी की-वैल्यू स्थिति। कुंजी 20-बाइट पहेली कोड है जिसमें 32-बाइट वॉलेट पता जोड़ा जाता है (कुल 52 बाइट); मान एक एकल बाइट है, जो संग्रहीत स्कोर को 255 चालों तक सीमित करता है, जो इस पहेली के किसी भी समाधान के लिए आवश्यकता से कहीं अधिक है। एक प्रविष्टि बनाने पर सटीक बॉक्स न्यूनतम-बैलेंस आवश्यकता खर्च होती है, जिसे कॉन्ट्रैक्ट रनटाइम पर निकालता है (2,500 microALGO आधार और 400 प्रति बाइट) और यदि खिलाड़ी removeScore के माध्यम से प्रविष्टि हटाता है तो वापस कर देता है। केवल-पठन विधियाँ खिलाड़ी को अपना या किसी और का स्कोर प्राप्त करने देती हैं।

दो लेखन पथ हैं: पहली प्रविष्टि के लिए addScore, और updateScore, जिसे कॉन्ट्रैक्ट केवल तभी स्वीकार करता है जब नया स्कोर संग्रहीत स्कोर से सख्ती से कम हो। दोनों को एक ही परमाणु समूह में एक साथ 'वेरिफायर' लेनदेन की आवश्यकता होती है, और यहीं पर प्रूफ़ की वास्तव में जाँच होती है। फ्रंटएंड तीन लेनदेनों का एक समूह बनाता है — एक शून्य-मूल्य भुगतान जो लॉजिक-सिग्नेचर खाते (ऐसा खाता जिसका अधिकार निजी कुंजी के बजाय एक प्रोग्राम होता है, जो गेम की सत्यापन कुंजी से व्युत्पन्न होता है) द्वारा हस्ताक्षरित होता है, न्यूनतम-बैलेंस भुगतान, और ऐप कॉल। कॉन्ट्रैक्ट सत्यापित करता है कि प्रमाणन भुगतान कॉन्फ़िगर किए गए वेरिफायर पते से आता है और प्रूफ़ के सार्वजनिक सिग्नल दावे किए गए स्कोर, पहेली कोड और प्रेषक से मेल खाते हैं; Groth16 सत्यापन गणित स्वयं लॉजिक-सिग्नेचर प्रोग्राम के अंदर चलता है, जो केवल तभी प्रमाणन भुगतान उत्पन्न करता है जब वह विटनेस को स्वीकार करता है। क्योंकि खिलाड़ी का स्कोर, पहेली और वॉलेट सभी एक ही प्रूफ़ में बंधे होते हैं, एक पहेली या एक खाते के लिए उत्पन्न सबमिशन को दूसरे के लिए पुनर्चक्रित नहीं किया जा सकता। फ्रंटएंड पर, वही बॉक्स स्टोर एक प्रतिशतक दृश्य को शक्ति देता है: कनेक्ट करने के बाद, गेम दिन की पहेली के लिए ऑन-चेन प्रविष्टियों को स्कैन करता है और खिलाड़ी को बताता है कि उन्होंने कितने अन्य लोगों को पीछे छोड़ा।

मेननेट पर लाइव — लेकिन कौन खेल रहा है?

कॉन्ट्रैक्ट वास्तविक, तैनात और वर्तमान है: एप्लिकेशन 3603459425 को राउंड 62,209,315 पर 16 जून, 2026 को प्रोजेक्ट के पीछे के खाते (जो .algo नाम tools.orange.algo का मालिक है) द्वारा बनाया गया था, और इसका वेरिफायर कुछ मिनटों बाद कॉन्फ़िगर किया गया। अब इसमें 94 स्कोर बॉक्स हैं, और बहीखाता राउंड 64,130,520 — 16 अगस्त, 2026, इस लेखन से दो दिन पहले — तक के ऐप कॉल दिखाता है। वेब बंडल पुष्टि करता है कि फ्रंटएंड का डिफ़ॉल्ट नेटवर्क मेननेट है, जो रेपो के नेटवर्क कॉन्फ़िगर में ऐप ID से मेल खाता है।

हालाँकि, प्रेषक बहीखाता एक अधिक मामूली अपनाने की कहानी बताता है। डेवलपर का अपना वॉलेट लेनदेन लॉग और बॉक्स कुंजियों दोनों पर हावी है; एक दूसरा सबमिट करने वाला वॉलेट लॉन्च के दिन बनाया गया था और डेवलपर द्वारा 1 ALGO से वित्तपोषित किया गया था — एक परीक्षण खाता। दो और वॉलेट अपने पहले वित्तपोषण का पता 2022 और 2024 में बनाए गए असंबंधित खातों से लगाते हैं, जो बाहरी खिलाड़ियों के अनुरूप है, हालाँकि दोनों में से कोई भी .algo नाम नहीं रखता। ईमानदार पाठ: यह एक लाइव लेकिन छोटी रजिस्ट्री है, जिसमें अधिकांश प्रविष्टियाँ डेवलपर के स्वयं के परीक्षण के कारण हैं और अभी तक किसी महत्वपूर्ण खिलाड़ी आधार का कोई सबूत नहीं है।

यह प्रोजेक्ट स्वयं एक एकल डेवलपर का काम है — GitHub खाता funk-af, जिसकी प्रोफ़ाइल मालिक का नाम 'Andrew' बताती है — और वही खाता अन्य Algorand कॉन्ट्रैक्ट कार्य प्रकाशित करता है, जिसमें Baanx और Immersve flexi-card वित्तपोषण प्रोटोकॉल के लिए स्मार्ट कॉन्ट्रैक्ट के रूप में वर्णित रिपॉजिटरी शामिल हैं। गेम रेपो जून 2026 के 18 कमिट दिखाता है और 18 जून के बाद कोई गतिविधि नहीं, जबकि तैनात फ्रंटएंड और ऑन-चेन कॉन्ट्रैक्ट चलते रहते हैं।

जहाँ विश्वास मॉडल की सीमाएँ हैं

तीन चेतावनियाँ उन लोगों के लिए मायने रखती हैं जो इस रजिस्ट्री को एक गेम से अधिक मानते हैं। पहली, दैनिक-पहेली व्युत्पत्ति एक फ्रंटएंड परंपरा है, कॉन्ट्रैक्ट नियम नहीं: कॉन्ट्रैक्ट कभी जाँच नहीं करता कि प्रस्तुत पहेली कोड आज की ब्लॉक-व्युत्पन्न पहेली से मेल खाता है, और सर्किट केवल यह मान्य करता है कि एक पहेली सुगठित और हल की गई है। उसी सर्किट प्रोफ़ाइल से किसी भी सुगठित पहेली के लिए एक प्रूफ़ स्वीकार किया जाएगा; कुछ भी ऑन-चेन सबमिशन को वर्तमान तिथि से नहीं जोड़ता। दूसरी, वेरिफायर पता और कॉन्ट्रैक्ट स्वयं दोनों निर्माता-नियंत्रित हैं — setVerifier और updateApplication निर्माता के वॉलेट तक सीमित हैं — इसलिए रजिस्ट्री की अखंडता अंततः एक एकल डेवलपर पर निर्भर करती है कि वह वेरिफायर को नहीं बदलता या कॉन्ट्रैक्ट को फिर से नहीं लिखता। तीसरी, प्रूफ़िंग स्टैक अपरीक्षित है: snarkjs-algorand README चेतावनी देता है कि SDK 'एक कार्य प्रगति पर है और अभी स्थिर नहीं है' और 'इस रेपो का कोड अपरीक्षित है। अपने जोखिम पर उपयोग करें!'

इनमें से कुछ भी उस चीज़ को कम नहीं करता जो वास्तव में उल्लेखनीय है: Algorand मेननेट पर ऑन-चेन वेरिफायर को फीड करने वाली ब्राउज़र-साइड Groth16 प्रूफ़ जनरेशन का एक काम करता हुआ एंड-टू-एंड प्रदर्शन, जिसमें दैनिक पहेली चेन के अपने ब्लॉक हेडर से सीड की जाती है। यदि यह पैटर्न परिपक्व होता है — एक ऑडिटेड वेरिफायर, कॉन्ट्रैक्ट-लागू पहेली एंकरिंग, और वास्तविक खिलाड़ी — तो ZK-सत्यापित कौशल गेमिंग एक विश्वसनीय नींव वाली क्षेत्र है। फिलहाल, यह एक ईमानदार, छोटा प्रयोग है, और यह काम करता है।

स्रोत

Source: https://zk-colorsort.netlify.app/