एक हैश कमिटमेंट क्या साबित करता है, और तीन चीजें जो यह नहीं कर सकता

ट्रिक, एक पैराग्राफ में

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

वह एक कमिटमेंट स्कीम है, और यह "provably fair" की पूरी क्रिप्टोग्राफिक सामग्री है। हाउस एक सर्वर सीड उत्पन्न करता है, इसके SHA-256 हैश को प्रकाशित करता है, सीड से प्राप्त राउंड खेलता है, और जब जोड़ी सेवानिवृत्त हो जाती है तो सीड को प्रकट करता है। बाकी सब कुछ प्लंबिंग है।

ENGINE-VERIFIED_shared/seedApi.ts: getRandomKey {serverSeedHashed, clientSeed, nonce} लौटाता है; renewRandomKey एक ताज़ी जोड़ी के साथ previousServerSeed और previousServerSeedHashed, प्रकाश लौटाता है। _shared/SeedPanel.tsx फील्ड को "server seed (sha-256 commitment)" के रूप में लेबल करता है। _shared/rng.ts: sha256Hex() फिंगरप्रिंट की गणना करता है और hmacSha256Utf8() प्रति-राउंड हैश की गणना करता है, इस टिप्पणी के साथ कि डेमो इंजन "verifier उपयोग करता है उसी primitives के साथ परिणाम GENERATES करता है — एक कार्यान्वयन, इसलिए डेमो वेरिफायर स्वीकार करता है उससे कभी नहीं हटता"।

तीन चीजें जो यह साबित करता है

वह क्या कमिटमेंट स्थापित करता है, और आप प्रत्येक को कैसे जांचते हैं

सभी तीन जांचें स्थानीय हैं: उन्हें प्रकट की गई सीड, आपकी क्लाइंट सीड, नॉन्स और व्युत्पत्ति कोड की आवश्यकता है, और जांच के समय हाउस से कुछ नहीं।

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

ENGINE-VERIFIED_shared/demoLocal.ts: uAt() per-round number को u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)) के रूप में derive करता है, जिसे server पर RandomUtils.generateHash से match करने के रूप में described किया गया है; _shared/rng.ts HMAC के पहले सात bytes को [0, 1) में एक uniform number में turn करता है "server के Long→Double rounding bit-for-bit को match करते हुए"। फिर प्रत्येक game का derive module उस number को एक roll, एक card या एक multiplier में map करता है।

The verification walkthrough एक real round पर सभी तीन steps करता है। अगर आपने कभी ऐसा नहीं किया है, तो एक बार करें; scheme का point यह नहीं है कि आप हर round check करें बल्कि यह है कि आप किसी भी round को check कर सकते हैं, और house advance में नहीं बता सकता कि कौन सा।

Three things it cannot prove

It cannot prove the seed was random. एक commitment एक seed को pin down करता है; यह कुछ भी नहीं कहता कि seed को कैसे choose किया गया। अगर house आपके client seed को जानता था जब उसने server seed generate किया, तो वह principle में seeds generate कर सकता था जब तक कि उसे ऐसा नहीं मिल गया जिसके पहले rounds उसे पसंद आए, और उस पर commit कर दे। Hash perfectly check out करेगा। Standard defence ordering है: server seed पहले commit होता है, और client seed बाद में set होता है, इसलिए जो भी house ने commit किया, वह नहीं जानता था कि इसे किसके साथ combine किया जाएगा।

वह ordering है जहाँ इस site के panel के पास एक boundary है जो plainly state करने लायक है। यहाँ एक client seed set करना current server seed को जगह में नहीं छोड़ता; यह pair को rotate करता है, और नया server seed उसी request द्वारा generate होता है जो आपके नए client seed को carry करता है। Client से यह दिखाना संभव नहीं है कि नया seed request को read करने से पहले fixed था। क्या server अगला seed pre-generate करता है, जैसा कि कुछ operators अगले commitment को advance में publish करके करते हैं, client के API में visible नहीं है, और check करने के लिए कोई "next server seed hash" field नहीं है। यह game team के पास raise किया गया है, और fix एक छोटा सा है: अगला server seed commit करें उसके client seed को accept करने से पहले जो इसके साथ pair होगा, और उस commitment को panel में show करें।

ENGINE-VERIFIED_shared/seedApi.ts: setClientSeed(clientSeed) नए client seed के साथ renewRandomKey को call करता है और nonce 0 पर एक fresh pair return करता है; rotate() seed के बिना उसी endpoint को call करता है। IHouseSeed serverSeedHashed, clientSeed और nonce को carry करता है, साथ ही rotation पर पिछला pair; कोई भी next-seed commitment type में present नहीं है।

तब तक, defence का practical version वह है जो scheme आपको हर दूसरे respect में देता है: reveal। एक house जो आपके client seed के against seeds को grind करता था वह भी हर rotation पर हर seed को reveal करना पड़ता, और हर round इसके under को recompute किया जा सकता है। जो boundary का मतलब है वह यह है कि एक suspicious streak seed change के बाद के पहले rounds में hash अकेले द्वारा rule out नहीं किया जा सकता; इसे केवल examine किया जा सकता है, round by round, reveal के बाद।

It cannot prove the game is fair in the other sense. "Provably fair" का मतलब randomness honest था, न कि odds even हैं। एक dice game perfectly verifiable हो सकता है और फिर भी design द्वारा 99% return कर सकता है; edge payout table में रहता है, जो एक published number और एक separate promise है। The ethics of the house edge उस promise के बारे में है। Commitment इस पर silent है।

