Open Poker की Evidence Layer के पीछे इंजीनियरिंग विकल्प

Open Poker का Digital Evidence integration एक इंजीनियरिंग विचार पर बना है: proof को hand records मजबूत करने चाहिए, पर वह critical poker path का हिस्सा नहीं बनना चाहिए। हम चाहते थे कि पूरे हुए hands को Constellation Digital Evidence के जरिए सत्यापित किया जा सके, लेकिन proof API, network delay या finalization wait यह तय न करे कि hand पूरा हो सकता है या pot दिया जा सकता है।

खुलासा: मैं openpoker.ai का संस्थापक हूं। यह दो पोस्ट की श्रृंखला का Part 2 है। Part 1 उत्पाद का कारण समझाता है; यह पोस्ट code walkthrough बने बिना इंजीनियरिंग विकल्प समझाती है।

Part 1: Product - Open Poker Constellation Digital Evidence क्यों इस्तेमाल करता है।

Part 2: Engineering - evidence layer के पीछे डिजाइन विकल्प: हम proof कब बनाते हैं, क्या hash करते हैं, क्या निजी रहता है और verification स्वतंत्र कैसे रहता है।

मुख्य बातें

• Open Poker hand result के database में commit होने के बाद ही evidence का काम शुरू करता है।
• Document hash सार्वजनिक hand payload के deterministic JSON पर SHA-256 है।
• स्थानीय evidence states स्पष्ट हैं: pending, submitted, finalized या error।
• Hand page status, document hash, fingerprint, explorer link और verification के लिए जरूरी canonical payload दिखाता है।

डिजाइन लक्ष्य

Evidence layer को एक साथ दो जरूरतें पूरी करनी थीं: hand-history में छेड़छाड़ दिखाने के लिए पर्याप्त मजबूत होना और इतना साधारण होना कि पोकर हैंड खेलने का तरीका कभी न बदले।

इससे एक सरल सीमा निकली। Open Poker गेम चलाता है, हैंड सेव करता है और सार्वजनिक hand page दिखाता है। Database commit के बाद एक background evidence service fingerprint बनाती है और उसे Constellation Digital Evidence को भेजती है। Proof में देरी हो तो भी hand मौजूद है। Proof विफल हो तो भी hand मौजूद है। Proof finalize हो जाए तो hand को मजबूत सार्वजनिक रिकॉर्ड मिलता है।

यह सीमा integration का सबसे महत्वपूर्ण इंजीनियरिंग निर्णय है।

Proof pipeline

Pipeline जानबूझकर छोटी रखी गई है।

पहले hand पूरा होता है और Open Poker परिणाम सेव करता है। फिर हम saved data से सार्वजनिक hand payload बनाते हैं: board cards, सार्वजनिक रूप से दिखे cards, winners, actions, stack movement, hand number, table ID और timestamps।

फिर उस payload को sorted keys और बिना अतिरिक्त whitespace वाले deterministic JSON में बदला जाता है। Deterministic होना महत्वपूर्ण है, क्योंकि proof तभी उपयोगी है जब एक ही hand data हमेशा एक जैसे bytes दे। यह वही सामान्य समस्या है जिसे IETF की JSON Canonicalization Scheme संबोधित करती है (RFC 8785), लेकिन Open Poker का local document hash पूर्ण RFC 8785 compatibility का दावा नहीं करता। उन bytes को SHA-256 से hash किया जाता है, जो NIST द्वारा परिभाषित Secure Hash Standard family का सदस्य है (FIPS 180-4)। इससे document hash बनता है, जिसे उपयोगकर्ता बाद में फिर से compute कर सकते हैं।

फिर Constellation के documented submit-and-verify model के अनुसार fingerprint Constellation Digital Evidence के जरिए submit होता है (developer docs, find and verify docs)। Open Poker hand के साथ proof status और explorer link सेव करता है, ताकि hand page दिखा सके कि रिकॉर्ड pending, submitted, finalized या errored है।

पूरा ढांचा यही है: saved hand, public payload, deterministic hash, external fingerprint, visible proof।

हम सार्वजनिक hand data को hash क्यों करते हैं

पोकर में privacy की ऐसी समस्या है जिसे कई "put it on-chain" विचार नजरअंदाज करते हैं: छिपी जानकारी खेल का हिस्सा है। यदि कोई proof system folded hole cards लीक कर देता है, तो उसने उत्पाद को खराब किया है।

Open Poker छिपे गेम को नहीं, सार्वजनिक रिकॉर्ड को hash करता है। Evidence payload का उद्देश्य उस चीज से मेल खाना है जो hand review सुरक्षित रूप से दिखा सकती है: public actions, public cards, winners और stack changes। इसमें folded hole cards, API keys, private agent IDs या internal owner state शामिल नहीं होते।

इससे हमें वही गुण मिलता है जिसकी वास्तव में जरूरत है। कोई डेवलपर यह सत्यापित कर सकता है कि सार्वजनिक hand record को चुपचाप बदला नहीं गया, और Open Poker को ऐसी जानकारी प्रकाशित करने की जरूरत भी नहीं पड़ती जो छिपी रहनी चाहिए।

यह hand save होने के बाद क्यों चलता है

Evidence layer persistence के बाद शुरू होती है क्योंकि proof को वास्तविक रिकॉर्ड का संदर्भ देना चाहिए। यदि hand save नहीं होता, तो proof करने के लिए कोई स्थिर सार्वजनिक hand history नहीं है।

यह क्रम game loop की भी रक्षा करता है। Hand पूरा होने से पहले proof service की प्रतीक्षा नहीं करता। Open Poker पहले परिणाम रिकॉर्ड करता है, फिर background में evidence का काम होता है।

इससे integration production में होने वाली सामान्य विफलताओं के प्रति मजबूत बनता है:

• बाहरी API धीमी हो सकती है।
• Finalization में समय लग सकता है।
• non-production environment में credentials मौजूद नहीं हो सकते।
• Hand result बदले बिना retry हो सकता है।

इनमें से किसी का भी असर pot सही तरीके से दिए जाने पर नहीं होना चाहिए।

हम local evidence state क्यों रखते हैं

Open Poker local evidence record रखता है क्योंकि उपयोगकर्ताओं को black box नहीं, स्पष्ट status चाहिए। रिकॉर्ड pending, submitted, finalized या error हो सकता है। यदि hand पूरा होने पर evidence disabled था, तो evidence record बिल्कुल भी नहीं हो सकता, जो proof होने का दिखावा करने से अलग बात है।

यही state UI को ईमानदार रहने देती है। Pending proof को pending कहना चाहिए। Finalized proof में explorer link दिखना चाहिए। Missing proof के मौजूद होने का ढोंग नहीं होना चाहिए।

Local record Open Poker को self-verification के लिए document hash और canonical payload रखने की जगह भी देता है। External proof उपयोगी है, लेकिन उपयोगकर्ता को hash फिर से compute करने के लिए सटीक payload bytes भी चाहिए।

यह retry behavior को भी स्पष्ट बनाता है। Pending submissions saved hand बदले बिना retry हो सकती हैं, submitted fingerprints को finalization तक poll किया जा सकता है और समाप्त retries error state बन सकती हैं जिसे UI ईमानदारी से दिखा सके।

UI क्यों महत्वपूर्ण है

अधिकांश उपयोगकर्ता API response नहीं पढ़ेंगे या fingerprint सीधे inspect नहीं करेंगे। Proof वहीं दिखना चाहिए जहां प्रश्न उठता है: hand page पर।

Hand detail view में status, fingerprint, document hash, confirmation time, Constellation explorer link और संक्षिप्त "कैसे verify करें" प्रक्रिया दिखती है। इसमें document hash बनाने के लिए इस्तेमाल किया गया canonical payload भी दिखाया जा सकता है। इससे evidence layer केवल backend की तकनीकी व्यवस्था नहीं रहती, बल्कि उपयोगकर्ता के काम आने वाला product feature बनती है।

UI का एक काम है: verification को ठोस महसूस कराना। आपको hand देख पाना चाहिए, proof मौजूद देखना चाहिए, explorer खोलना चाहिए और समझना चाहिए कि hash किसका प्रतिनिधित्व करता है।

यहां independent verification का क्या अर्थ है

Independent verification का अर्थ यह नहीं कि Open Poker पूरी तरह trustless हो जाता है। इसका अर्थ यह है कि सार्वजनिक hand payload को हमारे database के बाहर एक cryptographic commitment के विरुद्ध जांचा जा सकता है।

Verification का विचार है:

1. सार्वजनिक hand payload प्राप्त करें।
2. Canonical payload को hash करें।
3. उसकी तुलना Open Poker के दिखाए document hash से करें।
4. Constellation Digital Evidence पर fingerprint जांचें।

Commitment के बाद यदि public hand payload बदलता है, तो hash बदलता है। इससे चुपचाप किए गए edits का पता लगाया जा सकता है।

यह सीमित दावा है, लेकिन उपयोगी है क्योंकि इसका परीक्षण किया जा सकता है।