It proves nothing about rounds nobody checks. Scheme एक deterrent है, guarantee नहीं। एक round जिसे आप कभी recompute नहीं करते वह एक round है जिसे आपने trust पर लिया है, बिल्कुल जैसा आप कहीं भी करेंगे; जो changes है वह यह है कि trust optional है, और house नहीं जान सकता कि आप इसे कब exercise करेंगे। यह एक shuffling machine से एक बड़ी improvement है जिसे आप अंदर नहीं देख सकते, और शब्द "proof" से suggest करने वाले से एक छोटी।

Hash randomness के लिए एक receipt है। यह game के लिए certificate नहीं है।the sentence to remember

What would prove more

• A pre-committed next seed. अगले server seed का hash publish करना किसी भी client seed को इसके साथ pair होने से पहले ordering gap को ऊपर बंद करता है। यह एक ही change है जो panel को prove करने देगा कि seed fixed था इससे पहले कि आपका input known हो।
• A public source of randomness. एक beacon को mix करना जिसे कोई control नहीं करता, जैसे कि drand network, पूरे सवाल को remove करता है कि seed को किसने choose किया; inside drand describe करता है कि यह कैसे काम करता है और इसकी cost क्या है।
• A published derivation, kept public. पहले से ही यहाँ case है, और सबसे आसानी से खोया जाने वाला हिस्सा जब एक client rewrite होता है। Verifier केवल उतना ही honest है जितना code यह run करता है।

ये changes नहीं करते कि hash क्या है। ये changes करते हैं कि hash किसका fingerprint है, और कब। Scheme काफी simple है कि इसकी limits भी simple हैं, और एक player जो तीन things को जानता है जो यह prove करता है वह एक better position में है जिसे बताया गया है कि यह सब कुछ prove करता है।

FAQ

What is a hash commitment in a provably fair casino?

House के secret server seed की SHA-256 fingerprint, play से पहले दिखाई गई और seed को check किया गया जब यह reveal होता है। यह prove करता है कि seed आपके bets से पहले fixed था और वह revealed seed वह है जो committed है।

Does a matching hash prove the game was fair?

यह prove करता है कि randomness को commitment के बाद alter नहीं किया गया और, एक published derivation के साथ, कि प्रत्येक result seed pair से follow करता है। यह prove नहीं करता कि seed को randomly choose किया गया, और यह house edge के बारे में कुछ नहीं कहता, जो एक separate published number है।

क्या हाउस एक सर्वर सीड चुन सकता है जो इसके अनुकूल हो?

केवल अगर वह क्लाइंट सीड को जानता हो जिसके साथ सर्वर सीड को जोड़ा जाएगा जब वह चुनता है। रक्षा सर्वर सीड को कमिट करना है इससे पहले कि क्लाइंट सीड सेट हो। इस साइट पर एक क्लाइंट सीड परिवर्तन उसी अनुरोध में जोड़ी को घुमाता है, ताकि क्लाइंट से क्रम की पुष्टि न की जा सके; लेख सीमा और प्रस्तावित सुधार का वर्णन करता है।

मैं एक राउंड की जांच स्वयं कैसे कर सकता हूं?

सीड को घुमाकर सेवामुक्त सर्वर सीड को प्रकट करें, इसे हैश करें यह पुष्टि करने के लिए कि यह आपको दिखाई गई प्रतिबद्धता से मेल खाता है, फिर आपके क्लाइंट सीड, नॉन्स और कर्सर पर सर्वर सीड के HMAC-SHA256 की पुनः गणना करें, और परिणाम को गेम के प्रकाशित डेरिवेशन के माध्यम से पास करें। सीड पैनल आपके ब्राउजर में पुनः गणना करता है।

डेरिवेशन कोड महत्वपूर्ण क्यों है?

क्योंकि हैश केवल सीड को पिन करता है। सीड को एक रोल या कार्ड में बदलना एक फंक्शन है, और जब तक वह फंक्शन सार्वजनिक न हो तब तक मेल खाने वाला हैश आपको यह नहीं बताता कि परिणाम वह था जो सीड ने दर्शाया। यहां क्लाइंट वही डेरिवेशन भेजता है जिसे डेमो परिणाम उत्पन्न करने के लिए उपयोग करता है।

क्या provably fair लाइसेंस प्राप्त RNG ऑडिट से बेहतर है?

वे अलग-अलग प्रश्नों का उत्तर देते हैं। एक ऑडिट कई ड्रॉ पर जनरेटर के सांख्यिकीय व्यवहार को प्रमाणित करता है; एक प्रतिबद्धता आपको एक विशिष्ट राउंड की तथ्य के बाद जांच करने देती है। न तो दूसरे को प्रतिस्थापित करता है, और न ही कोई भी हाउस एज को बदलता है।

स्रोत और संदर्भ

• विकिपीडिया — प्रतिबद्धता योजना: छिपाना और बाध्यकारी, और हैश-आधारित प्रतिबद्धताएं
• विकिपीडिया — HMAC: कुंजीयुक्त हैशिंग और इसका pseudorandom फंक्शन के रूप में उपयोग
• Betkyo engine source: _shared/seedApi.ts (commit, reveal and rotation), _shared/rng.ts (sha256Hex, hmacSha256Utf8, the 7-byte uniform), _shared/demoLocal.ts (uAt derivation), _shared/SeedPanel.tsx

इस लेख में गेमDice — नियम और मुक्त खेल →Limbo — नियम और मुक्त खेल →