हमने जानबूझकर क्या नहीं किया

हमने Digital Evidence को gameplay dependency नहीं बनाया। Proof layer को यह तय नहीं करना चाहिए कि hand पूरा हो सकता है, बॉट कार्रवाई कर सकता है या river card बांटा जा सकता है।

हमने private game state प्रकाशित करना भी नहीं चुना। अधिक data हमेशा बेहतर proof नहीं होता। पोकर में गलत data भविष्य के hands की integrity को नुकसान पहुंचा सकता है।

और हमने feature को crypto knowledge पर निर्भर नहीं बनाया। उपयोगकर्ता को एक hash, एक status और एक explorer link दिखता है। किसी डेवलपर के लिए trust model समझने को इतना काफी है, और उसे हर internal implementation detail जानने की जरूरत नहीं पड़ती।

Builders के लिए सीख

यदि आप किसी app में evidence या notarization जोड़ रहे हैं, तो यह pattern फिर से इस्तेमाल किया जा सकता है:

1. वह रिकॉर्ड चुनें जिस पर उपयोगकर्ताओं को सच में भरोसा करना है।
2. सार्वजनिक payload को सावधानी से परिभाषित करें।
3. Hash करने से पहले payload को deterministic बनाएं।
4. Fingerprint को अपने primary database के बाहर commit करें।
5. Proof layer को critical runtime path से दूर रखें।
6. उपयोगकर्ताओं को परिणाम सत्यापित करने का दृश्य तरीका दें।

मुख्य बात संयम है। Evidence systems तब सबसे अच्छे काम करते हैं जब दावा सीमित हो, सीमा स्पष्ट हो और verification path समझाना आसान हो।

Open Poker के लिए दावा यह है: पूरा हुआ hand fingerprint होने के बाद, सार्वजनिक hand record को verification तोड़े बिना चुपचाप बदला नहीं जा सकता।

यही इंजीनियरिंग की कहानी है। Code उस दावे को सहारा देने के लिए है, feature को जरूरत से ज्यादा जटिल दिखाने के लिए नहीं।

इंजीनियरिंग संदर्भ

ऊपर दिए इंजीनियरिंग विकल्प कुछ बाहरी standards और product docs पर आधारित हैं:

• Evidence submission और verification model के लिए Constellation Digital Evidence developer docs।
• SDK-आधारित fingerprint creation और submission के लिए Constellation sign-and-submit docs।
• सार्वजनिक lookup और explorer behavior के लिए Constellation find-and-verify docs।
• Cryptographic workflows में deterministic JSON क्यों महत्वपूर्ण है, इसके लिए RFC 8785।
• SHA-256 को शामिल करने वाले Secure Hash Standard family के लिए NIST FIPS 180-4।

FAQ

Hand के दौरान notarize क्यों नहीं करते?

क्योंकि proof को gameplay धीमा या बाधित नहीं करना चाहिए। Open Poker पहले hand save करता है, फिर background में evidence बनाता है। इससे proof layer live game loop से अलग रहती है।

वास्तव में क्या verify हो रहा है?

सार्वजनिक hand payload: actions, public cards, winners, stack movement, hand IDs और timestamps। Private folded cards और internal secrets proof का हिस्सा नहीं हैं।

क्या finalized proof का अर्थ है कि poker engine में कोई bug नहीं था?

नहीं। इसका अर्थ है कि committed public hand record को बाद की छेड़छाड़ के लिए जांचा जा सकता है। Engine correctness अब भी tests, monitoring, replay और review पर निर्भर है।

यदि proof service बंद हो तो क्या होता है?

Hand फिर भी पूरा होता है और review किया जा सकता है। Evidence submission background में retry कर सकती है और यदि retries समाप्त हो जाएं तो evidence record gameplay रोकने के बजाय error state में जा सकता है।

Constellation Digital Evidence क्यों इस्तेमाल करें?

यह Open Poker को पूरे हुए hand records के लिए external fingerprint और public lookup path देता है। हमें ठीक यही बुनियादी भरोसा चाहिए था: पूरे गेम को chain पर ले जाए बिना सत्यापित किया जा सकने वाला evidence।

दूसरे डेवलपर को क्या अपनाना चाहिए?

इसमें तय की गई सीमा अपनाएं। पहले अपना प्रमाणिक record save करें, deterministic public payload को hash करें, proof को asynchronous तरीके से submit करें और verification result वहीं दिखाएं जहां उपयोगकर्ता रिकॉर्ड की समीक्षा करते हैं।